If you are asking “why is my WordPress site slow?”, the answer is in your own data, and you can find it in about an hour. First confirm the problem with field data from real visitors in Search Console or PageSpeed Insights. Then split the load into server time and browser time by checking TTFB on cached and uncached requests. If the server is slow, use Query Monitor and the database to find the plugin, query or remote call that costs the time. If the server is fast, use Chrome DevTools to find the image, script or third-party tag that delays rendering or interactions. Fix the biggest one first.
This post is the diagnostic half. My other article on why WordPress sites are slow for structural reasons explains the causes I keep finding: hosting, database, render-blocking assets and third-party scripts. Here the question is narrower: on your site, today, which one is it? Once you know, the guide to speeding up WordPress covers the fixes layer by layer.
Is the site slow for visitors, or only in a test?
Check this before anything else, because a lot of WordPress “slowness” is a lab score on one run. PageSpeed Insights shows two things on the same page: field data from the Chrome UX Report at the top, and a Lighthouse lab run below it. Field data is what Google uses for Core Web Vitals. It is the 75th percentile of real page loads over the last 28 days.
- If field data passes and only the lab score is low, you don’t have an emergency. You have a lab score.
- If field data fails, note which metric fails (LCP, INP or CLS) and on which URL groups. Search Console’s Core Web Vitals report groups similar URLs, which usually maps to templates.
- If there is no field data, the site doesn’t have enough Chrome traffic for CrUX. Use lab data, and treat it as an approximation.
Why the two kinds of data disagree is a topic of its own, covered in field data vs lab data.
Why is my WordPress site slow: server or browser?
Every page load splits into two halves: the time until the HTML arrives (TTFB), and everything the browser does after. That split tells you where to look.
| What you see | Likely layer | Where to look next |
|---|---|---|
| — | — | — |
| High TTFB on every page | Hosting, PHP, no page cache | Server checks below, TTFB guide |
| TTFB fast sometimes, slow other times | Cache misses or bypasses | Response headers, cookies, query strings |
| High TTFB only on some templates | A plugin, query or remote call on those templates | Query Monitor |
| Good TTFB, poor LCP | Images, CSS, fonts, render-blocking scripts | DevTools Performance panel, LCP guide |
| Good LCP, poor INP | JavaScript and third-party tags | DevTools with CPU throttling, INP guide |
| Admin slow, front end fine | Heartbeat, admin-ajax, cron, heavy plugin screens | Query Monitor in wp-admin |
web.dev considers TTFB good at 0.8 seconds or less. If yours is well above that, start with the server even if the complaint was about images.
How do you check whether the server is the problem?
Measure TTFB directly, with and without the cache. From a terminal:
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/gives the time to the first byte- run it twice on the same URL; the second run should hit the page cache
- run it again with a query string such as
?nocache=1or with a logged-in cookie to see the uncached time
Then read the response headers with curl -I. Most page caches add a header that says HIT or MISS, and a CDN adds its own. If your main landing pages return MISS on repeated requests, the cache is being bypassed. Common reasons are cookies set for every visitor, campaign parameters and short cache lifetimes. The three cache layers are explained in page cache, object cache, edge cache.
If the uncached time is high, the work is in PHP and the database. That is where you need tools that look inside WordPress.
How do you find plugins slowing down WordPress?
With a profiler, not by deactivating plugins one by one on production. My order:
- Install Query Monitor on a staging copy, or on production for administrators only.
- Load the slow template while logged in and open the Queries by Component panel. It groups database queries and their time by plugin and theme.
- Open the HTTP API Calls panel. A plugin calling a remote API during page generation is one of the most expensive things I find, and it hides well because it depends on someone else’s server.
- Check the Hooks and Actions panel for callbacks that run on every request but only matter on one screen.
- If you have WP-CLI, the profile command package (
wp profile stageandwp profile hook) breaks the request into bootstrap, main query and template, then down to individual hooks. - If you still need to confirm, deactivate plugins on staging in halves. Turn off half, measure, then narrow down the half that changed the number.
Write down the time per plugin or hook. That turns “WordPress is slow” into “this plugin adds this much time to this template”, which is a problem you can actually fix or escalate to a vendor.
How do you check whether the database is the problem?
Two places cover most cases. The first is autoloaded options: rows in wp_options that WordPress loads on every request. Site Health warns when they get too large (since WordPress 6.6), and with WP-CLI wp option list --autoload=on --format=total_bytes gives the total size. Then list the largest rows and find out which plugin owns each one.
The second is slow queries. Query Monitor flags slow and duplicate queries per request. On the server, the MySQL or MariaDB slow query log shows what is slow across all traffic, including cron and background jobs that Query Monitor never sees. Look for queries on wp_postmeta and wp_options without a usable index, and for the same query repeated dozens of times on one page.
The cleanup itself, and what is safe to delete, is in WordPress database optimization.
How do you find what slows down the front end?
When TTFB is fine, the delay is in the browser. Chrome DevTools has what you need:
- The Performance panel records a page load and marks LCP. Click the LCP marker to see the element, then check whether it was lazy loaded, discovered late or waiting on CSS.
- The Network panel, filtered by domain, shows how many requests come from third parties and how heavy they are. Sort by size and by start time.
- The Coverage panel shows how much of each CSS and JavaScript file the page actually used. On builder sites the unused share is often large.
- For INP, record an interaction (open the menu, add to cart, submit a search) with CPU throttling on, and look for long tasks. The Bottom-Up tab shows which script owns the time.
PageSpeed Insights’ diagnostics point to the same things, but DevTools lets you click through to the cause. The Core Web Vitals tools post compares what each tool shows and when to use it.
Why is only the WordPress admin slow?
A slow wp-admin with a fast front end usually comes from things visitors never trigger:
- the Heartbeat API polling
admin-ajax.phpwhile editors keep tabs open - WP-Cron running heavy scheduled tasks on page loads instead of a real system cron
- plugin dashboards and notices that make remote calls on every admin screen
- list screens that query large postmeta tables, common on stores
Query Monitor works in the admin too. On WooCommerce, the order screens and reports deserve their own check, which I cover in how to fix a slow WooCommerce admin.
What do you do with the findings?
Rank them. For each finding write the layer, the templates it affects, how much time it costs and how hard it is to fix. Server and cache problems affect every page, so they usually go to the top even when the PageSpeed report lists an image first. Then fix one thing at a time and measure again, so you know which change helped.
For the common fixes in a format you can tick off, use the WordPress speed optimization checklist. For the reasoning behind the fix order, go back to the engineer’s guide to speeding up WordPress.
When should you get help?
When the diagnosis points to something you can’t change yourself, or when you have done the obvious fixes and field data still fails. That is exactly what my WordPress performance audit is for: I go through each layer with field data as the reference and hand back a ranked list of what to fix. For longer engagements, see how I work as a WordPress performance specialist.