Site Speed Checklist: Core Web Vitals Fixes for Small Business Sites
What LCP, INP and CLS mean in plain English, how to read your scores, and the image, script and layout fixes that move them.
A one-page site speed checklist built from Google's own Core Web Vitals guidance. Check your real scores, then work through the fixes for images, scripts and layout shifts in order.
For: Small business owners and founders whose site feels slow on phones and who want to know what to fix, or what to ask a developer to fix.
- The 3 Core Web Vitals in plain English · 3
- Check your real scores · 5
- Fix 1: images (usually the LCP problem) · 6
- Fix 2: fonts and scripts (LCP and INP) · 6
- Fix 3: layout shifts and pop-ups (CLS) · 5
- After you fix · 3
- Write down your three scores from section 1 before changing anything.
- Work through the fix that matches your worst metric first.
- Re-test the same pages after each change, and wait for real-user data in Search Console.
The 3 Core Web Vitals in plain English
| Metric | Plain English | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How fast the main thing on screen appears | 2.5 s or less | Over 4 s |
| INP (Interaction to Next Paint) | How fast the page reacts when you tap or click | 200 ms or less | Over 500 ms |
| CLS (Cumulative Layout Shift) | How much stuff jumps around while loading | 0.1 or less | Over 0.25 |
Check your real scores
- Run your homepage and main money page in PageSpeed Insights (pagespeed.web.dev), Mobile tab first.
The top section is real-user data from Chrome (when there's enough traffic); the lower section is a lab test.
- Read the field data, not just the 0 to 100 score.
Google judges Core Web Vitals at the 75th percentile of real page loads, split by mobile and desktop. The lab score is a diagnosis tool.
- Open Search Console > Core Web Vitals.
It groups similar URLs and labels them Good, Need improvement or Poor using real-user CrUX data. A group takes the status of its worst metric.
- Note which metric fails. Fix that one first.
Each metric has different causes. Image fixes won't help a poor INP.
- Know that Lighthouse can't measure INP.
Lab tests have no real user taps, so Lighthouse shows Total Blocking Time as a stand-in.
Fix 1: images (usually the LCP problem)
- Compress big images and serve them in WebP or AVIF.
web.dev lists modern formats and compression as ways to cut LCP resource load time. Squoosh (squoosh.app) does this free in your browser.
- Resize images to the size they're shown at.
A 4000 px photo in a 600 px slot is wasted download.
- Never lazy-load the main hero image.
web.dev says lazy-loading the LCP image always causes unnecessary delay.
- Add fetchpriority="high" to the hero image, and only one or two images.
Tells the browser to fetch it first; using it on many images cancels the benefit.
- Put the hero image in the HTML as an <img>, not only as a CSS background or JavaScript slider.
The browser finds it sooner. If it must come from CSS or JS, preload it.
- Lazy-load images further down the page.
Saves bandwidth for what's on screen first. (loading="lazy" on below-the-fold images.)
Fix 2: fonts and scripts (LCP and INP)
- Remove plugins, chat widgets, trackers and pop-up tools you don't use.
Every script competes for the main thread. web.dev: reduce script evaluation work during load to cut input delay. (Which ones to cut is practical advice.)
- Avoid synchronous scripts in the <head>.
They block rendering and delay LCP.
- Ask your developer to break up long JavaScript tasks.
web.dev's main INP fix: split long tasks and yield to the main thread.
- Keep the page's HTML lean (fewer nested elements, no giant hidden menus).
Large DOMs make every interaction slower to render.
- Use fewer font files and preload the one you need above the fold.
Smaller fonts load faster; preloading critical fonts helps both LCP and CLS.
- Use a CDN or a faster host if the first byte is slow.
web.dev lists minimizing redirects and using CDNs to cut Time to First Byte.
Fix 3: layout shifts and pop-ups (CLS)
- Give every image and video width and height attributes (or CSS aspect-ratio).
The browser reserves the space before the file loads.
- Reserve space for ads, embeds, maps and iframes.
Use min-height or aspect-ratio so the page doesn't jump when they load.
- Don't push in banners, cookie bars or sign-up bars at the top after load.
Content injected near the top causes the biggest shifts. Overlay it, or reserve space.
- Animate with transform, not top/left/height.
Those properties trigger layout changes that count as shifts.
- Pick a fallback font close in size to your web font (or use size-adjust / font-display: optional).
Stops text jumping when the web font swaps in.
After you fix
- Re-test the same pages
Run PageSpeed Insights again on the exact URLs you tested before. Compare the lab numbers.
- Start validation in Search Console
In the Core Web Vitals report, open the issue and click to start tracking. Google monitors for 28 days; the issue passes if no affected URLs show up in that window.
- Keep perspective
Google says Core Web Vitals are used by its ranking systems, but it always tries to show the most relevant content even when page experience is weak. Speed helps most where many good pages compete, and it helps sales either way.
Unlock the full checklist
Everything above, plus the branded PDF to keep.