How long does a WordPress performance audit take?

Ten to thirty seconds, depending on how fast the server answers. The engine requests the page, robots.txt, the sitemap, the REST API and exposed files, and calls PageSpeed Insights for the Core Web Vitals when Google has data for the URL.

Do I need to install a plugin to audit WordPress performance?

No. The engine reads the site from the outside like Googlebot and only accesses public data: no installation, no admin access. The trade-off is that it cannot see the database, so bloated wp_options tables and post revisions stay invisible to it.

Is a performance score a Google ranking factor?

No score out of 100 is a ranking factor, neither ours nor PageSpeed's. Google measures thresholds on real users (LCP under 2.5 s, CLS under 0.1, INP under 200 ms) and weighs them lightly against relevance. A score is a thermometer, not a grade from Google.

Why does my performance score change between two scans?

TTFB varies with server load at that moment, sometimes by hundreds of milliseconds. PageSpeed data may be available on one call and not the next, which adds or removes six checks. A page cache also changes the answer depending on a warm or cold entry. Rescan a few times before drawing conclusions from a five-point move.

WordPress performance audit: the 21 checks, their thresholds, and what each failure costs

Q: What is a WordPress performance audit?

A WordPress performance audit measures everything that determines how fast the site is served and rendered: server response time, transfer weight, compression, cache headers, image formats and loading strategy, render-blocking CSS and JavaScript, third-party origins, DOM size, and the Core Web Vitals. A useful audit names the failing check, gives the measured value and states the fix, instead of stopping at a score.

Q: How much does a WordPress performance audit cost?

Three scans a month are free with no account: score per dimension and the five worst issues. The full report, with all 100+ checks across six dimensions and the PDF export, costs 9.90 EUR including VAT as a one-time payment. The Pro plan at 29 EUR per month is for continuous monitoring of several sites.

Q: How is this different from PageSpeed Insights?

PageSpeed Insights measures performance with field data from real visitors when it exists, but does not look at cache header policy, indexing, the exposed WordPress version, the REST API or the count of third-party origins. This engine calls PageSpeed for the Core Web Vitals and adds the WordPress-specific causes around them.

Q: My site is not on WordPress. Does the analysis still work?

Yes. The performance dimension is CMS-agnostic: TTFB, compression, images and render-blocking resources are the same everywhere. The engine detects the absence of WordPress and skips that dimension, leaving performance, SEO, security, accessibility and best practices.

This page publishes the scoring rubric of our performance engine. Every check, its exact threshold, and the number of points a failure deducts. No competitor publishes theirs. Run the scan first, then read this as the legend to your own result.

By Yohann Kipfer, developer — I wrote the analysis engine behind WP Speed. Published July 16, 2026 · updated July 16, 2026

Scan first, read second

Paste your WordPress URL. The engine runs the checks listed below and returns a score per dimension plus your five worst issues. No signup, three free scans a month.

Nothing to install, no plugin to add. The engine reads your site from the outside, the way Googlebot does.

In short: a WordPress performance audit measures server response time (TTFB under 600 ms), transfer weight, text compression, cache headers, image formats and loading, render-blocking CSS and JavaScript, third-party origins, DOM size, and — when PageSpeed data is available — LCP, CLS and TBT. Our engine runs 21 such checks on a URL in 10 to 30 seconds and starts from 100 points, deducting a fixed amount per failure. The full deduction table is below.

Why publish the rubric

Every performance tool hands you a number out of 100 and expects you to trust it. Where did the 63 come from? Which failure cost you 14 points and which cost 4? Nobody says.

That opacity is convenient for the vendor and useless for you, because it hides the only thing that matters when you have four hours on a Saturday: what do I fix first. So here is our table. It is not a marketing claim, it is a transcription of analyzePerformance() in our engine, and you can check every line against your own scan result.

One consequence I accept: you can now game our score. Fine. Every single way to game it happens to also make your site faster.

The 21 performance checks and their deductions

The dimension starts at 100. Each check either passes (0 points lost), warns, or fails. Read the right-hand column as a priority list: a missing compression header costs you more than every resource hint on the page.

Server and transfer

Server and transfer — 4 checks
Check	Pass	Warning	Fail
`ttfb` Server Response Time	< 600 ms	600 ms – 1.2 s: −12 1.2 – 2.5 s: −20	> 2.5 s: −30
`page_size` HTML transfer size, not total page weight	< 500 KB	500 KB – 1.5 MB: −8	> 1.5 MB: −18
`compression`	Brotli or Gzip	—	None: −18
`cache` Browser cache headers	`max-age` ≥ 86400	Shorter, or ETag/Expires only: −5	No cache headers: −12

TTFB carries the heaviest single penalty in the whole dimension, 30 points, and that is deliberate. On WordPress it is also the most fixable: a page cache plugin turns a 1.4-second TTFB into a 200-millisecond one in an afternoon, because you stop rebuilding the page from the database on every visit.

Images

Images — 4 checks, skipped entirely if the page has no `<img>`
Check	Pass	Warning	Fail
`image_format` WebP / AVIF share	≥ 80 %	30 – 79 %: −8	< 30 %: −14
`lazy_loading`	≥ 60 % lazy	20 – 59 %: −6	< 20 %: −10
`img_dimensions` width + height attributes — your first CLS lever	≥ 80 %	40 – 79 %: −5	< 40 %: −10
`srcset` Responsive images	≥ 50 %	15 – 49 %: −5 < 15 %: −8	—

Images can take 37 points off a WordPress page on their own. And a caveat our competitors would leave out: a high lazy_loading score is not automatically good. Lazy-loading the hero image — the one that is your LCP — is the classic self-inflicted wound, and this check will happily give you a pass while your LCP gets worse. Read it together with the LCP line.

Render-blocking resources

CSS, JavaScript and hints — 5 checks
Check	Pass	Warning	Fail
`js_blocking` External scripts without defer/async/module	0 blocking	1 – 2: −8	3+: −15
`css_blocking`	≤ 2 stylesheets	3 – 5: −5	6+: −10
`inline_css`	< 15 KB	15 – 50 KB: −5	> 50 KB: −10
`resource_hints` preload / preconnect / dns-prefetch	≥ 3	1 – 2: −4 none: −6	—
`font_loading` Only runs if Google Fonts is detected	`display=swap`	No swap: −5	—

The css_blocking threshold is where page builders get caught. Elementor and Divi ship one stylesheet per widget family; six is a normal Tuesday for them. The threshold of 2 is not us being harsh, it is what a concatenated theme actually looks like.

Third parties and DOM

Weight you did not write — 2 checks
Check	Pass	Warning	Fail
`third_party` Counted by distinct origin, not by script	≤ 3 domains	4 – 8: −5	9+: −12
`dom_size`	< 800 elements	800 – 1 500: −4	> 1 500: −8

Full disclosure on dom_size: we approximate it by counting < characters in the served HTML rather than building a DOM tree. It is fast, it is within a few percent on real pages, and it is why the report prints a tilde in front of the number. If you need the exact figure, Lighthouse gives it.

Core Web Vitals, from Google

PageSpeed Insights — 6 checks, present only when Google returns data
Check	Pass	Warning	Fail
`lighthouse` Mobile performance score	≥ 90	50 – 89: −8 below 70	< 50: −15
`cwv_lcp`	≤ 2.5 s	2.5 – 4 s: −4	> 4 s: −8
`cwv_cls`	≤ 0.1	0.1 – 0.25: −3	> 0.25: −6
`cwv_tbt` Lab proxy for INP	≤ 200 ms	200 – 600 ms: −4	> 600 ms: −8
`cwv_fcp`	≤ 1.8 s	Reported, 0 points
`cwv_si` Speed Index	≤ 3.4 s	Reported, 0 points

FCP and Speed Index cost nothing on purpose. They are downstream of TTFB and render-blocking resources, which are already penalised above — charging for them a second time would just double-count the same problem and make the score jumpy. You still see the values, because they are useful for diagnosis. They are not evidence.

Note that INP is absent. It cannot be measured in a lab; it needs real users. TBT is the accepted stand-in, and the honest place to read your actual INP is the Core Web Vitals report in Search Console.

What this audit does not see

Worth knowing before you read your score, and none of it is in a competitor's feature grid.

Your visitors' experience. Our TTFB is measured from our server in Europe, on one request, unauthenticated. If your audience is in Sydney and ours is a warm cache hit, our number flatters you.
Total page weight, precisely. The page_size check measures the HTML document. Images and scripts are counted and analysed, but the report's byte figure is the document, not the sum of everything the browser eventually pulls.
Your database. A wp_options table bloated with 30 MB of autoloaded junk from plugins you uninstalled in 2021 is read on every PHP request. It shows up as a bad TTFB with no visible cause. No external scanner can see the reason — you need to look inside.
The rest of your site. One URL per scan. Not your archives, not your orphan pages, not your 400 attachment pages.
Whether it matters commercially. A 92 on a page nobody searches for is worth less than a 61 on the one that pays.

What we actually find: 21 WordPress sites through the scanner

Method. On July 16, 2026 I ran 21 French-speaking WordPress sites through this engine: WordPress and SEO blogs, agency sites, hosting company sites. In other words, a flattering sample — these are web professionals, not a plumber's site left untouched since 2019. Keep that in mind while reading.

15 of 21 serve no WebP or AVIF image at all. Zero. Worst of the batch: a page loading 293 images, every one of them JPEG or PNG. That is a straight −14 on the rubric above, and the easiest 14 points on this list to get back.
8 of 21 lazy-load nothing, even though WordPress has done it natively since 5.5. So the setting was actively turned off somewhere, usually by a misconfigured cache plugin.
Median TTFB: 171 ms, and only 3 of 21 exceed 600 ms. European WordPress hosting is, honestly, in decent shape. Server response is not the epidemic — images are.
Worst TTFB of the sample: 1 802 ms. It is a site we host ourselves. I am not going to pretend otherwise.
Median global score: 79/100 (min 65, max 87). Nobody hit 90, including the people who do this for a living.

These numbers describe 21 sites on one day. It is not a study; it is what the scanner sees, and you can reproduce it on your own site in 30 seconds.

A real output, with the arithmetic

Rather than a polished mockup, here is the actual result from July 16, 2026 for mythologiste.com — a WooCommerce store we host. Its flaws are ours.

mythologiste.com 32/100 performance

Extract from the performance breakdown
Check	Measured	Cost
`ttfb`	1 802 ms	−20
`image_format`	0/34 in WebP/AVIF	−14
`lazy_loading`	0/34 lazy-loaded	−10
`css_blocking`	19 blocking stylesheets	−10
`compression`	Brotli enabled	0
`cache`	WP Rocket page cache	0

Those four failures alone account for 54 of the 68 points lost; the rest is spread over srcset, image dimensions, blocking scripts and DOM size, at 4 to 8 points each.

The interesting part is the contrast with the rest of the same report: 100/100 on SEO, 32/100 on performance, same site, same second. The SEO plugin does its job perfectly — titles, meta, canonical, sitemap, schema, all clean. And it says nothing about performance, because an SEO plugin does not look at that. Green lights in Yoast are not a speed audit.

Note the TTFB line too. WP Rocket is installed and passing, and TTFB is still 1.8 seconds. Page cache was not the bottleneck there — the origin was. Which is exactly why a score without a rubric is useless: without knowing that TTFB alone cost 20 points, you would spend the afternoon reinstalling a cache plugin that was already working.

The order to fix things, for WordPress specifically

Sorted by points-per-hour, which is the only ranking that respects your Saturday.

Compression (−18 if missing), 10 minutes. One line in your host's panel, or mod_deflate / gzip on;. Eighteen points is the single best return on this list and most managed hosts do it for you — if it fails, someone turned it off.
Page cache, for TTFB (up to −30), one afternoon. WP Rocket, LiteSpeed Cache if you are on LiteSpeed, W3 Total Cache if you enjoy dials. Then rescan. If TTFB collapses, it was PHP generation. If it does not move, it is your host or the network, and no plugin will save you.
WebP conversion (−14), an evening. Imagify, ShortPixel, or your host's image service. Bulk-convert the media library, keep originals. This is where 15 of our 21 sites are leaving points on the table.
Cache headers (−12), 15 minutes. Static assets with max-age under a day is a misconfiguration, not a policy.
Blocking JS and CSS (−15 and −10), variable. Your perf plugin has checkboxes for defer and for combining CSS. Tick them one at a time and rescan between each — this is the step that breaks page builders.
Lazy loading and dimensions (−10 and −10), 30 minutes. Usually one checkbox each. Exclude the hero image from lazy loading. Always.
Everything else. Resource hints, inline CSS, DOM size: 4 to 10 points each and, on a theme you did not write, hours of work. Do them when the list above is green, or never.

My honest opinion, having watched this engine's output on other people's WordPress sites for months: steps 1 through 3 get most WordPress sites from the sixties to the eighties, and step 7 is where people waste their weekends chasing a number.

Frequently asked questions

What is a WordPress performance audit?

It is a measurement of everything that determines how fast your WordPress site is served and rendered: server response time, transfer weight, compression, cache headers, image formats and loading strategy, render-blocking CSS and JavaScript, third-party origins, DOM size, and the Core Web Vitals. A useful audit does not stop at the number — it names the failing check, gives the measured value, and tells you the fix.

How much does a WordPress performance audit cost?

Three scans a month are free here, with no account: the score per dimension and your five worst issues. The full report — all 100+ checks across six dimensions, each with its measured value and recommendation, plus the PDF export — is €9.90 including VAT, one-time. The Pro plan at €29/month only makes sense if you monitor several sites continuously.

How long does the audit take?

Ten to thirty seconds, depending on how fast your server answers. The engine makes several requests: the page itself, robots.txt, the sitemap, the REST API, exposed files, plus a PageSpeed Insights call for the Core Web Vitals when Google has data for your URL.

How is this different from PageSpeed Insights?

PageSpeed Insights measures performance very well, with field data from your real visitors when it exists. It does not look at your cache headers policy, your indexing, your exposed WordPress version, your REST API, or your third-party origins by count. We call PageSpeed for the Core Web Vitals and add the WordPress-specific causes around them. Use both: PSI for measured speed, this for the causes and the rest of the site's health.

Do I need to install a plugin to be audited?

No, and that is deliberate. The engine reads your site from the outside like Googlebot, with access only to what is public. Nothing to install, no admin access, no credentials. The trade-off is that it cannot see your database, so bloated wp_options tables and endless post revisions stay invisible to it.

Is the performance score a Google ranking factor?

No. No score out of 100 is — not ours, not PageSpeed's. Google measures thresholds (LCP under 2.5 s, CLS under 0.1, INP under 200 ms) on real users, and weighs them lightly against relevance. A score is a thermometer, not a grade from Google. Going from 82 to 87 by polishing warnings earns you nothing; fixing an 18-point compression failure makes every page genuinely faster.

My site is not on WordPress. Does the analysis still work?

Yes. The performance dimension is CMS-agnostic — TTFB, compression, images and blocking resources are the same problems everywhere. The engine detects the absence of WordPress and skips that dimension, leaving performance, SEO, security, accessibility and best practices.

Why does my score change between two scans?

Three usual reasons. TTFB varies with your server's load at that moment, sometimes by hundreds of milliseconds. Google's PageSpeed data may be available on one call and not the next, which adds or removes six checks. And a page cache changes the answer depending on whether you hit a warm or cold entry. Rescan a couple of times before concluding anything from a five-point move.

Run the rubric against your site

Twenty-one checks, 10 to 30 seconds, no signup. You will know which ones are red on your URL, and now you know what each one costs.

Run the free audit

3 free scans a month · full report €9.90 incl. VAT · Stripe payment