"My site feels slow" is one of those complaints that sounds vague but is actually measurable to three decimal places. Google has spent years turning the squishy feeling of slowness into a small set of hard numbers called Core Web Vitals — and then it went a step further and made those numbers a confirmed ranking signal. So a slow site isn't just annoying. It can quietly cap how high you rank and how many visitors stick around long enough to buy.
The good news: you don't need to be a developer to understand what's wrong. Most slow sites are slow for the same boring handful of reasons, and the diagnosis is free. The bad news: the report that tells you the problem is written for engineers, full of acronyms and red boxes, and it rarely tells you which fix to do first.
This guide fixes that. We'll translate the three metrics that matter, show you what "bad" looks like for each, explain why your phone score is worse than your desktop score, and end with the short list of fixes that buy you the most speed for the least effort.
By the end you'll know:
- What LCP, CLS, and INP actually measure — and the exact threshold for "good" on each
- The usual culprits behind a slow site, ranked by how often they're the real problem
- Why your mobile score looks so much worse than desktop (and why that's the one that counts)
- How to measure all of this for free in about ninety seconds
- The highest-leverage quick fixes you can hand to a developer — or do yourself
Part 1 — The Three Numbers Google Actually Cares About
Forget the overall "performance score" out of 100 for a minute. That number is a blended average that bounces around and tells you nothing actionable. The three metrics below are the ones Google uses as a ranking signal, and each maps to a real thing a human notices.
1. LCP — Largest Contentful Paint (is the main thing visible yet?)
LCP measures how long it takes for the biggest element on screen — usually your hero image, a headline, or a big block of text — to finish loading and render. It's the closest single number to "how long until the page looks ready."
Good: under 2.5 seconds. Needs work: 2.5–4s. Poor: over 4 seconds.
What "bad" looks like: you click a link, stare at a white screen or a half-drawn page, and the main image pops in two or three seconds late. On mobile, LCP is the number that's wrong most often — and it's almost always an oversized image or a slow server to blame.
What to do: find out what your LCP element is (PageSpeed Insights tells you, lower down in the report), then make that one element load faster. If it's an image, that means compressing it and serving it at the right size — more on that in Part 3.
2. CLS — Cumulative Layout Shift (does the page jump around?)
CLS measures visual stability. You know the experience: you go to tap a button, an ad or image loads above it, the whole page lurches down, and you tap the wrong thing. CLS puts a number on that jumpiness.
Good: under 0.1. Needs work: 0.1–0.25. Poor: over 0.25.
What "bad" looks like: text reflows as a web font swaps in, images shove content downward as they load, a cookie banner or ad pushes everything around. Anything that moves after the user can already see the page counts against you.
What to do: the fix is almost always "reserve the space in advance." Images and video should declare their width and height so the browser holds the slot before the file arrives. Ad slots and embeds should have a fixed container. This one is cheap to fix and very satisfying — a janky page can usually be made stable in an afternoon.
3. INP — Interaction to Next Paint (does it respond when I tap?)
INP measures responsiveness — the delay between you doing something (tapping, clicking, typing) and the page visibly reacting. It replaced the old "First Input Delay" metric in 2024 because it captures the whole interaction, not just the first tap.
Good: under 200 milliseconds. Needs work: 200–500ms. Poor: over 500ms.
What "bad" looks like: you tap a menu and it opens half a second later. You type in a search box and the letters appear in stutters. The page is visible but it feels stuck, because the browser is busy running heavy JavaScript instead of listening to you.
What to do: INP problems are almost always too much JavaScript — your own, or more often a pile of third-party scripts (chat widgets, analytics, A/B testing tools, tag managers). The fix is to cut, defer, or lazy-load scripts. This is the hardest of the three to fix yourself, but the easiest to diagnose: if your site feels laggy to use rather than slow to load, INP is your problem.
Part 2 — Why Mobile Scores Look So Much Worse (and Why It's the One That Counts)
Run the test on your homepage and you'll often see a green desktop score next to an angry orange or red mobile score. This is normal, and it's not a bug.
PageSpeed Insights deliberately throttles the mobile test to simulate a mid-range phone on a slower network — because that's what a real chunk of your visitors are using. A laptop on office wi-fi has a fast processor and a fat pipe; a four-year-old Android on a patchy mobile connection does not. The same heavy JavaScript that a desktop chews through instantly can choke a phone for seconds.
Why you should care about the mobile number specifically
Google predominantly uses the mobile version of your site to decide your rankings (this is "mobile-first indexing," and it's been the default for years). So when desktop is green and mobile is red, the red one is the score that's affecting your search position. Optimize for the phone, not the laptop you happen to be testing on.
Part 3 — The Usual Culprits, Ranked
Almost every slow site loses its time to the same short list. Here they are, roughly in order of how often they're the real problem.
1. Oversized images
The single most common cause of a slow site, full stop. People upload a 4000-pixel-wide, 3 MB photo straight off a phone or stock site and let the browser shrink it to fit a 600-pixel slot. The visitor still downloads the whole 3 MB.
What "bad" looks like: PageSpeed flags "Properly size images" or "Serve images in next-gen formats," and your LCP element is an image weighing more than a few hundred KB.
What to do: compress every image, serve it no larger than it's displayed, and use a modern format (WebP or AVIF). A hero image should usually be well under 200 KB. Free tools like Squoosh or your CMS's built-in image optimization will do most of this for you.
2. Render-blocking scripts and CSS
When the browser hits a script or stylesheet in the page's head, it can stop everything and wait for that file before drawing anything. Stack up a few of those and your visitor watches a blank screen while files download one after another.
What "bad" looks like: PageSpeed flags "Eliminate render-blocking resources" and lists a string of .js and .css files.
What to do: mark non-essential scripts defer or async so they load without blocking the page, and inline only the small bit of CSS needed for what's visible first. Most of this is a developer task, but it's a well-understood one.
3. Web fonts
Custom fonts are gorgeous and quietly expensive. The browser often hides your text until the font file arrives, or draws it in a fallback and then swaps — which causes layout shift (hello, CLS) on top of the delay.
What "bad" looks like: a flash of invisible or restyled text on load, and "Ensure text remains visible during webfont load" in the report.
What to do: limit how many font weights you load, use font-display: swap, and preload the one or two fonts that appear above the fold. If you're loading six weights of two font families, you're paying for fonts no one will notice are missing.
4. Third-party tags
This is the one that creeps up over years. Every analytics pixel, chat widget, heatmap tool, ad script, and marketing tag is code that loads on every page — usually code you don't control and can't optimize. Ten "harmless" tags add up to a sluggish, laggy site and a wrecked INP score.
What "bad" looks like: a long list of third-party domains in the report, and a site that feels unresponsive even though it looks loaded.
What to do: audit your tags ruthlessly. Open your tag manager and remove anything you're not actively using. Load chat widgets and non-critical tools after the page is interactive. Every tag should justify the speed it costs you.
5. No caching / slow server
If your server takes a long time just to send the first byte of the page (a metric called TTFB), nothing downstream can be fast — you're behind before the race starts. Cheap shared hosting, an unoptimized database, or no caching layer all show up here.
What "bad" looks like: a high "Initial server response time" warning, or a slow time-to-first-byte regardless of how light your images are.
What to do: turn on caching (most CMS platforms have a plugin or built-in setting), put a CDN like Cloudflare in front of your site, and if your host is consistently slow to respond, consider upgrading. Caching is often the single highest-leverage fix for a site that's slow everywhere.
Part 4 — How to Measure It in Ninety Seconds
You don't need to install anything. Go to PageSpeed Insights (pagespeed.web.dev), paste in your URL, and hit Analyze. Here's how to read what comes back without drowning in it:
1. Check the field data first (if it's there)
At the top, if your site gets enough traffic, you'll see real-world data from actual Chrome users over the last 28 days — labeled "Discover what your real users are experiencing." This is the data Google actually uses for ranking. If it's green across LCP, CLS, and INP, you're in good shape regardless of what the lab score says.
2. Then read the lab diagnostics
Below that is the simulated "lab" test with the score out of 100. Ignore the exact number. Scroll to the Diagnostics and Opportunities sections — that's where it tells you, in plain-ish terms, exactly which images are too big and which scripts are blocking. Note which issue maps to which of your three failing metrics.
3. Test the pages that matter, on mobile
Test your homepage, your top landing page, and your most important product or service page — and read the mobile tab, since that's the one that affects rankings. A site can have a fast homepage and a painfully slow checkout; you won't know unless you test more than one page.
If you want the on-page basics handled at the same time — titles, headings, broken links — our On-Page SEO Checklist pairs well with this, since speed and clean markup are both part of the same technical-SEO foundation.
This guide gets you a confident diagnosis and the highest-leverage fixes. What it can't do is the tedious, per-file forensic work of a full audit.
- It won't tell you exactly which third-party script is eating 800ms of your INP, or which specific CSS file is the render-blocker — that takes a waterfall trace.
- It won't measure every important page automatically, or track whether your scores got better or worse after you shipped a fix.
- It won't separate the field data from the lab data for you, or flag when a green lab score is masking a red real-world one.
- It won't translate the engineer-speak into a prioritized, "do this first" punch list you can hand straight to a developer.
That's exactly the gap our paid product fills.
If you'd rather not squint at diagnostics and guess which fix matters most, that's what Performance Pulse is for. Point it at your site and it pulls live Core Web Vitals from Google's own data, tests your key pages on both mobile and desktop, names the specific oversized images and offending scripts, and hands you a prioritized fix list in plain English — no acronyms left unexplained. It's a $19.99 one-time report — a fraction of an agency retainer, no subscription, delivered in under 24 hours. You can run a Performance Pulse on your site here and have your answer before the kettle boils.
Rather have it done for you? The Performance Pulse pulls the data, runs every check above, and hands you a prioritized, plain-English report in under 24 hours — a fraction of an agency retainer, no subscription, no upsell.