Site Speed Checklist: Core Web Vitals Fixes for Small Business Sites

Why speed is a sales problem, not just SEO

Google says Core Web Vitals are used by its ranking systems, but it always tries to show the most relevant page, even when page experience is weaker. So speed rarely beats a better answer. Where it hurts more is after the click: a buyer on a phone who waits for a blank screen, or taps a button and nothing happens, leaves before seeing your price.

That's why this checklist starts with your money pages, not your blog. A fast homepage with a slow booking page still loses the sale.

You'll see old stats like '53% of mobile visitors leave after 3 seconds' quoted everywhere. That figure comes from a 2016-era Google study and isn't in Google's current docs, so don't build a plan on it. Your own numbers are better: compare conversion rate on fast and slow pages in your analytics.

How to read PageSpeed Insights and Search Console

• Read the top section (field data) before the 0 to 100 score

  The top section is real-user data from Chrome (CrUX), over the last 28 days, when there's enough traffic. The score below is a single lab test on a simulated phone.

• Check whether the field data is for 'This URL' or 'Origin'

  Low-traffic pages often fall back to the whole site's data. That's fine, just know which you're reading.

• 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.

• Use the 'Diagnose performance issues' list as hints, not orders

  It lists everything it can find. Start with the items tied to your failing metric.

Which fix first? (decision table)

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 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 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.

• Replace auto-playing sliders with one strong image

  Practical advice: sliders add scripts and often delay the main image.

• Lazy-load images further down the page

  loading="lazy" on below-the-fold images saves bandwidth for what's on screen first.

Fix 2: fonts, scripts and server (LCP and INP)

• Remove plugins, chat widgets, trackers and pop-up tools you don't use

  web.dev says to reduce script evaluation during load to cut input delay. Which ones to cut is practical advice: start with anything nobody has used in 3 months.

• Avoid synchronous scripts in the <head>

  They block rendering and delay LCP. Ask for defer or async.

• Ask your developer to break up long JavaScript tasks

  web.dev's main INP fix: do less work in each event handler and yield to the main thread (for example with setTimeout) so the page can paint.

• Keep the page's HTML lean (fewer nested elements, no giant hidden menus)

  web.dev says large DOMs make rendering after each interaction more expensive.

• Use fewer font files and preload the one you need above the fold

  Fewer fonts load faster; preloading the critical font 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. PageSpeed Insights shows TTFB under its diagnostics.

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.

Copy-paste: speed ticket for your developer

Subject: Core Web Vitals fix: [LCP / INP / CLS] on [page type]

Hi [name],

Search Console > Core Web Vitals (Mobile) marks [number] URLs as Poor for [metric].
Example URL: [url]
PageSpeed Insights field data (mobile): LCP __ s, INP __ ms, CLS __
Target: LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less (Google's 'good' at the 75th percentile).

What I've already done: [e.g. compressed hero images, removed 2 plugins]
What I think is left (from PageSpeed diagnostics): [paste top 3 items]

Please fix on the template, not just this one page, so the whole URL group improves. Tell me when it's live and I'll start validation in Search Console.

Thanks,
[you]

Page: ____
Date before: ____   LCP __ s  INP __ ms  CLS __   (field / lab)
Change made: ____
Date after: ____   LCP __ s  INP __ ms  CLS __   (lab now, field after ~28 days)
Search Console validation started: ____   Result: ____

Page: /emergency-plumber/ (mobile)
Before: LCP 4.6 s (Poor), INP 180 ms, CLS 0.02
Cause found: 2.8 MB hero photo, lazy-loaded by the theme
Change: resized to 1200 px, saved as WebP (~180 KB), removed lazy-load, added fetchpriority="high"
After (lab): LCP 2.1 s
Next: start validation, re-check field data in 4 weeks

After you fix

1. Re-test the same pages

   Run PageSpeed Insights again on the exact URLs you tested before. Compare the lab numbers. Run it 2 or 3 times; lab scores vary a little each run.

2. Start validation in Search Console

   In the Core Web Vitals report, open the issue and click Start tracking. Google monitors for 28 days; the issue passes if no affected URLs show up in that window. It doesn't trigger re-indexing.

3. Keep perspective

   Speed helps most where many good pages compete, and it helps sales either way. Once your money pages are 'good', stop tuning and go back to content.

Common mistakes

• Chasing 100/100 in PageSpeed Insights

  The lab score is a diagnosis. Google uses real-user Core Web Vitals.

• Only testing on desktop

  Mobile is usually slower and is what Google indexes first.

• Installing a speed plugin on top of a heavy theme and stopping there

  Practical advice: plugins can't fully fix a page that loads too much. Remove first, then optimise.

• Lazy-loading every image, including the hero

  It makes LCP slower, not faster.

• Judging a fix the next day in Search Console

  Field data is a 28-day view. Use the lab test for quick feedback.

• Expecting speed alone to lift rankings

  Google says relevance comes first. Speed is a tie-breaker and a sales lever.