A perfect Lighthouse score is the easiest way to lose three hours and end up with a slightly faster homepage that still doesn’t convert. The score measures what’s measurable in 30 seconds inside a browser; the things that actually drive revenue impact sit outside that window. Here’s what to look at instead.
If you haven’t used it: Lighthouse is a free audit built into the Google Chrome browser. It loads a single page in a controlled emulator and gives it a score out of 100, along with a list of suggested fixes. Agencies and procurement teams tend to look at that score first, which is why it became a number people chase. The trouble is that the audit runs in a vacuum, and your visitors don’t.
Quick Answer
Lighthouse measures what a single synthetic page load looks like under controlled conditions. Real performance is what your actual visitors experience across many pages, devices, and network conditions over time — and the gap between those two pictures is where most WordPress sites silently lose conversions.
Optimise for the second picture. Use Lighthouse only as a debugging surface, not a target.
What Lighthouse measures (and what it doesn’t)
Lighthouse runs a single page in a controlled emulator with throttling presets and reports a composite score. That’s useful for catching obvious regressions and for the dev team. It is not what your visitor experiences.
What Lighthouse does not see:
- Cache state — your real users hit warm caches; Lighthouse always tests cold.
- Return visits — repeat sessions are dramatically faster, and Lighthouse can’t simulate them.
- Network variation — a fixed throttle is not the long tail of real mobile networks.
- Plugin behaviour under load — Lighthouse runs against an idle server with one synthetic request; production plugins behave differently when fifty requests hit at once.
- Third-party script timing in production — analytics, tag managers, and live chat behave differently in a real browser session than in a Lighthouse run.
The score is a debugging surface. Treat it like the check-engine light, not the speedometer.
The metrics that actually predict revenue impact
Two layers matter: the SEO floor (Core Web Vitals) and the UX bar above it (real-user monitoring).
Core Web Vitals are the threshold Google uses for ranking. There are three of them — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — and the current targets are:
Above the floor, the metrics that map to revenue are:
- Real-user monitoring (RUM) percentiles — track the 75th-percentile (p75) and 95th-percentile (p95) LCP and INP per template. The average is misleading; the slow tail is where users abandon.
- Bounce rate by device type — if mobile bounces 12 points higher than desktop, performance is probably the cause.
- Time-to-interactive on conversion-critical templates — your homepage is not where you make money. Measure your service pages, your contact page, and your highest-converting lead magnets.
If you only watch one number, watch p75 LCP on the templates that get the most service-page traffic. That number changes when something real has changed.
Where WordPress slows itself down
WordPress overhead is the single biggest source of performance debt on a typical service business site, and Lighthouse rarely surfaces it because the bloat happens server-side before the HTML reaches the browser.
The usual suspects, in order of how much damage they do:
- Plugins running on every request. Most “set it and forget it” plugins register hooks that fire on every page load, whether they’re needed or not. A site with 30 plugins typically has 5-8 that contribute meaningful overhead.
- Unscoped query loops. Themes that re-query posts in the sidebar or footer on every page generate database trips that should be cached.
- Pile-up of plugin content modifications. Every active plugin gets a turn to modify the page content before it’s sent to the browser; the cumulative cost on a content-heavy page can add 200-400ms before any HTML is rendered.
- Missing object cache. Without a persistent object cache, WordPress hits the database for every option, term, and meta lookup. Hosts that don’t ship object cache are sites that will never be fast.
- Fragment caching gaps. Header, footer, and sidebar partials that don’t get cached because they reference the current user, the current cart, or the current location.
The diagnostic tool here is not Lighthouse — it’s a query-and-hook profiler such as Query Monitor running on a staging clone of your site, with the slow-query log enabled.
The three fixes that actually change real-world performance
Once you’ve measured the actual problem, the three highest-ROI interventions, in order:
- Cache-first architecture. Four layers of caching: page cache (the rendered HTML), object cache (database lookups), code cache (compiled PHP), and aggressive HTTP cache headers on static assets like images and stylesheets. Most managed WordPress hosts ship two of these four; getting all four in place typically halves p75 LCP without touching application code.
- Plugin audit. Disable plugins one by one on staging and re-measure. Anything that adds more than 50ms to a page load needs a justification — either it’s load-bearing for a feature, or it’s coming out. The goal isn’t fewer plugins; it’s plugins that earn their cost.
- Image pipeline. Modern image formats — WebP or AVIF, both more efficient than JPEG and PNG — as the served format, with JPEG or PNG fallback for browsers that don’t support them; properly sized variants for the actual breakpoints in use; native lazy-loading on everything below the fold; the LCP image preloaded explicitly. Most WordPress sites ship images 3-5× larger than the rendered size — this fix alone often moves CLS and LCP by enough to flip a Core Web Vitals score from “Needs Improvement” to “Good”.
Anything past these three is fine-tuning — important fine-tuning, but the gains are smaller and the effort is larger.
Common mistakes that game the score without helping users
The Lighthouse score is gameable. The user experience is not. For the full pattern of how optimisation efforts turn counterproductive, the over-optimisation post maps the failure modes. Common ways teams chase the score and regress real performance:
- Loading the LCP image as low-priority. A
loading="lazy"on the hero image takes a tenth of a second off the simulated load and adds half a second to the real one. - Defer-everything JavaScript strategy. Deferring third-party scripts is good; deferring critical UI handlers turns the first interaction into a stutter. INP regresses, and INP is part of the ranking signal.
- Critical CSS inlining without a path strategy. The first page is fast; the second page redownloads everything because the critical CSS isn’t reused. Net new render time goes up across the session.
- Score-chasing the homepage while leaving service pages slow. The homepage usually doesn’t convert. The service page does. A site that scores 95 out of 100 on the homepage but 60 on the service pages is worse than the inverse.
The pattern these four mistakes share is what makes them tempting: each one nudges the Lighthouse number in the right direction. The team that’s been told “get the score above 90” has earned the same response from every one of these moves. The score didn’t ask them to measure the user; it only asked them to game itself, and the easiest path was to give the test what it wanted instead of asking what the test was a proxy for.
A 15-minute audit you can run today
Before you spend a half-day on a Lighthouse score, run this:
- Open Chrome DevTools and switch to the Network tab.
- Throttle the connection to “Slow 4G” and set CPU throttling to 4× slowdown.
- Disable the cache (checkbox at the top of the Network tab).
- Hard reload the most important page on your site — your top-converting service page, not your homepage.
- Note the three slowest items by transfer size and the three slowest by load time.
- Repeat for one other template type (archive, blog post, contact).
If the slowest items are the same across templates, you have a sitewide problem (cache, theme, font). If they’re different, you have a template-specific problem (a plugin scoped to that template, a unique third-party script). The diagnosis takes ten minutes and tells you where to spend the next ten hours.
When to bring in a specialist
Most performance work is DIY-able if you have a long afternoon and a willingness to break things on staging. Where it stops being DIY-able:
- Server-side bottlenecks that need host-level access (web-server tuning, database slow-query logs, cache-server configuration)
- Cache misconfiguration that shows different behaviour on different pages
- Plugin conflicts where two plugins compete on the same hook and the resolution requires reading both source codes
- Template-level slowness on conversion-critical pages where any change risks the conversion path
The sites that quietly outperform their Lighthouse scores are usually the ones the team stopped chasing the score for. The audit number sits somewhere in the high-70s or low-80s, real-user p75 LCP holds under 2.5 seconds on the templates that actually convert, and the team measures the metrics that map to revenue rather than the composite number a synthetic audit produces. That’s what real performance looks like from the inside — boring, anchored to the user experience, and uncoupled from the number procurement asked about first.
Last reviewed June 1, 2026.
Rate and review this content
Be the first to rate this. Submissions are reviewed before they appear.