78 to 90: What We Removed to Fix a WordPress Page Speed Problem
Mobile score: 78. Google Core Web Vitals threshold: 80.
Two points below the line that matters. And a 28-day delay before field data catches up to any fixes you make.
That means you don’t get to move slowly. You can’t run a week of changes, wait for results, run another week. You need to diagnose it fast, make the right moves, and trust the lab scores while the real-world data crawls behind you.
That’s the situation we walked into with a B2B training company’s WordPress site. And this is what we actually did — not the theory, the actual changes.
The Addition Trap
Before I tell you what fixed it, I want to tell you about the pattern that broke it in the first place.
WordPress performance problems almost always trace back to the same bad habit: addition.
Something’s slow? Add a caching plugin. Add a CDN. Add an optimization plugin. Add a lazy-loading tool. Add a performance monitoring dashboard. The site gets slower, so you add another layer.
Nobody ever asks what’s already running that shouldn’t be.
This is the addition trap. And it’s everywhere. We’ve audited dozens of WordPress sites and the consistent finding is always the same: there are three times as many active plugins as necessary, half of them duplicate each other’s function, and at least one of them is silently destroying performance while sitting in the “recommended plugins” category.
The B2B training company site was a textbook case. Not because it was badly built — it wasn’t — but because it had grown organically over a few years and nobody had stopped to audit the weight of what was running.
Three Changes. No Paid Plugins. 78 to 90.
Here’s what we found and what we did.
Change 1: Remove Font Awesome
Font Awesome is on probably 80% of WordPress sites. It’s the icon library that ships with most themes and page builders by default. And it’s one of the most quietly devastating performance loads you can have.
On this site, Font Awesome was loading a 46 KiB JavaScript bundle. Even if the page only used two icons — or zero icons — the full library loaded anyway. On mobile, that translated to 750ms of additional load time that served no functional purpose.
We removed it.
The AO bundle dropped from 46 KiB to 29 KiB. The 750ms came back. The page didn’t visually change because the template wasn’t actually using the icons being loaded.
This is the dirty secret of icon libraries: they’re included by default, they’re never audited, and they sit there costing you performance milliseconds for features the site doesn’t use.
Check your site. Right now. If Font Awesome is loading and your page doesn’t have a deliberate icon strategy, that’s probably your fastest win.
Change 2: Disable Optimization Detective and Image Prioritizer
These are two WordPress plugins that sound exactly like what you’d want running on a performance-conscious site. Their job, in theory, is to help other optimization plugins work smarter.
In practice, they were creating a 4,030ms JavaScript execution chain.
Four seconds. On a mobile load. From two plugins whose entire purpose was to speed things up.
We disabled both of them. The JS chain disappeared entirely. That’s not a rounding error — that’s the difference between a site that passes Core Web Vitals and one that doesn’t.
Here’s the thing about optimization-on-optimization plugins: they add coordination overhead. Every tool that watches other tools adds weight. At some point the infrastructure of optimization becomes heavier than the optimization itself. That’s what was happening here.
The principle: if a plugin’s job is to help other plugins optimize images and those other plugins are already running, you’ve got redundancy. Cut it.
Change 3: Merge the Stylesheet
This one is simpler. The site was loading a separate stylesheet as an additional render-blocking request. Every render-blocking resource holds up the page — the browser can’t paint anything until it finishes loading.
We merged the stylesheet into the main CSS file. One less request. One less render-blocking delay.
Not glamorous. But every millisecond is a millisecond.
The CLS Win You Don’t Usually Think About
There was a fourth thing worth mentioning, even though it wasn’t about load speed.
Cumulative Layout Shift — CLS — was sitting at 0.024. Not terrible, but above the “good” threshold of 0.1, and it contributes to the overall Core Web Vitals assessment.
CLS is mostly caused by content that loads and then moves when another element arrives — usually images without defined dimensions, or web fonts that load and swap after the page has already painted.
The fix here was metric-matched fallback fonts. This is the practice of finding a system font that has close-enough metrics to your web font — same x-height, similar character width — so when the web font loads and swaps in, the layout doesn’t shift. The text repaints but the flow doesn’t move.
CLS dropped from 0.024 to 0.006. A 75% reduction. Done.
Nobody ever talks about metric-matched fallback fonts. It sounds fiddly. But it’s a one-time configuration change that kills layout shift permanently.
What the Lab Score Means (and Doesn’t Mean)
I want to be straight with you about something. The 90 score is a lab score. It’s measured in a controlled environment against a simulated mobile device.
Field data — the actual performance experienced by real users — takes 28 days to aggregate in Google Search Console. When we made these changes, we knew the lab score improvement was real, but we also knew we’d need a full data cycle to see it reflected in field metrics.
This matters for two reasons.
First: don’t panic if your field data doesn’t move immediately after making performance changes. It will. The lag is a measurement artifact, not a sign the changes didn’t work.
Second: lab and field scores can diverge. Lab scores measure a controlled scenario. Field scores reflect real network conditions, real device diversity, real user behaviour patterns. A 90 in the lab might become an 85 in the field. That’s still fine. What you’re optimising for is a field score consistently above the Core Web Vitals threshold — not a perfect number in a controlled test.
The principle that matters is the direction of travel and the speed at which you move. We needed to be above 80 before the 28-day window closed on the period we were optimising for. We got there.
The Only Rule in WordPress Performance Work
Stop adding things.
I mean it. Before you install anything, audit everything already running. Check what’s actually loading. Check what’s actually doing something useful versus what’s sitting there burning milliseconds on every page load.
The fastest WordPress sites I’ve ever worked with don’t have more tools. They have fewer. Every plugin has a cost — sometimes tiny, sometimes catastrophic, always real. The question isn’t “does this plugin help?” The question is “does the help it provides outweigh the cost it adds?”
Font Awesome: 750ms for icons nobody’s using. Cut.
Optimization pipeline that creates a 4-second JS chain. Cut.
Render-blocking stylesheet when the code can be merged. Cut.
78 to 90. No paid plugins. One focused session.
That’s not a trick. That’s what happens when you audit instead of add.
