How to Improve Website Speed and Core Web Vitals
Updated 11 September 2026 · 5 min read
Speed work goes wrong in two ways. Either people chase a lab score without knowing whether real visitors have a problem, or they apply a generic list of tweaks without finding what actually slows the page. This guide starts with measurement, then works through fixes metric by metric, so you spend time on changes that move the numbers that matter.
Know the targets: Core Web Vitals
Google's Core Web Vitals, documented on web.dev, measure three parts of the user experience:
| Metric | Measures | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading: when the main content appears | 2.5 s or less |
| Interaction to Next Paint (INP) | Responsiveness to clicks, taps and key presses | 200 ms or less |
| Cumulative Layout Shift (CLS) | Visual stability: unexpected movement | 0.1 or less |
The thresholds apply at the 75th percentile of page loads, segmented by mobile and desktop. A page passes when at least three out of four visits meet the target. INP replaced First Input Delay as a Core Web Vital in 2024.
Measure first: lab data vs field data
PageSpeed Insights reports two kinds of data:
- Field data comes from the Chrome User Experience Report: real Chrome users who opted in, on their own devices and connections, over a trailing 28-day window. This tells you whether real visitors have a problem.
- Lab data comes from Lighthouse running a simulated page load on one device profile and one network setting. It's repeatable and full of diagnostics, which makes it good for finding causes.
The two often disagree, and that's expected. Field data is history across many devices. Lab data is one controlled run. Use field data to decide whether to act and lab data to decide what to fix. Low-traffic pages may have no field data at all, so rely on the lab data for those, and on field data for similar pages on the same template.
Our Speed Test runs pages through Google's PageSpeed Insights API, so you can check key templates quickly. Test the home page, a category page, a product or article page and any page with heavy interaction.
Fixing LCP (loading)
web.dev's LCP optimization guide breaks LCP into four parts: time to first byte, resource load delay, resource load duration and element render delay. Find the biggest part, then fix that.
Make the LCP resource discoverable early. If the main image is set in CSS or injected by JavaScript, the browser finds it late. Put it in the HTML as an <img>.
Prioritize it, and don't lazy-load it:
<!-- Hero image: high priority, explicit size, never lazy -->
<img src="/img/hero-1200.webp"
srcset="/img/hero-800.webp 800w, /img/hero-1200.webp 1200w"
sizes="100vw"
width="1200" height="630"
fetchpriority="high"
alt="Product dashboard overview">
<!-- Images further down the page: lazy-load -->
<img src="/img/feature.webp" width="600" height="400" loading="lazy" alt="Feature detail">
web.dev notes that lazy-loading the LCP image always adds unnecessary delay. Lazy-load only images below the fold.
Shrink the resource. Serve modern formats such as WebP or AVIF, size images for their display dimensions with srcset, and compress them. A 4000-pixel photo scaled down to 800 pixels in CSS is a common cause of slow LCP.
Reduce render-blocking resources. Large stylesheets and synchronous scripts in the <head> delay rendering even after the image arrives. Inline critical CSS only if it's small, defer non-critical scripts with defer or async, and remove CSS that the page doesn't use.
Fixing server response (TTFB)
Time to first byte isn't a Core Web Vital, but everything else waits for it. web.dev suggests that most sites aim for a TTFB of 0.8 seconds or less as a rough guide.
- Cache full pages. For content that's the same for every visitor, serving cached HTML avoids running the CMS and database on each request.
- Use a CDN. A CDN serves static assets, and cached HTML where possible, from locations close to visitors.
- Avoid redirect chains. Each extra hop adds a round trip before the page even starts loading. Check with the Redirect Checker.
- Profile slow backends. Slow database queries, uncached API calls to third parties and underpowered hosting show up as high TTFB across every page.
Fixing INP (responsiveness)
INP measures the delay between an interaction and the next visual update. web.dev splits each interaction into input delay, processing time and presentation delay. Most problems come from JavaScript keeping the main thread busy.
- Break up long tasks. Split heavy work into smaller chunks and yield to the main thread between them, so the browser can respond to input.
- Do less in event handlers. Update the UI first, then defer non-urgent work such as analytics calls.
- Audit third-party scripts. Chat widgets, tag managers, A/B testing tools and ad scripts often dominate main-thread time. Remove what you don't use and load the rest later.
- Keep the DOM reasonable. Very large DOMs make rendering and updates slower.
- Avoid layout thrashing. Batch DOM reads and writes rather than alternating between them.
Fixing CLS (visual stability)
Most layout shifts have ordinary causes:
- Images and embeds without dimensions. Always set
widthandheight, or reserve space with CSSaspect-ratio. - Ads, banners and cookie notices inserted above existing content. Reserve their space up front, or overlay them instead of pushing content down.
- Web fonts that swap in with different metrics. Choose a close fallback font and an appropriate
font-displayvalue. - Animations of properties such as
toporleft. Animatetransforminstead.
Fonts
- Limit the number of families and weights. Each one is another download.
- Self-host fonts or preconnect to the font host so the connection starts early.
- Subset fonts to the characters you actually use.
- Preload only the one or two fonts that render text above the fold.
Caching static assets
Give versioned assets (files with a hash in the name) a long cache lifetime so returning visitors don't download them again:
Cache-Control: public, max-age=31536000, immutable
Keep HTML on a short cache lifetime, or use revalidation, so content updates appear quickly.
CMS-specific tips
Your platform decides which fixes are available. If you're analyzing a competitor's fast site, the CMS Detector shows what it runs on, which tells you what's possible on the same stack.
- WordPress: use full-page caching, audit plugins (each one can add CSS and JavaScript to every page), use an image optimization workflow, and pick a lightweight theme. Page builders often add heavy markup and scripts.
- Shopify: apps frequently inject scripts sitewide, even on pages that don't use them. Remove unused apps and check that the theme doesn't load assets for features you've switched off.
- Hosted builders (Wix, Squarespace and similar): you have less control over the stack, so focus on what you can control: image sizes, the number of embeds and third-party widgets, and page length.
- Custom and headless sites: watch the size of your JavaScript bundle and how much work hydration does. Server-render or statically generate content where possible.
A sensible order of work
- Pull field data for key templates and note which metric fails on which device type.
- Run lab tests on those templates and find the biggest contributor to the failing metric.
- Fix template-level causes first: hero images, render-blocking assets, heavy third-party scripts.
- Improve server response and caching.
- Re-test in the lab right away, then wait for field data to update over its 28-day window before you judge the result.
Speed is one part of site health. Our SEO audit checklist places it alongside crawlability, indexing and content.