When TTFB suddenly gets worse after a WordPress change, the instinct is usually to blame the server. Sometimes that is true. More often, the slowdown is split across application work, cache misses, and third-party code that changed the shape of the request.
Start with what changed
The useful shortlist usually looks like this:
- a theme update
- a new plugin or tracking script
- a cache or CDN rule change
- query-heavy template changes
- a deployment that altered warm-cache behavior
If the timing lines up with one of those, do not start with generic "optimize the server" work.
Separate cold-cache from warm-cache performance
A page that is slow on every request is a different problem from a page that is only slow when cache misses happen. That distinction tells you whether the bottleneck is mostly origin work or mostly cache strategy.
When the cold path is bad, look at:
- expensive queries
- plugin hooks that run on every render
- API calls or remote requests
- template logic that grew too heavy
When the warm path is still bad, the CDN, cache key logic, or bypass rules may be doing the damage.
Third-party code changes the shape of the slowdown
Some releases do not make PHP dramatically slower. They simply add more dependencies, more conditionals, or more post-render work that pushes the request over the edge. That is why the fix often lives in the interaction between plugins, object cache behavior, and page generation rather than the server tier alone.
Verify what actually moved
The clean first sprint is not "speed everything up." It is:
- isolate the dominant TTFB path
- fix the heaviest contributor
- compare before and after timings on the same page type
That gives you a defensible handoff instead of a long list of possible ideas with no proof attached.