WordPress performance statistics: we scanned 793 real homepages
We ran 793 real WordPress homepages through Google PageSpeed Insights — the same engine behind PageWeight's own scanner — to see what's slowing them down. The average score was 56 out of 100. Only 6.1% of sites had a slow server. The rest is images, render-blocking code, and unused JavaScript — fixable without touching hosting.
How slow are WordPress sites, really?
The average PageSpeed performance score across 793 real WordPress homepages was 55.9, and the median was 56.0 — close enough that the score distribution isn't meaningfully skewed by outliers. Only 6.8% scored "good" (90+). 38.7% scored "poor" (below 50). The remaining 54.5% landed in the "needs improvement" middle band.
| Score band | % of sites |
|---|---|
| Good (90–100) | 6.8% |
| Needs improvement (50–89) | 54.5% |
| Poor (below 50) | 38.7% |
Which Core Web Vitals do WordPress sites fail most?
Largest Contentful Paint (LCP) is the clearest failure point: 76.5% of sites scored poorly on it, closely followed by Speed Index at 75.0%. Layout stability is the one metric most WordPress sites already get right — only 11.6% scored poorly on Cumulative Layout Shift.
| Metric | % scoring poorly |
|---|---|
| Largest Contentful Paint (LCP) | 76.5% |
| Speed Index | 75.0% |
| First Contentful Paint (FCP) | 57.1% |
| Total Blocking Time (TBT) | 30.3% |
| Cumulative Layout Shift (CLS) | 11.6% |
Real-user data (Google's Chrome UX Report) was available for 569 of the 793 sites. Average Interaction to Next Paint (INP) was 155.8ms — but the median was only 128ms, comfortably inside Google's "good" threshold of 200ms. 16.5% of sites exceeded that threshold.
Is slow hosting to blame?
No. Only 6.1% of sites showed a slow server-response-time audit failure. Whatever is dragging down the average WordPress site's score, it almost never starts at the server — it's what the page asks the browser to download and render.
Are unoptimized images really the problem?
90% of the 793 sites had measurable wasted image bytes — oversized or non-next-gen-format images that could be served smaller with no visible quality loss. The average waste among those sites was 1,232 KB per homepage — but the median was only 378 KB. That gap matters: a smaller set of sites carrying extreme image bloat is pulling the average up, while the typical site with the problem is looking at a few hundred kilobytes of fixable waste, not over a megabyte.
What else is slowing WordPress sites down?
Beyond images, the next most common issues are render-blocking JavaScript or CSS and short cache lifetimes — both affecting 94.3% of the sites scanned. Unused JavaScript (88.7%) and unused CSS (87.3%) are close behind.
| Issue | % of sites affected |
|---|---|
| Render-blocking JavaScript or CSS | 94.3% |
| Short cache lifetimes on static files | 94.3% |
| Unused JavaScript | 88.7% |
| Unused CSS | 87.3% |
| Unnecessary redirects | 50.8% |
| JavaScript execution time too long | 44.5% |
| Unminified JavaScript | 40.5% |
| Unminified CSS | 37.6% |
What third-party scripts are WordPress sites actually running?
Google's own tooling dominates: Google Tag Manager appeared on 537 of 793 sites, followed by Google Analytics (474), Google Fonts (472), and Google/Doubleclick Ads (346). Third-party scripts like these run on the main thread and block rendering — they don't show up in an images audit, but they're part of the same front-end-weight problem.
| Third-party script | Sites (of 793) |
|---|---|
| Google Tag Manager | 537 |
| Google Analytics | 474 |
| Google Fonts | 472 |
| Other Google APIs/SDKs | 365 |
| Google/Doubleclick Ads | 346 |
| Cloudflare | 206 |
| Google CDN | 190 |
| 174 |
How was this data collected?
We sampled candidate domains from the Tranco top-1M list (a research-grade domain ranking), deliberately avoiding the very top ranks, which skew toward large non-WordPress tech companies. Each candidate was checked for WordPress signatures (wp-content, wp-json, the generator meta tag) before being scanned. Confirmed WordPress homepages were then run through Google's PageSpeed Insights API directly — mobile strategy, performance category — the same call PageWeight's own scanner makes. The target sample was 1,000 sites; the candidate pool was exhausted at 806 confirmed WordPress sites, of which 793 returned a usable result. We're reporting the real number rather than rounding up.
What should you fix first?
Based on this data, the highest-frequency, highest-impact fix for most WordPress sites is images — 90% of sites have the problem, and it doesn't require touching code or hosting.
If your site runs on WordPress
Picqlo converts JPEG and PNG images to AVIF and WebP automatically, in the background, with originals kept intact.
On any other platform
picqlo.com/convert converts JPEG and PNG files to AVIF, WebP, or JPEG XL directly in your browser — no upload, no account.
For the render-blocking and unused-code issues, see our guides on render-blocking resources and why WordPress sites fail Core Web Vitals.