It started with a number that wouldn’t sit still.
I’d run Google’s PageSpeed test on my site and get a mobile score of 97. Run it again an hour later, with nothing changed, and I’d get 88. A few tests after that, 64. Then it bounced back to 98. At one point my notes looked like a heart monitor: 93, 97, 97, 88, 88, 64, 64, 98, 98, 93.
That was my first real clue. If a site truly becomes three times slower, something has to have changed: a overloaded server, a broken cache, a heavy new script. I hadn’t touched anything. So rather than flipping random settings and hoping, I decided to check the site piece by piece.
First, was my hosting actually slow?
Before blaming WordPress, my host, or my plugins, I wanted to know how the server behaved on its own. I requested my homepage over and over from my own computer, a couple of seconds apart, and timed each response.
The results were boring in the best way. The server answered in roughly half a second every time, and the full page arrived in under a second. No mysterious five-second stalls.
That told me the server wasn’t the villain, and it gave me a rule I’ll keep: measure the server separately from the browser before you change anything.
A stylesheet loading twice
My site uses a popular lightweight theme with a child theme on top. Looking at the page’s source, I noticed the child theme’s stylesheet was being loaded two times.
The cause was a bit of code I’d copied from a tutorial years ago. It’s the kind of snippet you see everywhere, and it isn’t wrong in general. But my theme was already loading that file by itself, so the extra code just made the browser fetch the same thing twice.
Removing it didn’t turn a 50 into a 100. Those dramatic before-and-after stories are fun to read, but real optimization is usually smaller and less glamorous. Still, it was a genuine mistake, and deleting unnecessary work beats installing another plugin to make up for it.
The script I didn’t recognize
More interesting was a request to a website I’d never heard of. Some JavaScript was loading from an outside domain, and I had no idea why.
I searched my site’s files and found nothing. Then I searched the database and found it: a snippet saved by a “header and footer code” plugin, left over from an old third-party integration I’d stopped using long ago. The service was gone from my life, but its script had been loading on every page, quietly, for who knows how long.
I removed the snippet. When I checked again, the plugin’s settings were completely empty, so I removed the plugin too.
If you’ve run a site for a while, it’s worth looking for this kind of leftover: old affiliate scripts, analytics snippets, popups, chat widgets, ad code, verification tags. You stop using the service, but its code keeps loading.
When the settings screen and the site disagree
I was also experimenting with a caching plugin’s option to load CSS without blocking the page. The settings screen said it was on. The site said otherwise.
So I stopped trusting the checkbox and looked at what the site actually delivered. In the page’s source, the stylesheet was still loading the old, blocking way. Only after I fixed the setting did the page show the signs of the optimization working: the critical styles built right into the page, and the rest loading afterward.
The browser never sees your settings screen. It only sees the HTML you send it. I also compared what a phone receives against what a desktop receives, to make sure visitors on mobile weren’t getting a different, unoptimized version. They weren’t, and the page was being served from cache properly in both cases.
The real lesson: the score itself wobbles
Once the real problems were cleaned up, the score still swung around. In one bad run, the page took several seconds to show its first content, yet the measures of responsiveness and layout stability were perfect. Meanwhile, my own server timing stayed flat and steady.
That doesn’t make PageSpeed useless. It’s excellent at pointing out specific problems like oversized images, scripts that block the page, and heavy third-party code. But I stopped treating the final number as a verdict. A site that scores 98, then 64, then 98 again with no changes hasn’t gone through two dramatic transformations. The testing conditions moved, not the site.
One more piece of clutter
While tidying up, I found a backup plugin that was active, but I had never set it up. I checked and found no schedule running anywhere. Then I looked in my hosting control panel and discovered my host already makes full-account backups at the server level, which I could restore from at any time.
The plugin was redundant. It’s a good reminder to ask “What is this actually doing for me?” instead of “Is this a good plugin?” A great plugin can still be unnecessary on your particular site.
What I kept
I didn’t try to shrink my plugin list for bragging rights. The caching, SEO, newsletter and analytics tools stayed because they do real work. So did my ad code, even though PageSpeed sometimes grumbles about Google’s own advertising scripts. Removing the thing that pays for the site just to make a circle turn green would defeat the point.
The goal was never the lowest plugin count. It was to get rid of things that no longer had a job.
What I actually gained
A high score wasn’t the best result. The best result was that I could finally explain my own website. I knew what loaded, why it loaded, whether it was cached, where each unfamiliar script came from, and which tools were earning their place.
If I had to boil it down to one piece of advice: look at one layer at a time before changing anything. Check the server, then the page itself, then the database if you need to, then what each plugin really does. And treat PageSpeed as a diagnostic tool, not a scoreboard.
It took longer than installing yet another “speed booster.” But I ended up with a site I understand, which turned out to be worth more than the number.