Your 100 Is Tied Behind Your Back

Fresh out of a gastric bypass, Homer knots the loose skin behind his back and walks into the room.

From the front, he looks great. From any other angle, there is a situation happening back there.

That is a lot of WordPress sites with a 100 in Performance.

I am not here to tell you the score does not matter

I posted mine. Four greens on mobile, and I wrote a whole article about it.

Being proud of a fast site is correct. A good score usually means somebody made good decisions, and those decisions were probably not fun to defend in a meeting.

What I am arguing with is the next step, the one where the number stops being evidence of a well-built site and starts being a substitute for one. Especially when the number was not earned. It was produced.

What the 100 actually is

It helps to say out loud what the score is made of, because most people quoting it have never looked.

The Performance score in Lighthouse is a weighted average of five lab metrics. Since Lighthouse 10, the weights are: Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10%, Speed Index 10%.

Lab means exactly what it sounds like. One URL, loaded once, cold, from a datacenter, on a simulated mid-range phone with a throttled connection, by a robot that never scrolls, never taps anything, never fills in a form and never comes back for a second page.

That is a perfectly reasonable instrument. It is also a very specific one, and it is not your audience.

Lab data and field data are two different reports

PageSpeed Insights shows you both and a lot of people read them as one thing.

The top section, when it appears, is field data from the Chrome User Experience Report: real Chrome users, real devices, real networks, the 75th percentile over a rolling 28 day window. It only shows up if your site gets enough traffic to produce a sample at all, which for most small business sites it does not.

The bottom section is the Lighthouse run, and that is where the 0 to 100 comes from.

So the score is lab. The signal Google's ranking systems look at is field. Those can disagree, and when they disagree, the field one is the one with actual humans in it.

"I have 100" and "my visitors are having a miserable time" are not contradictory statements. They are two different instruments pointed at two different things.

How the knot gets tied

Here is the part that is uncomfortable, because the toggles have friendly names and they live in a plugin a client paid for.

Delay JavaScript until user interaction. This is the big one. Total Blocking Time is 30% of the score, and Lighthouse never interacts with the page. So every script you pushed behind the first tap costs exactly zero in the measurement. Meanwhile your real visitor touches the menu and pays the entire bill at once, in one long task, on the interaction they actually cared about. That delay is invisible to TBT and lands squarely in INP, which is the metric with real users in it.

Load all CSS asynchronously and strip "unused" CSS. You removed the render-blocking resource, so the paint happens sooner and the lab is delighted. Your visitor gets a flash of unstyled content and then a reflow. In the lab, CLS is only collected during the load window. In the field, it is collected for the entire life of the page.

Lazy-load everything, including the hero image. Usually this one is bad enough that it shows up in LCP anyway, which does not stop people from shipping it.

Serve the optimized pipeline only to known bot user agents. This one has a name in Google's documentation and the name is cloaking. It is a spam policy violation, which is a separate and larger problem than merely lying to yourself.

Look at what those four have in common. Not one of them makes the page do less work. They move the work to a moment the instrument is not watching, and the only moment the instrument is not watching is the moment your user is.

This is not an argument against cache plugins

It would be a stupid argument. A page cache is good engineering.

Rebuilding the same HTML from PHP and a database on every single request, for a page that changed last March, is pure waste. Caching it removes that waste for everybody, bots and humans alike, and it shows up as a lower TTFB, which is one of the few numbers that is honestly good for everyone. WP Rocket and LiteSpeed Cache do that job well.

The problem is never the cache tab. It is the optimization tab next to it, where the switches stop making the site faster and start making the measurement shorter.

There is a clean test for which one you are doing: does this change make the page better for a person who cannot see the report? If the honest answer is no, you did not optimize anything. You hid it.

So why do we want the 100 at all

Here is where I disagree with almost every SEO deck I have ever been sent.

It is not so Google will like you. Google ranks slow pages constantly. You can be mediocre on every vital and sit at the top of a competitive result, because relevance and quality of content do most of the work, and Google's own documentation is explicit that page experience does not rescue a page that is not useful. Core Web Vitals are a real input. They are a small one, and they read field data, not your Lighthouse score.

So why did Google spend years building this apparatus, publishing thresholds, swapping FID for INP in 2024, and shipping it into every SEO tool on earth?

Because they needed an objective, comparable, non-negotiable proxy for a thing that is otherwise pure opinion: was this a decent experience?

Read the three vitals as questions a person asks without words.

LCP: did the thing I came for show up, or am I looking at a white rectangle wondering if I typed the address wrong?

INP: when I touched it, did it answer?

CLS: did it stay where I put it, or did a banner load late and move the button under my thumb?

That is the whole ambition. Not speed as a virtue. Not a number as a tribute. Three questions, translated out of human complaint and into something you can put in a dashboard and argue about with a developer.

The crawl budget thing, said precisely

The other claim I hear is that a fast site gets crawled better, and this one is true with an asterisk big enough to matter.

Crawl budget, in the sense Google uses the term, is a concern for very large sites. If you have four hundred URLs, it is not your problem and it was never going to be.

What speed does move is crawl rate, and the part of speed that moves it is server response time, not your Lighthouse score. A server that answers fast gets pulled harder. A server that strains makes Googlebot back off. Clean, semantic HTML that does not need JavaScript executed before the content exists is cheaper to parse, cheaper to index and, increasingly, cheaper for a model to ingest and quote.

Notice that none of that is helped by deferring your scripts. TTFB and honest markup are doing that work. The optimization toggles are not invited.

What you actually bought

So you tie the knot. The report comes back green, the client is happy, the screenshot goes in the Slack channel.

Nothing about the experience changed. The page still takes three seconds to become usable, the menu still ignores the first tap, the layout still jumps once the font arrives. Those are not abstract failures. People leave, do not convert, do not call, and do not come back, and that behavior is visible in your analytics whether or not anyone ever calls it a ranking factor.

I have written about this exact mechanism in a completely different context: a measure that becomes a target stops being a good measure. It fails the same way in a QA dashboard and in a performance report, and it fails without anybody doing anything they would describe as dishonest. Every individual toggle was defensible. The number improved the whole time.

The audit nobody runs

Close the tab with the report in it.

Open your own site on your own phone. On mobile data, not the office wifi. In a private window, so you are not quietly logged in and being served some warmed-up version of reality.

Then use it. Tap the menu. Submit the form. Go to the second page. Click the phone number. Read a paragraph while the images are still arriving.

If you flinch at any point, that flinch is the metric. You just ran a better audit than GTmetrix did, because you did the one thing the robot cannot do, which is care.

Build it so the score is a consequence

The sites that score well without anybody gaming anything are not the product of a plugin. They are the product of a few boring questions asked early.

What is this page for. What has to be visible in the first second. What is the one thing we want the visitor to do. What can be deleted entirely.

That last one is the only optimization that is not a trade. Deferring moves a cost to the user's side of the table. Removing retires it. Every script you do not ship is a script that cannot block, cannot shift the layout and cannot make the first tap expensive.

And most of those questions are not developer questions. Deciding what a page is for belongs to strategy, the brand belongs to design, and somebody whose job is to assume you got it wrong has to look at it before a visitor does. That is part of why nobody ships a site like this alone.

Get that right and the 100 shows up on its own, as a byproduct, with nothing tied behind it.

The angle the meme is about

Homer's trick works on exactly one audience: the person standing directly in front of him.

Everybody else walks around.

Your users are already behind you.