An update changes code that WordPress runs on every request. New core files, new plugin code, new theme templates, and sometimes a new database schema. Any of those can change the cost of building a page. This article is about the window right after that change, when a site that was fast becomes slow for minutes, hours, or sometimes permanently.
What "slow after an update" actually is
Post-update slowness is not one failure mode. It is two, and the difference matters. There is a temporary dip that resolves on its own as caches warm up and one-time migrations finish, and there is a structural regression that the update introduced and will not fix itself. The temporary kind is the expected cost of replacing running code. The structural kind is a problem in the new code itself, in the interaction between new code and the rest of the stack, or in a database migration that did not complete cleanly. Confusing the two is the most common way. If the slowness coincides with a host migration, the migration itself may be the cause. Confusing the two is the most common way people waste an afternoon on this problem.
How an update actually disturbs a running site
A WordPress update touches three layers a request passes through: PHP, the database, and the various caches layered on top of both. Each layer reacts differently to files changing on disk.
PHP and OPcache. WordPress runs as PHP, and on modern hosts PHP is served from an opcode cache. OPcache stores precompiled bytecode in shared memory so PHP does not reparse files on every request. When you overwrite PHP files, OPcache has to notice, invalidate the old bytecode, and recompile. With the default opcache.validate_timestamps=1, OPcache rechecks file timestamps every opcache.revalidate_freq seconds (default: 2) and recompiles anything newer. On hosts that run with validate_timestamps=0 for performance, OPcache is blind to the change until the pool is reset, which is why some platforms reload PHP-FPM after a deploy. Either way, the first requests after an update hit a colder cache, and the request that triggers the recompile pays the parse cost.
The database. When the update crosses a WordPress core major version, WordPress runs wp_upgrade(), which flushes the cache, updates the schema via make_db_current_silent(), runs upgrade_all(), and fires the wp_upgrade action hook. WooCommerce, ACF, LearnDash, BuddyBoss, and other large plugins run similar one-time upgrade routines after their own updates, sometimes migrating tables with millions of rows. During that migration every request competes with a database doing heavy writes. This is the "Database update required" screen you sometimes see when visiting /wp-admin/ right after a core upgrade, and it is why WordPress's own upgrade guidance tells you to reactivate and check plugins individually after a major update.
Caches. Every full-page cache, object cache, and minified asset bundle is tied to the code that existed before the update. Most caching layers invalidate themselves on a core or plugin update so visitors do not see stale pages. That is correct behavior, but it also means the first page view after the update runs the full uncached WordPress path. The autoloaded options cache (alloptions, which WordPress loads at the start of every request) is rebuilt the same way: cleared, then repopulated from wp_options on the next request.
Layer those three mechanisms together and the site is running on colder PHP, a busier database, and an empty cache at the same time. That is the normal state of a WordPress site for the first few minutes after an update, before anything has gone wrong.
Temporary dip or structural regression
The diagnostic question is whether the site recovers on its own once those transient conditions clear. Give it fifteen minutes on a small site, an hour on a busy one with a cold full-page cache. If it is meaningfully faster by the end of that window, you saw a temporary dip. If it is still slow the next morning and re-warming the cache does nothing, the update introduced a structural regression.
Temporary causes (resolve on their own):
- OPcache cold start, until workers have reparsed the new files
- Full-page and object cache rebuild on first visits after the purge
- The
alloptionsautoload cache repopulating fromwp_options - One-time database migrations running in the background after a core or plugin upgrade
- Regenerating CSS, JavaScript, or image derivatives (thumbnail sizes, critical CSS, asset bundles)
Structural causes (stay until you fix them):
- A plugin or theme that is not compatible with the new WordPress core version, producing warnings, retries, or fatal errors that surface as the critical error screen
- A plugin version that added new work on every request: a remote license check, a new analytics event, a new hook into a core API
- A deprecation warning in the new code now logged on every request to
debug.log, at a measurable cost if the log lives on slow storage - A database migration that did not finish, leaving the site half on the old schema and half on the new one
A temporary dip gets better as you keep refreshing. A structural regression does not care how many times you reload.
What slow-after-update is NOT
Most confusion about this problem comes from treating every post-update slowness as the same thing, or blaming the update for a problem that was already there.
- Not the same as a generally slow site. If the site was already slow before the update, the update did not cause it. The update may have cleared a cache that was papering over the underlying problem, but that underlying problem is the one to fix. Start from the general slow WordPress site article instead of chasing the update.
- Not the same as slow after installing a plugin. An update changes existing code. Installing a new plugin adds new code. For an install the suspect is obvious; for an update it is one of dozens of files that changed.
- Not the same as hitting a worker or CPU ceiling. An update can push the site over an edge it was already near, but the underlying cause is still the ceiling. If the first post-update traffic spike saturates PHP-FPM workers or pins the CPU at its quota, raising the ceiling is the real fix, not rolling back the update.
- Not the same as WordPress being "heavier on newer PHP." The opposite is true. Kinsta's PHP benchmarks measured WordPress 6.1 on PHP 8.1 at roughly three times the requests per second of PHP 5.6. If a site feels heavier after an update, it is usually the reverse: old PHP is holding the site back and the update pushed it over the line. See how to change the PHP version in WordPress for the upgrade procedure.
- Not a signal that you need more hosting. Hardware is occasionally the bottleneck, but blaming the hosting plan is the default reach when the real cause is harder to find. More CPU and more RAM do not fix a plugin running a broken upgrade routine in a loop.
Where to go next
If you are not sure which layer is at fault, the general slow WordPress site article narrows down by request layer. If the slowness lines up with a specific plugin you just installed, the slow after plugin installation article walks through how to isolate it. If the update crashed the site rather than slowed it, the critical error on this website article covers the fatal-error path instead.