# WordPress Performance Audit: Fix What's Actually Slowing Your Site

> Run a WordPress performance audit in 7 steps. Learn which metrics matter, find what slows your site and fix it with free tools like xSpeed Scan.

- Published: 2026-10-28
- Updated: 2026-10-28
- Author: xSpeed Team
- Tags: WordPress performance, performance audit, Core Web Vitals, page speed, caching, WordPress speed optimization, xSpeed Cache, site audit
- Canonical: https://xspeedcache.com/blog/wordpress-performance-audit/

---

Your site feels slow. You run PageSpeed Insights, get a score in the 40s and a list of twenty warnings. You install another plugin, tick a few boxes and test again. The number barely moves.

That loop is where most WordPress speed work stalls. A **WordPress performance audit** breaks it by answering one question first: what is actually costing your visitors time? Once you know that, the fix list gets short and the results become measurable.

This guide walks you through a practical audit you can finish in under an hour. You will learn which numbers deserve your trust, what usually slows WordPress down and how **xSpeed Cache** turns each finding into a fix you can verify.

## TL;DR

A **WordPress performance audit** finds the specific causes of slow load times so you can fix the biggest ones first.

Start with real visitor data in Google Search Console. Then use lab tools such as PageSpeed Insights to find out why a page is slow.

Google's **Core Web Vitals** targets are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less.

Most slow WordPress sites share the same few causes: slow server response, a missing page cache, heavy images, render-blocking code and plugin bloat.

Change one thing at a time and re-test after each change so you know what worked.

[**xSpeed Scan**](https://xspeedcache.com/scan/) grades any site for free in 20 to 60 seconds and names a fix for every failing check. xSpeed Cache then applies those fixes and checks the result.

## What Is a WordPress Performance Audit?

A WordPress performance audit is a structured review of how fast your site loads and responds, followed by a ranked list of what to fix. It follows a page request from the server's first response to the moment a visitor can read, tap and scroll without the layout jumping.

It is narrower than a general WordPress site audit, which usually also covers SEO, security and content. It is also different from WordPress speed optimization. The audit is the diagnosis and the optimization is the fix. Running the audit first means you speed up your WordPress site with changes that actually matter.

![The five layers of a WordPress performance audit: server, cache, page weight, render path and database](https://xspeedcache.com/images/blog/wp-performance-audit-layers.webp)

A thorough audit covers **five layers:**

**i. Server response:** how long your host takes to send the first byte of a page.

**ii. Caching:** whether pages come from a ready-made copy or get rebuilt on every visit.

**iii. Page weight:** the total size of images, video, fonts, CSS and JavaScript on each page.

**iv. Render path:** the files that block a page from appearing on screen.

**v. Plugins and database:** the background work WordPress does before it can respond.

### Lab Data & Field Data: Two Views of Speed

Performance tools report two kinds of numbers. Mixing them up is the fastest way to chase the wrong problem. **Lab data** comes from a simulated visit on one device and one network. **Field data** comes from real Chrome users on your site over the previous 28 days. PageSpeed Insights also shows this real-user data from the Chrome UX Report (CrUX) at the top of its report for a URL or your whole origin, so you can see field data without opening Search Console.

**Lab data** from Lighthouse or GTmetrix is best for diagnosis, since you can re-run it after every change.

**Field data** from the Search Console Core Web Vitals report or the CrUX section of PageSpeed Insights reflects what real visitors experience on their own phones and networks.

Use field data to decide which pages need attention. Use lab data to work out why.

## Why Your Speed Score Can Mislead You

The 0 to 100 score in PageSpeed Insights is the number everyone screenshots, which also makes it the easiest number to misread. It comes from one simulated visit and says little about the range of experiences your real visitors have.

![Speed gauges on a phone and a laptop showing a lower score on mobile than on desktop](https://xspeedcache.com/images/blog/wp-performance-audit-mobile-desktop.webp)

Watch out for **three common traps:**

**i. Chasing a perfect desktop score.** Mobile is where most sites struggle. The [**HTTP Archive Web Almanac 2025**](https://almanac.httparchive.org/en/2025/performance) found that 48% of mobile websites pass all three Core Web Vitals, compared with 56% on desktop.

**ii. Treating every warning as equal.** A missing page cache on a slow server matters far more than a few kilobytes of unminified CSS.

**iii. Trusting a single test run.** Lab scores shift between runs. A change that lands inside that normal swing is noise.

Speed still pays off. The Google and Deloitte study [**Milliseconds Make Millions**](https://web.dev/case-studies/milliseconds-make-millions) found that a 0.1 second improvement in mobile site speed lifted retail conversions by 8.4%. The study dates from 2020 and covers retail, travel, luxury and lead generation sites, so treat it as a guide rather than a promise for every type of site. An audit helps you capture gains like that on the pages that bring in revenue.

## The Numbers That Actually Matter

You do not need to track every metric Lighthouse reports. These six cover almost every real WordPress speed problem. Each one points toward a different cause.

| Metric | What it measures | Good target | Usually points to |
| :---- | :---- | :---- | :---- |
| **LCP** (Largest Contentful Paint) | When the main content appears | 2.5 s or less | Slow server, large hero image, render-blocking CSS |
| **INP** (Interaction to Next Paint) | How quickly the page reacts to taps and clicks | 200 ms or less | Heavy JavaScript, third-party scripts |
| **CLS** (Cumulative Layout Shift) | How much the layout jumps while loading | 0.1 or less | Images without dimensions, late fonts or ads |
| **TTFB** (Time to First Byte) | How long the server takes to start responding | About 0.8 s or less | Hosting, missing page cache, heavy PHP work |
| **Page weight** | Total bytes a page downloads | As low as practical, ideally below the [**HTTP Archive median**](https://almanac.httparchive.org/en/2025/page-weight) of about 2.2 MB for a mobile home page | Large images, preloading video, unused CSS and JS |
| **Cache hit ratio** | Hits ÷ (hits + misses) over a rolling 24 hours. Bypassed requests, bot and scanner misses and 404s are not counted. | 80% or higher on a site with steady repeat traffic | A low ratio usually points to a CDN or Cloudflare answering at the edge, long-tail traffic where pages are rarely requested or caching enabled less than a day ago |

LCP, INP and CLS are the three **Core Web Vitals**. Google judges them at the 75th percentile of real page views, according to [**web.dev**](https://web.dev/articles/vitals). In practice, three out of four visits need to hit each target, so your slowest visitors matter a lot.

![The six metrics that matter in a WordPress performance audit: LCP, INP, CLS, TTFB, page weight and cache hit ratio](https://xspeedcache.com/images/blog/wp-performance-audit-metrics.webp)

LCP is where most sites fall short. In the [**Web Almanac 2025 SEO chapter**](https://almanac.httparchive.org/en/2025/seo), 62% of mobile pages had a good LCP, compared with 77% for INP and 81% for CLS.

## How to Run a WordPress Performance Audit in 7 Steps

This process takes 30 to 60 minutes for a typical site and needs no code. Work through the steps in order, since each one narrows down where to look next.

![The seven audit steps in order: field data, speed test, server, waterfall, plugins, prioritize and re-test](https://xspeedcache.com/images/blog/wp-performance-audit-7-steps.webp)

### Step 1: Start with Real Visitor Data

Open [**Google Search Console**](https://search.google.com/search-console) and go to Experience, then Core Web Vitals. The report groups your URLs by status using real Chrome user data, so you can see which page templates fail and on which device.

Note which metric fails most often: LCP, INP or CLS. Note which templates fail, such as product pages, blog posts or the home page. Pick two or three representative URLs to test in depth.

New or low-traffic sites may not have enough field data yet. In our own scans, [**only 23% of WordPress origins had any field data at all**](https://xspeedcache.com/blog/crux-coverage-census/). In that case, lab tests become your main source.

### Step 2: Run a Baseline Speed Test

Run a WordPress speed test on each representative URL in [**PageSpeed Insights**](https://pagespeed.web.dev/), starting with mobile. Record the score, LCP, CLS, Total Blocking Time and the top opportunities in a simple spreadsheet. Lab tools cannot measure INP because no real user is interacting with the page, so Total Blocking Time is the lab stand-in.

Use one row per URL and test date, with columns for the score, LCP, CLS, Total Blocking Time, TTFB, the top opportunities and the report link. Run each test three times and keep the middle result, since single runs vary.

Save every report link so you can compare before and after. For a faster first pass, [**xSpeed Scan**](https://xspeedcache.com/scan/) runs Lighthouse on desktop and mobile plus its own server probes, then grades the site from 0 to 100 in 20 to 60 seconds with no signup.

![xSpeed Scan report for xspeedcache.com: grade 95, desktop 95 and mobile 94, with 8 ms TTFB, 511 ms LCP and 0.00 CLS](https://xspeedcache.com/images/blog/wp-performance-audit-scan-report.webp)

### Step 3: Check Server Response & Cache Hits

Server response time sits underneath every other metric. When the first byte takes a full second to arrive, image compression alone will never get LCP under 2.5 seconds.

Check TTFB in your results. Slow first bytes on every page point to hosting, a missing page cache or heavy PHP work. Our guide to [**reducing WordPress TTFB**](https://xspeedcache.com/blog/reduce-ttfb-wordpress/) explains which number to work on first.

Load a page twice while logged out and check the response headers for a cache status. In Chrome, open DevTools, go to the Network tab, reload the page, click the page request (the first item in the list) and open the Headers panel. Look for a HIT or MISS value in headers such as x-cache or cf-cache-status. Header names vary by host and plugin. A page that never shows a cache hit is rebuilt on every visit. If you use xSpeed Cache, its Health and Insights module shows this for you.

Look for cookies set on every visit. One plugin that sets a cookie for all visitors can quietly stop your page cache from working.

### Step 4: Inspect What Loads on the Page

Next, look at what each page actually downloads. The waterfall in GTmetrix or the Network tab in Chrome DevTools shows every file, its size and when it loads.

- Find the **LCP element**. It is often a hero image, a slider or a large heading block.
- List the render-blocking CSS and JavaScript in the page head.
- Flag images larger than their display size, images missing width and height and videos that preload before anyone presses play.
- Count third-party scripts such as chat widgets, analytics tags, tracking pixels and embeds.

### Step 5: Audit Plugins and the Database

Plugins and database bloat slow down the part of WordPress visitors never see. Every uncached request pays that cost. Logged-in users pay it on every page.

Install [**Query Monitor**](https://wordpress.org/plugins/query-monitor/) on a staging copy to spot slow database queries and the plugins behind them.

List plugins you have stopped using and test deactivating them on staging.

Check the database for post revisions, spam, trashed content and expired transients.

Open Tools > Site Health in your WordPress dashboard. It is free, already installed and flags issues such as an outdated PHP version and a missing persistent object cache.

Check autoloaded options. These are settings WordPress loads on every request, and oversized autoloaded data is a common slowdown. Site Health now warns when it grows too large.

Keep plugin experiments on staging. Deactivating the wrong plugin on a live store can break checkout.

### Step 6: Sort Findings by Impact

By now your list is probably long. Sort it so the fixes with the largest expected gain come first. The effort column helps you spot quick wins.

| Priority | Finding | Why it ranks here | Effort |
| :---- | :---- | :---- | :---- |
| 1 | Slow TTFB or no page cache | Affects every page and every other metric | Low for a page cache, high for a hosting change |
| 2 | Large LCP image or render-blocking files | Directly delays the main content | Medium |
| 3 | Heavy or third-party JavaScript | Drives INP and Total Blocking Time | Medium to high |
| 4 | Layout shifts | Usually quick to fix with dimensions and font settings | Low |
| 5 | Database and plugin cleanup | Helps uncached and logged-in traffic | Low to medium |

### Step 7: Fix One Thing at a Time And Re-Test

Apply one change, clear the cache and re-test the same URLs. If the new score falls inside normal run-to-run variation, record it as unchanged.

Keep a change log with the date, the setting and the before and after numbers.

Undo any change that breaks the layout or makes the page measurably slower.

Recheck field data in Search Console after about 28 days, since real-user data updates on a rolling window. Here is [**why Search Console can flag LCP the same week you change something**](https://xspeedcache.com/blog/search-console-lcp-after-caching/).

### Quick WordPress Performance Audit Checklist

Use this short version once you know the process:

- Check field data in Search Console or the CrUX section of PageSpeed Insights.
- Run a baseline test three times per key URL and log the results.
- Check TTFB and confirm the page cache returns a HIT.
- Inspect the LCP element, render-blocking files, image sizes and third-party scripts.
- Review Site Health, autoloaded options, plugins and the database.
- Rank findings by impact and effort.
- Fix one thing at a time, re-test and keep a change log.

## The Most Common Causes of a Slow WordPress Site

Most answers to "why is my WordPress site slow" come from the same short list. Use this table to match what your audit found with its likely cause and fix.

| Symptom | Likely cause | Typical fix |
| :---- | :---- | :---- |
| High TTFB on every page | No page cache or slow hosting | Static page caching, object caching, better hosting |
| Poor LCP on mobile | Oversized hero image, render-blocking CSS | Preload the LCP image, Critical CSS, WebP or AVIF |
| Poor INP | Heavy JavaScript, third-party scripts | Delay JavaScript until interaction, remove unused scripts |
| High CLS | Images without dimensions, late fonts | Add dimensions, use font-display: swap |
| Slow admin and logged-in pages | Database bloat, repeated queries | Database cleanup, Redis or Memcached |
| Low cache hit ratio | Cookies or query strings bypassing the cache | Find the cookie source, review exclusions |
| Slow for distant visitors | All files served from one location | Serve static files through a CDN |
| Heavy page weight | Unoptimized images, preloading video | Modern image formats, lazy loading, click-to-play video |
| Heavy pages built with a page builder or theme | Complex layouts, too many widgets and assets loaded site-wide | Remove unused widgets, load assets only where needed, simplify layouts |
| Slow PHP execution | Outdated PHP version | Update to a PHP version your theme and plugins support, check Site Health |

## How xSpeed Cache Turns an Audit Into Fixes

Most audit tools end at the diagnosis. [**xSpeed Cache**](https://xspeedcache.com/) links each finding to the setting that addresses it, applies the change and checks whether it helped. It is a WordPress performance plugin from WPDeveloper with free and Pro features. The table shows which is which.

| Audit need | xSpeed feature | Tier |
| :---- | :---- | :---- |
| Quick external grade of any site | xSpeed Scan | Free |
| Check whether caching really works | Health and Insights | Free |
| Before and after test history | On-demand PageSpeed Insights or GTmetrix tests | Free |
| Preview database bloat before cleanup | Database scan with live counts | Free |
| Run the audit loop from an AI assistant | Built-in MCP server | Free |
| Audit many sites from one connection | xSpeed Hub | Free |
| Ranked, site-specific recommendations | AI-Powered Site Audit | Pro |
| Real visitor Core Web Vitals | Real-user monitoring | Pro |
| Fix render-blocking CSS and heavy images | Critical CSS, Remove Unused CSS, WebP and AVIF | Pro |

### xSpeed Scan: A Free Audit for Any Website

[**xSpeed Scan**](https://xspeedcache.com/scan/) is the quickest place to start. You can use it before installing anything. Paste a URL and it runs Google Lighthouse on desktop and mobile alongside its own server probes, then grades the site from 0 to 100.

![xSpeed Scan grading a site 96 out of 100 with a checklist of passed and failing checks](https://xspeedcache.com/images/blog/wp-performance-audit-scan-grade.webp)

- Checks Core Web Vitals and lab metrics, server response and caching, asset optimization and platform readiness.
- Names the exact fix for every failing check.
- Produces a shareable report link with no signup required.
- Also runs from Telegram through [**@xSpeedScanBot**](https://t.me/xSpeedScanBot).

### Health & Insights and On-Demand Speed Tests (Free)

Inside WordPress, the free **Health and Insights** module audits your caching setup itself. It shows a 24-hour hit-ratio chart, system diagnostics and a next-best-action recommendation. See the [**xSpeed Cache documentation**](https://xspeedcache.com/docs/) for setup details.

- **Cache-poisoning cookie detection** that names the plugin responsible.
- Response headers that tell a cache miss apart from a deliberate bypass.
- A dedicated check inside WordPress Site Health.
- Rule-based suggestions you can apply in one click.
- Checks that cannot complete say so, which keeps you from acting on a false alarm.

The same free plugin can run a PageSpeed Insights or GTmetrix test straight from the dashboard and keep every result. That gives you the before-and-after record that Step 7 depends on.

Results sit next to the plugin's own TTFB benchmark, so lab score and server response appear together. A failed run is reported as failed and never shows up as a score of zero.

Page weight, heavy videos and DOM size are reported too, since those need a human decision. External tests are off by default and never run on their own schedule.

### AI-Powered Site Audit & Real-User Monitoring (PRO)

The Pro audit handles the sorting work from Step 6 for you. It scans your specific site and tells you which performance features will help the most, with severity ratings and concrete reasons for each one.

- Findings ranked by severity so you know where to start.
- Recommendations built from your current settings and cache stats.
- Pairs with Pro fixes such as Critical CSS, Remove Unused CSS and WebP or AVIF conversion.

A lab test shows one simulated visit. **Real-user monitoring** shows what your actual visitors experience. xSpeed Cache Pro samples LCP, FCP, CLS, INP and TTFB from real visits and charts them per page and per device.

- Spot pages that pass in the lab but struggle for real visitors.
- Find your slowest URLs in one view.
- Watch how each change performs across days of real traffic.

### Let Your AI Assistant Run the Audit Loop (Free)

xSpeed Cache ships a built-in Model Context Protocol server, so Claude, ChatGPT or Cursor can run the audit in plain language. Ask "why is my site slow?" and your assistant can check cache status, read the health diagnostics and run a benchmark.

The `optimize_site` tool follows the same method as Step 7. It measures the site, applies recommended settings one at a time, re-checks the page after each change and reverts anything that breaks it or makes it measurably slower.

- Reports what it applied along with the latest score.
- Lists riskier next steps with their stated risk and waits for your approval before trying them.
- Flags problems no caching plugin can reach, such as hosting limits, so you know when to contact your host.
- Records every action in an activity log.

xSpeed Hub (Free) connects every site you manage to one account, so a single AI connection can reach the whole fleet, with a fleet dashboard, daily monitoring and team roles. See the [**xSpeed Hub documentation**](https://xspeedcache.com/docs/connecting-to-xspeed-hub/).

Setup takes a few minutes with the [**MCP server setup guide**](https://xspeedcache.com/docs/mcp-server-setup/).

## What a Plugin Can Fix & What It Cannot

An honest audit separates problems a performance plugin can solve from problems that need a person or a host. Knowing the difference saves hours of adjusting settings that were never going to help.

| Usually fixable with a plugin | Needs you or your host |
| :---- | :---- |
| Missing page cache | Underpowered hosting or an outdated PHP version |
| Render-blocking CSS and JavaScript | A theme that loads a heavy slider on every page |
| Missing image dimensions | Content choices such as autoplay video in the hero |
| Uncompressed text files | Third-party scripts the business depends on |
| Database bloat | Page layouts with thousands of DOM elements |
| Font loading delays | Slow external APIs called during page load |

xSpeed Cache reports page weight, DOM size and heavy videos directly, because only a person can decide what to remove. When its optimization loop finds a problem outside its reach, it says so plainly.

![Plugin fixes compared with problems that need you or your host](https://xspeedcache.com/images/blog/wp-performance-audit-plugin-vs-host.webp)

## Example Audit Scenarios

These illustrative scenarios show how the same audit plays out on three common kinds of WordPress sites. They describe typical patterns and do not represent specific customer results.

### A WooCommerce Store with a Slow Checkout

The audit shows fast cached product pages but a slow cart and checkout, which can never be page cached. The fix lives in the database layer, where a Redis or Memcached object cache cuts repeated queries and a cleanup removes expired transients.

xSpeed Cache keeps cart, checkout and account pages uncached by default. It also clears a product's cached pages when its price, sale or stock changes, so shoppers never see a stale price.

### A Content Blog Failing LCP on Mobile

Field data shows LCP failing on article templates. The lab waterfall reveals a large featured image loading late behind render-blocking CSS.

Preloading the largest image, trimming non-critical CSS and serving WebP or AVIF files usually moves LCP the most here. xSpeed Cache's LCP preload targets the largest image on the page, which matters on themes where a logo loads first.

### An Agency Auditing 20 Client Sites

Running seven manual steps on every client site takes days. Connecting the sites to [**xSpeed Hub**](https://xspeedcache.com/docs/connecting-to-xspeed-hub/), the free fleet dashboard described above, lets one AI connection check cache status, hit ratio and benchmarks across the whole fleet.

Daily monitoring then flags any site whose caching switches off or whose hit ratio drops below a floor you set. The audit becomes an ongoing routine with far less manual effort.

## Common WordPress Performance Audit Mistakes

Most audits go wrong in predictable ways. Avoid these six and your results will hold up.

**❌ Testing only the home page.** Product, category and article templates often fail for different reasons.

**❌ Testing while logged in.** Logged-in visits usually skip the page cache, so results look worse than what visitors see.

**❌ Changing five settings at once.** When the score drops, you will not know which change caused it.

**❌ Skipping the backup.** Database cleanup deletes content permanently. Back up first or use a tool that previews exactly what it will remove.

**❌ Ignoring mobile.** Mobile pass rates trail desktop, so start your testing there.

**❌ Stacking optimization plugins.** Two plugins minifying the same files is a common cause of broken layouts.

## Best Practices for Ongoing Performance Audits

A single audit fixes today's problems. A light routine keeps them from creeping back after the next plugin update or redesign.

✅ Run a quick scan every month and a full audit every quarter.

✅ Re-test after major plugin, theme or WordPress updates.

✅ Keep your change log next to your test history.

✅ Warm the cache after every purge so the first visitor still gets a fast page.

✅ Set alerts for cache failures so problems surface before visitors notice.

✅ Review Search Console field data once a month.

## Where WordPress Performance Auditing Is Heading

Performance auditing is shifting from occasional manual reviews toward continuous, automated checks. Three trends stand out.

![An AI assistant connected to a performance chart that trends upward over time](https://xspeedcache.com/images/blog/wp-performance-audit-future.webp)

**Browsers are loading pages before visitors click.** [**WordPress 6.8 turned on speculative loading in core**](https://make.wordpress.org/core/2025/03/06/speculative-loading-in-6-8/), which prefetches likely next pages for logged-out visitors so navigation can feel near instant. Audits will increasingly need to check which pages get prefetched, since every prefetch is still a request your server has to answer.

**Field data is becoming the default.** Real-user monitoring inside plugins makes it easier to act on what visitors actually experience.

**AI assistants are joining the workflow.** Through open standards like the Model Context Protocol, assistants can read audit results and apply fixes with a logged and reversible trail.

## Frequently Asked Questions

Quick answers to the questions site owners ask most about auditing WordPress speed.

### What is a WordPress performance audit?

It is a structured review of your site's speed that measures server response, caching, page weight, render-blocking files, plugins and the database. It ends with a ranked list of fixes, starting with the ones that will save visitors the most time.

### How do I check why my WordPress site is slow?

Start with field data in Search Console or the CrUX section of PageSpeed Insights to find the pages that struggle. Then run a lab test on those pages, check TTFB and look at the response headers to see whether your page cache is working. Finish with Tools > Site Health and Query Monitor to look for plugin and database problems. The seven steps above cover the full process.

### How often should I audit my WordPress site's performance?

Run a quick scan monthly and a full audit each quarter. Also re-test after major plugin, theme or WordPress updates, since those are the most common reasons a fast site slows down again.

### Why is my WordPress site slow even with a caching plugin?

The cache may not be serving pages. A cookie set on every visit, broad exclusions or testing while logged in can all bypass it. Heavy images, render-blocking scripts and slow hosting also limit what caching can do. Check your cache hit ratio first, then review your [**cache exclusions**](https://xspeedcache.com/blog/wordpress-cache-exclusions-setup/).

### What is a good PageSpeed score for WordPress?

Lighthouse treats 90 to 100 as good. Passing Core Web Vitals for real visitors matters more than the score itself. Aim for LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less.

### What is the best free WordPress speed test tool?

No single tool is best for everything, but PageSpeed Insights is the best place to start because it shows both lab results and real-user field data. GTmetrix is useful for its waterfall view. xSpeed Scan adds server probes and names a fix for each failing check. Using two of them together gives a more reliable picture than any single score.

### Can I run a WordPress performance audit for free?

Yes. Google Search Console, PageSpeed Insights, Query Monitor and [**xSpeed Scan**](https://xspeedcache.com/scan/) are all free. The free xSpeed Cache plugin adds Health and Insights, on-demand speed tests with history and a database scan.

### Does a performance audit help SEO?

It can. Google uses Core Web Vitals as part of its page experience signals, as described in its [**page experience documentation**](https://developers.google.com/search/docs/appearance/page-experience). They rarely outweigh content relevance, although they can make a difference when competing pages are similarly helpful.

### Which xSpeed Cache audit features are free?

xSpeed Scan, Health and Insights, on-demand PageSpeed Insights or GTmetrix tests, the database scan, the built-in MCP server and xSpeed Hub are free. The AI-Powered Site Audit, real-user monitoring, Critical CSS and image conversion are part of Pro. See the full [**Free vs Pro breakdown**](https://xspeedcache.com/free-vs-pro/).

## Start Your Audit Today

A slow WordPress site rarely has one big problem. It usually has three or four stacked together. An audit is how you find them in the right order.

Start with field data and a baseline test. Then work through server response, page weight, plugins and the database. Fix one thing at a time and keep the numbers.

Ready to see what is slowing your site? [**Run a free xSpeed Scan**](https://xspeedcache.com/scan/) to get your grade in under a minute. Then [**install xSpeed Cache for free from WordPress.org**](https://wordpress.org/plugins/xspeed/) and let Health and Insights guide your first fixes.