How to Improve Site Speed and Core Web Vitals

Website speed should no longer be judged only by the feeling that a page “opens quickly” or by a single PageSpeed Insights score. Google evaluates a page more broadly through Core Web Vitals — key page quality metrics that reflect real user experience. This matters for SEO, but without oversimplification: good performance and page experience can help a website, yet on their own they do not replace relevant content, structure, and actual usefulness.

That is why speed optimization should be treated as part of website SEO rather than as a standalone technical exercise done for the sake of a nice report. This is especially true for pages that already receive search traffic but underperform in behavioral metrics, conversions, or mobile user experience.

Today, it makes more sense to analyze speed through metrics rather than in general terms: what delays the appearance of the main element, what slows down the page response after a click, and what causes layout instability. That is why the focus is no longer on abstract “loading speed,” but on LCP, INP, CLS, heavy above-the-fold resources, JavaScript, fonts, third-party scripts, ad blocks, iframes, and other elements that genuinely affect user experience.

Which metrics matter now

At the time this article was updated, Google focuses on three main Core Web Vitals metrics:

• LCP — Largest Contentful Paint, meaning how long it takes for the largest visible element within the first screen to appear. A good value is up to 2.5 seconds.
• INP — Interaction to Next Paint, meaning how quickly the page responds to user interaction. A good value is up to 200 ms.
• CLS — Cumulative Layout Shift, meaning visual stability during loading. A good score is up to 0.1.

An important detail: Google evaluates these metrics not by a single visit, but by the 75th percentile of real visits on mobile and desktop devices. That is why a perfect lab test does not guarantee that a page will look good in field data. If users come from slower networks, older smartphones, or encounter a heavier page scenario, the real picture may be worse.

Where to start the analysis

The first mistake is looking only at the overall score in PageSpeed Insights . On its own, it explains very little. It is much more useful to look at two levels of data at once:

1. Field data — the real behavior of the page for actual users. When available, PageSpeed Insights shows it from the Chrome UX Report.
2. Lab data — a controlled Lighthouse test that helps identify the problem, but is not a substitute for real-world experience.

For practical diagnostics, the usual workflow is enough: first check the URL in PageSpeed Insights, then review the Core Web Vitals report in Google Search Console , and only then dig into the specific causes in DevTools, Lighthouse, or as part of a technical SEO audit .

There is another practical nuance to keep in mind: in Search Console, issues are often shown not for one specific page, but for groups of similar URLs. That is why such reports are better read as a signal for a page type rather than as an isolated failure on one address.

If a page is new and there is no field data yet, that does not mean everything is fine. It only means there is not enough representative CrUX data yet. In such cases, lab analysis is especially useful, but it should be treated as a hint rather than a final verdict.

What most often hurts LCP

LCP usually breaks not because the “site is slow in general,” but because of one specific large element above the fold. On commercial pages, this is often a hero image, a large banner, a heading with a web font, or the main content block that the browser discovers too late.

There is an important nuance here: the largest element on the page is not always what the site owner expects. Sometimes it really is the banner, but sometimes it is a large heading, a text block, or another first-screen element. That is exactly why the situation “we optimized the image, but LCP barely changed” happens much more often than it seems.

One of the most common mistakes is loading the main above-the-fold image with lazy loading. For LCP, this is a poor practice: the page delays loading the exact element that is supposed to appear first. If a large image is truly the main element on the page, it should be loaded with priority rather than deferred. This is also directly highlighted in web.dev’s LCP recommendations .

What usually helps with LCP:

• do not lazy-load the main above-the-fold image;
• serve it through a normal <img> rather than hiding it behind data-src or JavaScript;
• compress images without losing their meaning and use modern formats where appropriate;
• do not force the browser to discover the main resource too late because of heavy CSS or JS;
• when needed, use preload for a critical image or font if the browser discovers it with a delay.

If the website runs on an old theme, template, or builder, the problem is often deeper than just one image on the page. Sometimes poor LCP is the result of how the page was built in the first place during website development : a heavy first screen, unnecessary libraries, a background image instead of a proper <img> , tangled CSS, or delays caused by fonts.

How to improve INP

INP drops when the page responds slowly to user actions: a click, a tap, opening a menu, applying a filter, switching a tab, or filling out a form. In most cases, the issue is not the server, but the browser’s main thread — the primary thread occupied by long JavaScript tasks.

In practice, poor INP is most often linked to the following:

• heavy JS bundles that take too long to parse and execute;
• too many third-party scripts — chats, trackers, widgets, A/B testing tools, pop-ups;
• complex event handlers on buttons, filters, forms, and menus;
• a large DOM or frequent layout recalculations after user interaction;
• long tasks that block the page for hundreds of milliseconds.

That is why the classic advice to “use async and defer” no longer solves the problem on its own. Yes, defer and async are useful for non-blocking scripts, but if the page still carries heavy JavaScript, poor INP will not disappear. In such cases, you need to remove unnecessary scripts, split long tasks, defer non-essential modules, and check what actually happens after a click or tap.

How to reduce CLS

CLS is about layout shifts. It is the reason a button can suddenly move down just as a user is about to click it, or text shifts after a banner, iframe, or font loads. For both content and commercial websites, this is not a minor issue but a real user experience problem.

The most common reasons for poor CLS are well known:

• images without predefined dimensions;
• ad blocks, embeds, and iframes without reserved space;
• dynamically inserted content above the already visible part of the page;
• web fonts that change the size or width of text after loading.

That is why basic CLS hygiene is straightforward: define width and height for images, reserve space for banners and iframes, handle fonts carefully, and avoid pushing new blocks into the top of the page after the user has already started reading the content.

It is also worth checking whether CSS, JS, or images are blocked in robots.txt . These issues are not always the main reason metrics decline, but they can break proper rendering and search engine analysis of the page.

What else really affects performance

There are several factors that are not limited to a single metric but still have a stable impact on real website speed:

1. Critical above-the-fold resources. If the page cannot render the first screen quickly because of large CSS, heavy fonts, or a tangled resource chain, LCP almost always suffers.
2. Unused CSS and JS. Old themes, CMS plugins, and universal templates often load code that is not needed on a specific page but still blocks or complicates rendering.
3. Caching and compression. A long cache lifetime for static files, Brotli or Gzip, and proper cache headers will not fix poor architecture, but they often provide a visible improvement.
4. Server and TTFB. A slow server response also hurts performance, especially when it delays the HTML response. But in modern projects, TTFB is only part of the picture, not the only source of the problem.
5. CDN. A CDN is useful if the website has a wide traffic geography or heavy static assets. But a CDN will not eliminate long JS tasks, stabilize CLS, or make an overloaded first screen lighter.
6. Third-party services. These are often what “eat up” LCP, INP, and CLS at the same time: chats, widgets, pixels, third-party forms, video embeds, and recommendation blocks.

Meaningful performance improvements usually begin not with a “magic plugin,” but with cleaning up the unnecessary: redundant scripts, duplicated libraries, excessive styles, heavy banners, background images in the first screen, and any modules that do not contribute to conversion but slow the page down for everyone.

What people often get wrong

Articles about website speed still often repeat advice that sounds correct but does very little in real work. Here is what should be removed from the mindset right away:

• do not reduce all optimization to a single PageSpeed Insights score;
• do not claim that speed alone guarantees high Google rankings;
• do not lazy-load LCP images just because “that is recommended for all images”;
• do not try to fix INP only with async and defer if the page is overloaded with JavaScript;
• do not ignore CLS, because visual shifts often hurt UX more than a few tenths of a second in a lab test;
• do not expect CDN or caching to automatically solve problems caused by a heavy template, a poor DOM, or third-party widgets.

What a normal working plan looks like

If you ignore the nice presentations and look at the real process, it usually looks like this:

1. Check the field data and understand which metric is underperforming — LCP, INP, or CLS.
2. Find the exact element or scenario that is damaging the metric.
3. Review the mobile version separately, because this is where issues often show up more clearly.
4. Clean up the first screen, JavaScript, third-party scripts, fonts, banners, and unstable blocks.
5. Recheck the result in PageSpeed Insights, Search Console, and, if needed, your own RUM monitoring.

This approach is almost always more effective than endlessly “chasing the score” and pursuing minor audits that have no real impact on user experience. If you want to review technical ways to improve the metrics separately, it is also useful to compare them with web.dev’s practical Core Web Vitals recommendations .

Conclusion

Improving website speed today is no longer about the abstract idea of “making the page lighter.” It is about working with specific Core Web Vitals metrics and the specific technical reasons why a user sees a slow first screen, feels delay after a click, or сталкикається зі стрибками верстки.

For LCP, you need to show the main page element faster. For INP, you need to reduce JavaScript load and relieve the main thread. For CLS, you need to stabilize the layout before all blocks finish loading. Only after that do caching, CDN, compression, minor audits, and cosmetic fixes make real sense.

When a website is old, the template is overloaded, or the problem runs deeper than a few images and scripts, local fixes do not always deliver the desired result. In such cases, it is better to look at performance as part of broader technical optimization, SEO auditing, and website architecture rather than as a separate checkbox in a list.