Core Web Vitals in Webflow: What's Actually Slowing You Down

Every performance audit I've seen starts the same way: "compress your images." Sure, do that, it never hurts. But across the Webflow sites I've audited this year, images were the main bottleneck maybe twice. Here's what was actually causing the slow LCP and the janky interactions the rest of the time.

1. Third-party embeds nobody remembers adding

Chat widgets, an old analytics snippet nobody removed, a Calendly embed loading on every page instead of just the contact page, two different font providers because a redesign never fully replaced the old one. Each one is small on its own. Stacked together, they're often the single biggest chunk of render-blocking JavaScript on the page. Open the Network tab and sort by size — it's usually obvious within thirty seconds.

2. Animation running before the page is interactive

GSAP and Lottie are what make a lot of Webflow sites feel expensive, and I use both constantly. The problem is when that animation initializes immediately on page load and fights the browser for main-thread time at the exact moment it's trying to paint your largest content. Deferring non-critical animation until after the initial paint — or until the element actually scrolls into view — usually fixes this without changing how anything looks.

A number, because it's more convincing than the theory

On one rebuild, deferring a hero animation until just after load dropped LCP from 4.1 seconds to 1.6. Nothing else on the page changed. Same images, same fonts, same copy.

3. Fonts loading late and shifting the layout

Loading four font weights when the site actually uses two, missing font-display: swap, or self-hosting fonts without preloading the ones used above the fold — all of these either delay text from rendering or cause a visible reflow once the real font arrives. It's usually a quick fix and it's the one most directly responsible for a bad Cumulative Layout Shift score.

4. Video backgrounds autoplaying above the fold

A heavy MP4 hero background competes for bandwidth with everything else the page needs to load, right when it matters most. If a hero video is genuinely necessary, a compressed WebM with a proper poster frame and lazy initialization does the job for a fraction of the cost. Often, a CSS gradient or a static image does the job just as well and nobody notices the difference.

Where images actually do matter

To be fair to the standard advice: images are the real bottleneck when a site leans on large photography — a portfolio, a hospitality site, anything image-first. The usual culprit isn't file format, it's dimensions: a 4000px photo dropped into a 1200px slot because nobody resized it before uploading. Webflow's own image handling and responsive srcset take care of most of the rest.

• Resize to the largest size the image will actually render at
• Let Webflow serve WebP/AVIF automatically rather than fighting it
• Set explicit width and height so the browser can reserve space before it loads
• Lazy-load anything below the fold

What I'd actually check first

Test on a throttled mobile profile, not your dev machine's fast wifi — Webflow's own Lighthouse panel and PageSpeed Insights will occasionally disagree, and the honest answer is to trust whichever one is closer to how your actual visitors browse. Then work down this list in order. Nine times out of ten the fix isn't the images.

Get a Core Web Vitals audit