Why your Webflow site is slow

A Webflow site with nothing on it is fast. The HTML is small, it serves from a CDN, and there is no server rendering a page on request. That is the starting position, and it is a good one.

So when a Webflow site is slow, something was added. This post is about which something, in the order I find them.

Images, and the one setting that matters

This is first because it is nearly always the answer, and because the fix costs nothing.

The specific failure is a hero image exported at the size it came out of the design tool. Somebody hands over a 3000px wide photograph, it goes into a section that is 1440px at its widest, and every visitor downloads four times the pixels they can see. On a phone, where the image renders at 390px, it is much worse than four times.

Webflow does responsive sizing for you when you use an Image element, and does not when you set the same picture as a background image in the style panel. That is the single setting that matters. A background image is one file at one size served to every device, and it is how a hero that looks fine in the Designer becomes a two megabyte download on a phone.

Three things, in order:

Resize before uploading. Nothing needs to be wider than about 2000px. Most heroes do not need to be wider than 1600.

Use an Image element for anything large. Background images are for textures and gradients, not photographs.

Lazy-load everything below the fold, and nothing above it. Webflow's default is close to right, but a lazy-loaded hero is a self-inflicted delay: the browser waits to discover it is needed before it starts fetching.

Third-party scripts and the real cost

Second, and the one with the largest gap between what people think it costs and what it costs.

A tag manager, a chat widget, a heatmap recorder, an A/B testing tool, two analytics scripts and a cookie banner is a normal marketing stack, and I have audited sites where those seven things outweighed everything the site itself loaded. The site was not slow. The measurement and marketing layer was slow, and the site was carrying it.

The part that gets missed is that the cost is not only the download. A script has to be parsed and executed on the main thread, and while that is happening the page cannot respond to anything the visitor does. A chat widget that weighs 200KB and runs for 400 milliseconds of main-thread time is not a 200KB problem.

The chat widget is worth singling out, because it is the most common single offender and the easiest to fix. Load it on interaction rather than on page load: a button that looks like the widget, which fetches the real thing when somebody clicks. Visitors who never open chat, which is almost all of them, pay nothing.

Animation that fights the browser

Third, and the one that shows up as a page that feels slow rather than one that measures slow.

Webflow's Interactions panel will happily animate any property, and only two of them are cheap. transform and opacity can be handled by the compositor without the browser recalculating layout. Animating width, height, top, left or margin forces a layout pass on every frame, and on a long scroll-linked interaction that is a layout pass on every frame of a scroll.

The symptom is specific: scrolling that judders on a mid-range Android while being perfectly smooth on the laptop the site was built on. If that description fits, look at what the scroll interactions animate before looking at anything else.

The same applies to how many run at once. Six elements each with their own scroll-triggered animation is six things recalculating together.

Fonts

Last, because it is the smallest of the four, and worth doing because it is easy.

Two problems. The first is loading weights nobody uses: a family uploaded with six weights and two italics when the design uses regular and semibold. Every unused weight is a file downloaded for nothing.

The second is the flash. A custom font that is not ready when the text is means either invisible text for a moment or a visible reflow when it swaps. font-display: swap picks the second, which is the right choice, and the way to make the swap unnoticeable is to choose a fallback whose metrics are close to the real font rather than letting it fall back to Times.

Working out which one it is

The tools are free and the order matters. Run PageSpeed Insights on mobile, not desktop, because mobile is where the problems are and where your visitors are.

Three of those four causes have nothing to do with Webflow, which is the point worth taking away. A site that is slow for these reasons is slow for the same reasons on any platform, and moving it somewhere else carries all four across. When to leave Webflow covers the reasons that are actually about the platform.

If you want somebody else to run this on your site, the audit does it and tells you which of the four you are in.