Core Web Vitals Fail on a New Website? Impr...

Direct Answer

If your new website fails Core Web Vitals before publishing, fix the loading path first: compress the hero image, reserve image and embed space, and delay non-critical JavaScript. In my experience, most new sites fail LCP because the largest image loads late, fail CLS because fonts or ads shift the page, and fail INP because a page builder, slider, or chat widget keeps the browser busy. Test the staging URL with PageSpeed Insights or Chrome Lighthouse before you publish.

Explanation

Core Web Vitals are not mystery SEO scores. They measure three parts of the real page experience: how fast the main content appears, how quickly the page responds to input, and how stable the layout feels while it loads.

LCP means Largest Contentful Paint. Google’s Core Web Vitals guide lists a good LCP score as 2.5 seconds or less. On a new website, I usually see LCP fail because the hero image is too large, the server responds slowly, or the page loads too much CSS before the main content appears.

INP means Interaction to Next Paint. A good INP score is 200 milliseconds or less. INP fails when JavaScript blocks the browser after a tap, click, or key press. This often happens with sliders, popups, form validation scripts, chat widgets, heatmaps, and heavy page builder effects.

CLS means Cumulative Layout Shift. A good CLS score is 0.1 or less. CLS fails when text, buttons, images, or forms move after the page starts to load. I have seen this happen from missing image dimensions, late-loading web fonts, ads without reserved space, and banners inserted above the content.

A new website can also look worse in lab tools than it will later in real user data. PageSpeed Insights uses lab data, while Google Search Console Core Web Vitals uses field data from real Chrome users. If your site is brand new, you may not have enough real users for field data yet.

That does not mean you should ignore the lab result. I treat PageSpeed Insights as a pre-publish diagnostic tool. It shows the same types of problems that real users will hit, especially on a mid-range Android phone and a slower mobile network.

The official thresholds come from Google’s web.dev Core Web Vitals page: LCP 2.5 seconds, INP 200 milliseconds, and CLS 0.1. You can read the source here: Core Web Vitals.

When This Fix Works

This fix works when your site is reachable by testing tools and the red Core Web Vitals result points to images, JavaScript, CSS, fonts, or layout shifts. It also works well on WordPress, Shopify, Webflow, static sites, and custom sites where you can edit templates, media files, plugins, or theme settings.

It works best before publishing because you can test each change on a staging URL. In my experience, fixing these issues before launch is easier than cleaning up a live site after analytics, tracking scripts, and customer plugins pile on.

When This Does NOT Work

This does not work if your hosting server is too slow at the source. If Time to First Byte is over 800 milliseconds, image compression alone will not fix the page. You may need better hosting, server caching, a closer CDN location, or a simpler server setup.

It also does not work if the test tool cannot reach your site. Password protection, maintenance mode, firewall blocks, staging login walls, and “noindex” testing pages can stop PageSpeed Insights from reading the page correctly.

It may not work if a third-party service is the main problem. A slow booking widget, live chat, payment embed, or external API can drag down INP or CLS no matter how clean your theme is. In that case, you need to remove, replace, or delay that service.

Step-by-Step Instructions

1. Test the exact URL you plan to publish.

Open PageSpeed Insights, paste your homepage or key landing page URL into the Enter a web page URL box, then click the blue Analyze button on the right side of the screen. Record the LCP, INP, CLS, Time to First Byte, Largest Contentful Paint element, and Total Blocking Time. I like to keep these numbers in a small spreadsheet so I can see what changed after each fix.

2. Make the staging site visible to testing tools.

If your site is still private, turn off password protection for the test session or create a temporary public staging URL. In WordPress, check the Reading settings, your caching plugin, your security plugin, and any hosting staging tool for access blocks. If you are still setting up the site, use this related guide first: .

3. Fix the LCP image first.

In PageSpeed Insights, open the Largest Contentful Paint element section and look at the image URL listed there. In my experience, a 1.8 MB hero JPEG can push LCP past 5 seconds on mobile. Resize the image to the real display width, export it as WebP or AVIF, and aim for around 120 to 220 KB for a desktop hero image and 60 to 140 KB for a mobile hero image.

If you use WordPress, go to Media, upload the optimized version, then replace the hero image in the page editor. For more detail on image sizing and formats, see .

4. Stop the hero image from loading late.

Do not lazy load the main hero image. In the page editor, select the hero image block and check that width and height are set. If your theme or performance plugin has a preload option, preload only the main above-the-fold image, not every image on the page.

For a custom site, add a preload link for the hero image near the top of the document head. Use one preload tag only. Too many preload tags can make the page slower.

5. Cut render-blocking CSS and JavaScript.

Open Chrome, press F12, click the Lighthouse tab, select Mobile, then click Analyze page load. Look for “Reduce unused JavaScript,” “Reduce unused CSS,” and “Minimize main-thread work.” These warnings usually point to scripts that should be delayed, removed, or split.

In WordPress, use a performance plugin to defer non-critical JavaScript and delay scripts that are not needed for the first view. Be careful with sliders, popups, and form scripts. Delay them until after user interaction, then retest.

6. Remove the scripts that hurt INP.

Go through your active plugins and third-party tools one at a time. In WordPress, open Plugins, deactivate one non-essential plugin, clear cache, then retest the same URL. If INP improves by a large amount, keep that plugin off the page or delay its script.

I have seen chat widgets, heatmaps, cookie banners, and animated sliders add 300 to 800 milliseconds of main-thread work. If you need a chat tool, load it after the user clicks a chat button instead of loading it with the first page view.

7. Lock the layout to reduce CLS.

Set width and height values on every image above the fold. In WordPress image blocks, open the block settings on the right side of the screen and check the dimensions. In custom HTML, add width and height attributes or CSS aspect-ratio rules.

Reserve space for ads, embeds, forms, and banners before they load. If your homepage has a newsletter box below the hero section, give that section a fixed minimum height on mobile. This stops the footer or buttons from jumping when the form appears.

8. Fix font loading.

If your site uses custom fonts, check how many font weights are loading. A page with 6 font weights can load more font files than it needs. In my experience, 2 weights are enough for most small business sites.

Use font-display: swap in your CSS so text appears quickly while the custom font loads. If you use a performance plugin, enable font optimization, but test after each change. Some font tools can fix one problem and create a new CLS problem.

9. Check the page like a real mobile user.

In Chrome DevTools, click the Device Toolbar icon on the top left of the panel. Select a mobile device such as Pixel 7, then load your page. Tap the menu, tap buttons, type in a form field, and scroll slowly while watching for layout jumps.

This step matters because a score is only part of the story. I have seen pages with a “good” CLS score still feel jumpy when a cookie banner pushes content down.

10. Retest after each change.

Return to PageSpeed Insights and test the same URL again. Change one major item at a time: image, JavaScript, CSS, font, or layout. If you change five things at once, you will not know which fix moved the score.

If your theme choice is still open, compare it with a lighter option. This related guide can help you choose before you build too much: .

Alternatives / Related Fixes

1. Move to faster hosting or add server caching.

If Time to First Byte is slow, start with the server. Server-side caching, PHP version updates, object caching, and a closer CDN location can reduce the first wait before the browser receives HTML. This is a hosting fix, not a theme fix.

2. Replace heavy page builder sections.

Page builders are not always bad, but some templates load too much code for simple sections. If your homepage uses a complex builder layout for a basic headline and button, rebuild that section with native blocks or clean HTML. I have seen this cut Total Blocking Time fast.

3. Clean up tracking and marketing scripts.

Analytics, retargeting pixels, heatmaps, A/B testing tools, and chat widgets can hurt INP. Keep the tools you need, but delay anything that is not required for the first interaction. If a script is only for marketing reports, it should not block the main content.

4. Use a CDN for static files.

A CDN can help if your visitors are far from your origin server. It works best for images, CSS, JavaScript, fonts, and other static files. It will not fix bad server code by itself.

5. Reset or reinstall the theme only as a last resort.

Do not reinstall the theme first. Try image fixes, script delays, plugin cleanup, font fixes, and caching before you reset anything. If you reset the theme, export your content first, test on staging, and check that menus, widgets, forms, and custom CSS still work.

Decision Summary

If LCP is red → fix the hero image, preload it correctly, and check server response time.

If INP is red → remove heavy JavaScript, chat widgets, sliders, popups, and unused plugins.

If CLS is red → set image dimensions, reserve ad and embed space, and fix font loading.

If PageSpeed Insights cannot access the site → make the staging URL public to testing tools before changing code.

If your site is new and

Related Guides

• — Browse all guides in this category
• — If GA4 Realtime shows users but standard reports are blank, the tag is probably firing, but GA4 has
• — If GA4 traffic looks wrong after website setup, check three things first: Consent Mode, GA4 data fil
• — A sitemap can say “submitted successfully” while Google still leaves pages undiscovered because the