# WordPress Core Web Vitals: fix what actually matters > Improve LCP, INP, and CLS on WordPress and WooCommerce - field data first, real bottlenecks, and changes that do not break checkout. Source: https://larsik.com/blog/wordpress-performance-core-web-vitals/ Performance # WordPress Core Web Vitals: fix what actually matters Improve LCP, INP, and CLS on WordPress and WooCommerce - field data first, real bottlenecks, and changes that do not break checkout. July 6, 2026· Updated August 4, 2026· 4 min read·[Lars Koudal](/about/) - WordPress - Core Web Vitals - PageSpeed ![Website performance optimization project for boligsmag.dk](/images/gallery/boligsmagdk-hastighedsoptimering-og-admin-forbedringer-w400.webp) 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](/gallery/) 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](/services/pagespeed-performance/) - 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](/blog/technical-seo-what-to-fix-first/) · [Website rebuilds](/services/website-rebuilds/) when performance needs a structural fix, not another plugin. Want a performance audit on your WordPress or WooCommerce site? [Get in touch](/contact/). ## Frequently asked questions Is a 100 PageSpeed score the goal?+ No. Aim for healthy Core Web Vitals in the field, a site that feels fast, and unbroken checkout/forms. Lab scores are diagnostics, not the finish line. What usually fixes LCP on WordPress first?+ Correctly sized hero images (not lazy-loaded), fewer render-blocking scripts/fonts, and better TTFB from hosting or caching. Start there before micro-optimizations. Can caching plugins alone fix Core Web Vitals?+ They help TTFB and repeat views. They do not fix a 6MB homepage, oversized images, or heavy page-builder markup.