A site can score 100 on Lighthouse and still feel slow. It can also get a mediocre score in one isolated test and work well for most users. The difference is what each tool measures and under which conditions. Lighthouse is for finding problems. Real data is for knowing which ones matter.
Lighthouse measures a controlled scenario
When we run Lighthouse, the test happens under defined conditions. An emulated device. A simulated network speed. A specific page load.
That's useful because it lets you compare changes in a relatively stable environment. But a real user could be coming in from a different phone, a different connection, a different location, with extensions, cookies, cache, and resources loaded from a previous session.
The real experience is never just one thing.
Core Web Vitals look at something else
Core Web Vitals try to measure how the site behaves for real users. The three main metrics are: LCP — how long it takes for the main content to appear. INP — how long the site takes to respond when the user interacts with it.
CLS — how much the interface shifts while loading. They're not enough to describe a site's entire experience, but they help detect problems that tend to directly affect the perception of speed. And the important part is that Google can evaluate this data from real usage, not just a synthetic test.
A high LCP isn't always fixed by compressing images
The hero image is usually the first suspect. Sometimes it is. But there can also be a server taking too long to generate the page, a font blocking rendering, critical CSS arriving late, or JavaScript delaying content from appearing. Optimizing only the image's weight can shave off a few milliseconds and leave the main problem untouched.
It's worth looking at the whole chain: server → HTML → CSS → font → image → render. The metric shows the symptom. The job is finding where it starts.
INP tends to reveal debt you can't see on load
A site can open fast and feel heavy the moment you try to use it. Menus that respond late. Filters that freeze the interface. Fields that take a while to react.
Buttons that trigger too much JavaScript. INP does a pretty good job of exposing that kind of problem. And often the culprit isn't our main code. It can be an analytics script, an external widget, a chat, a marketing tool, or several plugins running work on the same thread.
Each dependency looks small on its own. Together, they can turn a simple interaction into a visible wait.
CLS is usually the sum of small decisions
An image without reserved dimensions. A font that changes the text width when it loads. A banner that appears after the content. A component that injects space once it finishes initializing.
None of that looks serious on its own. But if the interface shifts while the user is trying to read or click, the experience feels unstable. The fix usually doesn't require a sophisticated technique. Often it's enough to reserve space correctly and avoid letting late elements reorganize the whole page.
Third-party scripts deserve suspicion
A website can be very well built and still load: analytics, ad pixels, maps, players, chats, embedded forms, and tracking tools. All of that competes for the same resources. That's why a performance audit that only looks at our bundle falls short.
You also have to ask:
What are we loading that actually needs to run right now?
Some things can be delayed. Others can be loaded after an interaction. And some probably shouldn't be there at all.
Don't optimize for the number
Chasing a 100 can mean spending hours on improvements no user will ever notice. The priority should be problems that affect a meaningful share of visits. If the site has a bad LCP for real mobile users, that matters. If Lighthouse drops two points because it flags a minor recommendation on an internal page with almost no traffic, it's probably not urgent.
Performance is also prioritization.
Measure before and after
An optimization without measurement ends up being just an opinion. Before touching anything, it's worth having a baseline. After the change, you need to check whether it actually improved. And when we talk about field data, keep in mind results don't necessarily show up right away. New visits need to accumulate for the trend to shift.
The sequence should be simple: measure → identify → change → measure again. Not installing five optimization plugins and hoping for the best.
In WordPress, the cause can be far from the frontend
In WordPress, it's easy to focus only on CSS and JavaScript. But a poor LCP can also start with a high TTFB. Slow queries. Plugins doing unnecessary work.
The cause might also be an external API blocking PHP, bloated autoload data, poorly configured caching, or resources generated dynamically when they could be served directly. If the server takes too long to deliver the first byte, the browser is already starting the race from behind. The optimization has to cover the whole path.
The goal is for the site to feel fast
Core Web Vitals, Lighthouse, and PageSpeed Insights are instruments, not the product. They're useful for finding where to look and checking whether a change had an effect. But the result that actually matters is pretty simple: the page shows up fast, doesn't jump around while loading, and responds when someone tries to use it.
The score guides the diagnosis. Validation ends when the change improves the real experience and field data confirms it.