The key takeaway: a low PageSpeed Insights score on WordPress almost always comes from the same handful of causes — unoptimized images, render-blocking scripts, and no caching. Fix those in order, re-test after each change, and most sites move from red to green without a hosting upgrade or theme rewrite.
Why WordPress Sites Score Poorly on PageSpeed Insights
WordPress makes it easy to add plugins, page builders, and third-party scripts — and each one adds its own CSS, JavaScript, and sometimes external requests. A default install with a page builder, a few marketing plugins, and unoptimized media can easily ship 3-4MB of assets for a single page.
PageSpeed Insights runs two separate analyses on every URL you test:
- Lab data: a simulated Lighthouse audit, run instantly on Google's servers under fixed network and device conditions. Useful for catching specific issues, but it's a snapshot, not real user behavior.
- Field data: real measurements from actual Chrome users who visited your site in the last 28 days, pulled from the Chrome User Experience Report (CrUX). This only appears if your site has enough Chrome traffic to qualify.
A site can score 95 in the lab and still show a "poor" rating in the field data — usually because real users are on slower connections or older devices than the lab simulation assumes. Both numbers matter, but Search Console's Core Web Vitals report uses field data, so that's the one tied to search ranking signals.
The Order That Actually Moves the Score
Work through these in order — each one tends to have a bigger effect than the next, so fixing them out of order wastes time on smaller gains first.
1. Fix your images first
On the average WordPress page, images account for 50-80% of total page weight. This is almost always the single highest-leverage fix, and it's usually what's driving a red Largest Contentful Paint (LCP) score, since the LCP element on most pages is a hero image, featured image, or above-the-fold product photo.
Three things to check on every image above the fold:
- Format — is it still raw JPEG or PNG? WebP is roughly 25-35% smaller at equivalent quality, and AVIF often cuts size by half compared to JPEG.
- Dimensions — is a 4000px-wide photo being squeezed into an 800px container? The browser still downloads the full file before scaling it down.
- Loading priority — is the LCP image accidentally marked
loading="lazy"? That's one of the most common mistakes we see: a "speed" plugin lazy-loads every image on the page, including the one the browser needs first.
We cover this in more depth in our Core Web Vitals image checklist and WebP conversion guide. Erdo Image Optimizer handles format conversion and lazy-loading correction automatically, using your server's own GD or Imagick library — no external API or monthly quota.
2. Eliminate render-blocking CSS and JavaScript
Every <script> and <link rel="stylesheet"> in your <head> without async, defer, or a media query blocks the browser from rendering the page until it downloads and (for scripts) executes. Page builders and multi-purpose themes are frequent offenders here, often loading a full icon library or animation framework on pages that don't use them.
The fix isn't always "remove the plugin" — it's often just deferring non-critical scripts and inlining the small amount of CSS needed for the first screen. Most caching and performance plugins have a setting for this; test carefully after enabling it, since aggressive deferral can occasionally break a script that depends on load order.
3. Turn on server-side and browser caching
A page that has to be rebuilt by PHP and MySQL on every single request adds hundreds of milliseconds to Time to First Byte (TTFB), which delays everything downstream, including LCP. Page caching (serving a pre-built static HTML file to repeat visitors) and object caching (avoiding repeated database queries) are both worth having, and most caching plugins configure both with sane defaults.
This step matters, but it's rarely the biggest score driver — a well-cached page with a 2MB uncompressed hero image will still fail LCP.
4. Audit plugin count and quality
Plugin count itself isn't inherently a performance problem — a well-coded plugin that only loads its assets where needed costs very little. The real issue is plugins that load CSS/JS site-wide regardless of whether the current page uses them. Ten lightweight, well-scoped plugins are less of a problem than two poorly coded ones.
A practical audit: open Chrome DevTools → Network tab, reload a slow page, and sort by size. Anything unexpectedly large is worth investigating — trace it back to the plugin or theme component that's loading it.
Quick Reference: Core Web Vitals Thresholds
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Under 2.5s | 2.5s – 4s | Over 4s |
| INP (Interaction to Next Paint) | Under 200ms | 200ms – 500ms | Over 500ms |
| CLS (Cumulative Layout Shift) | Under 0.1 | 0.1 – 0.25 | Over 0.25 |
These are Google's published thresholds, measured at the 75th percentile of real visits — meaning three out of four of your visitors need to hit the "Good" range for the metric to pass.
A Worked Example
On a recent audit of a WooCommerce store with a fairly typical setup (page builder, 3 marketing plugins, unoptimized product photography), the breakdown looked like this before and after addressing images and render-blocking scripts:
| Change | LCP before | LCP after |
|---|---|---|
| Convert hero + product images to WebP | 4.8s | 3.6s |
| Correct oversized image dimensions | 3.6s | 2.9s |
Remove loading="lazy" from hero image |
2.9s | 2.1s |
None of these three changes touched hosting, caching configuration, or theme code — they moved LCP from "poor" to "good" through image handling alone. That's consistent with what we see across most WordPress audits: images are the first place to look, not the last.
The Mistake Worth Avoiding
A common instinct when PageSpeed Insights comes back red is to start disabling plugins one at a time, hoping to find "the" culprit. This is slow and often inconclusive, because the real bottleneck is frequently a single oversized image, not a plugin at all. Check the "Diagnostics" section of the PageSpeed Insights report first — it names the actual LCP element and lists the specific resources that are blocking render, which is a much faster starting point than trial-and-error deactivation.
Wrapping Up
A red PageSpeed Insights score on WordPress feels like it needs a hosting upgrade or a full theme rebuild, but in practice, the fix is almost always narrower: get images into a modern format at the right size, stop blocking render with unnecessary scripts, cache what can be cached, and trim plugins that load assets they don't need. Work through those four in order and re-test after each one — you'll usually know within the first step or two which fix is doing the heavy lifting.
If images turn out to be your biggest issue (they usually are), Erdo Image Optimizer automates the format conversion, dimension warnings, and lazy-loading audit covered above, so it becomes a one-time setup instead of a recurring manual check.