Core Web Vitals (LCP, INP, CLS): A Practical Guide to Fixing Business Website Speed

Many business owners have heard that a website must be fast, but it is hard to turn that advice into concrete work. Fast according to whom? Measured by what? On which device? Core Web Vitals is Google's answer to those questions: three metrics that measure how quickly the main content appears, how responsive the page is to taps and clicks, and how stable the layout stays while loading.

This article explains the three metrics in language that business owners and marketing teams can use, not only developers. You will see what the numbers mean, where to check your own website's scores, the most common causes of poor results, and the order of fixes that gives the biggest return. The general effect of speed on sales is covered in website speed and its impact; here the focus is the specific metrics that search engines use.

Summary

• Core Web Vitals has three metrics: LCP (main content speed), INP (responsiveness to interaction), and CLS (layout stability)
• A page is rated good if LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less, measured at the 75th percentile of real visits
• The most important data comes from real users on phones, not only lab tests on a developer laptop
• Most problems come from oversized images, heavy third-party scripts, fonts that block rendering, and elements without fixed dimensions
• The best fixes are done in order: measure, find the worst pages, fix the biggest cause, then monitor so scores do not slip again

What are Core Web Vitals and why should a business care?

Core Web Vitals are a set of user experience metrics announced by Google and used as one of the signals in page evaluation. It is worth being honest about proportions: content relevance still matters far more than speed scores. A slow page that answers a searcher's question very well can still rank high. But when two pages are equally relevant, the better experience tends to win, and more importantly, a poor experience makes visitors leave before they can become leads.

So the strongest reason to improve Core Web Vitals is not rankings alone but conversion. A visitor from an ad or a search who waits three seconds to see the page, then taps a button that does not respond, rarely comes back. Almost every improvement to these metrics is felt immediately by real visitors, so the benefit can be counted in submitted forms and incoming WhatsApp messages.

The three metrics you need to understand

LCP: how quickly the main content appears

Largest Contentful Paint measures the time until the largest element in the first screen finishes rendering, usually the main photo, a banner image, or a large heading block. A good value is 2.5 seconds or less; above 4 seconds is poor. For the visitor, this is the moment the page feels open. On business websites the LCP element is almost always the hero image, so how that image is delivered determines nearly the whole score.

INP: how quickly the page responds

Interaction to Next Paint replaced the older metric First Input Delay in March 2024. Unlike its predecessor, which only measured the first interaction, INP looks at all interactions during a visit, meaning clicks, taps, and key presses, and reports the worst or near-worst one. A good value is 200 milliseconds or less; above 500 milliseconds is poor. The problem appears when the browser is busy running JavaScript and cannot show a response to the user's tap. A menu that is slow to open or a cart button that seems dead are the classic symptoms.

CLS: how stable the layout is

Cumulative Layout Shift measures how much elements move unexpectedly while the page loads. The number has no unit, and a good value is 0.1 or less. Everyone has experienced it: you are about to tap one button, then an ad or image appears above it, pushing the button down so you tap another link instead. On product pages or forms, shifts like this immediately reduce trust and cause mis-taps.

How to check your website's scores

There are two kinds of data to tell apart. Field data comes from real users and is what is used for evaluation. Lab data comes from controlled simulation, which is useful for finding causes and testing fixes but is not the official number.

• The Core Web Vitals report in Google Search Console groups your pages into good, needs improvement, and poor based on field data, separately for mobile and desktop
• PageSpeed Insights shows field data when traffic is sufficient, plus a lab diagnosis with a list of improvement opportunities
• Lighthouse in the Chrome browser is good for testing changes before release
• Real user monitoring on your own website helps you see trends per page, per device, and per country

Start with Search Console because its report groups similar pages, for example all product pages or all blog articles. One fix to a template usually repairs hundreds of pages at once. If the website is new or has low traffic, field data may not be available yet; in that case use lab tests on a mobile profile with throttled network as an approximation.

Common causes of poor scores and how to fix them

Fixing LCP

• Compress and convert the hero image to a modern format such as WebP or AVIF, sized for the screen rather than a multi-megabyte camera photo
• Provide several image sizes so phones do not download the desktop version
• Do not lazy-load the main image; images at the top of the page should load immediately while below-the-fold images can wait
• Reduce server response time with caching, a content delivery network, and efficient database queries, as discussed in [database and business application performance](/blog/performa-database-dan-aplikasi-bisnis-yang-melambat)
• Avoid large sliders at the top that load many images at once

Fixing INP

• Audit third-party scripts such as chat widgets, ad trackers, maps, and video players; every script adds work for the browser
• Defer scripts that are not needed on the first screen until the user interacts or the page finishes loading
• Break long JavaScript tasks into small pieces so the browser can respond in between
• Limit large libraries used for small functions; often a few lines of plain code are enough
• For applications that rely heavily on JavaScript frameworks, consider server-side rendering so less code runs on the user's device

Fixing CLS

• Set width and height (or an aspect ratio) on all images and videos so the browser reserves space before the file finishes downloading
• Reserve fixed space for ads, cookie consent banners, and widgets that appear later
• Choose a font loading strategy that does not make text jump, and use a fallback font of similar size
• Do not insert new content above content that is already visible, except in response to a user action
• Animations should use transforms rather than changing the size or position of elements that affect layout

Third-party scripts: the most overlooked cause

On many business websites, the code written by your own team is actually light. What weighs the page down are the additions installed one by one by marketing and sales: ad trackers from several platforms, session recording, pop-up surveys, chat widgets, interactive maps, and A/B testing tools. Each loads its own code, often from another server, and not infrequently they overwrite one another.

Run an inventory: list all third-party scripts, their purpose, who owns them, and whether they are still used. A script for a campaign that ended two years ago is the first candidate for removal. For those that are still needed, ask whether they can load after the first interaction or be replaced with a lighter version. Tidy tag management is also good for measurement; further guidance is in the article on website and mobile app analytics.

Recommended order of work

1. 01Open the Core Web Vitals report in Search Console and note the page groups rated poor or needs improvement, starting with mobile
2. 02Pick one representative page from each group, such as the homepage, a service page, an article, and a product page
3. 03Run PageSpeed Insights on those pages and note the LCP element, the heaviest scripts, and the sources of layout shift
4. 04Fix the biggest cause first, usually the hero image and third-party scripts
5. 05Retest in the lab, release, then wait for field data to refresh, which takes about four full weeks
6. 06Set up monitoring and performance budgets so later changes do not quietly lower the score

The last step is often skipped, yet it matters most in the long run. A website that is fast at launch can become slow within a year because of new content, new plugins, and new scripts. Setting limits, such as a maximum page size or number of third-party scripts, and checking them automatically on every release is far cheaper than periodic big repair projects. This approach resembles uptime and website health monitoring.

The role of the CMS, theme, and website architecture

There is a limit to how far optimization can go if the foundation is heavy. A website built on a ready-made theme with dozens of plugins usually carries a lot of unused code on every page. In such cases small fixes help, but the best results come from simplifying the theme and plugins or, at some point, rebuilding with a leaner architecture. Platform choices are covered in CMS and website content management and headless website architecture.

If you decide to rebuild, protect existing rankings by paying attention to redirects, URL structure, and metadata, as explained in website redesign and migration without losing SEO rankings. Other complementary optimization basics are listed in basic SEO for company websites.

Common mistakes

• Chasing a lab score of 100 when field data is already good; a perfect score is unnecessary and expensive
• Testing only on desktop, when most evaluation is based on mobile
• Manually fixing one page when the problem is in a template used by hundreds of pages
• Installing optimization plugins without understanding what they change, breaking other features
• Ignoring the effect of cookie banners, chat widgets, and ads on CLS and INP
• Not monitoring after the fix, so scores fall again after a few months

Frequently asked questions

Do Core Web Vitals determine rankings? These metrics are one signal of page experience, but not a single deciding factor, and their weight is smaller than content relevance. Treat them as a requirement for good experience, not a shortcut to climb rankings.

Why do PageSpeed Insights scores differ each time I test? Lab tests are affected by network conditions and device load at that moment. Use the trend across several tests and prioritize field data, which is more stable because it is a 28-day aggregate.

How long until improvements show in Search Console? Because data is collected over a rolling 28 days, changes usually reflect fully after about one month. Real improvement for users is felt from the moment of release.

Does a small website with little traffic need to worry? It should still ensure the basic experience is good, but no big project is needed. Compressing images, reducing plugins, and removing unused scripts solves most problems.

Are these fixes also useful for international visitors? Very much. Visitors from regions with slower networks are the most affected by heavy pages. Using a content delivery network and lightweight images helps every market, including for a multilingual website.

Conclusion

Core Web Vitals is not a technical puzzle that only developers can understand. The three questions are simple: how quickly does the main content appear, how quickly does the page respond, and how stable does it look. By measuring real user data, fixing the biggest causes first, and monitoring continuously, a business website can deliver a better experience, healthier SEO prospects, and higher conversion from the same traffic.