Project: getfixmyspeakers.com — a free browser-based phone speaker cleaning tool built on WordPress (Kadence, Rank Math, LiteSpeed Cache).
Result: A verified 100 / 100 / 100 / 100 Google PageSpeed Insights score on mobile — Performance, Accessibility, Best Practices, and SEO — with LCP 1.2s, Total Blocking Time 0ms, and CLS 0 under Slow-4G throttling. See the public test result →
The starting point: an alarming audit
A Lighthouse report on the site showed numbers that looked disqualifying for search: Total Blocking Time of 6,640ms, Largest Contentful Paint of 4.6s, Cumulative Layout Shift of 0.381, and a Speed Index of 7.4s. Taken at face value, the site appeared to need a rebuild.
Step 1: Audit the audit
Before changing anything, I verified how the test was run — and found the report had been captured while logged in as a WordPress administrator. A logged-in session loads the admin bar, the full Gutenberg React editor stack, analytics scripts, and a 2.8 MB hosting-provider chatbot bundle. None of that ships to real visitors or to Googlebot.
Fetching the site as an anonymous visitor told a different story: cached HTML served in ~300ms with Brotli compression, critical CSS inlined, and only four small scripts. Most of the “emergency” was a measurement error.
Lesson worth stealing: always performance-test in an incognito session or via PageSpeed Insights. Logged-in Lighthouse runs misrepresent every WordPress site.
Step 2: Fix the genuine problems
The corrected baseline still exposed two real, visitor-facing issues:
1. A render-blocking Google Fonts chain
The site’s custom CSS loaded its two typefaces with @import url('fonts.googleapis.com/...'). An @import inside head CSS creates a serial, render-blocking chain — HTML → Google CSS → font files from a second third-party domain — costing roughly 3.2 seconds on the critical path and causing font-swap layout shifts.
Fix: switched the theme to self-host both fonts locally with <link rel="preload">, then removed the @import. Zero third-party font requests remain, and the fonts now load from the site’s own domain in parallel with the page.
2. No efficient browser-cache policy
Static assets (CSS, JS, fonts) were served with only a 7-day cache lifetime, and the cache plugin’s browser-cache module was disabled. Fix: enabled browser caching with a 1-year TTL, verified live via response headers (cache-control: public, max-age=31557600). Repeat visits now load almost entirely from the visitor’s own device.
Step 3: Verify publicly
Screenshots can be edited; public test links can’t. The final verification is Google’s own tool, run on Google’s infrastructure:
| Metric (mobile, Slow-4G) | Initial report* | Verified after |
|---|---|---|
| Performance score | — | 100 |
| Largest Contentful Paint | 4.6 s | 1.2 s |
| Total Blocking Time | 6,640 ms | 0 ms |
| Cumulative Layout Shift | 0.381 | 0 |
| Speed Index | 7.4 s | 2.2 s |
*The initial report was captured under logged-in admin conditions, which inflates these figures — that discovery was itself part of the diagnosis. The verified “after” numbers are from Google’s public PageSpeed Insights test under standard anonymous conditions.
View the live PageSpeed Insights result →
Why this matters for rankings
Google’s page experience signal evaluates Core Web Vitals against three thresholds: LCP under 2.5s, INP under 200ms, and CLS under 0.1. This site now clears all three with a wide margin — meaning content and authority, not performance, decide how it ranks.
Need the same for your site? Tell me about your project →