A slow website shows on mobile first: the page stays blank, the text jumps when the image arrives, the menu reacts a beat too late. Google measures these three problems with the Core Web Vitals, and your visitors feel them before they read a single line.
In this article, we cover the thresholds to aim for in 2026, the tools to test your website's speed (and what each one actually measures), a method to decide where to start, and what you can tune on a Webflow site.
Originally published in 2021, fully updated on October 6, 2026.
Core Web Vitals in 2026: three thresholds to meet
The Core Web Vitals are three metrics measured on real visits. A page meets them when 75% of visits (the 75th percentile) fall under the threshold, with mobile and desktop assessed separately (web.dev).
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | when the largest visible element renders: main image or headline block | ≤ 2.5 s | up to 4 s | > 4 s |
| INP (Interaction to Next Paint) | the delay between a click, tap or key press and the page's visible response | ≤ 200 ms | up to 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | how much the layout shifts during the visit | ≤ 0.1 | up to 0.25 | > 0.25 |
Thresholds: web.dev, LCP, INP, CLS.
INP replaced FID on March 12, 2024 (web.dev). FID only measured the delay before the first interaction; INP covers every interaction during the visit. If a guide still talks about FID, it predates 2024.
For SEO, Google says Core Web Vitals align with what its core ranking systems seek to reward, and recommends getting them right (Google Search Central). It doesn't promise that a good score will lift a page: speed separates pages that are otherwise close, it doesn't replace relevant content.
For visitors, a 2017 Google/SOASTA study, best read as an order of magnitude, estimated that the probability of a mobile bounce rises by 32% as load time goes from one to three seconds (Google, Milliseconds Make Millions).
Probability of bounce based on mobile page load time (source: Google/SOASTA, 2017)
How to test website speed: which tool for what
There are two kinds of data. Field data comes from real Chrome visits, through the Chrome User Experience Report (CrUX). Lab data comes from a simulated page load under fixed conditions. Field data tells you whether you have a problem; lab data helps you find where it comes from.
| Tool | Data | Price | Use it to |
|---|---|---|---|
| PageSpeed Insights | field (CrUX, last 28 days) and lab (Lighthouse) | free | check one page: does it pass Core Web Vitals? |
| Search Console, Core Web Vitals report | field (CrUX), grouped by similar pages | free | see which page templates fail across the whole site, then validate a fix |
| CrUX (CrUX Vis, API, BigQuery) | field | free | track trends over time, compare with a competitor |
| Lighthouse (in Chrome DevTools) | lab | free, open source | diagnose: which file, script or image slows the page down |
| WebPageTest | lab, from 30 locations worldwide | free up to 150 test runs a month; Pro from $180 a year | test from another country or on a slow connection, and read the loading waterfall frame by frame |
Before drawing conclusions, keep in mind what each number measures:
- The performance score out of 100 is a lab score. A 99 in Lighthouse doesn't guarantee your visitors pass the thresholds, and the reverse is also true. PageSpeed Insights grades Core Web Vitals on field data: a page passes when all three metrics are good at the 75th percentile (PageSpeed Insights documentation).
- In a standard page-load test, Lighthouse doesn't measure INP. Without a user clicking, there's no interaction to measure, so Lighthouse reports Total Blocking Time (TBT) instead (web.dev). For INP, field data is what counts.
- A low-traffic site may have no field data at all, because CrUX only covers pages and sites with enough visits (Chrome for Developers). That's common for B2B websites: PageSpeed Insights then shows lab data only, and the Search Console report stays empty. In that case, run Lighthouse on your main page templates, on mobile.
In Search Console, you confirm a fix with the Start tracking button: Google then monitors the affected pages for 28 days (Search Console Help). Speed is also one of the checks in a complete SEO audit.
Where to start: read what slows down LCP
"CDN or image optimization: which gives the biggest improvement?" It depends on your page, and the answer is in the LCP breakdown. web.dev splits LCP into four parts (web.dev, optimize LCP):
- Time to First Byte (TTFB): how long before the browser receives the first byte of the page.
- Resource load delay: how long before the browser discovers the main image and starts downloading it.
- Resource load duration: how long that image takes to download.
- Element render delay: the gap between the end of the download and the moment it appears.
Lighthouse's LCP breakdown audit, also shown in the lab section of PageSpeed Insights, and the Performance panel in Chrome DevTools display this breakdown (Chrome for Developers). From there, the choice almost makes itself:
| What dominates | Likely cause | Action |
|---|---|---|
| Time to First Byte | slow hosting, server far from visitors, redirects | CDN, better hosting, remove redirects |
| Resource load delay | main image set to lazy, image loaded through CSS or JavaScript | load the main image right away, with fetchpriority="high" |
| Resource load duration | image too heavy | WebP or AVIF, right dimensions |
| Element render delay | render-blocking CSS and JavaScript, web font, entrance animation | defer scripts, trim CSS, rethink the animation |
If CLS fails, look for an image without dimensions, a font that changes text size when it loads, or a banner (cookies, ads, widget) injected above the content (web.dev). If INP fails, look at JavaScript: third-party scripts, long tasks, a page with too many elements (web.dev, optimize INP).
Images: the most common culprit
On a marketing website, the LCP element is often an image. Four settings cover most of it:
- Format: WebP or AVIF for photos, SVG for logos and icons. Both formats are supported by more than 96% of browsers (Can I use: AVIF, WebP).
- Dimensions: serve the image at the size it's displayed, with
srcsetso the browser can pick. Always set a width and a height, or the layout will shift when the image arrives. - Lazy loading: useful for images further down the page, never for the main image. web.dev is explicit: don't put
loading="lazy"on the LCP element. - Priority: the
fetchpriority="high"attribute on the main image tells the browser to download it first.
The recommended dimensions for each use (full width, blog post, Open Graph, favicon) are in our guide to website image sizes and formats.
Fonts, third-party scripts, animations
Fonts
Every font and every weight is one more file to download before text shows in its final form. web.dev recommends WOFF2, fewer fonts (one variable font can replace several weights) and an explicit font-display setting: swap shows text immediately in a system font, optional favors performance and may keep the system font if the web font arrives too late (web.dev). We go deeper in Font Display: optimize your site on Google.
Third-party scripts
Analytics, tag manager, chat, cookie banner, heatmap, embedded video: every tool a marketing team adds loads its own JavaScript, and that's often what drags INP down. Ask three questions for each script:
- Is it still used? Tags from a finished campaign often stay in place for months.
- Can it load later? A script that isn't needed for the first render can load with
deferorasync, at the end of the page. - Is there a lighter option? A YouTube video can show as a clickable image and only load the player on click.
Animations
A well-built animation costs almost nothing. web.dev recommends animating transform and opacity rather than width, height or position, which force the browser to recalculate the layout and cause shifts (web.dev).
A frequent trap is the entrance animation at the top of the page. An element with an opacity of 0 isn't considered for LCP (web.dev): if the headline or main image fades in after load, LCP is only recorded once the fade ends.
Servers and CDNs: what a CDN really changes
A CDN (Content Delivery Network) keeps copies of your files on servers spread around the world. Visitors get them from the nearest server instead of your origin hosting. The gain is on server response time and file download: it's one of the levers web.dev lists to improve LCP (web.dev).
Without a CDN, every visitor hits the same server; with a CDN, they're served from the nearest point
Time to First Byte isn't a Core Web Vital, but web.dev advises aiming for 0.8 seconds or less (web.dev). Beyond that, look at hosting before compressing one more image. Without a CDN, server location matters: a site whose audience is in the US is better hosted in the US. With a CDN, it matters much less.
If your hosting doesn't include a CDN, two common options:
| Service | Price (checked on October 6, 2026) |
|---|---|
| Cloudflare | Free plan at $0; Pro at $20 a month billed annually, $25 billed monthly; Business at $200 a month billed annually |
| Bunny CDN | pay as you go: $0.01 per GB in Europe and North America, more in other regions |
A CDN doesn't fix everything. It delivers a 3 MB image faster, it doesn't make it lighter. And it has almost no effect on INP or CLS, which happen in the browser.
On Webflow: what's included, what you control
What's included
Webflow hosting runs on AWS infrastructure and Cloudflare's CDN; Webflow says it reaches 95% of the world in under 50 milliseconds (Webflow, hosting). SSL, responsive images and conversion to WebP or AVIF come with site plans. So there's no CDN to plug in, no server to pick and no cache to configure.
What you control
- Images: new images are set to lazy load by default (Webflow), so switch each page's main image to Eager in the element settings. Lazy loading doesn't apply to background images: a large background image at the top of the page can be the LCP element, and the browser only discovers it when it reads the CSS. Convert images in the Assets panel, keeping in mind that Webflow doesn't generate responsive variants for AVIF (details in our image guide).
- Fonts: the font-display setting is available for custom fonts uploaded in Site settings, not for Google or Adobe fonts added through the native integration. To set it on those, download the files and upload them as a custom font (Webflow).
- Code: everything is under Site settings → Publishing → Advanced publishing options. HTML, CSS and JavaScript minification; asynchronous JavaScript loading, launched on February 18, 2025 and limited to paid plans (Webflow); per page CSS, launched on May 27, 2025 and off by default (Webflow). These last two can break custom code: test on the staging domain before publishing.
- Third-party scripts: code added in site settings runs on every page. Put anything that doesn't need to be in in the Footer code area (before ), and add page-specific code in that page's settings rather than site-wide.
- Interactions: since September 30, 2025, Interactions with GSAP let you scope an interaction to specific pages and respect the visitor's reduced motion setting (Webflow). Avoid fade-in entrances on the headline and main image at the top of the page.
Our take
On a properly hosted marketing website, slowness rarely comes from the server. It comes from a main image that's too heavy, an entrance animation on the headline, or a dozen third-party scripts added campaign after campaign. In other words, design and marketing decisions, which you can fix without changing hosts.
So look at field data before the score out of 100. A 99 in Lighthouse looks good in a meeting; what matters is the LCP measured on your visitors' phones. And speed is maintained more than it's achieved once and for all: every new page, every new tool can degrade it. If you want a team to look after your site over time (SEO, AI visibility, CRO, new features), that's what our Webflow support and growth services are for.
Frequently asked questions
How do I improve my website's loading speed?
Start by measuring: run PageSpeed Insights on your homepage and key pages, on mobile. Then check which of the three metrics fails. Most of the time, the gains come from the main image (format, weight, immediate loading), unused third-party scripts and entrance animations. Hosting and a CDN come next, if Time to First Byte is above 0.8 seconds.
What is a good page load time?
Google doesn't set a "total load time". The official benchmark is LCP: 2.5 seconds or less for at least 75% of visits. For responsiveness, an INP of 200 ms or less; for stability, a CLS of 0.1 or less.
How does a CDN help page speed?
It serves your files from a server close to the visitor instead of your origin hosting. Server response time and download time drop, especially for an audience far from your server. It doesn't make files lighter and doesn't improve INP or CLS.
CDN or image optimization: which should come first?
Check the LCP breakdown in the lab section of PageSpeed Insights. If Time to First Byte dominates, the CDN or hosting comes first. If it's the image download, work on the image. On a Webflow site the question doesn't arise: the CDN is already there, the images are what's left.
How can I test my website's speed for free?
PageSpeed Insights for a single page, the Core Web Vitals report in Search Console for the whole site, Lighthouse in Chrome for diagnosis. WebPageTest has a free plan with 150 test runs a month to test from other countries or on a slow connection.
Why doesn't PageSpeed Insights show field data for my site?
Because your page or site doesn't get enough Chrome visits to be included in CrUX. You only have lab data then: test your main page templates on mobile and fix what Lighthouse flags.
Does website speed affect SEO?
Yes, as one factor among others. Google says Core Web Vitals align with what its ranking systems seek to reward, without promising a ranking gain. A fast site with thin content won't outrank more useful content.
Sources
- web.dev: Core Web Vitals · LCP · INP · CLS · TTFB
- web.dev: optimize LCP · optimize INP · font best practices · INP becomes a Core Web Vital
- Google Search Central: Core Web Vitals and Search results · Search Console Help: Core Web Vitals report
- PageSpeed Insights documentation · CrUX · Lighthouse · WebPageTest plans
- Cloudflare plans · Bunny CDN pricing
- Webflow: hosting · per page JavaScript · per page CSS · font display · Interactions with GSAP
- Google/SOASTA, 2017, in Milliseconds Make Millions
