How to Speed Up Your Website: Core Web Vitals

To speed up your website, you need to move three Core Web Vitals metrics past Google's thresholds: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. At least 75% of your real visitors must see those numbers, and Google grades you on field data from actual Chrome users — not on a lab score.

Most site owners treat speed as a single number. A green 90 in PageSpeed Insights feels safe; an orange 60 triggers panic. Neither reaction is useful, because the score in that report is not the data Google's ranking systems consume. This guide walks through what each metric means, how to measure it correctly, and which fixes actually move the needle.

Table of Contents

• What Slow Pages Actually Cost You
• Core Web Vitals: Three Metrics, Three Thresholds
• What Changed in 2026 and What Did Not
• Lab Data vs Field Data: Measuring What Google Sees
• How to Get LCP Under 2.5 Seconds
• Image Optimization: The Fastest Win
• INP: The Freeze After the Tap
• CLS: Stop the Page From Jumping
• The Real Bill for Third-Party Scripts
• Caching, CDN and the Server Layer
• A 30-Day Speed Roadmap
• Frequently Asked Questions

What Slow Pages Actually Cost You

Speed looks like an engineering topic, but the invoice lands in revenue. Google and Deloitte studied retail sites for their "Milliseconds Make Millions" research and found that a 0.1-second improvement in mobile load time lifted conversion rates by 8.4% and average order value by 9.2%. The unit of measurement is milliseconds; the unit of impact is percent.

Individual brands report the same direction. In a case study published on web.dev, Vodafone improved its LCP by 31% and recorded 8% more sales, a 15% better lead-to-visit rate and an 11% better cart-to-visit rate. The changes were not exotic: they rendered widgets on the server, sent critical HTML earlier, and shipped images at sensible sizes.

There is also a cost most teams never put in a spreadsheet. A slow landing page quietly drains paid budget: your cost per click stays the same, but every visitor who bounces before the hero renders pushes your acquisition cost up. You win fewer customers with the same spend, and the monthly report calls it "ad performance dropped."

The competitive picture favours anyone who acts. According to the HTTP Archive Web Almanac 2025 performance chapter, only 48% of sites pass all three Core Web Vitals on mobile, and 56% on desktop. When more than half your competitors fail the bar, fixing your own pages buys cheap differentiation.

Search adds the final argument. Core Web Vitals are not a switch that ranks you first, but they act as a tiebreaker when pages of similar quality and authority compete. If your competitor renders in 1.8 seconds and you take 4, the winner is easy to predict.

Core Web Vitals: Three Metrics, Three Thresholds

Google defines the three metrics in the Web Vitals documentation on web.dev. The thresholds look like this:

Google grades all three at the 75th percentile and separates mobile from desktop. Three quarters of your visits must clear the bar, so a healthy average still fails if the slow tail is long enough.

The metric names sound technical, but what they measure is ordinary: when did the page appear, how fast did it answer my tap, and did it stay still while I read. Every Core Web Vitals project boils down to answering those three questions better. Use those sentences instead of the acronyms when you brief non-technical stakeholders — budget conversations get much shorter.

Which metric causes the most trouble? The Web Almanac 2025 data is blunt. On mobile, 81% of pages score "good" for CLS and 77% for INP, but only 62% for LCP. The weak link is almost always loading speed, so that is where your first fix list belongs.

What Changed in 2026 and What Did Not

One claim deserves an immediate correction: the story that "Google lowered the LCP threshold to 2.0 seconds in 2026" has no official source behind it. web.dev still documents 2.5 seconds, and Google keeps these metrics at "stable" status — a label that promises no more than one change per year and clear advance notice for any change. Do not budget against threshold news that does not come from Google.

The real break happened in 2024, when INP replaced FID as a permanent Core Web Vital. FID only captured the delay of the first interaction. INP reports something close to the worst interaction across the page's lifetime, which finally exposed the classic "the first tap feels fast, then the menu freezes" problem.

Something else is moving, though: the bar keeps rising. Mobile pass rates climbed from 44% in 2024 to 48% in 2025. Over the same period the median mobile Total Blocking Time grew by 58%, so pages got heavier while browsers and engineers worked to absorb the weight. Stand still and you do not hold your position — you fall behind.

The practical takeaway: build your Core Web Vitals plan on Google's own documentation rather than on threshold rumours circulating in agency blogs. Definitions and limits live in one place and stay current there, and Google Search Central announces anything structural.

Lab Data vs Field Data: Measuring What Google Sees

A PageSpeed Insights report has two blocks. The top block shows field data from the Chrome User Experience Report (CrUX) and summarises what real users experienced over the last 28 days. The bottom block shows a single Lighthouse run in a laboratory.

The gap between them explains most bad decisions. Lighthouse applies simulated throttling: it loads the page on a fast connection, then calculates what a slow mobile connection would have produced. That model can miss the mark on JavaScript-heavy pages and on devices with different CPU profiles. So a Lighthouse score of 95 alongside a poor field LCP is entirely possible — and so is the reverse.

Our own client work keeps confirming it. Teams usually contact us because of an orange score; we open the field data and find LCP sitting at 2.1 seconds, meaning no ranking problem exists at all. The opposite happens too: a corporate site scoring 90 in the lab shows a 4.3-second field LCP, because most of its visitors arrive on mid-range Android phones over mobile data.

The decision rule is simple. Field data answers "do I have a ranking and conversion problem"; lab data answers "what do I fix first." The Core Web Vitals report in Search Console groups URLs so you can see which template misbehaves, and its 28-day rolling window means your fixes show up there weeks after you ship them.

There is a third layer worth adding: your own real-user monitoring. Drop Google's open-source web-vitals library into the page and send every visit's LCP, INP and CLS to your analytics. This solves two problems. CrUX only reports pages with enough traffic, so low-traffic B2B sites often see an empty field report. And your own data breaks results down by device, browser and template, which turns "which page type is slow" from a guess into a query.

If you want a starting point for your own site, our free site analysis tool runs the PageSpeed infrastructure and reports mobile performance plus baseline SEO checks in about 30 seconds.

How to Get LCP Under 2.5 Seconds

LCP marks the moment the largest visible content element finishes painting. On 76% of mobile pages that element is an image, so most LCP work reduces to one sentence: find the hero image early, download it early, and ship it at the right size.

Discoverability is the classic failure. web.dev reports that only 35% of LCP images appear in the initial HTML response; the browser finds the rest after JavaScript executes. A homepage that builds its slider in JavaScript throws away the browser's chance to prioritise that image at all.

Priority is the second failure. Only 15% of eligible pages use the fetchpriority="high" attribute. The third is self-inflicted: 17% of pages lazy-load their own LCP image. Adding loading="lazy" to an above-the-fold image tells the browser the most important pixel on the page can wait.

Work through the fixes in this order:

1. Get TTFB under 800 ms. The web.dev TTFB guide sets that target, and image work delivers little while the server answers slowly.
2. Put the LCP image in the HTML source with a real src/srcset, then add fetchpriority="high".
3. Never lazy-load anything above the fold. Lazy loading belongs strictly below it.
4. Preload critical fonts and use font-display: swap so text does not wait on a download.

Those four steps produce the single largest gain in most corporate sites, and none of them require a rebuild.

Image Optimization: The Fastest Win

Pages keep gaining weight. The Web Almanac 2025 page weight chapter puts the median mobile page at 2,164 KB, of which images account for 911 KB and JavaScript for 632 KB. The median grew 8.4% on mobile in a single year, so a site you never touch gets slower every year by default.

Format adoption lags badly. Among LCP images, 57% remain JPG and 26% PNG, while WebP holds 11% and AVIF just 0.7%. Modern formats deliver real savings at the same visual quality:

AVIF has one drawback: encoding takes noticeably longer than WebP. If your platform processes large volumes of user uploads in real time, budget for that cost. On a corporate site that publishes a handful of images per week, it never matters.

Image work gives the best return per hour of any item on a speed list, because you can do it without touching application architecture. Converting 40 product images on an e-commerce category page to AVIF can halve the page weight. Achieving the same saving in JavaScript takes weeks of refactoring.

Three habits matter as much as the format. Generate images at the size you actually display — squeezing a 3,000-pixel product photo into a 600-pixel box makes visitors download data they will never see. Serve device-appropriate variants with srcset and sizes. Finally, put width and height on every img tag, which both lowers CLS and lets the browser reserve space.

INP: The Freeze After the Tap

INP measures the delay between a click, tap or keypress and the first visual change on screen. A single sluggish interaction drags the whole metric down, because INP reports close to your worst case rather than your average.

The numbers point straight at the cause: 97% of desktop pages pass INP, against 77% on mobile. The gap is not network, it is CPU. A mid-range Android phone runs the same JavaScript several times slower than a laptop.

Technically the culprit is usually long tasks — JavaScript blocks that hold the main thread for more than 50 milliseconds. Tap a button during one of those and the browser simply cannot answer. The fix is to break the work up and let the browser breathe. scheduler.yield() is the standard tool for that today, with setTimeout(resolve, 0) as a fallback for older browsers. One detail decides whether it works: remember the await, or the browser never splits the task.

INP usually lands last on a Core Web Vitals plan, because the fix reaches into front-end architecture. On mobile-heavy sites, though, it generates the most complaints: users tap twice, the form submits twice, and support opens a "system error" ticket without ever learning why. Fixing INP often closes a bug queue as well.

Beyond yielding, three moves help. Strip unused JavaScript out of the bundle, apply route-level code splitting, and cut unnecessary hydration. Adding React hydration to a static corporate page is usually a cost with no return; our article on modern web design trends covers what that choice means for the interface itself.

CLS: Stop the Page From Jumping

CLS measures how much content shifts while the page loads. A visitor reaches for "Buy now", a banner loads above it, the button slides down, and the tap lands on an ad instead. That experience is exactly what CLS quantifies.

The main cause is surprisingly mundane: images without dimensions. web.dev reports that 66% of pages have at least one image missing width/height, and the Web Almanac puts the mobile figure at 62%. If the browser learns an image's size only after downloading it, everything below jumps once it arrives.

Four measures close most of the gap:

• Give images and iframe slots explicit width/height or a CSS aspect-ratio.
• Reserve min-height for ads, promo bars and embedded content.
• Reduce font swap jumps with size-adjust and a suitable font-display value.
• Animate transform instead of margin or border; pages that animate layout properties hit poor CLS at nearly twice the average rate.

Treat late-loading components such as cookie banners and announcement bars as overlays that sit on top of the content rather than blocks that push it down.

The Real Bill for Third-Party Scripts

Nobody deliberately installs a slowdown, yet every marketing request eventually arrives as a script tag. The Web Almanac 2025 third parties chapter finds that more than 90% of pages load at least one third party. A median page makes 79 third-party requests on mobile and 83 on desktop; among the top 1,000 sites that figure climbs to 106–129.

The most important finding is chain depth, with a median of 3. The third party you added loads more third parties of its own. You think you pasted one snippet into a tag manager, but you handed the browser dozens of requests and hundreds of milliseconds of main-thread work.

A typical mid-size site inventory looks like this: Google Analytics, a Google Ads conversion tag, the Meta pixel, a heatmap tool, a live chat widget and two social embeds. Most of them measure something; none of them create value for the visitor.

Cleaning that list is the most political part of any speed project, because every script has a team behind it. One question settles the argument: "In the last 90 days, who used this data to make which decision?" Scripts without an answer leave the page. That turns an opinion fight into a measurable case.

Three steps then finish the job. Delete unused tags in your tag manager first — most sites still fire tags from campaigns that ended years ago. Load chat and comment widgets on interaction instead of on page load. Finally, defer measurement scripts until after consent, which serves both privacy compliance and speed.

Caching, CDN and the Server Layer

No front-end work rescues a slow server. The TTFB target is 800 milliseconds, and the Web Almanac 2025 reports that only 44% of mobile pages meet it. More striking: just 33% of HTML document requests come from a CDN, so two thirds of the web answers every visitor from a single origin regardless of where they live.

Caching operates in four layers, each solving a different problem. Browser caching (Cache-Control, plus immutable for long-lived static files) speeds up repeat visits. Full-page caching stops the server from rebuilding identical HTML. An object cache such as Redis removes repeated database queries. On the database itself, missing indexes explain most slow queries.

The server layer is the least visible but most durable part of the work. A theme update can undo any front-end tweak you make; a properly configured cache and CDN keep paying off for years. On tight budgets, starting at the server is the safer sequence.

The most common hosting problem we see is shared hosting. A cheap plan puts hundreds of sites on one machine, and when a neighbour gets traffic your TTFB rises with it. Diagnosis is easy: test the same page at different hours, and if TTFB swings between 400 ms and 1,500 ms, the bottleneck is your plan rather than your code. Moving to a VPS or managed hosting then beats weeks of code optimization on both speed and cost.

CDN choice deserves attention too. If most of your visitors sit in one region, a provider with a nearby point of presence saves a few hundred milliseconds on its own. Brotli compression and HTTP/2 or HTTP/3 support are baseline expectations today. Teams weighing platform decisions will find related trade-offs in our comparison of website builders and custom development.

A 30-Day Speed Roadmap

The plan below improves a mid-size corporate site measurably in four weeks. Order matters: acting before measuring hides both your gains and your losses.

One rule keeps the plan honest: repeat the measurement at the end of every week and write down what you changed. Most speed projects quietly regress in year two because nobody recorded which fix produced which gain. Teams that keep notes avoid repeating the same mistakes at the next redesign.

Do not expect the field data to refresh by the end of week four. Because CrUX uses a 28-day rolling window, Search Console charts typically take another three to four weeks to catch up. Knowing that delay stops your team from declaring failure too early. The same discipline applies to any launch; our guide to corporate website best practices covers the wider checklist.

Frequently Asked Questions

How long does it take to speed up your website?

Most technical fixes land within two to four weeks. Reflecting them in Core Web Vitals reports takes another three to four weeks because CrUX uses a 28-day data window. Budget six to eight weeks for measurable, reportable results.

Does my PageSpeed score need to be 100?

No. The PageSpeed score summarises a lab measurement, and Google does not use that number for ranking. Your actual target is field data: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1.

Do Core Web Vitals really affect rankings?

Yes, but never on their own. Google treats them as page experience signals that separate pages of comparable quality and authority. Poor Core Web Vitals cap what strong content can achieve, and great Core Web Vitals will not rescue weak content.

Can a caching plugin fix a slow WordPress site?

Caching and image plugins deliver real gains, but they hit a ceiling. A heavy theme, dozens of page-builder modules and a long list of third-party scripts stay slow underneath the cache. Reduce plugins first, simplify builder modules second, and install the cache last.

Why are my mobile and desktop scores so different?

The gap comes mostly from processing power. A mid-range phone executes the same JavaScript several times slower than a desktop, and mobile network latency adds to it. Google grades mobile and desktop separately, so mobile deserves your first attention.

How much conversion lift does a speed improvement produce?

Industry studies report roughly 2–7% more conversions per second of improvement, and the Google–Deloitte retail research measured an 8.4% lift from just 0.1 seconds on mobile. Your actual number depends on your sector, device mix and starting point — a site at five seconds gains far more than one already at two.

Speeding up a site is a discipline rather than a one-time project. Page weight grows every year, marketing asks for a new script every month, and theme updates roll back hard-won gains. Teams that hold their numbers watch field data continuously and measure every new template before it ships.

At Master Web we treat performance as part of the design decision rather than an optimization pass bolted on afterwards, both in custom web design projects and in ongoing maintenance work. If you want a prioritised, line-by-line view of where your current site loses visitors, get in touch with us and we will build that roadmap from your own field data.