7 Core Web Vitals WordPress Fixes That Actually Work
Core Web Vitals failures on WordPress sites almost always come down to the same handful of problems. Heavy images, missing dimensions, scripts that block rendering before anything appears on screen. The fixes are not complicated, but they do need to be done properly, in the right order. This checklist covers the six that move the needle most consistently, based on what we see when auditing sites that are failing their vitals.
On this page
1. Switch your images to WebP
JPEG and PNG are still the default on most WordPress installs, and both formats carry far more weight than necessary. WebP typically cuts file size by 25 to 35 per cent with no visible drop in quality. WordPress has supported native WebP uploads since version 5.8, so there is no technical barrier to making the switch.
If uploads are still arriving as JPEG, a plugin like Imagify or ShortPixel will convert them automatically on upload. Oversized images are one of the most consistent causes of a poor Largest Contentful Paint score, and this is almost always the right place to start.
2. Add width and height to every image
Cumulative Layout Shift happens when the browser does not know how much space to reserve for an image before it loads. Without declared dimensions, the page reflows mid-load and content jumps down the screen as images arrive. That reflow is exactly what CLS measures.
WordPress adds width and height automatically for images inserted through the media library. The problem usually comes from images added via a page builder, a custom HTML block, or hardcoded into a theme template. Check those manually. It takes around ten minutes, and the CLS improvement tends to show up immediately.
3. Defer render-blocking scripts
Every JavaScript file that loads in the <head> without a defer or async attribute stalls the browser before it can paint anything visible. On some themes, six or seven of these are queued before the first pixel appears.
Audit what is actually loading and defer anything that does not need to run before the page displays. Most contact form scripts, analytics tags, and slider libraries can be deferred safely. It is unglamorous work. It is also one of the highest-impact changes you can make for both LCP and INP scores.
One honest caveat, deferring the wrong script can break functionality. Test after every single change, not just once at the end.
4. Start with a lightweight theme
Themes carry a lot of hidden weight. A popular commercial theme can load dozens of CSS files, register several JavaScript libraries, and pull in font packages you never asked for. All of it runs whether or not you use those features.
Themes like GeneratePress or Kadence are built lean by default. Switching mid-project is not always practical, but if you are starting fresh or rebuilding, the theme is the single decision that shapes every performance choice that follows. A bloated base is genuinely hard to work around, no matter how much optimisation you layer on top.
A common issue we see is a site built on a theme that was originally layered on top of another theme, creating custom post type conflicts and styling overhead that compounds over time. Getting back to a clean foundation is often what actually returns a site to the first page of Google for competitive terms, not one small tweak in isolation.
5. Host your fonts locally
Google Fonts served from Google’s CDN add a DNS lookup, a connection, and a stylesheet request before any font file arrives. On a fast desktop connection that is barely noticeable. On a slower mobile connection, it shows up clearly in Time to First Byte and LCP.
The fix is straightforward. Download the font files, add them to your theme, and serve them from your own server. The visitor sees no difference. The performance difference is measurable. It also removes a third-party dependency that can cause GDPR complications for visitors in the UK and Europe, since the request to Google’s servers logs an IP address.
6. Set up proper caching
Without caching, WordPress builds every page from scratch on every single request. That means a database query, PHP processing, and a full HTML build each time someone visits. For a site with even modest traffic, that overhead adds up quickly.
A caching plugin like WP Rocket or W3 Total Cache stores a pre-built HTML version of each page and serves that instead. The difference in server response time is significant, and it is one of the simpler wins available. If your host offers server-level caching, use that as well. Both together outperforms either on its own.
None of this is quick to get right across an entire site. Google’s own Core Web Vitals documentation lays out what each metric measures, which helps when you are trying to understand why a fix did or did not move the score. The technical work underneath the surface takes time, but the gains are real and they hold.
Related: Image Optimisation WordPress: File Size, Format and Lazy Load
Related: Page Speed Fixes That Actually Move Core Web Vitals