A WordPress site slow after an update is a measurement problem before it is a fixing problem. “Slow” can live in four different places: the server building the page, the database answering queries, the front end loading assets, or an external service timing out. Each has a different fix, and stacking optimisation plugins before measuring usually adds a fifth problem. Here is how to find where your seconds actually go.
Write down what changed before you measure anything
An update made the WordPress site slow, so the list of what updated is half the investigation.
WordPress keeps that history. The Updates screen shows core versions, and each plugin’s changelog shows what shipped in the version you now have. Your host may also keep an update log, and many managed hosts record automatic plugin updates you never approved.
Note the exact time the site got slow, then compare it with that list. A plugin that updated four hours before the first complaint is a far stronger suspect than one that updated last week. Also check whether anything else happened at that moment, such as a PHP version bump, a cache purge, or a traffic spike, because hosts frequently do those on their own schedule.
WordPress site slow? Separate server from front end
First, measure time to first byte for the homepage and one inner page. This one measurement cuts the suspect list in half.
Measure it twice, and ignore the first result. The first request after a cache purge builds the page from scratch and is not representative of what visitors get.
A TTFB under half a second, with a site that still feels slow, means the weight is in the front end: images, scripts, fonts. In contrast, a TTFB of two seconds or more means the server or database is doing too much work before sending anything, and no image optimisation will help that.
Measure logged out. An admin session skips the page cache entirely and runs extra queries, so a WordPress site slow only for you may be perfectly fast for everyone else.
If the server is slow: find what changed
Test with the most recent changes reversed one at a time, ideally on a staging copy rather than on production.
Then check the two classic post-update culprits. The first is a cron task that now runs on every request instead of on a schedule. WordPress cron fires on page loads by default, so a plugin that schedules aggressive work makes every visitor wait for it.
The second is an external HTTP call that started timing out. License checks, API syncs and font fetches all block page generation while they wait. A service that has gone away can hold every page for the full timeout. The Site Health screen flags some of these, and the error log names the rest.
Also confirm the object cache is still working. An update that changes a caching plugin’s configuration can silently drop the site back to querying the database for everything. That looks exactly like “the server got slower” without anything on the server having changed.
If the database is slow
Autoloaded options are the quiet killer behind a WordPress site slow on every page equally. Plugins accumulate data that loads on every single request, and one bad update can balloon it from a few hundred kilobytes to several megabytes.
Measure the autoload size and the largest tables. It takes minutes and it regularly explains a mysteriously slow site outright. Anything much above a megabyte of autoloaded data deserves investigation, and the offending option usually names its plugin.
Similarly, tables left behind by removed plugins and unbounded log tables grow until queries crawl. Action-scheduler tables, statistics plugins and security logs are the usual suspects. None of them cleans up after itself by default.
Finally, transients that never expire behave like a slow memory leak in the options table. A site that gets steadily slower over weeks rather than suddenly after an update often has this rather than a code fault.
If the front end is slow
Compare what the page loads before and after the update. A plugin that started enqueueing its scripts on every page, rather than only where they are needed, is the classic regression. It shows up immediately as a longer request list.
Meanwhile, keep Core Web Vitals in view, because they name the symptom precisely. Largest Contentful Paint measures when the main content appears. Cumulative Layout Shift measures whether things jump around while loading. Interaction to Next Paint measures how quickly the page answers a click. Each maps to a different class of fix.
Lab numbers guide you, but field numbers decide. A tool running from a data centre on a fast connection tells you about your code. Real users on real phones tell you about your site, and only the second one affects how the page is judged.
Render-blocking resources are worth checking specifically after an update. A new script in the head, or a font that arrives late, delays the whole visible page. The server timing meanwhile stays perfectly healthy, which is why this version of a WordPress site slow to appear confuses people.
Measuring without buying a tool
You do not need a paid service to answer the first question.
The browser’s own developer tools report it: open the Network tab, reload, click the document request, and read the “Waiting for server response” figure. That is your TTFB, and it is measured from where your visitors actually are.
For the front end, the same Network tab gives you the total request count and the transferred size, which is exactly what you want to compare before and after an update. A jump of thirty requests after a plugin update is a finding, not a theory.
Then, for field data, the Core Web Vitals report in Search Console shows what real visitors experienced over the past month. It lags by weeks, so it will not confirm today’s fix, but it does tell you whether a WordPress site slow enough to hurt rankings has been slow for a while or only since Tuesday.
When it is not the update at all
Three causes look exactly like a bad update and are not.
A noisy neighbour or a throttled plan. Shared hosting performance varies with what else runs on the machine, and hosts throttle accounts that exceed their CPU allowance. The tell: everything is slow, static files included, and it comes and goes on its own.
An empty cache. Right after a purge or a deployment, every page is built from scratch. That is real slowness, but it fades over minutes and is not worth optimising.
A bot or scraper. A crawler hitting expensive pages hundreds of times a minute makes a WordPress site slow for everyone else. The access log shows it in seconds, and blocking it is the whole fix.
Fix one thing, then re-measure
Whatever you found, change one variable and measure again with the same tool, from the same place, logged out. Consequently you will know which change paid and which was superstition.
Most importantly, resist installing a second caching plugin on top of the first. Overlapping caches produce bugs that are far harder to diagnose than slowness, and on a store they break the cart in ways nobody connects back to the performance work.
Keep the numbers. A WordPress site slow this month and “fixed” next month without any measurements will be slow again by December, and nobody will know which of the six changes mattered.
Quick checklist
In short: list what updated and when, measure TTFB logged out and twice, then reverse the latest change on staging. Next, check autoloaded options and cron, look for external calls that time out, and compare the asset list before and after.
Then change one variable at a time and re-measure. That order turns a vague complaint into a named cause, which is the only thing that stops it recurring.
Related faults worth ruling out
An update that made the site slow sometimes made other things worse at the same time. If parts of the site now fail rather than merely drag, our guide to a WordPress white screen covers the fatal-error path, and recovering from a failed WordPress update covers the half-written-files case that produces both symptoms at once.
On a store, slowness at checkout specifically is a different investigation, and WooCommerce checkout not working walks that path in order.
When you want it found for you
This measure-first order is our standard method: diagnose, change the smallest thing, verify, record. If your site got slow and you would rather see a written diagnosis than run one, tell us what changed and when, and our WordPress support service will trace it.
Google’s own Core Web Vitals documentation is the reference for the front-end metrics above, and the WordPress optimization documentation covers the server and database side in more depth than fits here.