Webflow site speed: how to pass Core Web Vitals in 2026

Webflow site speed is rarely limited by the hosting, so most Webflow sites can pass Core Web Vitals. A page passes when, at the 75th percentile of real visits, Largest Contentful Paint is 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift is 0.1 or less. When a Webflow page fails, the usual causes are the hero image, third-party scripts, fonts and animation, and each one can be fixed inside Webflow.

I'm Chirag Singh, and I've built Webflow sites since 2023. The thresholds and settings below come from Google's documentation and Webflow's Help Center, read on 29 Oct 2026 and linked where they appear. If you only want the steps, the prioritized fix list is near the end.

What are the Core Web Vitals thresholds in 2026?

Good is LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Google's PageSpeed Insights documentation sets the three bands below, and says a page passes the Core Web Vitals assessment "if the 75th percentiles of all three metrics are Good." When there isn't enough INP data, LCP and CLS decide it on their own.

Do Core Web Vitals affect rankings?

They count, but relevance counts more. Google's page experience documentation (updated 22 Sep 2026) says "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." I treat speed as something that helps a good page win and keeps visitors from leaving, and I'd fix a page that doesn't answer its search before a page that loads slowly. Speed is one part of the wider question of whether Webflow is good for SEO.

How to measure Webflow site speed: field data vs lab data

Use field data to find out whether you have a problem, and lab data to find the cause. Field data is what real Chrome users experienced over the past four weeks. Lab data is one simulated page load. The two often disagree, and the Core Web Vitals assessment and the Search Console report are built on field data.

PageSpeed Insights

The top of a PageSpeed Insights report is field data from the Chrome UX Report, covering "the previous 28-day collection period," per the documentation linked above. The lower half is a Lighthouse test that simulates "a mid-tier device (Moto G4)" on a mobile network. When a URL has too little traffic, the report falls back to data for the whole origin, and a new or small site may have no field data at all.

A Webflow PageSpeed score, the Lighthouse performance number where 90 and above counts as good, is lab data. A page can score in the 70s and pass Core Web Vitals on real phones, or score in the 90s and fail them. I use the score to compare before and after a change, not as the target. If the site isn't live yet, lab data is all you have, and my Webflow SEO launch checklist covers which pages to test before launch.

Search Console's Core Web Vitals report

Search Console groups URLs "that have a similar user experience" and labels each group Good, Need improvement or Poor, separately for mobile and desktop, according to Google's report documentation. On a Webflow site the groups tend to follow templates: blog posts, the home page, service pages. That tells you which template to open in the Designer. Groups without enough LCP and CLS data are left out, which is why a small site's report can be empty.

The order I measure in

1. Open the Search Console report and note which metric fails, on which device, in which URL group.
2. Run PageSpeed Insights on one URL from that group, on mobile.
3. Read the Lighthouse diagnostics for the element behind the failure: the LCP element, the shifting elements or the long tasks.
4. Change one thing, publish, and run the lab test again.
5. When the fixes are live, start validation in Search Console, which then watches the issue for 28 days.

Why is my Webflow site slow? Causes and fixes

Most Webflow performance optimization comes down to the same few causes: hero images that are too large or lazy loaded, third-party scripts, web fonts, animation and heavy embeds. Below is each one with the Webflow setting or habit that fixes it, and the metric it moves.

Images and responsive sizes (LCP)

Webflow makes smaller copies of inline images for you. Its responsive images article says originals wider than 3200px get seven variants, from 3200px down to 500px, and the browser picks one through srcset. Background images get none. Neither do images inside rich text elements, or images added through CSV import or the API.

The last two catch blogs and migrations. Post images live in rich text, and a site imported from WordPress by CSV can send full-size photos to phones. Resize post images before they go in, to roughly the width of your content column, and re-upload the hero images in Webflow so they get their variants.

Then compress. Webflow's image conversion tool turns JPEG and PNG assets into AVIF or WebP and updates every placed copy on the canvas. CMS images convert in bulk from the Collections panel, under Compress assets. The tool takes 100 assets per request, so a large library needs a few passes.

The hero image and lazy loading (LCP)

Webflow sets every new image to lazy load by default, a change it made on 27 Aug 2020 (Webflow update). That's right for images further down the page and wrong for the hero. Google's guide to optimizing LCP is direct about it: "Never lazy-load your LCP image." Select the hero image, open its settings in the Settings panel, and switch its loading to eager.

The same guide recommends fetchpriority="high" on the image most likely to be the LCP element, and warns that it stops helping once more than one or two images have it. In Webflow you can add it to the hero image as a custom attribute, with the name fetchpriority and the value high. If the hero is a background image, I rebuild it as an inline image set to cover its section, so it gets responsive sizes and can load eagerly.

Video and embeds (LCP and INP)

A background video in the hero is usually the heaviest file on the page. Keep it short, compress it hard, give it a poster image, and ask whether a still photo would do the same job on phones.

YouTube and Vimeo embeds load the player's scripts with the page, whether anyone presses play or not. Chrome's Lighthouse documentation on facades describes the fix: show "a static element that looks similar to the embedded third-party" and load the real player on click. It lists lite-youtube-embed for YouTube and lite-vimeo-embed for Vimeo. The page notes that Lighthouse 13 removed this audit, but the technique still cuts the work done on load.

Fonts and font-display (LCP and CLS)

Font loading settings in Webflow belong to custom fonts only. Webflow's font display update says "font display controls are only available with custom fonts, not Google or Adobe fonts." To control how a Google font loads, download it, upload it to Webflow as a custom font in WOFF2, and set its font display to swap.

Swap shows text in a fallback font straight away, which helps LCP when the largest element is a heading. The cost is a small shift when the real font arrives, so choose a fallback with a similar width. My default is two families and only the weights the design uses.

Third-party scripts and custom code (INP and LCP)

Chat widgets, tag managers, heatmaps and review widgets all run JavaScript on the page's main thread, and while that work runs, taps and clicks wait. They're the first place I look when INP fails.

Webflow's custom code article warns that external script tags in the head "can slow page loads," suggests the async or defer attribute, and recommends the Footer code section, which outputs before the closing body tag. Pages have their own custom code fields too, so a script used on one page doesn't have to load on all of them.

For a script that isn't needed in the first few seconds, I go a step further and wait for the visitor to interact. This goes in Site settings, Custom code, Footer code:

<!-- 1. A script the page doesn't need to render: defer it -->
<script defer src="https://example.com/helper.js"></script>

<!-- 2. A chat widget: load it on the first interaction, or after 6 seconds -->
<script>
  (function () {
    var loaded = false;
    var events = ['pointerdown', 'keydown', 'scroll', 'touchstart'];

    function loadChat() {
      if (loaded) return;
      loaded = true;
      events.forEach(function (e) {
        window.removeEventListener(e, loadChat);
      });
      var s = document.createElement('script');
      s.src = 'https://chat.example.com/widget.js'; // your vendor's script URL
      s.async = true;
      document.body.appendChild(s);
    }

    events.forEach(function (e) {
      window.addEventListener(e, loadChat, { passive: true });
    });
    setTimeout(loadChat, 6000);
  })();
</script>

Replace the URL with your vendor's script, and keep any settings lines the vendor gives you above this block. The script loads exactly once, whichever comes first. Test the widget on the published site afterwards, because some vendors expect their snippet to run during page load.

Webflow's own CSS and JavaScript (LCP and INP)

Three of Webflow's publishing settings affect speed. Webflow's advanced publishing options article describes each:

• Minify HTML, CSS and JS can each be switched on separately, and the article says minifying "can help your live website load faster." I turn on all three.
• Per page CSS replaces the single site-wide stylesheet with a shared file plus one file per page, so each page loads less CSS.
• Asynchronously load JavaScript, on paid plans, loads JavaScript files alongside rendering instead of one after another. It can break custom code that expects scripts to load in order.

Interactions, GSAP and Lottie (INP and LCP)

Webflow now has two animation systems, Interactions with GSAP and Classic Interactions, and each loads its own resources. Webflow's comparison of the two ranks performance as GSAP only first, Classic only second, and both together last. On a new build I pick GSAP and stay with it. On an older site, moving every Classic animation across means the page loads one set of resources instead of two.

Animation can also delay LCP directly. If the hero heading starts invisible and fades in on load, the largest element only appears when the fade finishes. Keep the hero still on load, or animate something smaller beside it. Treat Lottie files the same way: keep them small, and keep them out of the first screen where you can.

Finsweet Attributes and big CMS lists (INP)

Finsweet Attributes adds filtering, load more and nesting on top of Webflow's CMS. The slowdown usually comes from what it's asked to render: a page that shows hundreds of Collection items at once gives the browser more work every time something on the page changes. Paginate long lists instead of loading them all, and load the Attributes script only on the pages that use it, through that page's custom code. I cover how I structure big Collections in Webflow CMS limits.

A prioritized fix list for Webflow Core Web Vitals

Work from the top and measure after each step. The list starts with LCP fixes because they're usually the cheapest, then moves to INP and CLS.

1. Find the failing metric, device and URL group in Search Console, then open that template in the Designer.
2. Set the hero image to load eagerly, size it for its slot, and convert it to AVIF or WebP.
3. Remove scripts nobody uses. Move the rest to Footer code with defer, and delay chat and review widgets until the first interaction.
4. Turn on minify for HTML, CSS and JS, and Per page CSS. Test asynchronous JavaScript on staging before switching it on live.
5. Cut fonts to two families in WOFF2, uploaded as custom fonts and set to swap.
6. Take fade-in animation off the hero, and use one interaction system across the site.
7. Replace video embeds with facades, and compress any background video.
8. Give every embed, banner and form a fixed height or aspect ratio, so nothing pushes content down as it loads.
9. Publish, run PageSpeed Insights again, and start validation in Search Console.

If a page still fails after that, the Lighthouse diagnostics will usually point at one script or one element. At that stage the cause is specific to the site, and it's worth looking at that template properly.

Speed also drifts after launch, as new scripts and big images get added. On my Webflow care plans, from $150 a month for 4 hours of changes, the monthly check includes speed alongside forms, links and errors.

Before you change anything, open Search Console's Core Web Vitals report and write down which metric fails on mobile. That one line tells you which section of this guide to start with.