Webflow Page Speed Performance Optimization - The Definitive Guide

This article was also published on Waveshape Collective’s Medium

Having a speedy website is incredibly important for a variety of reasons. Not only does it provide a smooth user experience, but multiple studies have concluded that just a few additional seconds in page loading speed may decrease a websites’ customer conversion, acquisition and interaction.

However, user experience is also a big factor in Googles’ decisions when it comes to ranking your website in their search index. Page speed itself was included as a factor as early as 2010.

This article goes into how you can measure the performance, understanding the performance metrics, some precautions surrounding automated performance analysis, and finally some in-depth solutions to the most common problems regarding performance in Webflow.

Webflow performance guide thumbnail

Measuring performance

While there exists multiple techniques of measuring performance of a website or page, one of the most common ways among individual developers and agencies is using automated performance analysis software like Google Lighthouse.

This is a software developed by Google that analyzes websites in a variety of categories, performance being one of them. 6 metrics are provided, all related to a web pages’ performance in some way or another.

Google Lighthouse performance

Probably the most common way of running Google Lighthouse is through an instance of a Google Chrome browser, but it can also be used through a Node package or in a terminal through its CLI.

Web vitals

A common term that’s used when talking about performance is web vitals, a set of metrics (developed by Google) measuring the quality of a web page in terms of performance.

These metrics include what’s called core web vitals, a subset of metrics that Google deems to be the most important.

The metrics

  • Total Blocking Time (30%) (CWV)
  • Largest Contentful Paint (25%) (CWV)
  • Cumulative Layout Shift (15%) (CWV)
  • First Contentful Paint (10%)
  • Speed Index (10%)
  • Time to Interactive (10%)

Google Lighthouse performance metrics

The percentages after each metric in the list represents its weight. This is the weight that’s being used when Lighthouse calculates an analyzed website’s total performance score.

As you can see, the first three metrics in the list belongs to the core web vitals. These are therefore weighted a bit higher than the rest of them.

So what does that mean? Well, it might be beneficial to focus a bit extra on the ones included in the core web vitals (at least if you trust Google (which you should)).

You can read more details about all of these metrics, and a lot more about web performance overall at Googles’ blog Web.dev.

Some precautions

While it’s easy to run your site through Lighthouse, receive a good total score and brag about it on Twitter, the score that you receive might not actually be that accurate.

As mentioned, Lighthouse can be run in multiple different ways. If you test your site through all of the previously mentioned methods, you might receive highly inconsistent results between all of them.

If running Lighthouse locally on your computer for example, the result can be affected by many things such as:

  • Slow computer hardware
  • An unstable internet connection
  • Physical distance between you and the server on which you host your website
  • Various throttling settings in Google Lighthouse
  • …and a whole lot more.

Therefore it’s recommended to test your site multiple times in succession (5–10) when using Lighthouse. This might still not provide a 100% accurate result, but will hopefully at least eliminate some of the affecting factors.

It’s also important to measure your site on both desktop as well as a simulated mobile device (which is automatically simulated by clicking the mobile button in Lighthouse when running it in a Google Chrome browser).

Google Lighthouse device choice

You would be surprised how much the results might vary between desktop and a simulated mobile device with throttled hardware and internet speeds.

The performance of Webflow

While one might feel a lack of control over the websites’ performance by developing it using a website builder such as Webflow, it’s also important to remember that Webflow actually provides quite a few performance enhancing features right out of the box.

Some examples of these features are:

  • Assets delivery through CDN’s
  • Code minification
  • Responsive image delivery
  • Video transcoding
  • CSS & Javascript clean-up features
  • Static site generating CMS
  • Responsive image delivery

Webflow responsive images

However, as your site grows larger and more complex, these features are oftentime not quite enough to ensure fast loading speeds, especially on mobile devices.

And that’s why I’ve written this guide.

Let’s go through some of the most common performance related issues in Webflow and how you can solve them (fiiinally).

1 — Imports of third party Javascript/CSS libraries

While I don’t have any data to support the following claim, I’m still absolutely sure that this is the point that causes the most issues for most Webflow users when it comes to bad performing websites. That’s why this step is on top of the list.

All code used for a website has to be downloaded, compiled and executed by the browser. While Webflow does seem to keep its native generated Javascript & CSS code fairly small, importing third party libraries can affect the performance quite a lot.

This is also (probably) the main cause of the famous minimize main thread work, reduce Javascript execution time and remove unused Javascript recommendations that quite a few Webflow users seem to have problems with.

Google Lighthouse errors

There are quite a few ways to fix this problem. Let’s go through them one by one from the most simple solutions to some more advanced techniques.

1.1 — Remove everything that’s not needed

The first question to ask yourself is if you really need all the libraries and packages that you’re importing.

Are you sure you need that typewriter effect created by a 200kb Javascript library? Do you really need to create a circular text element using Javascript? Why do you have 5 different analytics software imported?

The simplest way of battling this problem is simply to go minimalist when it comes to external libraries and packages.

Go and take a look at the file sizes of all your imported libraries and remove everything except the ones that you are absolutely 100% certain you need.

1.2 — Don’t import external scripts site-wide

Importing scripts in your site settings makes sense when using analytics or similar things that are meant to be used on every single page of your site.

However, if you’re importing some kind of animation effect that’s only really needed on your homepage, it’s definitely important to keep it in that specific page settings instead.

1.3 — Place your Javascript imports before the closing body-tag

The code of a web page is parsed from the top to the bottom by the browser. This means that if you leave your script imports in the head tag, it has to be fully downloaded and parsed before even starting to parse the actual HTML of the page.

Therefore it’s best practice to import it at the bottom of the page, unless there’s an extremely good reason not to.

Webflow page settings

1.4 — Use defer or async attributes

This is a really important point.

For every script you import, you’re able to use a couple attributes: defer or async. I won’t go into too many details, but both are used to eliminate render-blockage while loading scripts (they won’t block parsing while being downloaded).

The defer attribute

The defer attribute will download the script in the background and runs the script after all other DOM elements are built.

Defer looks something like this:

The defer attribute

The defer attribute should be used if the external script require DOM-elements, or if the order of script execution is important (scripts that waits for other scripts).

Usage of the defer attribute on scripts looks something like this:

<script defer src=”https://example.com"></script>

The async attribute

The async attribute will download the script in the background and run the script immediately when finished downloading. This means that it doesn’t care how long the download takes, but simply runs the script immediately after download.

Async looks something like this:

The async attribute

Async could be used if the script doesn’t need to access any DOM-elements and if the order of the script execution isn’t important (totally independent scripts).

Usage of the async attribute on scripts looks something like this:

<script async src=”https://example.com"></script>

2 — Asset optimization

The second (probably) most common problems has to do with all the assets that commonly are used on websites nowadays. These may consist of images, videos, fonts, animations and so on.

Every single kilobyte is counted when it comes to performance on the web. Using assets that are unnecessarily large will slowly become a huge hassle when the file sizes start to build up.

There are a lot of steps to go through with this one. Let’s take a look at each and every one of the most common asset types when it comes to building sites in Webflow.

2.1 — Images

Update 14.7 — Webflow now supports the WEBP image file type!

2.1.1 — File types

Choosing the right file type for your images is extremely important.

SVG should be used for any vector graphics you’re using. This file type is really small since it’s basically just math of points and fills and whatever else it contains.

JPG/JPEG should be used for any kind of traditional image/photograph that doesn’t need a transparent background. This format is smaller than PNG and allows for heavy compression (more on that soon).

PNG should be used for any image that needs a transparent background. Simple as that.

2.1.2 — Image compression

In case you’re not already using software capable of automatically compressing exported images (Adobe XD, Photoshop), there are a lot of free online tools that can be used to compress images without losing too much of their quality.

Image compression visualization

Some examples are TinyPNG, CompressPNG, CompressJPEG and Vecta.io for SVG.

If you are lazy and have some money to spend, there are even Webflow specific tools such as Optily that automatically compresses all uploaded images that exist in the asset panel.

Optily image compression

2.1.3 — Image sizing

Even though Webflow automatically serves responsive image sizes based on visitor screen size, you should aim to size all images as closely to their needed resolution as possible.

2.1.4 — Lazy loading

Webflow automatically sets each images’ loading setting to “lazy”, giving a faster initial page load. However, make sure not to lazy load any image above the fold as well as any initially hidden icons (in modals for example) etc.

2.1.3 — Image sizing

Even though Webflow automatically serves responsive image sizes based on visitor screen size, you should aim to size all images as closely to their needed resolution as possible.

2.1.4 — Lazy loading

Webflow automatically sets each images’ loading setting to “lazy”, giving a faster initial page load. However, make sure not to lazy load any image above the fold as well as any initially hidden icons (in modals for example) etc.

Lazy loading in Webflow

2.1.6 — Reduce use of background images

Since background images aren’t able to be given a srcset (responsive) attribute, Webflow isn’t able to create responsive versions of background images.

Therefore you should probably limit the use of background images and instead use the “real” image element.

2.2 — Videos

2.2.1 — File types

Videos on the web are recommended to be in MPEG-4 format (MP4, MV4). Make sure to export and upload them in this format.

2.2.2 — Don’t use the native video embed element

For some reason, Webflow imports some extra Javascript libraries and other strange things when using its native video embed element.

Therefore, make sure to use an actual embed element in which you’re able to paste whatever code YouTube/Vimeo/Other services gives you.

Video embed in Webflow

2.2.3 — Watch out for the video transcoding bug

I’ve noticed a mysterious bug while using Webflow’s native video transcoding feature. For some reason the size of the video increased after transcoding it, even though I’m fairly sure it should have resulted in the opposite.

Make sure to look out for this.

2.3 — Fonts

2.3.1 — Upload your fonts manually

You know how you’re able to just select a Google font (and Adobe I believe) in the site setting of your project? Yeah, don’t do that.

This will fetch the font from the Google Font CDN, creating an extra request the visitor has to do before loading the page.

Instead download the font(s) you want to use, upload them through the site settings and make sure to keep the “display: swap” setting on.

Font uploads in Webflow

2.3.2 — If possible, use system fonts All fonts have to be downloaded by the visitor, except fonts that might already be installed on their computer.

If your design allows for it, try to go with one of the commonly installed system fonts such as Arial, Verdana, Helvetica etc.

Read more about web safe fonts.

2.3.3 — Limit the amount of fonts you use

If you’re going with a third party font (Google, Adobe & others), try to limit the amount of different fonts you’re using.

The difference between having to load one font compared to five different fonts can be huge when it comes to performance.

2.3.4 — Strip your font file from unnecessary characters

This is quite the overkill performance enhancing step, but in order to keep your font files as small as possible, you’re able to use a software such as FontForge in order to strip the file from any characters not needed in a certain language.

2.4 — Lottie animations

2.4.1 — Optimize your Lottie animations

According to Jared Stanley who has written this Medium article called Improving Site Performance by Optimizing Lottie Animations, one single Lottie animation increased a pages’ DOM-elements from 600 to over 2000.

I won’t go into the Lottie optimization process since I’m no motion graphic professional, but make sure to read his article for more information.

2.5 — Preconnect assets to required origins

Now here we have a bit more complicated step in our performance optimization journey.

If you’ve every run Google Lighthouse on a web page, you might have received a “Preconnect to required origins” recommendation.

The recommendation might look something like this:

Google Lighthouse preconnect recommendation

What this means is that Lighthouse has recognized one or more domains of external assets (images, scripts, whatever) that are being loaded, and that should be prioritized when loading the page.

So how do we fix this? Well, by adding any of the following simple little lines of code to the head section of our website:

<link rel=”preconnect” href=”https://assets.website-files.com">
<link rel=”dns-prefetch” href=”https://assets.website-files.com">

Please note that if you’re using other third party CDN’s or similar, you want to add all of them as well.

You can read more details about which one to choose by going over to the article on Web.dev.

Fun fact, this is actually something that Wordpress does out of the box for any third party domains that delivers assets.

Webflow is a no-code website builder which, as any other website builder, is meant to generate code.

Now, at this moment of time I can’t recall ever seeing or using a website builder that doesn’t generate bloated code in one way or another. This includes Webflow.

However, there are quite a few web development techniques that can help us keep the code as simple and clean as possible. Let’s go through them one by one.

3.1 — Make use of Webflows’ clean-up features

Webflow has two clean-up features when it comes to cleaning up the generated code:

The unused class remover The unused interaction remover Make it a habit to use these every time you’re publishing after making some major changes to your site.

CSS clean up in Webflow

3.2 — Avoid CSS utility frameworks

This one might be a bit controversial, but utility frameworks that contain pre-made classes should probably not be used if you’re going for maximum performance and the cleanest code possible.

The reason for this is that you’re not able to use the CSS clean-up feature if you want to keep all currently unused classes for later use.

3.3 — Focus on creating reusable CSS classes

In order to keep the CSS-code as light as possible, it’s highly important to focus on creating reusable modular code (or in this case no-code).

Following some kind of design system like the Atomic Design Methodology can definitely help keeping everything structured and component based instead of creating new classes for everything.

Using class naming conventions such as BEM can also help stay structured.

BEM naming conventions in Webflow

3.4 — Reusable animations/interactions

Similar to the previous point, making sure to reuse animations and interactions between elements are crucial to keeping the Javascript code as light as possible.

3.5 — Minimize the total use of animations

You have probably seen some websites developed in Webflow that are just filled to the brim with animations and interactions on most, if not all, elements.

This is not just aesthetically unpleasing, but it also creates a huge amount of generated Javascript that needs to be downloaded and parsed when loading the page. That’s no fun.


There we have it. Quite a few steps to go through in order to improve the performance of your Webflow created websites.

Hopefully you’ve found some new information that helps you on your journey to performance perfection.

If you have any other tips & tricks that you’d like to share, don’t hesitate to write them in a comment below.

This has been Robin, and I’m out. Byeee.