Understanding the Inconsistencies in PageSpeed Insights Performance Metrics: A Case Study
Achieving optimal web performance metrics is a common challenge for developers striving for a fast and responsive user experience. Recently, I dedicated several weeks to fine-tuning a custom frontend to attain a perfect 4/4/100 score across Desktop and Mobile in Google PageSpeed Insights (PSI). While I’ve successfully reached 100 on desktop and am close on mobile, the journey has been marred by perplexing fluctuations in PSI’s performance scores, even when testing the same page under identical conditions.
The Core Challenge: Fluctuating PSI Performance Scores
Despite consistent optimizations—such as inline CSS, compressed HTTP responses, prioritized preload hints for critical resources, and a carefully staged JavaScript loading sequence—I notice jittery PSI results on mobile. Sometimes, the score plummets to 79 or below for “Performance,” even though the page source remains unchanged. In contrast, using Lighthouse (with throttling calibrated to Slow 4G and low-tier CPU), I consistently achieve a perfect 4/4/100 score.
This inconsistency only appears in PSI; Lighthouse reports stable performance metrics. The discrepancy is baffling because, under the hood, the page loads swiftly—most core resources are ready by 1 second, as confirmed by performance logs. This raises the question: Why does PSI sometimes report such poor scores despite transparent, fast-loading content?
Investigation Efforts and Findings
To diagnose, I integrated comprehensive frontend logging—initially using LogRocket—to monitor what occurs during PSI tests. I observed that all console errors, including logs from various scripts, appear within PSI’s reports. I further enhanced logging to include every event, analyzing each line to identify potential bottlenecks or errors. Yet, even with exhaustive inspection, the scores remain inconsistent.
I speculate that the root cause may relate to third-party scripts, particularly consent management and analytics tools—for instance, CookieYes and Google Analytics (GA4). These scripts likely influence the timing and rendering processes, although logs indicate that “window.load” fires within 0.5 seconds consistently, and all lazy-loading finishes before 1 second. Therefore, logically, performance metrics like First Contentful Paint (FCP) and Largest Contentful Paint (LCP) should be stable, yet PSI fluctuates unpredictably.
Performance Optimization Strategies in Place
My optimization approach includes:
- Heavy inlining of critical CSS
- HTTP response compression
