What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Debug WordPress performance by measuring the same request repeatedly, then separating frontend loading problems from backend time, database work, cache behavior, and hosting capacity. Start with Tools → Site Health, profile representative requests with Query Monitor, and compare cached, uncached, anonymous, and logged-in cases before changing code or server settings.
A speed score alone cannot identify the bottleneck. The useful evidence is a repeatable test case with its URL, user state, device, geography, cache state, timings, query counts, PHP time, headers, and Web Vitals. This guide shows how to collect that evidence safely and turn it into a targeted fix.
Free tools Windows power users keep installed
One-click scans. No signup required.
1. Define the exact performance symptom before changing anything
“WordPress is slow” describes several different failures. A page can render slowly in a browser while the server responds quickly, or the server can spend seconds generating HTML before the browser receives the first byte. A problem may affect every visitor, only logged-in users, one template, one device class, or only cache misses.
Write down a test case that another person can repeat. Use the same URL and request conditions after every change so that an improvement can be attributed to one intervention rather than to a different cache state or network path.
#1 Best Overall
Record these variables
- URL and route: include the exact page, post, archive, search, checkout, REST endpoint, or admin screen.
- User state: anonymous, logged in, administrator, or a special account with a particular role.
- Device and browser: desktop or mobile, operating system, browser, viewport, and whether extensions are disabled.
- Geography and connection: testing location, network type, and whether a VPN or corporate proxy is involved.
- Cache state: page-cache hit, miss, bypass, stale entry, or a request that normally excludes caching.
- Time and repetition: timestamp each run and repeat enough times to distinguish a stable delay from a one-off backend or network event.
Build a small test matrix
| Scenario | What it helps reveal | Result to record |
|---|---|---|
| Anonymous visitor, cached page | Whether the delivery path can serve ready HTML without running WordPress | Time to first byte (TTFB), status, cache headers, total load time |
| Anonymous visitor, cache miss | PHP, database, plugin, theme, and external-request work needed to generate the page | TTFB, PHP time, query time, query count, HTTP API time |
| Logged-in visitor | Authenticated pages often bypass full-page caches and expose uncached application work | TTFB and the same backend metrics as the miss |
| Mobile browser or mobile lab run | Image, font, JavaScript, CSS, and main-thread limitations that desktop tests can hide | LCP, INP, CLS, transferred bytes, waterfall order |
| Several representative routes | Whether the defect belongs to one template or the whole installation | Per-route timings and the shared component responsible |
Keep the original measurements. Do not flush every cache or disable several plugins at once before recording a baseline; doing so removes the evidence needed to identify the cause.
2. Check WordPress Site Health first
WordPress’s native starting point is Tools → Site Health. Review both the Status and Info screens. Site Health does not replace profiling, but it can expose configuration and server conditions that make every request slower or prevent a cache from working.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Review critical and recommended issues
- Read critical issues first, then recommended improvements. Treat recommendations as clues, not proof that they explain the measured delay.
- Check the PHP version, loaded extensions, PHP variables, memory limits, maximum execution time, and upload limits. A host may need to change values that cannot be edited from WordPress.
- Inspect the database section and confirm that WordPress can connect normally.
- Check filesystem permissions and whether WordPress can write updates, temporary files, and cache files.
- Review REST API availability. A blocked or failing REST request can delay editor screens, authenticated interfaces, and plugins that depend on asynchronous requests.
- Examine scheduled events. A backlog or an expensive recurring task can compete for PHP workers and database resources.
- Confirm that plugins and themes are current and note whether an update coincided with the regression.
Use the Info screen as a configuration inventory
Record the server architecture, web-server software, PHP version and extensions, database engine and version, active theme, active plugins, filesystem method, and available constants. This inventory makes a staging reproduction possible and gives a host enough detail to investigate resource limits.
Check cache and object-cache detection
Site Health can report whether a page cache is detected and whether a persistent object cache is available. A “not detected” message is a signal to inspect the actual response headers and host configuration; it is not, by itself, a measurement of page speed. Some hosts expose a cache through a reverse proxy that WordPress cannot identify reliably.
3. Measure the browser and Core Web Vitals separately from server time
The Core Performance Handbook treats Web Vitals as the overall benchmarking layer. Use field data when available to understand real visitors and a controlled lab run to reproduce a page under known conditions. Browser developer tools add the request-level detail that a single score omits.
Interpret the main browser metrics
- Largest Contentful Paint (LCP): when the largest visible content element becomes available. Inspect the element itself, its image or font dependency, server response, and render-blocking resources.
- Interaction to Next Paint (INP): how quickly the page responds throughout the visit. Long JavaScript tasks, heavy event handlers, and third-party scripts can increase it even when the initial page appears fast.
- Cumulative Layout Shift (CLS): unexpected movement during loading. Missing image dimensions, late font swaps, injected banners, and dynamically inserted elements are common causes.
Do not use a poor Web Vitals result as evidence that a particular plugin is responsible. First identify the slow request, long task, asset, or layout change in the browser trace.
Read the network waterfall
- Open the browser’s developer tools and select the Network panel.
- Reload with the same cache setting used in your test case. A hard reload can represent a cold browser cache rather than a normal visitor.
- Find the document request and record DNS, connection, TLS, request waiting, response download, and total timing. The waiting portion commonly contains server TTFB.
- Sort or filter by size and duration. Identify oversized images, font files, render-blocking CSS or JavaScript, long third-party requests, and requests that start only after another script runs.
- Compare a cached document with an uncached or logged-in request. If the document’s server wait dominates only on misses, investigate PHP, database, and cache generation rather than image compression.
Distinguish frontend transfer from backend TTFB
A high TTFB means the browser waited a long time before receiving the first byte; it can reflect slow PHP, database contention, a cache miss, an external API wait, or insufficient workers and host resources. A low TTFB with a late LCP points instead to HTML size, images, fonts, CSS, JavaScript, or third-party work after the response arrives.
4. Profile PHP, database, hooks, and HTTP calls with Query Monitor
Install and use Query Monitor in a controlled manner, preferably on staging or temporarily for an authenticated administrator. It profiles the current request and adds overhead, so do not treat its timings as production visitor timings.
Inspect the request overview
Start with total request time, memory usage, and the PHP version. Compare the same URL as an anonymous cache hit, an anonymous miss, and a logged-in request. The pattern is more informative than one absolute number.
Find slow and duplicate database queries
- Sort queries by duration to find statements that consume the most database time.
- Look for duplicate queries: repeated requests for the same data often indicate inefficient code or missing caching.
- Group queries by component when Query Monitor identifies the responsible plugin, theme, or core call.
- Note whether a query runs only on one route, only for logged-in users, or only when a cache is bypassed.
Capture the query text, caller, component, duration, and count before changing code. A query that is fast once but repeated hundreds of times can be more important than a single moderately slow statement.
Rank #3
Trace hooks and actions
Review the hooks and actions that consume the most time and identify the callback or component attached to them. This can reveal a plugin that performs expensive work on every request even when its visible feature is not used on the page.
Inspect WordPress HTTP API calls
External HTTP calls can pause PHP until a remote service responds or times out. Record the destination, duration, response status, and caller. A slow analytics, licensing, feed, payment, or social request may be responsible for TTFB even when local PHP and database queries are normal. Do not assume that making the call asynchronous is safe; confirm what data the page or transaction requires.
Check PHP warnings and notices
Warnings and notices can identify deprecated or failing code and may add logging overhead. Fix the underlying component rather than hiding the message. A warning is not automatically a speed bottleneck, but it is valuable evidence when it appears on the slow request.
5. Map every cache layer instead of treating “cache” as one switch
WordPress hosting guidance describes several distinct layers. Each removes different work, and a hit in one layer does not guarantee a hit in another.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall| Layer | What it stores or avoids | What to verify |
|---|---|---|
| Browser cache | Previously downloaded static assets in the visitor’s browser | Cache-Control or equivalent headers, expiration, and whether versioned files are reused |
| CDN cache | Copies of responses or assets at edge locations | Hit/miss headers, geography, purge behavior, and whether cookies bypass it |
| Reverse proxy | Full HTML responses before they reach PHP, such as a Varnish or NGINX cache | Response headers, bypass rules, logged-in exclusions, and stale-object handling |
| Full-page plugin or file cache | Generated HTML on the web server | Whether the tested route is cached and whether invalidation occurs after edits |
| Static-asset cache | CSS, JavaScript, images, fonts, and other files | Asset headers, compression, file versions, and cache busting after updates |
| OPcache | Compiled PHP bytecode in server memory | Enabled status, memory availability, and reset behavior after deployment |
| Persistent object cache | Reusable WordPress objects and query results between requests | Whether a cache server and compatible drop-in/plugin are active and receiving hits |
| Fragment cache | Reusable portions of a page that cannot be cached as one complete document | Fragment keys, expiration, personalization rules, and invalidation |
Test a cache hit and a cache miss explicitly. A full-page or reverse-proxy hit can avoid running PHP and WordPress altogether. Persistent object caching instead reduces repeated trips to the database while PHP and WordPress still run. As WordPress Developer Resources explains, “Using a persistent Object Cache helps speed up page load times by saving on trips to the database from your web server.” It requires a cache server and a compatible drop-in or plugin; enabling a plugin without a reachable cache server does not create the benefit.
Diagnose bypass and purge errors
- Cookies, query strings, authorization headers, preview mode, and logged-in sessions commonly bypass full-page caches.
- Incorrect exclusions can make every request a miss, while overbroad caching can serve personalized or stale content.
- After changing cache rules, purge the relevant layer and repeat the same request. Record the resulting headers rather than assuming the purge worked.
- Check that cache invalidation occurs when posts, menus, widgets, CSS, and plugin settings change.
6. Investigate PHP, database contention, and server capacity
Every uncached WordPress request may load core files, the active theme, plugin PHP, and database queries. High TTFB can therefore arise from application code, a busy database, an external wait, or a host that cannot provide a worker promptly.
Use timing patterns to narrow the cause
- High PHP time with ordinary query time: inspect theme and plugin callbacks, loops, template rendering, and remote HTTP calls.
- High database time or lock waits: inspect slow and duplicate queries, large option values, scheduled tasks, and concurrent traffic.
- High TTFB but low measured application time: ask the host about worker queues, CPU, memory, process limits, network storage, and upstream proxy delays.
- Only cache misses are slow: prioritize page-cache coverage, PHP execution, database work, and object caching.
- Only logged-in pages are slow: examine authenticated queries, admin-bar or personalization code, and the normal cache bypass rules.
Understand persistent object caching
A persistent object cache keeps selected WordPress objects between requests, reducing repeated database trips. It is different from a full-page cache: personalized or uncached requests still execute PHP, but repeated lookups can be served from the cache server. Confirm that the cache server is reachable, that the drop-in is active, and that keys are being stored and invalidated correctly. A stale or misconfigured object cache can create correctness problems, so test updates and invalidation as well as speed.
Account for scheduled work
Scheduled events can run during visitor requests when they are triggered by traffic. Review expensive recurring tasks and backlogs in Site Health and correlate their execution times with slow requests. Move heavy maintenance work to an appropriate system scheduler or adjust the task only after confirming the host’s supported configuration.
7. Isolate a plugin, theme, or code regression safely
Make isolation changes on staging whenever possible. If production must be tested, restrict access, take a current backup, choose a low-risk window, and change one component at a time.
- Clone the affected route and its test conditions: the same URL, account state, cache state, and device.
- Switch temporarily to a default WordPress theme. Retest and compare the same Query Monitor and browser measurements.
- If the problem disappears, restore the original theme and inspect its template, hooks, queries, and asset enqueues.
- If it remains, disable one plugin at a time, starting with components that run on every request, make remote calls, modify queries, or add frontend scripts.
- After each change, purge only the required cache layer, repeat the test, and record the result.
- Inspect PHP and web-server logs for the exact request. Re-enable unaffected components so the final isolation state remains understandable.
Use diagnostic constants only in controlled environments
For staging or local work, WordPress debugging constants can expose warnings and use unminified assets. A typical temporary configuration is:
Best Value
- Offer contains ONLY 2 titles regardless of the order quantity placed for this listing. Set of volumes may vary. Ordering in multiples will not change the volume received. Image is meant to display the type of book you will be receiving only.
- BRAIN TEASING. Perfect Puzzle Book for all ages to learn. Enjoy puzzles, maze, word search, or crosswords! This puzzle book is ideal for people on the go and will provide hours of entertainment.
- FUN & CHALLENGING. Exercise your brains long-term memory, working memory, executive functioning, attention to detail, multitasking, and processing speed. Perfect gifting item for those who love word search puzzles!
- RELAX, RECHARGE, & REFOCUS. The word find puzzle book offers an enjoyable challenge for all, from beginners to experts. Ideal for learning, practicing, and having fun time for various users.
- OFFICIALLY LICENSED. High-resolution printing. Perfect for family activities, classroom learning, or travel. Provide an engaging, educational experience with every page, making it both fun and meaningful.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'SCRIPT_DEBUG', true );These settings can reveal problems, but debug output and logs may disclose paths, queries, credentials, or user data. Turn them off after the test or restrict access and protect the log. Do not leave broad debugging enabled for public production visitors.
Use local tools for code-level defects
PHPUnit is appropriate for repeatable tests of plugin and theme behavior. Xdebug can provide step debugging and profiling in local or staging environments. Both tools can add substantial overhead; use their output to understand a defect, then measure the normal configuration again.
8. Choose a fix by symptom layer and intervention scope
| Observed symptom | First evidence to collect | Likely intervention scope |
|---|---|---|
| Poor LCP with low document TTFB | LCP element, image/font timing, render-blocking waterfall | Image dimensions and delivery, font loading, CSS, JavaScript, or third-party assets |
| High INP after the page appears | Long tasks, event handlers, script ownership | Plugin/theme JavaScript, third-party scripts, and main-thread work |
| High CLS | Layout-shift entries and the element that moved | Reserved media space, stable fonts, and controlled dynamic insertion |
| High TTFB only on cache misses | Cache headers, PHP time, database time, HTTP API calls | Page-cache rules, PHP code, queries, object cache, or worker capacity |
| One route has many slow or duplicate queries | Query Monitor callers, duration, count, and route | Template/plugin query code, indexes or data access, and object caching |
| All routes slow during external-service incidents | HTTP API timings, status, timeout, and caller | Timeout and failure handling, deferred work, or removal of nonessential calls |
| Logged-in users slow while public pages are fast | Authenticated Query Monitor profile and cache-bypass headers | Personalization, admin-only queries, authenticated APIs, and worker capacity |
Compare candidate fixes by the layer they affect, how consistently the symptom reproduces, whether the request is a cache hit or miss, and how broad the change is. A targeted query or plugin correction is safer than replacing the entire cache stack when the evidence points to one callback.
9. Verify the fix and document what changed
- Keep the original baseline and repeat the identical test matrix after the change.
- Record TTFB, total request time, PHP time, database time, query count, duplicate-query count, HTTP API time, memory, cache headers, and relevant Web Vitals.
- Test representative routes, not only the page used during debugging.
- Test both cached and uncached states, plus an authenticated request when the site has logged-in users.
- Check content correctness, personalization, forms, REST requests, scheduled events, and cache invalidation.
- Watch logs and field measurements after deployment. A lab improvement that introduces a production regression is not a successful fix.
Document the exact configuration or code change, the environment, the cache state, the measurements before and after, and the rollback method. WordPress Core Performance Team states: “Measuring performance is crucial to identify notable performance improvements and to avoid performance regressions.” That principle is what turns troubleshooting into a repeatable engineering process rather than a sequence of guesses.
Quick Recap
10. Common debugging mistakes
- Changing several settings at once: you lose the ability to identify which change mattered.
- Optimizing from a single score: a score does not reveal whether the delay is network, browser, PHP, database, cache, or a third party.
- Testing only a warm browser cache: first visits and cache misses can have a completely different path.
- Assuming a cache plugin caches every request: cookies, authentication, previews, and exclusions often bypass it.
- Blaming the largest plugin: ownership of a slow query, hook, or HTTP call is stronger evidence than plugin size or popularity.
- Leaving debugging enabled: public logs and displayed notices can expose sensitive information and add overhead.
- Declaring success after one fast run: repeat the request and test other routes, devices, and user states.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
