A speed score of 60 on mobile is common for Webflow sites that have been live for a year or two. It is rarely the platform's fault. Pages pick up weight one decision at a time: a bigger hero image, another tracking script, a second font family. Each one is small. Together they add seconds.
This note covers the four causes I find most often when I audit a site, in the order I fix them. The order matters, because the first two usually account for most of the gain.
Images larger than the space they fill
The most common problem is an image uploaded at 4,000 pixels wide and shown at 600. Webflow creates smaller versions of images placed as image elements, but not of background images set in the Designer. A hero background is often the single heaviest file on the page.
- Replace background images with image elements where the layout allows it.
- Upload at twice the largest displayed size, and no more.
- Convert to WebP or AVIF.
- Lazy-load everything below the first screen, and load the hero image eagerly.
Scripts from other companies
Chat widgets, heat maps, ad pixels and consent banners all run on the visitor's phone before the page becomes usable. I often find scripts left over from a tool the team stopped paying for a year ago. Every one of them costs time, and none of them is visible in the Designer.
- List every script in the site settings and in page-level custom code, and remove what nobody uses.
- Load the rest after the page is interactive, and load chat widgets on first interaction.
- Move tags into one tag manager, so there is a single place to check.
Fonts
Each font file can hold text back until it loads. Four weights of two families is eight files. Most sites need two or three.
- Cut the weights you do not use.
- Upload fonts as WOFF2 and let text show in a fallback font while they load.
- Preload the one file used by the main headline.
A heavy first screen
A background video, an animation and a slider in the first screen all compete for the same second. The score depends heavily on how fast the largest thing in the first screen appears, so that is where restraint pays most.
The first two fixes usually account for most of the gain. Start there before anyone suggests a rebuild.
What it takes
| Fix | Typical effort | Risk to the design |
|---|---|---|
| Resize and convert images | 2 to 4 hours | None |
| Remove and defer scripts | 1 to 3 hours | None, but check analytics afterwards |
| Trim and preload fonts | 1 hour | None |
| Lighten the first screen | 2 to 6 hours | Needs a design decision |
On most sites this is about a day of work, done on staging and checked before it goes live. If the score is still low after that, the cause is usually structural, and that is when moving the site to custom code becomes worth pricing.
Scores vary between runs and devices. Measure three times on mobile before and after, and compare the middle result.