Recommended Free Tools
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.
Check a WordPress site in layers rather than trusting one speed score. Start in Tools > Site Health, test representative public URLs in PageSpeed Insights and WebPageTest, read LCP, CLS, INP, FCP and TTFB together, then classify the delay as front-end, server-side or third-party work. Make one controlled change and rerun the same tests several times.
This approach tells you both what visitors experience and which part of the stack is responsible. It also prevents a common mistake: replacing plugins or changing hosts when the actual problem is an oversized hero image, a blocking script or a slow database query.
What a useful WordPress performance check should tell you
A performance check is more than asking whether a homepage “feels fast.” You need evidence for five separate questions:
- Can WordPress complete its own updates, loopback requests and background operations?
- How quickly does the server begin responding?
- When do visible page elements render, and does the layout remain stable?
- How quickly does the page respond when a visitor taps, clicks or types?
- Which request, plugin, image, font, database operation or external service is creating the delay?
No single measurement answers all five. WordPress Site Health exposes configuration and operational problems; PageSpeed Insights combines controlled lab testing with real-user data; WebPageTest gives you more control and a request-by-request waterfall. For server-side investigation, WordPress Core Performance documentation points to profiling and timing tools such as Query Monitor, XHProf and Server-Timing.
#1 Best Overall
Step 1: Start with WordPress Site Health
In the WordPress dashboard, open Tools > Site Health. The Status tab groups findings into critical issues, recommended improvements and passed tests. Resolve a critical operational issue before treating a speed score as a tuning target: a site that cannot update reliably or complete loopback requests may also fail to produce dependable performance measurements.
Review the Status tab
- Critical issues: Investigate these first. They can indicate failures that affect normal requests, updates or background tasks.
- Recommended improvements: These are not always immediate outages, but they can reveal configuration that limits reliability or efficiency.
- Passed tests: Keep them as part of your baseline. A later change that turns a passed test into a warning is a regression even if a synthetic score rises.
Site Health can flag outdated PHP, update problems, loopback failures and blocked HTTP requests. Each warning needs context: a blocked request may be caused by a firewall, authentication rule or server policy rather than by a theme or plugin.
Free tools Windows power users keep installed
One-click scans. No signup required.
Use the Info tab as an environment record
The Info tab exposes WordPress, active theme and plugin, media, server, database, constants and filesystem details. It can export this information. Save an export with your test notes so you can tell whether a later result used the same PHP version, database, theme and active plugins.
The server section is particularly useful when a slow response might be outside your control. It documents the PHP and server environment, while host-controlled settings may require the provider’s assistance. Do not infer that a particular host setting is wrong merely because a front-end score is low; use the later timing and waterfall evidence to connect the environment to the symptom.
Step 2: Select representative URLs
Do not test only the homepage. Record the exact final URL, including any redirect, for each template that matters to your visitors:
- Homepage
- A typical blog post or article
- A landing page
- A category or other archive page
- A product, cart or checkout page when the site has commerce
This is a practical testing recommendation, not a mandatory WordPress page list. Pick URLs that represent different templates, query patterns and content weights. A cached marketing homepage can be fast while an uncached archive or checkout page remains slow.
For every URL, record the device mode, test location, browser or connection profile, date and whether you were logged in. Use the same final URL and setup in later runs. If a page changes by geography, cookie, personalization or experiment, note that too; otherwise you may compare different documents and mistake content variation for a performance regression.
Step 3: Run PageSpeed Insights and keep lab and field data separate
PageSpeed Insights reports two different kinds of evidence:
| View | What it represents | Best use | Important limitation |
|---|---|---|---|
| Lab data | A controlled page load under the tool’s test conditions | Reproducing a problem and evaluating a change | It is not the experience of every visitor and can vary between runs. |
| Field data (CrUX) | Real-user measurements for eligible pages and visitors | Understanding production experience across actual devices and networks | It may be unavailable for a page without sufficient eligible data and changes more slowly than a lab run. |
Run both mobile and desktop views. Read the field section as a population-level signal and the lab section as a controlled diagnostic. A page can have a respectable lab result while real visitors on slower phones experience delayed interaction, or show a poor lab result while field data remains healthy for the audience you actually serve.
Capture the metric values, the displayed opportunities and the URL tested. An opportunity is a lead, not an automatic prescription. For example, reducing JavaScript may improve a lab estimate but break a menu, form or checkout flow; verify the page after every change.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsStep 4: Use WebPageTest when you need a diagnosis
WebPageTest lets you select test locations, browsers and connection speeds. Its detailed results include optimization opportunities, image analysis, an environmental impact report and a waterfall that separates connection time, server response, blocking resources and late-loading assets.
Use a location near your principal audience for an experience-oriented check, then choose a second location when geography is part of the problem. Keep the browser and connection profile fixed while comparing versions. The waterfall is often more informative than a headline grade:
- A long wait before the first response points toward DNS, network or server processing.
- A fast document followed by a long queue of scripts, fonts or styles points toward front-end work.
- A late, oversized image can explain a poor largest-contentful paint even when the server responds quickly.
- Repeated calls to an external domain identify third-party work that your WordPress code may not directly control.
Save the test result or its identifier in your notes. A later test is useful only if you can reconstruct the conditions that produced the earlier one.
The metrics to read in WordPress performance tests
Read these metrics as a chain, not as isolated grades.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →| Metric | What it measures | Question it helps answer |
|---|---|---|
| Largest Contentful Paint (LCP) | When the largest visible element becomes available | When can a visitor see the main content, hero image or heading? |
| Cumulative Layout Shift (CLS) | Movement of page elements while loading | Does the page jump as images, ads, fonts or embedded content arrive? |
| Interaction to Next Paint (INP) | Responsiveness after user interactions | After a click, tap or key press, how quickly does the interface show the next visual response? |
| First Contentful Paint (FCP) | When the first piece of content appears | How quickly does anything visible begin to render? |
| Time to First Byte (TTFB) | Time until the first byte arrives from the server | Is the initial delay occurring before the browser can receive the document? |
FCP and LCP describe progressively later rendering milestones. TTFB provides server-response context, while INP reveals a problem that a static load test can miss. CLS is about stability rather than speed: a page may display quickly and still be frustrating if controls move under the visitor’s finger.
PageSpeed Insights’ lab and field sections may show different values for the same metric because they measure different populations and conditions. Do not average them into one number or describe a lab value as a real-user result.
Classify the bottleneck before changing anything
Once you have Site Health, PageSpeed Insights and a waterfall, classify the dominant delay. The same low score can have entirely different fixes.
| Evidence | Likely layer | Next investigation |
|---|---|---|
| High TTFB or a long gap before the document arrives | Server, network, PHP or database | Review Site Health’s server details, cache behavior, database work and server timing. |
| Document arrives promptly, but scripts, styles, fonts or images occupy the waterfall | Front end | Inspect asset size, priority, render-blocking behavior and which plugin or theme enqueues each file. |
| LCP is delayed by a large hero or featured image | Media delivery and rendering | Check image dimensions, format, compression, preload decisions and whether the image is hidden behind a carousel or script. |
| CLS rises as content loads | Layout and embeds | Reserve dimensions for images and frames; inspect fonts, ads, banners and injected notices. |
| INP is poor after a click or tap | JavaScript and main-thread work | Identify long tasks, event handlers and third-party scripts triggered by the interaction. |
| A late external request dominates the waterfall | Third party | Determine whether the service is essential, defer it where safe, or remove it and retest. |
Front-end causes
Large images, custom fonts, carousels, popups, bloated themes, plugin assets and embedded media all add browser work. A plugin can slow a page even when its visible feature is not used on that template if it loads assets site-wide. Compare the list of requests on a fast template with the list on a slow one, then identify which theme or plugin added the extra files.
Windows 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 reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteDo not disable a plugin solely because it appears in the request list. First verify whether the request belongs to that plugin, whether the feature is needed, and whether a configuration can limit the asset to the pages that use it. Test navigation, forms, search and logged-in behavior after any asset change.
Server and back-end causes
Hosting infrastructure, network distance, server hardware, PHP configuration, database operations and cache state influence TTFB. A page that is fast from one location and slow from another may have geographic or network effects; a page that is slow only when uncached may have expensive PHP or database work.
Site Health documents the environment but does not replace server logs or profiling. Ask the provider for help when a setting is host-controlled, and supply the exact URL, time, location and repeated measurements rather than a single score.
Third-party causes
Analytics, advertising, chat, social embeds, consent tools and externally hosted fonts can delay rendering or interaction. Third parties can also vary independently of your deployment, so record the domain and request timing in the waterfall. Remove or defer one service at a time, verify legal and product requirements, and retest the same URL.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When a page test is not enough: profile WordPress
Use deeper tools when you need to locate a query, hook or server-side operation rather than simply observe a slow page.
Query Monitor
Query Monitor can help associate slow database queries, PHP errors, hooks and HTTP requests with a request while you are logged in. Use it in a staging environment or during a controlled diagnostic window where possible. Logged-in pages, debugging output and uncached requests are not equivalent to a normal visitor request, so use the tool to find suspects and then confirm the result with an external page test.
XHProf or an equivalent PHP profiler
A PHP profiler records where server-side execution time is spent. It is appropriate when a request has high TTFB but ordinary plugin lists do not reveal why. Profiling adds overhead and may require server access; enable it only for a controlled test and follow the host or staging environment’s safety procedures.
Server-Timing
Server-Timing can expose backend phases in browser developer tools or a compatible test report. Use it to distinguish application, database and cache portions of the response. The names and granularity of timings depend on the implementation, so treat them as instrumentation rather than a universal WordPress report.
Web Vitals and field data
Web Vitals data helps connect loading, stability and interaction to production visitors. Field evidence is especially valuable after a release because a synthetic test may not reproduce the device, network or interaction pattern that triggered a regression.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A repeatable test protocol
Performance naturally varies. WordPress Core Performance guidance notes that even two tests of the exact same URL can produce slightly different results. Use several requests and change only one variable at a time.
- Freeze the test definition. Write down the final URL, mobile or desktop mode, browser, connection profile, location, login state and date.
- Record the software state. Note the WordPress version, PHP version, database, active theme, active plugins and relevant cache settings. Site Health’s Info export can provide much of this record.
- Warm or clear caches consistently. Decide whether the comparison is for a cold request or a warmed cache. Apply the same procedure before every run.
- Run multiple requests. Do not base a decision on one request. Keep the setup unchanged and record the range or pattern of results.
- Capture both evidence types. Save PageSpeed Insights lab and field observations separately, then use WebPageTest when the waterfall or controlled location is needed.
- Make one controlled change. Change one image, plugin setting, script, cache rule or server variable so any movement in the metrics has a plausible cause.
- Retest the same scenarios. Use the identical URLs and conditions, and check functionality as well as timing.
- Document the decision. Keep the before-and-after values, the changed variable, the date and any side effects. Revert if the change harms another template or interaction.
Common findings and what to do next
“My score changes on every run.”
That is normal. Network congestion, machine load, cache state and third-party responses change between requests. Increase the number of runs, hold the setup constant and look for a consistent pattern instead of chasing the best or worst single value.
“The homepage is fast, but posts are slow.”
Compare the templates and request lists. Posts may load different fonts, related-content widgets, comments, advertising, featured images or plugin assets. Test a representative post and the homepage separately; do not apply a homepage-only conclusion to every URL.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →“TTFB is high, but the browser waterfall is otherwise short.”
Investigate server-side work and cache state. Review Site Health’s server and PHP information, then use Server-Timing, Query Monitor or profiling if you have access. If the delay is host-controlled, provide repeated measurements and timestamps to the provider.
“LCP is poor even though TTFB is acceptable.”
Inspect the element identified as the largest contentful element. Check its image size and delivery, whether CSS or JavaScript delays its visibility, and whether a carousel or consent layer hides it until late in the load. Optimize or reprioritize that element, then retest the same URL.
“CLS is high.”
Look for images, video frames, advertisements, banners, web fonts and injected UI that change dimensions after the first paint. Reserve space for known content and retest on the affected device profile. A visual-stability fix should be checked on every template that uses the component.
“INP is poor, although the page loads quickly.”
Reproduce the interaction that feels slow. Identify the event handler, long JavaScript task or third-party callback running after the tap, click or key press. Reduce the work or defer nonessential code, then verify that the interaction still performs its required action.
“A plugin appears in every performance discussion.”
Presence is not proof of causation. Confirm the plugin’s requests, database queries or hooks on the slow URL. Test its setting or removal in staging, check the site’s required features, and compare multiple runs before deciding.
How to choose the right checking method
| Need | Best starting method | Access required |
|---|---|---|
| Check WordPress configuration and operational warnings | Site Health Status and Info | WordPress administrator access |
| Quick mobile and desktop view with real-user context | PageSpeed Insights | Public URL |
| Control location, browser and connection; inspect requests | WebPageTest | Public URL |
| Find a slow query, hook or PHP operation | Query Monitor, XHProf or Server-Timing | Usually WordPress, staging or server access |
| Detect production regressions over time | Field data and recurring monitoring | Production data or a monitoring system |
Use the least complicated method that can answer the question. A public page test is sufficient for a first observation; server profiling is justified when the evidence points to back-end work and you need to identify the exact operation.
A practical performance-check worksheet
Keep one record per URL with these fields:
- Final URL and template type
- Mobile or desktop mode
- Test location, browser and connection
- WordPress, PHP, theme and plugin versions
- Cache state and login state
- PageSpeed Insights lab values and field-data availability
- WebPageTest waterfall notes and test identifier
- LCP, CLS, INP, FCP and TTFB observations
- Suspected layer: front end, server/back end or third party
- One change made, date, before-and-after runs and functional checks
Review this worksheet after releases, theme changes, plugin updates and infrastructure changes. A performance improvement is credible when it appears across repeated runs without creating a new Site Health warning or breaking a required interaction.
How to prioritize fixes
Prioritize a bottleneck that is both measurable and important to visitors. Start with a problem that affects a high-value template or a large share of traffic, then choose the smallest change that tests your hypothesis. For example, if a waterfall shows one oversized above-the-fold image delaying LCP, changing that image is a more informative first experiment than replacing the entire theme.
Separate reliability work from optimization work. Resolve update failures, blocked requests and loopback problems as operational issues. Address high TTFB with server, cache, PHP or database investigation. Address LCP, CLS and INP with the specific rendering, layout and interaction evidence shown by the tests. Recheck all representative templates after a shared theme or plugin change.
Quick Recap
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.
