That 42 is a simulation. It comes from Google loading your page exactly one time, on a pretend mid-range Android, over a throttled connection, from a data center you don’t pick and can’t see. Run it again in five minutes and you might get a 51. Or a 37. Nothing changed in between.
So don’t panic. Don’t close the tab either. There’s real information further down that page and almost nobody scrolls to it. Here’s how to read it, and what fixing it takes.
Is your PageSpeed Insights score real, or is it made up?
It’s real. It’s just answering a different question than the one you’re asking. The report stacks two data sets, and the big colored number belongs to the less important one.
Field data sits at the top. It’s the Chrome User Experience Report: anonymized measurements from real visitors on real phones, 28-day window, 75th percentile. Chrome-only, so your Safari visitors aren’t in there. Green means three of four Chrome visitors had it at least this good. This is the data Google uses.
Lab data is everything below, including the score. That’s Lighthouse: one synthetic load, network throttled, CPU slowed to a quarter speed, run once, so you have something to diagnose against. Google has said outright that the score is not a ranking factor. The field metrics are.
So if field data’s green and your lab score is 42, nothing’s on fire today. The diagnostics underneath are still the list of what starts hurting the day you add pages, photos, or another tracking script.
One catch. On a small site that field section will probably say there isn’t enough data, meaning Chrome hasn’t logged enough visits to report anonymously. Then the lab run is all you’ve got: read the diagnostics, ignore the number.
What do LCP, INP, and CLS actually mean?
Did the main thing show up, did the page respond when you tapped it, did it jump around while you were reading. That’s the whole list.
| Metric | What it’s asking | Target | Usual culprit |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How long until the biggest thing on screen draws? | Under 2.5 seconds | An enormous hero photo |
| INP (Interaction to Next Paint) | You tapped the menu. How long before anything happened? | Under 200 milliseconds | JavaScript tying up the phone |
| CLS (Cumulative Layout Shift) | Did the button move right as you went to tap it? | Under 0.1 | Images and embeds with no reserved space |
If a speed guide still talks about First Input Delay, it’s stale. INP replaced FID in March 2024, and it grades every interaction, not just the first.
Why is my website slow? The five real answers
In the order we check them, roughly the order they turn out to be the answer.
1. Your photos
Start here. It’s usually this one. Somebody shot a picture on their phone, uploaded it straight into WordPress, and it landed on the homepage at 4,000 pixels wide and four megabytes. On office wifi you’d never notice. On a phone in a parking lot with two bars, that one file is the experience.
Resize before uploading (a hero rarely needs to be wider than about 2,000px), then serve it as WebP or AVIF. Newer formats, same picture, a fraction of the size. A decent optimization plugin handles both, plus the fallback for older phones.
Telling somebody their speed problem is their own photographs is an awkward conversation. Not the fun answer. Usually the true one.
2. Everything your page builder loads before your content
Does Elementor slow down your site? Yes, and so does Divi. A builder has to be ready to render whatever you might drag onto the canvas, so it ships a generic stylesheet and JavaScript bundle covering features you’ll never use. Lighter builders ship less, but they all ship some. In your report that’s “reduce unused JavaScript” and “reduce unused CSS.”
AI site builders do the same for the same reason: they generate against a general-purpose component library, so you get the whole library whether the page uses four components or forty.
Fair about the size of it, though. A builder is rarely the whole gap between a bad score and a good one. It’s a slice, and often what stands between you and a passing INP.
3. The scripts you agreed to and forgot
A chat widget. Two analytics tools because nobody turned the old one off. A pixel from an ad campaign that ended two years ago. Each one fetches code from somebody else’s server, so part of your load time belongs to a company you cannot call.
Somebody has to go through the plugins and the header and footer scripts and cut what isn’t earning its place. Not once. Quarterly, forever, because the pile rebuilds itself. That’s what a care plan catches before it compounds for three years.
4. Fonts, done the expensive way
Three families, six weights each, pulled from a third-party host, so the browser opens a connection to another server before it can draw a letter. Cut to two families and three weights, self-host, preload the headline face.
5. Hosting
Real, and last on purpose. Cheap hosting shows up as a slow initial server response time. If that number’s high, hosting is the problem, and moving is a migration, not a setting: DNS, email, SSL, staging, and a window where the site can go dark if a step gets missed. If it isn’t high, a move buys nothing.
Why won’t a caching plugin fix this?
Because caching changes how fast the server hands the page over. It doesn’t delete the JavaScript the browser has to run once the page arrives. Bundled optimization plugins can defer that script, which buys real ground, but deferred work is still work.
A pre-baked copy of your HTML helps server response time and LCP. INP is the stubborn one: main-thread work on the visitor’s phone. Three hundred kilobytes of JavaScript served instantly is still three hundred kilobytes a budget Android has to parse and run. We ran that route on Divi builds for years. Whatever’s in the page to begin with is still your ceiling.
We rebuilt our own site. Here’s what I will and won’t claim.
Our old site ran a Divi-era stack. The current one is a custom theme on ACF Pro blocks, with the markup written for speed instead of patched for it afterward. You can see what that produces across our recent work.
Now the part where most agency posts publish a tidy before-and-after table assigning points to each change. Not doing it. It’d be fiction: we swapped theme, images, fonts and scripts in one pass and nobody isolated variables. Anyone selling you “compression was worth 14 points” is guessing.
What I’m confident about is the order. Dropping the builder’s CSS and JavaScript payload was the structural fix. Images were the biggest win available without touching the theme.
And the honest footnote. Speed by itself doesn’t create demand. It removes a reason to leave, which isn’t a reason to call. Which is why we’ve never sold a rebuild as a speed project: the same pass is where the page finally says what you do and puts the phone number where a thumb already is. Fast is the floor. The rest is the actual job.
What order should these get fixed in?
Same order whether it lands on our desk or the desk of whoever built the site.
- Resize and compress every image above the fold. No license cost, biggest single win, and across a hundred images it eats more of your week than you’d guess.
- Cut scripts and plugins nobody is actively using.
- Cut fonts to two families, three weights.
- Set width and height on images, reserve space for embeds. Kills most CLS.
- One caching and optimization plugin, configured once. Then stop chasing settings.
- Only now look at hosting.
- Still red on INP? That’s the builder’s floor, and no setting gets you under it. Foundations that don’t fight you are what we build for small business sites.
If you’re reading this at eleven at night because that’s when you finally had a minute: that list isn’t hard, it’s long, and it expands to fill whatever evening you feed it. It also doesn’t stay done. Images get compressed once, then a season of new posts goes up full size and you’re back at 42.
Maintenance is the line I’ll argue about when budgets get tight. Updates, backups and security patching are the difference between a slow site and no site. A slow site still takes calls. A hacked one is offline for a week.
What is a faster site actually worth?
You’ve seen the statistic. Some percentage of conversions lost per second of load time. Not repeating it: it traces back to enterprise retail measuring millions of sessions and says nothing about a plumbing company doing 600 visits a month.
Use your own numbers. Say 500 mobile visits a month and 15 calls, so 3%. If the homepage takes six seconds on a phone, some share of the people who never became one of those 15 left before the hero image drew. They don’t show up as a bounce, because the analytics script hadn’t run when they hit back. They don’t show up at all. That’s the real case for speed: the people you never see.
Questions we get about this
Why does my speed score change every time I run the test?
Because it’s one simulated load on shared infrastructure, and conditions vary between runs. Google documents the variance itself. A swing of several points with no code change is normal, so one run is never a verdict. Run it three times, take the middle.
What’s a good PageSpeed Insights score for a small business site?
Green field data matters more than any lab number. If the lab score is all you have: 90s excellent, 70s and 80s fine for a brochure site, under 50 on mobile means something structural is wrong and worth a proper look.
My site came out of an AI builder and the score is bad. Did I do something wrong?
No, and there’s no better prompt waiting for you. AI tools are genuinely good at producing a starting point, and a starting point is what you have. They ship a general component bundle and full-size imagery, and nothing in that process answers for how the page behaves on a four-year-old Android in a real visitor’s hand. It isn’t a skill you’re one tutorial from. It’s the part of a build that’s a job, and the part we get hired for.
Does a slow site hurt my Google rankings?
The score, no. Google doesn’t use Lighthouse scores in ranking at all. Core Web Vitals measured on real visitors do count, but Google calls them closer to a tiebreaker between comparable pages. On page four for a competitive term? Load time isn’t the reason. Usually the page doesn’t cover the topic, has nothing linking to it, or targets a phrase nobody in your city types. Different problem. Also ours.
Do I need a whole new website to fix this?
Often no, and I’d rather say that than sell you a rebuild you don’t need. Images, scripts and fonts get a lot of sites into the green without touching the theme. That’s a scoped project we run as a cleanup, or fold into a care plan so it stays fixed. The rebuild conversation starts when INP stays red after all of it, and our pricing and calculator are public if you want both numbers.
Your score is a smoke alarm, not a diagnosis. It knows something’s burning, not what. If you’d rather not be the one up a ladder at midnight with a nine-volt, send us the URL through the contact form. We’ll read the diagnostics, tell you which of the five it is, and quote the fix. Prefer numbers before humans? The calculator‘s public. Either way, stop refreshing the test. It’ll say 51 next time.