Why Are Core Web Vitals Still Failing After Website Speed Optimization?

Images have been compressed and a CDN has been set up. The speed test score has gone from red to green, yet Core Web Vitals in Search Console still shows “Needs improvement.” For people managing an overseas-facing independent website, this discrepancy can easily raise doubts: did the optimization actually work?

Not necessarily. The loading speed measured by tools is not the same as what overseas customers actually experience as they browse, click, and interact with page elements. To learn how to optimize website speed and meet Core Web Vitals requirements, first distinguish between measurement methods, then identify the pages and interactions that are affecting the experience.

First, check: are you looking at a lab score or real-user data?

The Lighthouse performance score in PageSpeed Insights comes from a lab test conducted under specific simulated conditions. The real-user experience data shown at the top of the page is primarily from the Chrome User Experience Report (CrUX). These serve different purposes, and a high score does not necessarily mean that Core Web Vitals are passing.

Core Web Vitals focuses on three metrics, which are generally evaluated using the 75th percentile of real-world visit data, not the average:

All three metrics must be rated “Good” to pass the assessment. Check mobile and desktop separately. If there is insufficient data for the current URL, also check whether the tool is showing data for the entire origin so you do not mistake site-wide results for those of a single page.

CrUX also uses a rolling 28-day data window. If you deploy a fix today, older visit records will still be included in the data, so the results will not turn green immediately. Search Console updates are also delayed, so monitor trends rather than making repeated changes every few hours.

Troubleshoot by metric instead of blindly compressing more assets

Use PageSpeed Insights to confirm which metrics are failing, then record the relevant page using the Performance panel in Chrome DevTools. Do not test only the homepage: product detail pages, category pages, and ad landing pages are often the actual entry points for overseas customers.

LCP is failing: the image is smaller, but still discovered too late

A large above-the-fold image is often the LCP element, but file size is not necessarily what is slowing it down. Slow server response, too many redirects, or an image inserted only after JavaScript runs can all delay the browser from starting its download.

In the Network panel, check when the resource request starts, and use the performance recording to distinguish between waiting, downloading, and rendering time. Do not lazy-load critical above-the-fold images. Make them discoverable from the initial HTML where possible, and set a high fetch priority if needed. Consider preloading only when you have confirmed that resource discovery is delayed, to avoid unnecessarily competing for bandwidth.

Overseas websites should also be tested from their target markets. A page that loads quickly at an office in Beijing may not be just as fast for mobile users in Germany or Brazil. Check CDN cache hits, requests back to the origin server for dynamic pages, and whether redirects between language versions add to wait times.

INP is failing: the page loads, but the buttons “do nothing”

INP measures interaction responsiveness during a page visit, so a single load test is not enough to assess it. Product filters, specification selectors, inquiry pop-ups, and shopping carts are all interactions that should be tested in practice.

Record the click process and check for long tasks occupying the main thread. Common causes include rendering a large number of products at once, complex form validation, and chat plugins, ad tracking, and heatmap scripts running all at once. To address these issues, break up long tasks, reduce unnecessary JavaScript, or load non-essential features at an appropriate time.

Total Blocking Time in lab tests can help pinpoint issues, but it cannot replace real-user INP data. Deleting marketing scripts is not the only solution: first clarify each script’s purpose and trigger conditions to avoid improving performance at the cost of losing inquiry attribution.

CLS is failing: the first screen is stable, but the page starts jumping as users scroll

Focusing only on the first few seconds after a page loads can make it easy to miss layout shifts. Delayed promotional banners, recommendation modules, font swaps, and videos without reserved space can all push content around while users browse.

Set dimensions or aspect ratios for images, videos, and embedded modules, and reserve space for asynchronous content. Multilingual websites should also check long text, font loading, and button wrapping: a template that is stable in Chinese may not remain stable in German.

Why does the report still show a group of failing pages after fixing one page?

Search Console groups URLs with similar user experiences. Fixing one product page does not mean every page in the same group has improved: other pages may still use an old template, larger hero images, or additional third-party components.

Create a checklist organized by “template × language × device,” select representative pages for each category, and include high-traffic entry points and pages with more severe issues. For overseas marketing sites, also check landing pages with ad parameters separately to confirm whether the parameters affect caching and whether ad entry points trigger additional scripts.

Platforms such as EasyYingbao, which provide intelligent website building and overseas marketing services, make it possible to troubleshoot templates, scripts, and campaign entry points together, rather than having operations staff compress images one by one. When working together, clarify which issues affect the site-wide template and which occur only on specific marketing pages.

Use follow-up testing to assess results instead of just waiting for the score to “turn green”

For every change, record the deployment time, affected pages, and target metrics. After deployment, first use lab tests under the same conditions to verify whether the issue has been resolved, then use real-user monitoring to track changes across regions, devices, and page types. If traffic is low, do not draw conclusions from just a handful of visits.

After confirming that the fix covers the relevant pages, you can start validation in Search Console and continue monitoring the rolling data. Also regression-test inquiry submissions, payments, ad conversions, and consent management features to ensure that delayed scripts do not disrupt business processes.

Core Web Vitals failures are usually not caused by “one more speed optimization plugin” being missing. More often, measurement methods, page templates, and real-world usage scenarios are not aligned. Identify the failing metric first, then fix the corresponding bottleneck. That is how a speed improvement can become a smoother experience that overseas customers actually notice, rather than just a nice-looking test screenshot.