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.

5. Heavy JavaScript that makes every tap feel late (INP)

LCP and CLS get all the attention, but Interaction to Next Paint is the third Core Web Vital now — it replaced First Input Delay in 2024 — and it's the one Webflow sites quietly fail. INP measures how long the page takes to actually respond after someone taps or clicks. If the main thread is busy running a slider script, a form library, and three analytics tags, that tap sits in a queue and the whole site feels sluggish even though it loaded fast. The fix is the same discipline as the rest of this list: ship less JavaScript up front, defer anything that isn't needed for the first interaction, and be honest about whether an interaction needs a library at all. A button that loads 40KB of script to toggle a class is exactly the kind of thing that shows up here.

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.

Core Web Vitals are only one part of technical SEO, and a slow site quietly drags down everything else you rank for. If you want the full picture, I keep a running checklist of what to fix in what order.

Read the Webflow SEO checklist

Common questions about Webflow Core Web Vitals

How do I improve Core Web Vitals in Webflow?

Start by cutting render-blocking JavaScript — remove third-party embeds you no longer use, defer non-critical animation until after the first paint, and preload only the fonts used above the fold. Then resize oversized images to the dimensions they actually render at. In practice those four moves fix the large majority of failing Webflow LCP and CLS scores.

Why is my Webflow site slow even though the images are optimized?

Because images are rarely the real bottleneck. On most Webflow sites the slowdown comes from stacked third-party scripts, animation that runs before the page is interactive, and late-loading fonts. Compressing images that were never the problem won't move the score — audit the JavaScript and the fonts first.

Is Webflow good for Core Web Vitals?

Yes — Webflow serves responsive WebP/AVIF images, lazy-loads media, and ships clean markup out of the box, so a lean build passes Core Web Vitals comfortably. Sites fail when heavy embeds, unused font weights, and eager animation get piled on top. The platform isn't the limit; how it's built is.

What is INP and why does it matter for Webflow sites?

Interaction to Next Paint measures how quickly a page responds after someone taps or clicks — it became the third Core Web Vital in 2024, replacing First Input Delay. Webflow sites tend to fail it when the main thread is busy running slider, form, and analytics scripts at once, making every tap feel late even on a page that loaded fast.

Get a Core Web Vitals audit