Core Web Vitals explained for WordPress (and how to improve them)

Introduction

Usability and speed are crucial for the success of your WordPress site. Google’s Core Web Vitals (CWV) are three metrics that quantify these aspects: they measure how quickly the main content appears, how stable the layout is while loading, and how smoothly the site responds to input. Since 2021, Google has used these metrics as part of the Page Experience ranking factor, which means they not only affect user experience but can also impact your SEO performance. For freelancers and small businesses with a WordPress site, it’s important to understand what LCP, INP, and CLS mean, and how you can measure and improve them. In this article, I explain in clear language what these three Core Web Vitals mean for your WordPress site, how they influence user experience and findability, and we share practical tips (without excessive jargon) to improve them. Where useful, we’ll go a bit deeper into the technical side—but always with clear explanations.

In short, the three CWV metrics measure the following:

• Largest Contentful Paint (LCP): how fast the most important part of the page loads (usually a large image or heading).
• Interaction to Next Paint (INP): responsiveness during interaction—how quickly the page responds to user actions (the successor of First Input Delay).
• Cumulative Layout Shift (CLS): visual stability—how much elements move around while loading.

We’ll cover each metric separately, how you can test them (with tools like PageSpeed Insights, Search Console, WebPageTest, Lighthouse, etc.), and which concrete steps you can take—specifically for WordPress—to improve your scores. Finally, you’ll find a handy checklist to optimize your site across all points. Let’s get started!

Largest Contentful Paint (LCP)

What is LCP? Largest Contentful Paint measures how long it takes for the largest content element on the screen to load. In practice, this is often the hero image, a large banner, or a prominent heading at the top of the page. The moment this element becomes visible gives Google an indication of when the page is “really” usable for the visitor. A slow LCP means visitors stare at an empty or incomplete screen for too long before the main content appears—and that’s frustrating. Google uses strict thresholds: an LCP of 2.5 seconds or faster is considered good, between 2.5 and 4.0 seconds “needs improvement,” and anything above 4.0 seconds is poor. In other words: your largest content should appear within about two and a half seconds after opening the page for an optimal experience.

How does LCP affect the experience? A fast LCP makes users feel your site loads quickly. When the main image or heading is visible right away, it builds confidence that the rest will follow smoothly. If LCP is slow, users may bounce early—for example, someone who sees a blank or half-loaded page for three seconds is more likely to leave. A good LCP also supports better SEO: Google values fast load times and uses LCP as a ranking factor in search results.

What negatively affects LCP? In WordPress, there are a few common culprits behind a high (slow) LCP:

• Heavy, unoptimized images: This is often the #1 cause. A huge hero image or slider of multiple MB can severely slow down the first render. For example, a 2MB PNG used as a hero element costs a lot of load time. Images loaded at too high a resolution (e.g., a 3000px-wide image on mobile) also hurt LCP.
• Slow hosting or server response (TTFB): TTFB (Time to First Byte) is the time until the server sends the first response. If your server needs 1.5 seconds just to start responding, you’ve already burned over half your LCP budget before anything even loads. Slow hosting, no server caching, and a server location far from your users can all increase TTFB.
• Render-blocking resources (CSS/JS): Many WordPress themes and plugins load substantial CSS files and JavaScript that the browser has to process before it can show the page. For example, if your theme loads five stylesheets and a pile of scripts in the header, the browser may delay rendering until it has read them. This pushes LCP out. Page builders (like Elementor or Divi) often add extra layers of CSS/JS; that can worsen LCP unless it’s optimized. Gutenberg (the block editor) usually generates lighter code, but even then you can run into delays if your page loads lots of block-related scripts.
• No caching or CDN: Without caching, WordPress has to build the page from scratch for every visitor via database + PHP—which takes time. And without a CDN (Content Delivery Network), every visitor has to fetch assets from a single origin server, which is slower for distant users.

How to measure LCP: Luckily, you can map LCP pretty easily with free tools. The simplest is Google PageSpeed Insights (pagespeed.web.dev). Enter your URL and you’ll get an analysis with Core Web Vitals at the top. It shows LCP for mobile and desktop and whether it’s rated Good, Needs Improvement, or Poor. PageSpeed Insights also shows which element on your page is the LCP (for example the hero image or heading)—useful to focus your optimization. Beyond PageSpeed, the Core Web Vitals report in Google Search Console gives site-wide insight into LCP performance across your URLs (if you have enough traffic to collect data). For deeper analysis, you can use WebPageTest, which shows a filmstrip of how your page loads and the LCP timing, so you can visually see when the main elements appear. You can also run Lighthouse (in Chrome DevTools or via tools like GTmetrix); Lighthouse provides a simulated LCP and improvement suggestions. Note: Lighthouse results are lab data (simulated), while PageSpeed Insights can also show field data—real user data from the Chrome UX Report when available.

Tips to improve LCP: The good news: with a few targeted optimizations, you can often speed up LCP significantly. Some WordPress-specific advice:

• Optimize images: Because LCP is almost always an image or large visual element, start there. Compress photos and banners heavily without visible quality loss (use WebP or AVIF instead of JPEG/PNG for better compression). Serve the right dimensions per device (responsive images) and avoid forcing mobile users to download a giant 3000px desktop image. WordPress partly handles this via srcset; make sure your original uploads aren’t unnecessarily huge.
• Lazy-load below the fold: Defer loading images that are not immediately visible. Since WordPress 5.5, it automatically adds loading="lazy" to images, which helps load off-screen images only when the user scrolls. But important: do not lazy-load your hero image or other LCP element—it should load immediately. Make sure the main image is excluded from lazy loading (WordPress usually does this automatically for the first content image).
• Improve server response (TTFB): Choose a solid hosting provider or upgrade your plan if the server is slow. Fast hosting with a datacenter close to your target audience (or a CDN) can significantly reduce TTFB. If your TTFB is around or above 600ms, it’s hard to achieve a good LCP regardless of other optimizations. Use server-level caching or a caching plugin so WordPress can serve pre-built pages quickly without running the full PHP/WordPress stack on every request. This can take sites stuck above 4s LCP on weak hosting down below 2s LCP on a stronger setup. In other words: a caching plugin helps, but it won’t fix a slow server on its own—the foundation still matters.
• Inline and minimize critical CSS: Large CSS files can block the initial paint. Consider critical CSS: inline only the CSS needed for above-the-fold content in the head, and defer the rest until after the first render. There are plugins and tools that automate this (WP Rocket, Autoptimize, etc.). Minify your CSS/JS files and remove unused CSS where possible so the browser has less to process before showing content.
• Defer JavaScript: Set non-critical JS files to defer or async so they load after the first render. Scripts not needed for the initial view (e.g., tracking scripts or below-the-fold functionality) should be delayed. Many performance plugins offer a “defer JS” or “Delay JavaScript execution” option to do this automatically.
• Lightweight theme and page builder: Prefer a lightweight theme that prioritizes performance. A “bloated” theme packed with sliders, effects, and unnecessary scripts makes good LCP much harder. Also consider your page builder: a tool like Elementor can be fine, but disable modules you don’t need and use its performance settings (some builders now offer options like disabling emoji scripts, or loading YouTube videos via a placeholder). If you’re building a new site, consider Gutenberg (the block editor) or a lean builder, because they often have less overhead than traditional page builders. Bottom line: load only what you actually need on that page.
• Use a CDN: A Content Delivery Network caches your static content (images, CSS/JS) on servers worldwide. Visitors download assets from a location close to them, improving load times and reducing pressure on your server. For international audiences, a CDN is highly recommended to speed up LCP.
• Other tips: Preload important resources when useful (for example, a <link rel="preload"> for your hero image or critical CSS) so the browser starts fetching earlier. Watch out for webfonts (we’ll return to this under CLS)—fonts can also slow down LCP if they load late; you can preload your main heading font so it’s available immediately.

With these optimizations, you can usually bring LCP down significantly. Start with the biggest wins: images and server/caching. A fast LCP gives visitors a great first impression and lays the foundation for higher conversion and better visibility.

Interaction to Next Paint (INP)

What is INP? Interaction to Next Paint (INP) is Google’s metric for responsiveness. It looks at how quickly your page responds to user actions such as clicks, taps, or keystrokes. Unlike the older metric FID (First Input Delay), which only measured the very first interaction, INP considers all interactions during a visit and takes (roughly) the slowest as representative. It measures not only the delay before a click is processed, but also how long it takes until there is visual feedback (the next “paint” confirming the action). For example, if you click a menu button and it takes half a second before the menu opens, that 500ms delay is an INP problem and it feels like the site is lagging. Google classifies an INP under 200 milliseconds as good, between 200 and 500ms as needing improvement, and above 500ms as poor. In other words: ideally, each interaction should be processed and visible within a few tenths of a second. Since March 2024, INP has officially been the Core Web Vital for interactivity, replacing FID.

Why is INP important? A website can load quickly (LCP) and look stable (CLS), but if buttons don’t respond or forms feel sluggish, users will still get annoyed. Especially on interactive sites—think webshops (filters, add to cart), blogs with interactive widgets, or sites with dynamic content—good INP is crucial. Slow responsiveness makes your site feel slow, even when the initial load was fast. Users expect clicks to have an almost immediate effect (within ~0.1s it feels “instant”). If it takes a few hundred milliseconds, people notice the delay and the experience suffers. From an SEO standpoint, Google is also taking INP into account as part of page experience. A poor INP can indirectly hurt rankings—content still matters most—but every improvement helps. Faster sites often see better engagement and conversion, which can create positive effects elsewhere.

What negatively affects INP? On WordPress sites, these are the most common causes of a high (bad) INP—i.e., slow interactions:

• Too much or too-heavy JavaScript from plugins/themes: This is the biggest factor. Any plugin or theme feature that runs JavaScript can contribute to main thread blocks. Think sliders, pop-ups, form plugins, cookie banners—these add scripts the browser has to load and process. If you stack multiple such plugins, the browser gets “busy” and may not be able to respond immediately when a user interacts. Heavy features like large animations or complex client-side logic also slow interactivity.
• Third-party scripts: External resources like chat widgets, ad networks (e.g., Adsense), social embeds (Twitter feeds, Instagram widgets), and analytics tools often bring their own JavaScript. These scripts run alongside your site code and compete for CPU time. Some third-party scripts are poorly optimized and can wreck INP on their own—for example, a live-chat widget that constantly consumes resources can make the UI sluggish.
• Page builders and heavy themes: As mentioned earlier, page builders can load a lot of code. For INP, the amount of JavaScript is especially relevant. Some builders or themes load a big JS bundle on every page (sometimes multiple megabytes)—even on pages with very little interactivity. For example, a homepage with a parallax slider and animated counters looks nice, but the underlying scripts can keep your site busy for 1–2 seconds longer and slow down every click. A bloated theme or builder can push INP into the red because the browser must process all that script.
• Large DOM or complex layout operations: If your page has an extreme number of elements (e.g., a very long page with many sections, or an HTML structure full of nested divs), it takes the browser more time to respond during an interaction (for example, showing/hiding something). Scripts that perform lots of DOM manipulation per action can delay the next paint as well.

How to measure INP: INP is harder to measure with a simple lab test because it’s about real-user interactions. Your best friend here is Google Search Console. Since the shift from FID to INP, Search Console’s Core Web Vitals report includes separate notices for INP issues. If your site has enough traffic, you’ll see whether there are URLs with “poor” INP (above 500ms at the 75th percentile). This is valuable field data (CrUX) from real users. PageSpeed Insights can also show INP: if field data is available for your page, it will show the measured INP (next to LCP and CLS). No field data? Then PageSpeed may not report INP, but you can look at Total Blocking Time (TBT) in the lab results. Lighthouse and other lab tools don’t measure FID/INP directly, but TBT is a useful indicator: high TBT (many milliseconds of blocking script) usually means INP is likely at risk, because long blocking tasks cause input delay. For developers, there’s also the Web Vitals Chrome extension, which shows live CWV (incl. INP) while browsing, or you can record Chrome DevTools Performance and inspect interaction timings. But for most site owners, PageSpeed and Search Console are enough to know whether INP is a problem.

Tips to improve INP: Improving responsiveness is mainly about reducing heavy JavaScript and optimizing how your site handles interactions. Some concrete tips:

• Cut heavy plugins: Do a critical plugin audit. Many WordPress sites have a long list of plugins, and a few of them are the main causes of slowness. Try disabling plugins one by one and test INP (or the impact on TBT). It takes some time, but you can find surprising offenders—like that fancy social feed plugin or a page builder add-on adding 500ms of delay. For every feature, ask: is the performance hit worth it? Maybe you can consolidate functions or use a lighter alternative. Be especially careful with plugins that load lots of front-end scripts. A lean site with fewer bells and whistles often delivers a much better experience than a slow site full of extras.
• Optimize and defer JavaScript: For scripts you truly need, make sure they get out of the way. Use an optimization plugin to minify JavaScript files and bundle where possible. Set non-critical scripts to defer so they run after the initial page setup. Some plugins like Flying Scripts can delay external scripts (e.g., chat or analytics) until there’s interaction or after X seconds. This removes them from the critical path so a visitor can interact immediately without the browser still executing a pile of scripts. Important: be smart here—don’t delay essential interaction scripts (like your menu functionality) until far after load, or you’ll harm usability. Delay what isn’t needed for primary interactions (for example, a chat popup can wait 3 seconds).
• Limit third-party content: Review every external widget you load. Do you really need live chat on every page, or only on the contact page? Could you replace heavy social feeds with simple links instead of embedding a full script? Sometimes you can also lazy-load embeds—for example, only load a YouTube iframe when someone clicks on a thumbnail (there are WP plugins for this, or built-in embed optimizers). Fewer external scripts means less competition for the main thread, improving responsiveness.
• Choose performance-friendly themes/builders: If your theme or page builder adds a lot of JS to every page, see whether you can reduce it. Many modern themes are modular: disable features you don’t use. Page builders like Elementor have experimental settings to reduce unnecessary scripts (for example, not loading an icon library if you don’t use it, etc.). Over the long term, consider switching to a lighter theme or the WordPress block editor as a base, especially if your site is relatively simple. The difference in INP can be significant: a minimalist theme that loads only what’s needed often responds instantly, while a heavy theme with lots of dynamic effects can feel sluggish.
• Avoid giant “one-page” script payloads: Along the same lines, try to load features only where they’re needed. WordPress is modular—if a script isn’t needed on a particular page, you don’t have to load it there. Plugins like Asset CleanUp or Perfmatters can disable scripts per page. This is more advanced, but it can keep key pages responsive by shedding unnecessary load.
• Revisit your design if necessary: Sometimes the most honest advice is: less is more. Ask yourself whether heavy interactive elements really add value for your visitors. A clean, simple design without too many moving parts is almost always faster and more responsive. If INP remains a major problem, you may need to simplify certain buttons, effects, or sections. In the end, visitors will prefer a smooth site over a flashy one that lags.

Improving INP can require some technical work, but the core idea is clear: take pressure off the browser. Make sure the browser isn’t busy for minutes after load so that when a user clicks, your site has breathing room to respond. With selective trimming, delaying, and optimizing scripts, your WordPress site can feel wonderfully snappy.

Cumulative Layout Shift (CLS)

What is CLS? Cumulative Layout Shift measures the visual stability of your page while loading. It quantifies how much and how often the layout shifts unexpectedly. You’ve probably experienced it: you’re about to click a button, but at that exact moment something appears—an ad or an image loads late—so the content shifts and you click the wrong thing. Super annoying! Those unexpected shifts contribute to your CLS score. CLS is expressed as a number (a score) without units. Google considers a CLS score of 0.1 or lower good, between 0.1 and 0.25 as needing improvement, and above 0.25 as poor. A score of 0 means perfect stability (nothing moves), but in practice some movement can be hard to avoid. The goal is to stay under 0.1 so users don’t experience noticeable disruption.

Why is CLS important? Visual stability is often overlooked until it becomes a problem. A site that loads calmly and stays in place feels reliable and professional. If elements keep jumping around, it frustrates users: they lose their reading position or misclick because the layout shifts unexpectedly. In extreme cases it can look chaotic—text and images bouncing around. CLS directly affects how pleasant (or unpleasant) your site feels while loading. From an SEO perspective, CLS is also a ranking factor (a smaller one). Google wants to reward sites that provide a stable web experience.

What causes CLS? The typical causes of layout shifts on WordPress sites are well known:

• Images without fixed dimensions: If you insert an <img> without width and height attributes (or without CSS reserving a fixed size), the browser doesn’t know how much space the image will take. It draws the page without the image, and when the image arrives later, text or other content suddenly moves to make room. This also applies to video embeds or other media. Fortunately, WordPress automatically adds dimensions to images inserted via the editor, but there are situations (e.g., certain page builders or older content) where this still happens.
• Ads and external embeds that load late: A common CLS source is an ad block or embed (e.g., an Instagram post or Twitter feed) that loads its content later. If space isn’t reserved, the content above gets pushed down when the ad appears. Third-party scripts that inject content (ads, related-post widgets, etc.) are notorious for causing these jumps.
• Webfonts (FOIT/FOUT): External webfonts can also trigger shifts. Without a good font strategy, the browser may show a fallback font first, and only once the custom font loads, it re-renders the text—potentially with different metrics. That can shift text blocks (Flash of Unstyled Text, or Flash of Invisible Text if text is initially hidden). A large difference between fallback and webfont can cause noticeable layout shift.
• Dynamic content without a placeholder: Pop-ups, notification bars, or dynamic banners that suddenly appear can also cause shifts. For example, a cookie banner that shows at the top and pushes the page down. If this happens during page load (before the user does anything), it counts toward CLS. (Shifts that happen in response to a user action don’t count—CLS is about unexpected movement.)

How to measure CLS: CLS is easy to measure with the same tools mentioned earlier. PageSpeed Insights shows CLS per page (field data from real users when available, plus lab measurement via Lighthouse). In the diagnostics section you’ll often see items like “Avoid large layout shifts” or “DOM elements causing layout shifts”, which identify which elements moved and how much they contributed. That’s very useful: you might see a certain image or a specific div (like an ad container) as the main culprit. In Search Console, you can see on a domain level if there are groups of URLs with CLS problems—often template-based pages (e.g., all blog posts) if a specific element causes shifting site-wide. WebPageTest also reports CLS and can generate a video/filmstrip to show whether the page “jumps” while loading. For developers: in Chrome DevTools Performance you can see “Layout Shift” events and track CLS live with the Web Vitals extension or Lighthouse trace. But for most site owners, PageSpeed and Search Console are enough to find the issues.

Tips to improve CLS: The good news: CLS issues are usually solvable by applying a few best practices—and many are easy to implement in WordPress:

• Reserve space for images and embeds: Always specify height and width in the HTML, or use a container with a fixed ratio (e.g., via CSS aspect-ratio). That way the browser reserves exactly the right space before the image loads. WordPress does this automatically for images inserted via the block/classic editor (it adds width/height and CSS scales). Check whether your plugins or page builder do this too; if not, account for it manually. For videos, iframes, and other embeds: wrap them in a <div> with a fixed height or aspect ratio. Many YouTube embed plugins offer an “aspect ratio 16:9” wrapper so the player space exists before content loads. This prevents a sudden jump while loading.
• Give ads a fixed slot: If you run ads, you must prevent the layout from shifting when ads load. Give each ad block a fixed size or at least a min-height. For example: reserve 250px of height for a banner even if no ad is shown yet. This keeps surrounding content stable. Google AdSense has guidelines—use recommended sizes and slotting scripts that reserve height. The same applies to other dynamic embeds: if you embed a Twitter post, add styling so the tweet roughly has the right height upfront.
• Use font-display: swap for webfonts: This ensures text shows immediately in a fallback font and switches to the webfont once loaded without being invisible. It prevents the “no text, now text” flash (FOIT) and limits shifts. There may still be a small change if the font metrics differ, but because the text was visible, the impact is less jarring. Choose a fallback font similar in size/metrics to your webfont to minimize differences. You can also preload webfonts to fetch them sooner, or reconsider whether you really need multiple external fonts—each one adds weight and potential shifts. Often, one good font is better than three.
• Watch for late content injection: Do you have a newsletter popup that appears after 5 seconds? Or a “related posts” section that only shows after everything loads and suddenly appears above the footer? Implement these so they don’t cause jumps. For example, reserve a container in the HTML with a spinner/skeleton so space exists. Or show popups as overlays instead of pushing content (overlays don’t count toward CLS as long as they don’t reflow the underlying layout).
• Test pages step by step: Sometimes diagnosing CLS is about experimenting. Use PageSpeed’s info to find the element, then fix that issue and retest. Did you have CLS from an image without dimensions? Add them and test again. Gone? Great. Still some CLS? Look for other shifting elements.
• Theme choice and plugins: Most modern WordPress themes are aware of CLS and follow best practices (thumbnail dimensions, etc.). But if your theme falls short, you may need manual CSS fixes or consider a different theme. Some performance plugins also offer specific CLS options like “Add missing image dimensions” or “Preload fonts”. Use them.
• Visual stability above all: Rule of thumb: anything that appears on the page without user interaction should have its space reserved from the start. Then everything stays in place.

With these measures, you can often reduce CLS to nearly zero. Visitors will be happy your site doesn’t “bounce” while loading. A stable site looks professional and helps people navigate and read smoothly, improving user experience and conversion.

Closing & Checklist

Quick summary: Core Web Vitals cover the core of user experience—load speed, interaction speed, and visual stability. For your WordPress site, that means paying attention to how quickly the main content appears (LCP), how smoothly and immediately your site responds to users (INP), and whether anything shifts unexpectedly while loading (CLS). Good scores here lead to happier visitors and can give your SEO a boost because Google prefers pages with excellent CWV performance. Improving Core Web Vitals isn’t a one-time task—it’s ongoing. Every new plugin, design change, or content addition can affect performance, so keep testing and fine-tuning periodically.

Below is a handy checklist of action points to optimize your WordPress site for the three Core Web Vitals. Go through this list and see where you can gain the most:

• Hosting & server: Check the speed of your hosting. Is the time to first byte (TTFB) low? If not, consider a better host or upgrade your plan. Implement server-side caching (often via your host or a plugin) and use a CDN, especially if your audience is spread out. A fast server response is an essential foundation for good LCP.
• Caching & plugins: Install a reliable caching plugin (like WP Rocket, W3 Total Cache, or an alternative) to store pages statically and apply compression/minification. Don’t enable dozens of “speed plugins” on top of each other—that backfires. Choose one all-in-one solution or a few complementary tools and configure them well. Don’t forget object caching or database caching if your site has many dynamic queries (some hosts provide Redis/Memcached).
• Image optimization: Compress images aggressively (use tools or plugins that optimize JPEG/PNG or convert to WebP). Make sure images are never larger than needed for the device. Consider an image CDN or a plugin that does on-the-fly resizing. Lazy-load everything except above-the-fold images (the hero/LCP image must load immediately). Always add width/height to <img> tags to prevent CLS.
• Themes and page builders: Use a light, clean theme known for good performance. Too much visual fluff can be harmful for both LCP and INP. Page builders like Elementor can deliver great designs, but watch what they load under the hood. Disable unused modules and enable performance settings (many builders have experimental optimizations). Test your site with and without builder plugins if you’re unsure—sometimes a block-editor template is far lighter than a builder version. But if you need the builder, optimize where possible and use caching/optimization plugins to cover the rest.
• CSS & JavaScript: Minimize render-blocking CSS and inline critical CSS. Defer non-essential CSS until after the first render. For JavaScript: defer or async as much as possible. Remove unused JS libraries or effects. Pay attention to third-party scripts—load them late or conditionally. A smaller CSS/JS payload helps LCP, and fewer JS blocks help INP.
• Plugin audit: Review all plugins and ask if you really need them. Some duplicate functionality or are “nice to have” but cost too much performance. For example: do you have three different slider plugins active? Could you use one solid contact form plugin instead of multiple? Every extra plugin can add CSS/JS—keep it lean. Run tests to find which plugin causes noticeable delay. Don’t hesitate to replace a plugin with a faster alternative or a small code solution—especially when Core Web Vitals are affected.
• Fonts and icons: Host your fonts locally where possible and use modern formats (WOFF2). Add font-display: swap to avoid invisible text during font load. Consider system font stacks if speed is the top priority (no external fonts needed). Convert icon fonts (like FontAwesome) to inline SVGs or use a subset; icon fonts often load slowly and can cause CLS when they appear late.
• Test, measure, repeat: Make it a habit to test your site regularly. Use PageSpeed Insights for quick per-page checks and look in Search Console’s Core Web Vitals reports for the big picture. Tools like WebPageTest and Lighthouse are great for deeper debugging when something is off. Identify bottlenecks and fix them directly. Don’t forget to check both mobile and desktop—mobile is often harder due to slower devices/links, so prioritize optimization there.
• Keep the user central: In the end, these metrics are a way to improve user experience. With every change, ask: does this make the experience better? Faster load, instant interaction, and no layout shifts mean happier visitors who stay longer and are more likely to become customers. That’s valuable.

With this checklist, you’re well on your way to making your WordPress site Core Web Vitals-proof. Hopefully you now have a clear understanding of what LCP, INP, and CLS are and how to improve them without drowning in technical jargon. Good luck optimizing—your visitors (and Google) will thank you for a fast, smooth, and stable website!