The site speed fixes that actually move Core Web Vitals in 2026

Most site speed work stalls because it starts with a tool score instead of a bottleneck. The fixes that reliably move Core Web Vitals are a short list: get the largest image right, stop fonts and scripts from blocking the first paint, put a hard budget on third-party tags, and cut server response time with caching. Do those in order, measure in the field, and everything after that is tuning.

Measure in the field before you change a line

Core Web Vitals are scored on real visits, not on your laptop. The three that matter are Largest Contentful Paint, which is how quickly the main content appears; Interaction to Next Paint, which is how quickly the page responds to a tap or click; and Cumulative Layout Shift, which is how much the page jumps while it loads. Google's published thresholds, current at the time of writing, are 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS, assessed at the 75th percentile of visits.

Get two views before you touch anything. The field view comes from the Chrome User Experience Report, surfaced in PageSpeed Insights and in Search Console, and it is what search engines actually see. The lab view comes from Lighthouse or WebPageTest and is useful for one thing: telling you which element or script is responsible. If you want per-page numbers rather than origin-level averages, add the web-vitals script to your pages and send the readings into your analytics tool as events.

Scope the work by template, not by site. Pick your five highest-traffic page types, usually home, category, product or service, article, and the main form page. A homepage fix rarely transfers to a product template, and averaging the two hides both.

A lab score is a hypothesis. Field data at the 75th percentile is the result.

Images: usually the whole LCP story

On most sites the LCP element is a hero image, and the fix is mechanical. PageSpeed Insights names the element for you. Once you know it, work through four things.

Format. Serve AVIF with a WebP fallback through a picture element. AVIF gives the smallest files at a given quality for photographic content, and WebP covers the rest. Keep a JPEG or PNG original only if your pipeline needs one.

Sizing. Ship a srcset with three or four widths and an honest sizes attribute, so phones do not download a desktop-width file. Set explicit width and height attributes, or an aspect ratio in CSS, so the browser reserves the box and CLS stays flat.

Priority. Give the LCP image a high fetch priority and leave it eagerly loaded. If the hero is a CSS background, the preload scanner cannot see it in the markup at all, and the request waits for the stylesheet to download and the rule to match the element, so use a real image element instead, or preload the file in the head.

Lazy loading. Add native lazy loading to every image below the fold and to embedded iframes, and to nothing above it. The common failure is a page builder or carousel that lazy loads all images including the first one, which pushes LCP back by a full round trip. The second failure is a JavaScript lazy loader that waits for hydration before it requests anything. Native lazy loading needs no library and no framework, and it is the version that actually helps.

Fonts and render-blocking resources

Fonts cause two problems: invisible text while the file downloads, and a layout shift when the real face replaces the fallback. Self-host the woff2 files rather than calling a font service, preload only the one or two faces used above the fold, and set font-display to swap. To stop the shift, subset the file to the characters you use and match the fallback's metrics using size-adjust and the ascent and descent overrides on a font-face block for the system fallback. Two well-chosen weights beat six.

Stylesheets block rendering by design. Inline the CSS needed for the header and hero, then load the rest without blocking. Never use an import statement inside a stylesheet, because it hides a second request behind the first. If your site runs on a theme or page builder, check how much CSS ships that no template uses. On marketing sites that is often the largest single saving available.

For JavaScript the rule is short: nothing in the head without defer or async unless the first paint genuinely depends on it. Split bundles by route so a visitor to one page does not parse the code for all of them, and look hard at what your framework sends as a hydration payload. Parsing and executing script is main-thread work, and main-thread work is exactly what INP measures.

Third-party tags and the INP tax

Tag containers accumulate. Chat widgets, heatmaps, session recorders, A/B testing snippets, retargeting pixels, review embeds and consent tools all compete for the single thread the browser needs in order to respond to taps. Open your tag manager and list every tag with the date it was added and the person who asked for it. Anything nobody can name an owner for comes out.

For what survives, set loading rules. Consent and core analytics fire early; everything else waits for idle time or for the first real interaction. Chat widgets in particular can load on a click of a placeholder button rather than on page load, and almost nobody notices the difference. A/B testing snippets deserve extra scrutiny, because the anti-flicker snippet many of them install deliberately blocks rendering until the variant decides. Where a vendor supports server-side tagging, moving collection there cuts what the browser has to download and run.

Your own code contributes too. Long tasks come from oversized event handlers, unbatched DOM writes that force layout recalculation, and heavy work on scroll. Break them up: yield back to the browser between chunks, debounce input handlers, and read layout values before you write them. The Long Animation Frames API, current at the time of writing, will tell you which script owned the frame that made your INP bad.

Server response, caching and the CDN

Time to first byte is part of LCP, and no front-end fix can outrun a slow origin. Budget it separately and treat anything sluggish as a back-end defect rather than a hosting fact of life.

Start with full-page caching at the edge for anonymous traffic. Most marketing and content pages have no reason to be generated per request, and a CDN with a sensible stale-while-revalidate policy serves them from somewhere near the visitor. Hashed static assets get a long max-age and an immutable flag. Where personalisation is the excuse for not caching, move the personalised fragment into a client or edge request that runs after paint, instead of holding the whole document hostage to it.

Then look at the database. The recurring culprits are N+1 query patterns, missing indexes on columns used for filtering and sorting, and unbounded queries that were fine when the table was small. Turn on the slow query log for a week and fix the top five. An object cache in front of repeated reads usually handles the remainder. If your origin is undersized or sitting in the wrong region for your audience, that is a cloud infrastructure decision rather than a code one, and it is worth making before you spend another sprint shaving kilobytes off a bundle.

What to do first, and how to prove it worked

Sequence matters, because some fixes mask the effect of others. Work through it in this order.

1. Capture baseline field data for your five key templates, and write down the date.
2. Identify the LCP element on each of those templates in the lab.
3. Fix images: format, sizing, priority, and lazy loading below the fold only.
4. Fix fonts: self-host, preload, subset, match the fallback metrics.
5. Defer or delay scripts, starting with third-party tags.
6. Add edge caching, then cut time to first byte at the origin.
7. Re-measure field data after 28 days of collection, not the next morning.

The table below is a working guide to what each fix buys you and what it can break.

Report the outcome the way the business reads it. Field vitals belong beside bounce rate, form starts and revenue per session in the same dashboard, which is where analytics and CRO work joins engineering work instead of running beside it.

How OlDevs helps

We are a full-stack technology studio in Vancouver, building for clients since 2014. On performance engagements we start with your field data and your templates rather than a generic checklist, and we hand back a prioritised list with the measurement plan attached to it. The same accountable team that finds the problem writes the fix, you see a working demo every week, and you own all the code, designs, accounts and IP at the end, including anything we configure in your analytics or your CDN. Accessibility to WCAG 2.2 AA is part of the build rather than a later pass, and we work in English and French.

If slow pages are a symptom of an ageing stack rather than a tuning problem, our web development team will tell you which it is before you commit to a rebuild. Send us your site and the pages that matter most and we will reply within one business day. Request a quote, and we will start with the numbers you already have.