If you've read our Website Speed 101 post, you already know the three Core Web Vitals and their targets. This one's different. It's about what actually breaks them, how to check your own scores, and what to do about it. No code involved.

Quick refresher on the numbers

Google's current official targets, straight from its own documentation:

  • LCP (how fast the main content loads): 2.5 seconds or faster is good.
  • INP (how fast the site responds to a tap or click): under 200 milliseconds is good.
  • CLS (how much things jump around while loading): under 0.1 is good.

Some sites claim these have tightened recently. Google's own current documentation still lists these exact numbers.

2.5s

Google's "good" target for LCP -- the moment the main content of your page shows up. Most small business sites that miss it are losing time to one oversized image.

What actually breaks each Core Web Vital

LCP usually fails because of:

  • A giant, uncompressed hero image
  • The main image accidentally set to "lazy load," so it waits instead of loading first
  • A slow web host or server
  • Too much CSS and JavaScript loading before anything shows up on screen

CLS usually fails because of:

  • Images or ads without a reserved size, so the page jumps when they load in
  • Custom fonts that swap in late, shifting text around
  • Banners, popups, or "load more" sections getting injected above what's already on screen

INP usually fails because of:

  • Too many third-party scripts -- chat widgets, ad trackers, embedded videos, and analytics tools all stacked on one page
  • A page builder or theme doing more behind-the-scenes work than it needs to

Notice a pattern? Almost all of it traces back to images, fonts, and other people's scripts. Not your writing, not your design choices -- the technical plumbing underneath.

How to check your own score (5 minutes, no login)

Go to pagespeed.web.dev, paste in your URL, and hit enter.

You'll get two kinds of data. Field data is what real visitors actually experienced -- the honest number. Lab data is one simulated test run, useful for spotting specific problems even if your site doesn't get enough traffic for field data yet.

Below the scores, Google lists opportunities -- plain-language fixes, ranked by impact. You don't have to understand the code. You just need to hand that list to whoever manages your site.

If your site is set up in Google Search Console, its Core Web Vitals report shows real visitor data across your whole site, grouped by page type, so you can spot which pages are struggling.

What to actually ask for

You don't need to become a developer. You need to ask the right questions.

Try this: run your homepage and your most important service page through PageSpeed Insights this week. Screenshot the list of opportunities. Send it to your host, your web person, or your page builder's support team with one sentence: "Can you fix these?"

Common, low-drama fixes that don't require a redesign:

  • Compress and resize images (many hosts and plugins do this automatically once it's turned on)
  • Turn off lazy-loading on the main hero image only
  • Remove chat widgets or trackers you're not actually using
  • Reserve space for images and ads so nothing jumps around

Is this actually worth fixing?

Google says good Core Web Vitals, "along with other page experience aspects, aligns with what our core ranking systems seek to reward." It's a real signal, but one piece of a much bigger picture -- not a dominant ranking factor on its own.

So don't panic over one poor score. Do fix the obvious stuff, because slow, jumpy pages lose customers directly, whatever Google thinks.

Try this this week

  1. Run your homepage through pagespeed.web.dev. Look at the phone results first -- that's where most of your visitors are.
  2. Screenshot the top three opportunities. Don't worry about what they mean.
  3. Send them to whoever manages your site with a one-line ask: "Can you fix these?"

That's the whole assignment. No new tools, no new skills.

If you'd rather skip straight to knowing where you stand, GIT Technology runs a free website speed and visibility check for Irvine and Orange County businesses -- plain-English results, no pressure.

Frequently asked questions

What's the difference between field data and lab data?
Field data is real visitor experience, collected from actual Chrome users. Lab data is one simulated test. Field data is more honest; lab data is faster to get and useful for low-traffic sites.

Do I need a developer to fix Core Web Vitals issues?
Often no. Many fixes are settings -- image compression, turning off lazy-load on one image, removing unused scripts -- that a host or page builder's support team can handle.

Are Core Web Vitals a big deal for Google rankings?
They're a real signal, but Google describes them as aligning with what its ranking systems reward, not as a dominant factor on their own. Worth fixing, not worth losing sleep over.

How often should I check my scores?
Every month or two is plenty for most small business sites, unless you've just made a major change to the site.

Is this the same as the Website Speed 101 article?
No. That one covers the basics and Google's targets. This one is about diagnosing what's actually broken and what to ask for.

A fast page is a courtesy to every visitor. Five minutes with PageSpeed Insights tells you whether you're offering it.