Core Web Vitals checklist for Elementor V4 sites in 2026

How to use this checklist

This is a copy-pasteable checklist for passing Core Web Vitals on Elementor V4 sites. Each item includes what to check, how to check it, and what to do if it fails. Items are organized by the Core Web Vital they affect most: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift).

Run PageSpeed Insights on your most-trafficked page first. Note which metrics fail. Start with the section for your worst-performing metric. Do not try to fix everything at once. Fix the biggest problem first, re-test, then move to the next one.

LCP: Largest Contentful Paint

Target: under 2.5 seconds. Google considers 2.5s "good." Between 2.5s and 4.0s is "needs improvement." Over 4.0s is "poor."

1. Identify the LCP element

Open Chrome DevTools, go to the Performance tab, record a page load. In the results, find the LCP marker. Click it to see which element was identified as the LCP element. Usually it is a hero image, a heading, or a background image.

If the LCP element is an image, jump to items 2-4. If it is a text element, jump to items 5-6.

2. Optimize the LCP image format

If the LCP element is a JPEG or PNG, convert it to WebP. WebP is 25-35% smaller at equivalent quality. Use your image optimization plugin (ShortPixel, Imagify, or EWWW) to auto-convert uploads.

Check: right-click the hero image on your live page, click "Open image in new tab." Look at the file extension or the Content-Type header in DevTools. If it is not WebP or AVIF, your image plugin is not converting it.

3. Size the LCP image correctly

If the LCP image displays at 1200px wide but the source file is 4000px wide, the browser downloads 3x more data than needed. Set the source image to 2x the display width (for retina) and no more. A 1200px display width needs a 2400px source file maximum.

Check: in DevTools, select the LCP image, look at "Rendered size" vs "Intrinsic size" in the element info. If intrinsic is more than 2x rendered, the image is too large.

4. Do not lazy-load the LCP image

Lazy loading defers image loading until the image scrolls into view. If the LCP image is above the fold, lazy loading delays it instead of helping. WordPress adds loading="lazy" to images by default since version 5.5.

Check: inspect the LCP image element. If it has loading="lazy", remove it. You can add fetchpriority="high" instead, which tells the browser to prioritize downloading this image.

In Elementor V4, the first image widget on the page should have no lazy loading. Check the widget's settings for a lazy loading toggle. If there is none, use a plugin like Perfmatters to selectively disable lazy loading on above-the-fold images.

5. Reduce render-blocking CSS

V4 already loads per-element CSS (a major improvement over V3), but other sources of render-blocking CSS might remain: your theme's stylesheet, plugin stylesheets, Google Fonts stylesheets.

Check: in PageSpeed Insights, look for "Eliminate render-blocking resources" in the Opportunities section. It will list every CSS file blocking initial render.

Fix: WP Rocket can defer non-critical CSS. Enable "Optimize CSS delivery" in WP Rocket settings. For Google Fonts, self-host them using OMGF plugin and load them with font-display: swap.

6. Reduce render-blocking JavaScript

JavaScript files in the document head block rendering. Elementor's own JS, jQuery, and third-party scripts all contribute.

Fix: defer non-critical JS. WP Rocket's "Load JavaScript deferred" option handles most scripts. Exclude jQuery from deferral if your site has plugins that depend on it loading early (you will know because things break). For third-party scripts (analytics, pixels), move them to the footer or load them after DOMContentLoaded.

7. Check TTFB

TTFB (Time to First Byte) measures how long the server takes to start sending HTML. If TTFB exceeds 600ms, it consumes a significant portion of the LCP budget (2.5s total, minus 600ms for server response, leaves only 1.9s for everything else).

Check: in PageSpeed Insights, look for "Reduce initial server response time" or check the TTFB value in WebPageTest.

Fix: enable page caching (WP Rocket or host-level). If TTFB is still high with caching, your hosting is the bottleneck. Upgrade to managed WordPress hosting with TTFB under 400ms.

INP: Interaction to Next Paint

Target: under 200ms. Measures how fast the page responds to user interactions (clicks, taps, key presses).

8. Minimize main-thread JavaScript

INP is primarily a JavaScript problem. Every script the browser parses and executes occupies the main thread. While the main thread is busy with JavaScript, it cannot respond to user input.

Check: in PageSpeed Insights, look at "Total Blocking Time" (TBT). This correlates with INP. If TBT is over 300ms, you have too much JavaScript executing during page load.

Fix: audit your JavaScript. Use Chrome DevTools Performance tab to identify which scripts take the longest to execute. Common culprits: analytics scripts, chat widgets, carousel libraries, animation libraries. Defer or lazy-load what you can.

9. Audit third-party scripts

Each third-party script (Google Analytics, Meta Pixel, Hotjar, Intercom) adds to main-thread work. Five third-party scripts can easily add 500ms+ of blocking time.

Check: in Chrome DevTools, go to the Performance tab, look at the "Third-party" category in the Bottom-Up view. Note total time consumed by each third-party domain.

Fix: remove any tracking script you are not actively using for decisions. If nobody checks Hotjar recordings, remove Hotjar. If you run Google Analytics and Meta Pixel, consider whether you actually need both. For scripts you keep, defer them or load them after user interaction (load the chat widget when the user clicks "Chat with us," not on page load).

10. Avoid long event handlers

If clicking a button triggers a JavaScript function that takes 300ms to complete (complex DOM manipulation, heavy calculations), INP will fail for that interaction.

This is less common on standard Elementor sites, but check interactive elements: accordion opens, tab switches, filter clicks, popup triggers. If any of these feel sluggish, profile the click event in DevTools to identify the slow function.

CLS: Cumulative Layout Shift

Target: under 0.1. Measures how much visible content shifts during page load. High CLS means elements jump around as the page loads, which is jarring for users.

11. Set explicit dimensions on images

If an image element does not have width and height attributes, the browser does not know how much space to reserve until the image loads. When it arrives, the content below shifts to make room. This shift counts toward CLS.

Check: inspect your image elements. They should have width and height attributes in the HTML, or use CSS aspect-ratio to reserve space.

Fix: Elementor V4 generally includes inline dimensions on images, but verify. For images loaded through custom code or third-party plugins, ensure dimensions are specified. WordPress's native responsive image handling usually includes width and height attributes.

12. Reserve space for ads and embeds

If your site has ads (Google AdSense, Mediavine) or embeds (YouTube, Google Maps) that load after the initial page render, the space they occupy pushes content down when they appear.

Fix: wrap ads and embeds in a container with a minimum height matching the expected ad/embed size. A Google Maps embed in a container with min-height: 400px reserves that space before the map loads.

13. Avoid injecting content above the fold dynamically

Cookie consent banners, notification bars, and sticky headers that load via JavaScript and push content down after initial render cause CLS. A cookie banner that inserts itself at the top of the page shifts everything below it.

Fix: use cookie banners that overlay content (fixed position at the bottom of the screen) instead of inserting into the document flow. For top-of-page notification bars, include the HTML in the initial page render rather than injecting it via JavaScript.

14. Stabilize font loading

When a web font loads, text rendered in the fallback font reflows to match the new font's metrics. If the web font and fallback font have different widths, lines of text wrap differently, causing layout shift.

Fix: use font-display: swap combined with size-adjust on your @font-face declarations to match the fallback font's metrics to the web font. The OMGF plugin handles this automatically when self-hosting fonts. Alternatively, use font-display: optional, which prevents the fallback-to-web-font swap entirely (showing the fallback font if the web font has not loaded within 100ms).

General optimizations

15. Enable text compression

Gzip or Brotli compression reduces the transfer size of HTML, CSS, and JavaScript by 60-80%. Most hosts enable this by default, but verify.

Check: in PageSpeed Insights, look for "Enable text compression" in Opportunities. If it appears, your server is not compressing responses.

Fix: if your host does not enable compression by default, add it through .htaccess (Apache) or the server configuration (Nginx). Cloudflare enables Brotli compression automatically for all proxied traffic.

16. Use a CDN

A CDN serves static files from servers close to the visitor. Without a CDN, every asset loads from your origin server, adding latency for visitors in distant regions.

Fix: Cloudflare free plan for basic CDN. Enable "Auto Minify" for JS, CSS, and HTML. For full-page caching (the biggest performance win), add Cloudflare APO for WordPress ($5/month). APO caches the full HTML page at edge locations, reducing TTFB to under 100ms for cached pages globally.

17. Reduce DOM size

V4 already handles this on Elementor's side, but check the total DOM node count. Google flags pages over 1,500 nodes.

Check: in PageSpeed Insights or Lighthouse, look for "Avoid an excessive DOM size." Note the total element count.

Fix: if the count is over 1,500, identify where the excess nodes come from. DevTools Elements tab, sort by subtree count. Often the culprit is a mega menu, a footer with extensive link lists, or a third-party plugin injecting hidden elements. Simplify complex navigation structures. Remove hidden elements that never become visible.

18. Preload critical resources

Preloading tells the browser to start downloading a resource before it naturally discovers it in the HTML. Useful for the LCP image, primary font files, and critical CSS.

Fix: add preload links in the head section. WP Rocket's "Preload" feature handles fonts and critical CSS. For the LCP image specifically, add fetchpriority="high" to the image element. In Elementor V4, set this in the image widget's advanced settings.

The testing workflow

After implementing changes, test in this order:

1. Run PageSpeed Insights on the specific page you changed. Note the new scores.
2. Wait 28 days for Chrome UX Report data to reflect the changes in real-user metrics.
3. Check Google Search Console > Core Web Vitals report for site-wide status.
4. Re-test monthly. Performance is not a one-time fix. New content, new plugins, and server changes can degrade metrics over time.

This checklist covers the items that make the biggest difference for Elementor V4 sites specifically. A site that passes all 18 checks will pass Core Web Vitals in 2026. Most sites fail on 3-5 items. Fix those, and the green scores follow.