Why WordPress sites fail Core Web Vitals (and how to fix them)
WordPress powers over 40% of the web, but a lot of those sites score poorly on Google’s Core Web Vitals. The good news: the problems are nearly always the same, and every one of them can be fixed without a developer.
What are Core Web Vitals?
Core Web Vitals are three measurements Google uses to assess the real-world experience of visiting a page: how fast the main content appears (LCP), how stable the layout is as the page loads (CLS), and how quickly the page responds to interaction (INP). Google uses these as a ranking factor — a site that performs well on all three will rank higher than a slower competing page, all else being equal.
You can check your current scores using PageWeight, Google Search Console, or Google PageSpeed Insights.
Why do WordPress sites fail Core Web Vitals?
We scanned 793 real WordPress homepages to find out which problems actually show up most, rather than guessing. Two issues dominate — render-blocking code and unoptimized images, each affecting the large majority of sites. A few other issues matter when they occur but turned out to be far less common than you might expect. Here’s what the data actually shows, ranked by how often each issue appeared.
1. Render-blocking JavaScript and CSS
This was the single most common issue in our scan: 94.3% of the 793 sites had a render-blocking problem. Every plugin you install can add JavaScript and CSS to your pages — contact form plugins, chat widgets, slider plugins, cookie notice tools — and each one loads code that the browser may have to process before the page can display or become interactive.
This mainly hurts First Contentful Paint (how quickly anything appears on screen). Interaction responsiveness specifically — INP and TBT — turned out to be a smaller share of the problem: only 30.3% of sites scored poorly on TBT, and only 16.5% of sites with real-user data exceeded the "good" INP threshold. So render-blocking mostly slows down how fast the page first appears, not how quickly it responds once loaded.
2. Unoptimized images
Close behind at 90% of sites. Most WordPress sites accumulate hundreds or thousands of images that were uploaded at full camera resolution and never compressed. A single high-resolution photo can be 4–6 MB when it only needs to be 80–200 KB. Multiply that across a page and you’ve explained the slow load time.
Large images directly hurt LCP (the time until the main content is visible) — and in our scan, LCP was the worst-performing Core Web Vital by far, with 76.5% of sites scoring poorly on it.
3. No caching
WordPress generates pages dynamically by running PHP code and database queries on every visit. Without caching, every visitor forces this work to happen from scratch. A caching plugin stores a pre-built copy of each page so it can be served instantly, bypassing the database entirely. Without one, your TTFB (time to first byte) will be slow even on decent hosting. Note: our 793-site scan didn't specifically measure page-caching-plugin adoption — it measured a related but different thing, static-asset cache headers on images/JS/CSS files, which affected 94.3% of sites. That's still a real and extremely common issue, just not the same one page-caching plugins solve.
4. Slow server response time
This turned out to be far less common than its reputation suggests: only 6.1% of the 793 sites we scanned had a slow server-response-time flag — by far the rarest issue we measured. It still matters when it happens — your server's response time (TTFB) sets a floor on everything else, and if your server takes 1.5 seconds to start sending the page, no amount of image optimization will make LCP fast — but for most WordPress sites, the server isn't where the problem is. PageSpeed Insights flags this as “Reduce initial server response time.” If your TTFB is over 600ms, hosting is likely a genuine bottleneck; for the other 94% of sites, look at images and render-blocking code first.
5. Layout shift from images without dimensions
Also rare: only 11.6% of sites scored poorly on CLS in our scan — the least common Core Web Vitals failure we found. CLS measures how much the page layout shifts as content loads in. The most common cause on WordPress is images that don’t have width and height attributes specified in their HTML — the browser doesn’t know how much space to reserve, so it allocates nothing, then shoves everything else aside when the image finally arrives. WordPress has set width and height attributes on media library images automatically since version 5.5, which likely explains why this issue is now uncommon.
How do you fix these issues?
Fix 1: Audit your plugins and manage render-blocking scripts
Since render-blocking code was the most common issue in our scan, start here. Go through your installed plugins and deactivate any you aren’t actively using. For the ones you keep, a performance plugin like WP Rocket or Perfmatters can disable scripts on pages where they aren’t needed, and delay non-essential JavaScript so it loads after the page is already visible.
Fix 2: Convert your images to a modern format
Picqlo converts all your existing images to AVIF and WebP automatically — the two modern formats that typically cut JPEG photo sizes by 20–50% and PNG graphics by 70–95%+, with no visible quality difference. New uploads are converted as you add them. Your originals are never deleted. Installation takes two minutes and no technical knowledge is needed.
Fix 3: Enable a caching plugin
If you’re not already using one, install a caching plugin. WP Rocket is the most popular paid option and handles most of the setup automatically. LiteSpeed Cache is free and excellent if your host uses LiteSpeed servers. W3 Total Cache and WP Super Cache are free options that work on any hosting.
Fix 4: Switch to faster hosting
Only worth prioritizing if your TTFB is consistently over 600ms — per our scan, that's true for a small minority of sites. If it applies to you, no plugin will fully solve it. Managed WordPress hosting providers like Kinsta or WP Engine use server infrastructure specifically optimized for WordPress, with built-in caching and server-level performance tuning. They cost more than shared hosting, but the performance difference is significant.
Where should you start?
Run a free scan with PageWeight. The results will show you your current performance score, whether your LCP or INP is the problem, and — most usefully — which specific images are oversized and which scripts are render-blocking. That tells you which of the two most common issues is your biggest lever.
For most WordPress sites, fixing render-blocking scripts and unoptimized images together covers the large majority of what's dragging the score down.