WordPress carries a reputation for being slow. After building and optimizing a lot of WordPress sites, I can tell you the platform is rarely the real problem. The problem is almost always the configuration on top of it: too many plugins, unoptimized images, render-blocking assets, and a page builder shipping more CSS and JavaScript than the page will ever use.
Google's Core Web Vitals put hard numbers on this. If you want a WordPress site that loads fast, ranks better, and does not annoy your visitors, these are the metrics that matter and the fixes that actually move them. This is the same checklist I run through on real client builds, so it is field-tested rather than theoretical.
The three metrics you are being graded on
Core Web Vitals are three user-experience measurements Google uses as a ranking signal:
- LCP (Largest Contentful Paint): how long the biggest visible element takes to render. Target: under 2.5 seconds.
- INP (Interaction to Next Paint): how quickly the page responds when a user taps or clicks. This replaced FID in 2024 and it is stricter. Target: under 200 milliseconds.
- CLS (Cumulative Layout Shift): how much the layout jumps around while loading. Target: under 0.1.
Everything below maps back to one or more of these three.
Fix your LCP first (biggest wins live here)
LCP is usually your hero image or hero heading, and it is where most WordPress sites lose the race in the first second.
1. Serve next-gen images and size them correctly. Convert JPEG and PNG assets to WebP. Never upload a 3000px image and let CSS scale it down to 600px. The browser still downloads the full file. Resize before upload, then let WordPress generate responsive sizes.
2. Preload the LCP image. If your hero image is the largest element, tell the browser to fetch it early:
<link rel="preload" as="image" href="/wp-content/uploads/hero.webp" fetchpriority="high">
3. Stop lazy-loading the hero. Lazy loading is great for below-the-fold images and terrible for the LCP element, because it delays the exact thing Google is timing. Exclude above-the-fold images from lazy loading.
4. Cache aggressively and put a CDN in front. A page cache turns dynamic PHP into static HTML, and a CDN serves that HTML from a location near the visitor. On my own stack I run a caching plugin paired with Cloudflare, and the LCP difference between "no cache" and "cache plus CDN" is not subtle. This is one of the highest-leverage changes you can make on a WordPress site.
Tame your INP (the metric most sites ignore)
INP punishes heavy JavaScript. WordPress sites accumulate scripts fast: analytics, chat widgets, sliders, form libraries, and whatever three plugins each decided to enqueue.
1. Audit what is actually loading. Open your browser DevTools, go to the Coverage tab, and record a page load. You will usually find large percentages of CSS and JavaScript that never execute on that page.
2. Delay non-critical JavaScript until interaction. Chat widgets, tracking pixels, and video embeds do not need to run before the user does anything. Most performance plugins can defer or delay these until the first scroll or tap, which frees up the main thread when it matters most.
3. Dequeue what you do not use. If a plugin loads a script or stylesheet site-wide but you only use it on one page, unload it everywhere else:
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_page( 'contact' ) ) {
wp_dequeue_style( 'contact-form-styles' );
wp_dequeue_script( 'contact-form-script' );
}
}, 100 );
4. Be honest about your page builder. Builders are productive, but they can be heavy. Turn off features you are not using, and prefer the lighter core widgets over add-on packs that inject extra libraries.
Kill layout shift (CLS)
CLS is the cheapest metric to fix and the most annoying to leave broken.
1. Set explicit width and height on images and iframes. This reserves the space before the asset loads, so nothing jumps.
2. Reserve space for ads and embeds. Any element that loads late should have a defined container height.
3. Fix your fonts. Web fonts cause a flash and a shift when they swap in. Self-host your fonts instead of pulling them from a third-party origin, preload the key weight, and use font-display: swap with a sensible fallback so text stays put:
@font-face {
font-family: 'Inter';
src: url('/fonts/inter.woff2') format('woff2');
font-display: swap;
}
Database and plugin hygiene
Speed is not only front-end. A bloated database slows every request.
- Delete plugins you deactivated but never removed. Deactivated is not gone.
- Clean out post revisions, spam comments, and expired transients on a schedule.
- Be ruthless about plugin count. Every plugin is code you did not write running on every request. Ten well-chosen plugins beat forty convenient ones.
Measure the right way
Two tools, two different jobs:
- PageSpeed Insights and Lighthouse give you lab data: a controlled test that tells you what to fix.
- The Core Web Vitals report in Search Console gives you field data: what real visitors actually experienced. This is the one Google ranks on.
Chase the field data. A perfect Lighthouse score means little if real users on mid-range phones are still waiting three seconds for your hero image.
The order that works
If you only have an afternoon, do this in sequence:
- Optimize and convert images, exclude the hero from lazy loading.
- Install a caching plugin and connect a CDN.
- Delay non-critical JavaScript.
- Self-host and preload fonts.
- Add explicit dimensions to media.
- Clean the database and cut dead plugins.
That order front-loads the biggest gains, so you see the LCP and INP numbers drop before you have finished the small stuff.
I build custom WordPress websites for a living, and this checklist is roughly the speed optimization pass I run before any site goes live. WordPress can absolutely hit strong Core Web Vitals scores. It just will not do it by accident.
If you have a WordPress performance trick that consistently works for you, drop it in the comments. I am always collecting new ones.
Top comments (0)