Your site got slow after an update

Hardware does not get tired and PHP does not wear out. When a site that felt fine in spring feels heavy in summer, something was added, and the addition falls into one of three buckets. More requests in the browser: a script, a font, a stylesheet, an image that now loads on every page instead of one. More work per request on the server: a plugin running queries on every page load, a theme that lost its cache-friendly output. More data underneath: a table that grew until the queries reading it stopped being cheap. Each bucket produces a different symptom, and that is useful, because a slow first paint and a slow time to first byte point at opposite ends of the stack. Work out which one moved before you touch anything, or you will spend a day optimising images while the real cost sits in a database query.

You are looking for the day the site changed, not yet the reason it is slow. Reasons are easy once the date is fixed. Pull the WordPress plugin and core update history, including anything on auto-update, since those land without a human deciding. Check theme changes and whatever deploy, backup or file-edit timestamps your host keeps. Then check the things that live outside WordPress entirely: the tag manager container someone published last Tuesday, the ad pixel a freelancer added for a campaign that ended, the chat widget marketing trialled and never removed. A surprising share of the front-end weight a store gains in a year arrives through a tag manager rather than the codebase, and nobody in the room remembers approving it, because publishing a container does not feel like changing the website.

• Plugin and core update history, auto-updates included
• Theme edits and host deploy or backup timestamps
• Tag manager container versions and who published them
• Content edits: new homepage blocks, banners, embedded video

Four front-end additions cause most of the regressions worth investigating. A newly installed plugin that enqueues its CSS and JavaScript on every page rather than the one page it serves, the classic being a form plugin loading across your product templates. A theme update that reintroduced a render-blocking script an earlier optimisation had deferred, because the update overwrote the customisation. A tag manager container that has quietly grown from two tags to fifteen, each opening its own third-party connection. And a large image or slider dropped at the top of the homepage, which becomes the Largest Contentful Paint element and pushes everything behind it. The first is the most common and the least visible from outside, which is why auditing what each plugin actually loads is usually the first hour of work: what plugin bloat does to a storefront explains the mechanism.

• One plugin loading assets site-wide instead of on its own page
• A theme update that overwrote a deferred or removed script
• A tag container that grew without anyone auditing it
• A new hero image or slider above the fold

If the browser waterfall looks much as it did but pages are slow to start, the regression sits behind the wall. Two patterns dominate. The first is a cache that was invalidated and never warmed: most update routines flush page and object caches, so the first visitor to each URL pays full price, and on a large catalogue that state can persist for days if nothing crawls the site. Check whether your slow pages are simply your least-visited ones. The second is data growth. WordPress stores expired transients in the options table, and a plugin that writes them faster than cron clears them leaves a table every page load reads through. Autoloaded options, post revisions and orphaned metadata behave the same way. Neither problem is dramatic, and both stay invisible in a lab score run against a page that happened to be cached.

One lab run, on one machine, over one network, moves several points between attempts and cannot tell you what your customers experienced last week. Field data can. The Core Web Vitals report in Search Console and the Chrome User Experience Report both describe real sessions, at the cost of a rolling twenty-eight-day window, which means a change from seven days ago is still diluted by the three weeks before it. Use both: field data to confirm that something genuinely moved, lab tooling to find the specific asset responsible. Keep the comparison honest by holding everything else fixed, and understand how the Core Web Vitals metrics behave before reading the numbers, because loading, responsiveness and layout stability fail for entirely different reasons and reward different fixes.

• Confirm with field data; treat lab scores as a debugging tool
• Hold the template constant: home, category and product differ
• Split mobile from desktop before reading any average
• Define the before window and the after window in advance

Deactivating a plugin on the live site confirms a hypothesis in seconds, and it is not always safe. Some plugins run database migrations on activation that do not reverse cleanly, reverting a version can undo a security fix, and a rollback during trading hours turns a performance problem into an availability one. Run the test on a staging clone where a wrong answer costs nothing, then decide. Fixing forward is the right call more often than owners expect, because the addition usually exists for a reason somebody in the business cares about. A marketing tag that has to stay can load after first interaction rather than in the head. A plugin's assets can be scoped to the pages that need them. A hero image can be resized, converted and given fetch priority rather than deleted. Removal is one option among several, not the objective.

There is a version of this where the update is a coincidence. If your store was already at four or five seconds on a mid-range phone before anything changed, the update did not create that. It nudged a number that was already failing into the range where you finally noticed. Chasing the last change will produce a small win and leave the structural problem intact: a theme carrying thirty plugins' worth of assets, category templates running uncached queries, a page weight no amount of tuning brings under the threshold. The honest test is your own field data from before the update window. If it was already red, start with the deeper diagnosis of a slow store instead. And if the site is only marginally slower with no business impact you can see, doing nothing for a month while the data accumulates is a legitimate decision rather than an evasion.

Regressions come back because nothing in the process notices them. Four habits prevent that, and none require a rebuild. Stage changes, so a plugin can be installed and measured before it reaches customers. Change one thing at a time, so the day the numbers move you know what moved them. Set a performance budget: a page weight and a request count you refuse to exceed, written down where whoever adds the next tag will see it. Then check monthly, which is genuinely fifteen minutes: field data per template, plugin count, database table sizes, a note of anything published to the tag container. When nobody internally owns that rhythm, it is what a maintenance and support arrangement exists for, and it costs considerably less than running this investigation twice a year.