Short answer: a sudden slowdown is a change, not gradual decay. Something specific happened — a plugin, a data volume, a server condition, an external dependency or an attack. Find it before adding more layers on top.
Measure before you optimise
Installing a caching plugin over an unknown bottleneck masks the symptom for logged-out visitors while the admin stays unusable. Establish where time goes: waiting for the server to respond (TTFB) versus downloading and rendering assets. Use the browser Network tab and a tool like Query Monitor to see slow database queries and which plugin fires them.
Slow server response usually means
- An inefficient or unbounded database query — Query Monitor names the plugin and the query.
- A slow external API called during page generation.
- A bloated database: autoloaded options, expired transients, revisions, sessions.
- Resource contention on shared hosting, or bot/scraper traffic consuming capacity.
Narrow it down
- Compare a logged-out load with a logged-in one; a big gap points at the admin or an uncached path.
- Check whether one page or the whole site is slow.
- Review what changed — updates, imports, new plugins, traffic patterns.
- Rename the plugins folder to measure a baseline, then re-enable in groups to find the heavy one.
- Ask the host for resource metrics over the period the slowdown began.
Consider whether it is really performance
Sudden slowness sometimes has a security explanation: a compromised site can send spam, mine, or serve injected content, all of which consume resources. If it arrived with unexplained traffic, unknown files or hosting warnings, treat it as a possible compromise, not a tuning exercise. Re-measure the pages that matter commercially — landing, product, checkout — from a realistic connection, not a cached local test.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Sudden slowness is a change event. Measuring server wait, database time, external calls and asset rendering separately prevents cache from masking an unhealthy backend.
- 1
Compare time to first byte with asset download and rendering time.
- 2
Measure logged-out and logged-in requests and one slow route versus the whole site.
- 3
Inspect database queries, autoloaded options, external calls and server resource graphs.
- 4
Correlate the start with updates, imports, traffic changes, cron or security events.
What must be verified
- Representative cached and uncached requests meet an agreed baseline.
- Database and external-call time are stable under realistic concurrency.
- The administrator and scheduled jobs remain responsive.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →