Define what is slow
Record the specific admin screen, action, user role and time to respond. Compare the dashboard with a public page and repeat a small number of times. Slow admin-only requests may bypass a page cache, so a fast cached home page does not rule out PHP or database pressure.
Check server CPU, memory, storage latency and PHP worker availability during the slow request. Correlate web-server timing and application logs without exposing session cookies or customer data. An external API call, database query or plugin hook can all contribute.
Compare one change at a time
Use a staging copy with comparable plugins, configuration and representative data. If outbound email, payments or integrations are enabled in the copy, disable or redirect them safely before testing. Deactivate one suspected plugin at a time or use an isolated troubleshooting mode, then repeat the same action.
Inspect slow-query evidence and application profiling if available. A slow query in one request needs context: check frequency, parameters and the caller before changing indexes. Avoid deleting database tables merely because a plugin appears in a trace.
Check shared resources
Exhausted PHP workers can make unrelated admin requests wait. Compare active workers, request duration and memory headroom. Increasing worker count without a memory budget may worsen the outage. Check whether object cache, external calls and scheduled tasks behave differently in staging.
Choose a supported fix, verify both the original admin task and public functionality, then monitor the next representative workload. Record versions, measurements and the rollback point so that a later update can be evaluated against the same baseline.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.