For a long time, PageSpeed Insights was a default reference point for performance work when Google announced that Largest Contentful Paint (LCP) was a ranking factor. It is easy to access, it is official, and it produces a clean list of warnings that feel actionable. Like most WordPress developers, we treated it as a diagnostic tool also and assumed that if PSI said something was broken, it must be.
That approach worked – until it didn’t.
When we started doing deeper work on Largest Contentful Paint (LCP) and Critical CSS on a large WordPress e‑commerce site, we ran into a disconnect that PageSpeed Insights could not explain. We were making real improvements in the browser. Pages were visibly faster. Above‑the‑fold content rendered immediately. Lighthouse confirmed the changes.
But at the end of the day, PageSpeed Insights still said nothing had improved.
At first, that feels like failure. Eventually, it becomes clear.
Quick Answer: Should I Use PageSpeed Insights or Lighthouse?
- Use Lighthouse to debug and verify performance fixes.
- Use PageSpeed Insights to confirm long‑term performance trends after changes are deployed.
If you reverse those roles, performance work quickly becomes confusing.
The Moment the Data Stopped Making Sense
We were working on a website that followed a common modern WordPress pattern: a custom theme, Elementor templates, WooCommerce products, and a healthy number of plugins. Nothing unusual. Performance issues were also familiar—large CSS payloads, slow LCP, and a long critical rendering path.
We generated Critical CSS for key templates and inlined it so the browser could render above‑the‑fold content immediately. Everything else was deferred. This is a well‑established optimization, and one Google explicitly recommends.
The result was obvious in the browser. The hero section rendered instantly. Layout shifts were reduced. Lighthouse showed fewer render‑blocking resources and an improved LCP.
PageSpeed Insights scores did not change much.
It continued to list the same CSS files as render‑blocking and showed little movement in scores. That forced an uncomfortable but necessary question.
What is PageSpeed Insights actually designed to tell us?
What PageSpeed Insights Is Really Measuring
PageSpeed Insights combines two different data sources:
The field data is the part most website developers underestimate. It represents a rolling 28‑day average of how real users experienced the site. It is intentionally slow to change and may fall back to origin‑level data if a specific URL lacks traffic.
That means PageSpeed Insights is excellent for answering questions like:
- Are users generally having a good experience?
- Did performance improve over the last month?
- Are problems consistent across page types?
It is not designed to answer:
- Did my Critical CSS fix work?
- Did LCP improve after today’s deployment?
- Is this page still blocked right now?
That distinction explains most of the confusion web developers experience.
But what about websites with minimal traffic? The field data simply doesn’t exist and we’re left using the tool Google provides at https://pagespeed.web.dev or the one built into the Google Search Console. Neither of which shows the whole picture!
Why Lighthouse Gave Us the Answers We Needed
Lighthouse behaves very differently because it runs in the browser against the page exactly as it exists at that moment. There is no averaging, no aggregation, and no delay.
When we ran Lighthouse after implementing Critical CSS, the results aligned perfectly with what we were seeing visually. Render‑blocking resources were reduced. LCP improved. The critical rendering path was shorter.
This was not theoretical. It was observable and repeatable.
Google’s own documentation describes lab data as useful for debugging and optimization work. Lighthouse is not a reporting layer—it is a verification tool.
Why This Problem Is Amplified on WordPress Sites
WordPress loads CSS globally by default. Themes and plugins enqueue styles whether or not they are needed above the fold. Elementor adds global CSS and per‑template CSS. WooCommerce adds cart, checkout, and payment styles that often load site‑wide.
From the browser’s perspective, CSS is render‑blocking unless explicitly deferred. Every linked stylesheet delays first paint and affects LCP.
This is why WordPress performance problems so often come down to CSS – and why Critical CSS is one of the most effective optimizations available.
There are services to scan and produce a Critical CSS report, but we’re old school. We like to see how or why things are being done. As such, we generate our own Critical CSS files for pages.
What Is Critical CSS? (Plain‑English Answer)
Critical CSS is the minimum set of styles required to render the visible portion of a page.
By inlining Critical CSS and deferring everything else, the browser can render above‑the‑fold content immediately instead of waiting for full stylesheets to download. Lighthouse is designed to confirm whether this actually happens.
If you are going to build out the Critical CSS, you need to monitor the Mobile Version of the website, and not the Desktop. Google doesn’t care so much about the Desktop version these days. It’s all about Mobile First – Display & Indexing!
How We Implemented Critical CSS in WordPress
The goal of Critical CSS is not to remove CSS, but to control when it loads. We can utilize the following two snippets of code added to the functions.php of a child theme to accomplish what we need with Critical CSS implementation.
Inlining Above‑the‑Fold Styles
function inline_critical_css() {
// Load Critical CSS generated for a specific template
$critical_css = file_get_contents(
get_stylesheet_directory() . '/critical/home.css'
);
// Output it early in <head> so rendering is not blocked
if ($critical_css) {
echo '<style id="critical-css">' . $critical_css . '</style>';
}
}
add_action('wp_head', 'inline_critical_css', 1);
What Lighthouse verifies here:
- Above‑the‑fold content renders without waiting on external styles
- LCP occurs earlier
- The critical rendering path is shorter
Deferring the Remaining Styles
function defer_theme_css( $html, $handle ) {
if ( 'theme-style' === $handle ) {
return str_replace(
"rel='stylesheet'",
"rel='preload' as='style' onload="this.rel='stylesheet'"",
$html
);
}
return $html;
}
add_filter('style_loader_tag', 'defer_theme_css', 10, 2);
What Lighthouse verifies here:
- CSS no longer blocks initial rendering
- Styles load after first paint
- No layout shifts are introduced
PageSpeed Insights may continue to flag these files for days or weeks. That does not mean the fix failed.
Why PageSpeed Insights Still Shows Render‑Blocking CSS
Short answer: PageSpeed Insights is reporting historical or aggregated data.
Long answer: PSI reflects how users experienced the site over the last several weeks. It does not reflect your most recent deployment and may not be page‑specific.
- Lighthouse answers the implementation question.
- PageSpeed Insights answers the reporting question.
Common Mistakes Developers Make
Mistake 1: Using PageSpeed Insights to Validate Fixes
PSI is not designed to confirm whether a change worked today.
Mistake 2: Undoing Correct Fixes Too Early
Critical CSS often works immediately, even if PSI scores do not move.
Mistake 3: Inlining Too Much CSS
Critical CSS should only include above‑the‑fold styles.
Mistake 4: Ignoring Page State
Logged‑in headers, WooCommerce notices, and personalization affect LCP. Lighthouse accounts for this.
Elementor and WooCommerce: Why Lighthouse Matters More
Elementor may still appear render‑blocking in PSI long after Critical CSS is implemented. Lighthouse shows whether visible content is actually blocked.
WooCommerce loads large amounts of conditional CSS that are rarely needed for first paint. Lighthouse exposes these inefficiencies immediately.
PSI vs Lighthouse: Which Tool Answers Which Question?
| Question | Correct Tool |
|---|---|
| How are users experiencing the site overall? | PageSpeed Insights |
| Which page types need work? | Search Console |
| Did my Critical CSS fix work? | Lighthouse |
| Is LCP improving right now? | Lighthouse |
| Are improvements holding long-term? | PSI / Search Console |
The Workflow That Finally Made Sense
We now use Search Console and PageSpeed Insights to identify patterns and slow templates. Once a page type is identified, we select a representative URL.
From there, all real work happens in Chrome DevTools using Lighthouse. We verify that render‑blocking resources are removed and that LCP improves immediately.
Only after deployment do we return to PSI and Search Console, knowing they reflect trends, not instant feedback.
Final Takeaway
PageSpeed Insights is not wrong. It is just not a debugging tool.
If you are working on WordPress performance, LCP optimization, or Critical CSS, Lighthouse is the tool Google built to verify real fixes in real browsers.
Trust the data – but always verify the fix.
Get in Touch with Big Red SEO
If this article sounds familiar, you are not alone. We work with businesses every day that know something is off with performance metrics, but are struggling to reconcile what the tools are saying with what they are seeing in the browser.
At Big Red SEO, we focus on practical, real-world solutions – especially for WordPress sites running WooCommerce, Elementor, or custom themes. That means fixing the things that actually affect load time, LCP, and user experience, not just chasing scores.
If you want help validating performance issues, implementing Critical CSS correctly, or understanding what your data is really telling you, feel free to reach out.
