WordPress Core Web Vitals: fix what actually matters

Clients often come to me with one number: a red PageSpeed score. That number is useful as a signal, not as a goal. What actually matters is Core Web Vitals in the field - LCP, INP, CLS - and whether checkout, forms, and admin still work after you “optimize.”

Here is how I approach WordPress performance without breaking the site.

Measure field data, not just lab scores

Start with Chrome UX Report / Search Console CWV and a few real URLs:

• Homepage
• Top landing page from organic search
• Product or service page
• Cart/checkout (WooCommerce) if applicable

Lab tools (PageSpeed Insights, Lighthouse) help find causes. Field data tells you if users are actually suffering. I document both before changing anything.

Also note device mix. A site that looks fine on desktop fiber can fail mobile CWV for most of your traffic.

Find the real bottleneck

On WordPress, slow sites usually fall into a few buckets:

1. Oversized images served at full resolution
2. Too many plugins loading CSS/JS on every page
3. Slow TTFB - hosting, PHP, or database queries
4. Render-blocking third-party scripts - analytics, chat, ads, fonts
5. Page builders outputting heavy markup

I trace waterfall and query load before recommending a new caching plugin. Another plugin is rarely the whole answer.

Images: the highest ROI fix on most sites

Modern formats and sane dimensions beat micro-optimizations:

• Convert hero and content images to WebP/AVIF where supported
• Serve responsive sizes - stop uploading 4000px photos for 800px slots
• Lazy-load below-the-fold media; do not lazy-load LCP images
• Set explicit width/height (or aspect-ratio) to limit CLS

On client projects like boligsmag.dk speed work this alone moved the needle before we touched caching.

Scripts and styles: load less, defer the rest

• Dequeue plugin assets on pages that do not need them
• Delay non-critical third-party scripts (chat widgets, pixels) until interaction or idle
• Avoid loading five different font families for one marketing page
• Prefer self-hosted fonts with font-display: swap over render-blocking CDN stacks when practical

Be careful with aggressive “remove all JS” approaches - WooCommerce checkout and many form plugins need their scripts. I test purchase flows after every change.

Caching and hosting - when they help

Object cache, page cache, and opcode cache help TTFB and repeat views. They do not fix a 6MB homepage.

If TTFB is consistently bad on a lightweight page, I look at:

• PHP version and worker limits
• Database bloat (post revisions, oversized autoloaded options)
• A neighbor-noisy cheap host
• Misconfigured full-page cache that bypasses on every cookie

Common cache traps in 2026:

• Two caching layers fighting each other (host + plugin + CDN)
• “Optimize JS” combining files that break cart fragments
• Serving a cached HTML shell that still waits on a huge uncached LCP image

I will say plainly if hosting is the bottleneck - I do not sell hosting, so there is no incentive to blame plugins when the server is the problem.

WooCommerce-specific notes

Shop pages add:

• Cart fragments and session calls
• Product gallery scripts
• Payment gateway JS

Optimize category and product templates first; then checkout. A fast homepage with an 8-second checkout is not a win.

Exclude cart, checkout, and account pages from aggressive full-page cache. Test add-to-cart and payment methods after every optimization pass.

A practical 2026 CWV pass (in order)

1. Fix LCP image (size, format, priority, no lazy-load)
2. Cut or delay obvious third-party scripts
3. Check TTFB on a cached and uncached URL
4. Reduce CLS from fonts, banners, and late-loading embeds
5. Profile INP on mobile (heavy main-thread JS, chat widgets)
6. Only then chase Lighthouse “opportunities” that do not risk business flows

What “done” looks like

You should expect:

• Before/after CWV and PageSpeed on agreed URLs
• A short list of what we changed and what to avoid undoing
• Notes on maintenance - image upload guidelines, plugin discipline

I am not aiming for 100 in Lighthouse. I am aiming for a site that feels fast, ranks without CWV warnings where it matters, and still lets you run the business.

Related: Technical SEO: what to fix first · Website rebuilds when performance needs a structural fix, not another plugin.

Want a performance audit on your WordPress or WooCommerce site? Get in touch.