Google has been explicit about it for years: page experience, and specifically speed, is a ranking signal. But "make your site faster" is vague advice. What actually moves the needle is understanding the three Core Web Vitals metrics Google measures, knowing which one is failing on your site, and fixing the specific technical cause — not guessing and hoping.
This checklist walks through what's typically slowing sites down, how to diagnose it properly, and what to fix first for the biggest impact.
1What Core Web Vitals Actually Measure
Core Web Vitals aren't a single "speed score" — they're three separate metrics, each measuring a different kind of user frustration. A site can pass one and fail another, so treating "speed" as one problem usually means fixing the wrong thing first.
| Metric | What it measures | Good threshold |
|---|---|---|
| LCP Largest Contentful Paint |
Time until the largest visible element (hero image, headline) renders | ≤ 2.5s |
| INP Interaction to Next Paint |
Responsiveness — delay between a click/tap and visible feedback | ≤ 200ms |
| CLS Cumulative Layout Shift |
Visual stability — how much elements jump around while loading | ≤ 0.1 |
Google uses field data collected from real Chrome users (the Chrome UX Report) — not lab tests — to score your site. That means fixes have to hold up under real network conditions and real devices, not just a clean run in a testing tool.
2What's Usually Slowing LCP Down
LCP problems almost always trace back to one of a handful of causes. Work through these in order of likelihood:
- ✓Unoptimized hero images. A 4MB uncompressed banner image is the single most common LCP killer. Convert to WebP or AVIF and compress aggressively.
- ✓Render-blocking CSS and JavaScript. Scripts and stylesheets loaded in the
<head>withoutasyncordeferdelay everything below them. - ✓Slow server response time (TTFB). Cheap shared hosting, no caching layer, or an unoptimized database query can add seconds before any HTML even arrives.
- ✓No preloading for the hero element. If the largest element is a background image loaded via CSS, the browser often discovers it late — a
<link rel="preload">fixes this. - ✓Third-party embeds loading early. Chat widgets, video embeds, and font scripts placed high in the page compete for bandwidth with your actual content.
3What's Usually Causing Poor INP
INP replaced First Input Delay in 2024 and it's the metric most sites quietly fail without realizing it, because it only shows up when a real person interacts with the page.
- ✓Heavy JavaScript execution on the main thread. Large bundles, unoptimized React re-renders, or bloated analytics scripts block the browser from responding to taps and clicks.
- ✓Too many third-party scripts. Every ad tag, tracking pixel, and chat widget adds its own JavaScript that competes for processing time.
- ✓Long tasks that never yield. A single JavaScript task running longer than 50ms blocks all user interaction until it finishes.
- ✓Unoptimized event handlers. Expensive functions attached to scroll or input events without debouncing can freeze the interface.
4What's Usually Causing Layout Shift
CLS issues are visually obvious once you know what to look for — content jumping as the page loads — but the underlying causes are easy to miss in code review.
- ✓Images and embeds without set dimensions. If width and height aren't defined, the browser doesn't reserve space and content jumps when the asset loads.
- ✓Web fonts causing a "flash of unstyled text." When a custom font loads after a fallback font, text reflows and pushes content around.
- ✓Ads and embeds injected without reserved space. Dynamically inserted content above existing elements is the most common CLS complaint on publisher and e-commerce sites.
- ✓Animations that use layout-triggering properties. Animating
width,height, ortopinstead oftransformforces the browser to recalculate layout repeatedly.
5The Diagnostic Checklist
Before making any changes, run this sequence to find out exactly what's broken and where — guessing wastes development time on fixes that won't move your score.
Pull field data from PageSpeed Insights or Search Console
Start with real-user data, not a lab test. Search Console's Core Web Vitals report shows exactly which URL groups are failing and on which metric.
Run a Lighthouse audit in Chrome DevTools
Lighthouse gives you a prioritized list of specific opportunities — unused CSS, oversized images, render-blocking resources — ranked by estimated time savings.
Check the Performance panel for long tasks
Record a page load and interaction in DevTools' Performance tab to see exactly which scripts are blocking the main thread and for how long.
Audit third-party scripts individually
Use the Coverage tab or a tool like Request Map Generator to see how much weight each embedded script, tag, or widget is actually adding.
Test on a throttled mobile connection
Most traffic and most failures happen on mid-range mobile devices over 4G, not on your development machine over fiber. Always test throttled.
Re-test after every fix, not just at the end
Isolate changes so you know which fix actually improved the metric — bundling multiple fixes together makes it impossible to know what worked.
6Quick Wins vs. Structural Fixes
Not every fix takes the same effort, and it helps to separate what you can ship today from what needs a bigger engineering push.
Quick wins (hours, not days)
- ✓Compress and convert images to WebP or AVIF
- ✓Add
widthandheightattributes to every image and embed - ✓Add
font-display: swapto web font declarations - ✓Defer non-critical JavaScript and remove unused scripts
Structural fixes (needs planning)
- ✓Move to a CDN and enable proper server-side caching
- ✓Code-split large JavaScript bundles and lazy-load below-the-fold components
- ✓Re-architect how third-party scripts and ad tags are loaded
- ✓Migrate to a faster hosting stack if TTFB is consistently high
Speed isn't a one-time project — it's a maintenance habit. New images, new plugins, and new tracking scripts will keep eroding your Core Web Vitals unless you're monitoring field data regularly and re-auditing after every major content or design change.