A fast public site with a slow dashboard points to a different problem from a site that is slow everywhere. Start by separating those two cases.
Compare frontend and admin performance
Open the public site logged out, then compare several wp-admin screens. Note whether the delay affects every admin page or only a plugin-specific screen.
Check resource usage
Hostinger recommends reviewing hosting resource usage when diagnosing a slow WordPress admin area. Its current wp-admin performance guide also highlights resource-heavy database queries as a common cause.
Review recent changes
If slowness started after installing or updating a plugin, test that change first. Security scanners, backup tools, analytics dashboards, page builders and import/export jobs can all create expensive admin requests.
Check scheduled/background work
Look for backups, imports, image processing and WordPress cron activity that coincides with the slowdown. A problem that appears at the same time each day is especially useful evidence.
Avoid optimisation-plugin stacking
Adding multiple caching/database optimisation plugins can create conflicts and does not necessarily speed up wp-admin. Change one variable at a time and measure again.
If the symptom becomes a 503
Use our Hostinger 503 troubleshooting guide and correlate the failure with resource usage.
Slow-admin diagnosis matrix
Use the symptom as evidence. Change one variable at a time so you can tell which action actually fixes the problem.
| What you see | What it suggests | Best next check |
|---|---|---|
| Frontend fast, all admin slow | Admin workload/database/resource issue | Check resource usage and recent dashboard plugins |
| One plugin screen slow | Plugin-specific API/query workload | Test that plugin and its external calls |
| Slow at a fixed time | Scheduled backup/cron/import | Correlate timestamps with scheduled jobs |
| Admin and frontend both slow | Broader hosting/application bottleneck | Check resources, cache, database and traffic |
What not to do
Do not stack extra optimisation plugins while diagnosing. Each additional cache, database or security layer makes it harder to identify which request is actually slow.
How to verify the fix
Measure the same dashboard screens before and after one change. Confirm the improvement persists when logged in and that frontend pages have not regressed.
When to escalate
If the problem persists after the evidence-based checks, preserve screenshots, timestamps, the exact affected URL and any relevant error/log entry before contacting hosting or plugin support. That gives support a reproducible case instead of a generic “site not working” report.
