Free Checklist · Updated 2026-10

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

Free. You also get my weekly newsletter on SEO + AI search. Unsubscribe anytime.

How to use it
  1. Write down your three scores from section 1 before changing anything.
  2. Work through the fix that matches your worst metric first.
  3. 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

MetricPlain EnglishGoodPoor
LCP (Largest Contentful Paint)How fast the main thing on screen appears2.5 s or lessOver 4 s
INP (Interaction to Next Paint)How fast the page reacts when you tap or click200 ms or lessOver 500 ms
CLS (Cumulative Layout Shift)How much stuff jumps around while loading0.1 or lessOver 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

  1. Re-test the same pages

    Run PageSpeed Insights again on the exact URLs you tested before. Compare the lab numbers.

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

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

Free. You also get my weekly newsletter on SEO + AI search. Unsubscribe anytime.

FAQ

Frequently asked questions

What is a good page speed score?
Focus on Core Web Vitals rather than the 0 to 100 score: LCP 2.5 s or less, INP 200 ms or less and CLS 0.1 or less, for at least 75% of real visits.
Is site speed a Google ranking factor?
Google says Core Web Vitals are used by its ranking systems, but relevance comes first. A fast page with the wrong answer won't outrank a slower page with the right one.
Why is my PageSpeed score different every time?
The lab test runs once on simulated conditions, so it varies. The real-user field data at the top is based on many visits and is the number Google uses.
How long until Search Console shows my speed fix?
Field data reflects real visits over time, and Search Console's validation tracks for 28 days.