Honest answer: Most Core Web Vitals failures on WordPress are not mysterious. Oversized hero images kill LCP. Plugins loading JavaScript everywhere hurt INP. Images and ads without dimensions cause CLS. No caching makes all of it worse. Google wants roughly LCP under 2.5s, INP under 200ms, and CLS under 0.1—and plenty of WordPress sites can hit that without ripping the stack out.
This post is about those three metrics specifically. If you want the wider "why is my site slow" picture, read why WordPress is slow first—then come back here for the fix order.
What are Core Web Vitals?
Core Web Vitals are how Google measures real user experience on a page—how fast the main content shows up, how snappy the site feels when someone taps or clicks, and whether the layout jumps around while loading.
In Search Console and PageSpeed Insights you'll see LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift). When Google has enough field data, these feed into rankings. They're not abstract lab scores—they're tied to what visitors actually feel.
LCP — usually the hero image
LCP is "how long until the biggest thing on screen appears." On most WordPress homepages that's a hero image or banner—not your logo.
We still see 3–4MB heroes where 250–300KB would look the same on a laptop screen. The browser downloads what you uploaded. No plugin magically shrinks a file you never compressed.
Fix LCP by shrinking that image before upload, using WebP where you can, setting width and height in the markup, and turning on caching so repeat visits aren't rebuilding from scratch every time.
INP — plugins and JavaScript on every page
INP is response time—click a button, open a menu, submit a form. If the page feels laggy, INP is often why.
On WordPress this is usually theme bloat plus plugins that enqueue scripts site-wide: chat widgets, sliders, page builders, analytics, popups. Each one adds work on the main thread before the browser can respond.
We've cut INP issues by auditing which plugins load JS on pages that don't need them—not by installing another "speed" plugin on top.
CLS — layout shift when things load late
CLS is the annoying jump when you go to click something and the page moves because an image, font, or ad loaded above it.
Give images and embeds explicit dimensions. Reserve space for ad slots and banners. Don't inject banners above content after the page has already painted. Limit web fonts—four families in six weights is a common WordPress theme mistake.
Caching still matters for LCP
Without caching, WordPress runs PHP and hits the database on every visit. For a quiet brochure site you might not notice. For anything with traffic, it shows up in LCP and server response time.
Page caching is boring work and high impact. A surprising number of sites we audit simply never turned it on.
Hosting — after you've fixed the obvious stuff
Shared hosting on a heavy theme with no cache will stay slow no matter how many blog posts you read. But if images, plugins, and caching are sorted and mobile LCP is still red, hosting or a CDN for international visitors is the next question—not a Next.js migration on day one.
Page builders get blamed for everything
Elementor isn't automatically evil. A site with forty widgets per template and animation on every block will score badly—that's misuse, not the tool itself. You'll see it in both LCP and INP.
Fix order we use on WordPress audits
Don't random-fix. This sequence stops you chasing the wrong metric:
- Run PageSpeed Insights on mobile for your homepage and one money page. Write down which metric is failing—LCP, INP, or CLS.
- Fix LCP first if it's red: hero image size, format, dimensions, preload only if it truly is the LCP element.
- Turn on page caching. Confirm logged-out visitors get cached HTML.
- Tackle INP: list plugins loading JS globally, remove or limit them to the pages that need them.
- Fix CLS: dimensions on images/embeds, reserved space for ads and late content.
- Re-test. If TTFB or international LCP is still poor, look at hosting or a CDN.
- Run PageSpeed again and note what actually moved. Screenshot before/after—you'll want it if you brief a developer.
What we look at in a Core Web Vitals audit
PageSpeed Insights and Lighthouse first—the waterfall shows what loads first and what's heavy. Then the plugin list, theme assets, third-party tags. Most failures are visible in under an hour if someone actually looks.
Perfect lab 100 isn't the goal. Passing field Core Web Vitals on the URLs that bring leads is.
What passing scores look like (real projects)
Performance metrics were verified using Google PageSpeed Insights (powered by Lighthouse). Our studio site devcritters.com—desktop, May 18, 2026: Performance 99, SEO 100, LCP 0.9s, CLS 0. Screenshots on services.
Client example: Oxbridge Summer Courses (Next.js, not WordPress)—mobile Core Web Vitals passed April 2026, LCP 1.8s, INP 139ms, CLS 0.01. That's a rebuild story. Most WordPress sites don't need that if configuration is the real problem.
When fixing WordPress isn't enough
Heavy WooCommerce, complex integrations, mobile scores stuck in the 30s after a proper audit—that's when we talk headless WordPress and Next.js. Fix what you have first. Migration cost and timeline is a separate conversation.
FAQ: fixing Core Web Vitals in WordPress
What is a passing Core Web Vitals score?
Google's "good" band: LCP at or below 2.5 seconds, INP at or below 200 milliseconds, CLS at or below 0.1. PageSpeed labels each Good, Needs Improvement, or Poor. Focus on the pages that actually convert—not every archive page on the site.
Can WordPress pass Core Web Vitals?
Yes. WordPress isn't the ceiling—lazy images, no cache, and plugin sprawl are. We've seen sites pass after a focused audit without changing CMS.
What's the fastest way to improve LCP?
Shrink the largest above-the-fold image and enable caching. Those two alone beat most optimization plugins.
Do plugins hurt Core Web Vitals?
Some do, mostly INP. It's which plugins load JavaScript everywhere—not whether you have "too many" in absolute terms.
Will changing hosting improve Core Web Vitals?
Maybe—for LCP and TTFB under load. Fix images, cache, and scripts first so you're not paying for hosting when configuration was the issue.
Should I move to Next.js to improve Core Web Vitals?
Not by default. Try the fix order above. Next.js makes sense when you've hit architectural limits, not when nobody turned on caching.
Related resources
- Core Web Vitals services
- Why WordPress is slow
- WordPress to Next.js migration cost
- Headless WordPress with Next.js guide
- Oxbridge case study
- React vs WordPress comparison
Bottom line
Core Web Vitals on WordPress usually fail for boring reasons—fat heroes, script sprawl, no dimensions, no cache. Work through the list, re-test, then decide if the platform is wrong or the setup is.
We audit and fix WordPress performance for international businesses, and build headless Next.js when the situation calls for it. Services · Performance proof · Book a consultation.
