A client sent me a PageSpeed Insights report recently. Their WordPress site was failing its Core Web Vitals assessment, Google was complaining about server response time, and the score had become a bit of an obsession.
They had compressed the images, installed a speed plugin and worked through (some of) Google’s recommendations. Some changes improved the score. Others made it worse. The results were bouncing around from one test to the next, which is a special kind of maddening.
Eventually, it landed in my inbox.
The site seemed fast after it loaded. The problem was the pause before anything appeared. Its Time to First Byte, or TTFB, was over two seconds.
I like to think of TTFB as a footrace. The visitor clicks, the stopwatch starts and the browser crouches at the starting line, ready to run. But the server waits two full seconds before firing the starting gun!
Once released, the browser runs quickly. Images load, scripts execute and the page comes together. But those first two seconds are already on the clock. The browser can run a great race and still finish with a poor time.
That delay before the starting gun is TTFB. WordPress is running PHP, querying the database, loading plugins and sometimes waiting for outside services. The browser can’t do anything until the server sends that first byte.
The client had been buying the runner better shoes. The problem was the person holding the starting pistol.
And one of the speed plugins was standing on the track.
High TTFB Is Time You Can’t Win Back
TTFB is not technically one of Google’s Core Web Vitals. But it affects the metrics that are, particularly Largest Contentful Paint.
If WordPress takes two seconds to respond, everything else begins two seconds late. You can compress every image into a tiny digital raisin and defer JavaScript until the cows come home. The stopwatch is already running.
Google considers 800 milliseconds or less a good TTFB. That is a useful benchmark, not a sacred text. A complex website does not need to win the Internet Olympics.
But two or three seconds of silence before the page begins is not a minor scoring disagreement with Google. It is a real delay, and visitors feel it even if they have never heard the term TTFB.
They click. Nothing happens. They wonder whether the click worked. They click again.
That is how a server problem becomes a human problem.
Speed Plugins Are Very Good at the Jobs They Actually Have
I don’t have a grudge against speed plugins. We occasionally use them.
They can compress images, reduce CSS and JavaScript, cache pages and delay scripts that don’t need to run immediately. Those things can make a meaningful difference.
But most speed plugins work on the runner. High TTFB often comes from something happening back near the starting line:
- a database query wandering around looking for its keys
- years of old plugin data being loaded on every request
- an outside API taking its sweet time
- too few PHP workers serving too many visitors
- a scheduled task that has gone feral
- an overloaded or poorly configured server
A speed plugin cannot compress a database query. It cannot defer an API call if WordPress insists on finishing that call before rendering the page. And it cannot invent PHP workers that the hosting account doesn’t have.
Also—and this part gets overlooked—the speed plugin is itself another plugin. WordPress has to load it, run it and deal with whatever clever activities it has scheduled.
Sometimes the coach is eating all the snacks.
The Speed Plugin That Would Not Stop Speeding
On this site, the optimization plugin was preloading the page cache.
Cache preloading is sensible in theory. The plugin visits pages before real people do, builds cached copies and leaves them ready for visitors. A little digital prep cook, chopping the onions before dinner service.
The problem was that this site had thousands of URLs.
The preloader kept sending WordPress out to run lap after lap, rebuilding cached pages and occupying the PHP workers needed by actual visitors. It was trying so hard to make the site fast that the server barely had time for humans.
I disabled the preloader. TTFB improved immediately.
That exposed another problem: an oversized autoloaded options table filled with data left behind by old plugins. Every request was strapping on a backpack full of obsolete settings before approaching the starting line.
We cleaned up the database and simplified the caching setup. The server response dropped without another plugin, a redesign or a larger hosting plan.
Mostly, we persuaded the site to stop doing a tremendous amount of useless work.
This is surprisingly often the secret to speed.
Every Slow WordPress Site Is Its Own Weird Little Mystery
This is the part I love.
High TTFB is a symptom, not a diagnosis. Two sites can post nearly identical PageSpeed results while suffering from completely different acts of backend foolishness.
I’ve found deleted plugins that left thousands of autoloaded records behind. The plugin was gone, but its luggage was still living in the hallway.
I’ve found a tiny feature in a site header contacting an outside API before every page load. When the other server slowed down, the entire website waited politely. Nobody had told it that leaving was an option.
I’ve found sites that were fast with one visitor and nearly comatose with five because the hosting account had too few PHP workers. Each request waited in line for the one available worker like customers at a post office during lunch.
Other recurring characters include failed cron jobs, enormous log tables, security scans running at the worst possible time, uncached database queries and multiple optimization plugins fighting over the same cache like raccoons in a trash can.
Same red PageSpeed warning. Completely different story underneath it.
That is why installing a speed plugin is not a diagnosis. It is a thing you tried.
Why PageSpeed Keeps Changing Its Mind
Clients sometimes send me several PageSpeed reports taken minutes apart. One score is decent. The next is terrible. A third lands somewhere in the middle and seems pleased with itself.
This doesn’t necessarily mean the tool is broken.
You may be viewing a cached page while a first-time visitor gets an uncached one. A logged-in administrator may bypass the page cache. Mobile and desktop tests use different conditions. The server may be quiet for one test and busy when the next arrives.
PageSpeed also shows two kinds of data. Field data comes from real Chrome visitors over time. Laboratory data comes from one simulated test. One describes what visitors have experienced; the other describes what happened during that particular run.
They are related, but they are not twins.
Search Console moves slowly too. Fixing the site today will not erase weeks of historical performance data tomorrow. Google needs to collect enough new visits to see the change.
Running PageSpeed again can tell you the score changed. It usually cannot tell you why.
Eventually you have to stop weighing the patient and find out why they feel lousy.
WooCommerce Runs With a Shopping Cart
WooCommerce makes the race more interesting because its most important pages are dynamic.
A homepage can usually be cached. A cart, checkout or customer account may need current pricing, inventory, taxes, shipping rates, sessions and payment information. Those requests have to reach WordPress and often the database.
This is why a store can have a wonderfully fast homepage and then develop a thousand-yard stare when someone clicks Add to Cart.
I wrote about one of those cases in I Finally Fixed a WooCommerce Slow Add to Cart Problem. The public pages were fast. The cart request was dragging old database baggage behind it.
For an ecommerce site, I care much more about whether the product, cart and checkout remain responsive than whether the homepage earns a ceremonial 100. A useful WooCommerce performance audit tests the parts of the store where customers are trying to give you money.
That feels like the important bit.
The Question Is: What Is the Server Waiting For?
Not “Which speed plugin should I install?”
Not “How many times should I clear the cache?”
And definitely not “What happens if I turn on all the settings?” I know what happens. We all get an exciting afternoon.
The useful question is: What is the server waiting for?
Sometimes it is the database. Sometimes PHP is buried in plugin code. Sometimes an external service is slow. Sometimes all available workers are busy. Sometimes the cache is missing, and sometimes the cache has become a project of its own.
Once we know where the time is going, the fix is often fairly ordinary:
- remove unnecessary autoloaded data
- repair an expensive query
- move an API request out of the page-rendering path
- configure Redis object caching properly
- fix a runaway scheduled task
- remove overlapping optimization plugins
- add server capacity where it is actually needed
WooCommerce databases deserve particular attention because years of orders, sessions, logs and expired data can accumulate quietly. Our article on how to optimize WooCommerce goes further into that particular basement.
Better hosting is sometimes the right answer. But upgrading the server before identifying the bottleneck can turn inefficient code into slightly faster inefficient code, now with a larger monthly bill.
Before You Install Another Speed Plugin
If PageSpeed Insights shows high TTFB, I would pause before adding anything else.
Your website probably isn’t broken. You probably didn’t break it. WordPress sites grow, collect integrations and carry leftovers from years of perfectly reasonable decisions. Eventually the setup that worked at launch no longer fits the site it became.
Another plugin may change the score without bringing you any closer to the reason.
Good WordPress maintenance means paying attention to how the whole system behaves, not just keeping its individual parts updated.
At Watermelon Web Works, we follow performance problems through the code, database, cache and server until we know what the site is waiting for. Every site is different, which is exactly what makes this work interesting.
If you are done negotiating with PageSpeed Insights, send us the report. We’ll help you separate the useful clues from the noise and find what is actually slowing the race.
