Core Web Vitals: Why Site Speed Decides Your Conversion Rate

Site speed is often treated as a matter of technical taste: nice when it is fast, but not a priority. Its impact, though, is entirely concrete. Every extra second before a page becomes readable pushes another slice of visitors out — not because they were uninterested, but because they never got to see what you offer.

Core Web Vitals measure that experience with three numbers you can defend. This article explains all three in business language, shows how to measure them with the right kind of data, and lays out a repair order that delivers the biggest gains first.

Three metrics, three visitor questions

The easiest way to understand these metrics is to translate them into questions a visitor actually feels.

LCP — "when can I start reading?"

Largest Contentful Paint measures how long until the biggest element on screen appears: usually the main image or a large headline. Until it happens, the visitor is staring at a page that means nothing yet. A good target is under 2.5 seconds.

INP — "why did nothing happen when I tapped?"

Interaction to Next Paint measures the gap between a visitor interacting — tapping a button, opening a menu, typing — and the page showing a response. It is the most viscerally felt metric and the most damaging to trust when poor. Good target: under 200 milliseconds.

CLS — "why did the button move?"

Cumulative Layout Shift measures how much page content moves on its own while loading. Shifting causes mis-taps, and mis-taps cause people to leave. Good target: under 0.1.

Field data versus lab data

This distinction decides whether your measurement is useful or misleading. Lab data comes from a single test in a controlled environment. It is useful for comparing before and after a fix, because conditions stay consistent.

Field data comes from real visitors on their own devices and networks. This is what search engines use to assess your site, and it reflects genuine experience. Field numbers are almost always worse than lab numbers, especially in Indonesia where most visits arrive from phones on mobile networks.

Practical rule: use lab data to diagnose and prove fixes, use field data to judge whether the site is genuinely healthy. Do not celebrate a high lab score while field data is still red.

Causes of slow LCP, ordered by frequency

1. The main image is too large. A multi-megabyte photo scaled down with CSS still has to download in full. This is the number one cause on almost every business site.
2. The main image loads too late. Marking the hero image as lazy-loaded actively punishes LCP; that marker is only for images below the fold.
3. Render-blocking fonts. Text stays invisible until the font finishes downloading. Providing an immediate fallback resolves most cases.
4. Third-party scripts in the head. Every script that must download before rendering delays everything.
5. Slow server response. If the server takes a second just to start replying, that second cannot be recovered in the browser.

Image fixes that almost always work

These four steps typically cut image weight by eighty percent or more with no visible difference: convert to a modern format, supply multiple sizes for different screen widths, set explicit dimensions in the markup, and make sure no image is larger than the space it occupies.

The third step also improves CLS, because the browser can reserve space before the image arrives.

Causes of poor INP

INP is nearly always about JavaScript. While the browser's main thread is busy executing code, it cannot respond to taps. The most frequent culprits:

• Too many third-party scripts. Trackers, live chat, maps, review widgets — all stack up on the same thread.
• Frameworks re-rendering the whole page for small changes.
• Heavy work running at page load that could be deferred until genuinely needed.

The most effective fix is usually not optimising code but having less of it. Audit third-party scripts once a quarter: there is almost always one or two installed for a purpose that ended long ago.

A third-party script is debt paid by every visitor, on every visit, for as long as it stays installed.

Causes of CLS and how to stop them

CLS has a short list of causes with clear solutions.

Cause	Fix
Images without dimensions	Set width and height, or an aspect ratio
Ads or widgets injected inline	Reserve fixed space up front
Font swap changing line height	Match fallback font metrics to the main font
Banners appearing at the top	Overlay them rather than pushing content down
Content loaded later mid-page	Reserve a fixed-size container

The repair order that pays back fastest

If you have only one day, this order usually produces the largest improvement.

1. Compress and convert every image on your most-visited pages.
2. Set dimensions on all images and reserve space for widgets.
3. Move third-party scripts to load after the page is ready, and delete unused ones.
4. Fix font loading so text appears immediately with a fallback.
5. Enable browser caching and a content delivery network for static assets.

Those five rarely require architectural change, and on most sites they are enough to move scores from red to amber or green.

Servers, hosting, and time to first byte

Every browser-side optimisation has a floor set by one number: how long the server takes to start sending bytes. If that is a second and a half, LCP under two and a half seconds is close to impossible no matter how tidy your images and scripts are.

Slow response usually comes from one of four things. First, the server is geographically far from visitors — a site serving Indonesia while running in a data centre a continent away carries unavoidable latency. Second, shared hosting whose capacity is taken in turns with dozens of other sites. Third, pages rebuilt from scratch on every request, complete with dozens of database queries. Fourth, inefficient queries — typically one query inside a loop running hundreds of times.

Three of those four are solved by caching rather than by upgrading server specifications. A page whose content is identical for every visitor does not need rebuilding each time; build it once, store it, and serve from storage until the content genuinely changes.

The caching layers worth understanding

• Browser — static assets like images, fonts, and scripts stored on the visitor's device. Second visits become far faster.
• Content delivery network — copies of assets distributed to locations closer to visitors, cutting travel distance.
• Full page — finished HTML stored and served without touching the database at all.
• Database and object — expensive query results stored so they are not recomputed.

The usual trap is not installation but invalidation. A site caching pages too aggressively will serve old prices, old articles, or forms with expired tokens. Decide up front which events clear the cache — an article published, a product edited, settings saved — and test that the clearing actually happens.

Network reality in Indonesia

Most visits to Indonesian business sites come from phones, and most of those over mobile networks whose quality varies dramatically by location and time of day. Testing from an office computer on a fixed connection paints a far rosier picture than reality.

Two testing habits are therefore worth making standard. First, always test with a mid-range phone simulation, not a flagship. Second, test on a throttled network too — not to chase a score, but to see what visitors see when signal is poor. That is usually where problems invisible on fast connections surface: text blank for seconds, buttons that cannot be tapped, images shifting content after they appear.

The practical consequence: total page weight matters far more than usually assumed. A three-megabyte page may feel fine in an office, but on a congested mobile network it means a dozen seconds of waiting — and data consumed, which some visitors also notice.

When the problem is architecture, not optimisation

There is a point where optimisation stops being enough. The sign: after every image is compressed and every script tidied, LCP is still above four seconds, or INP remains poor on mid-range phones.

The cause is usually singular — the page is rendered entirely in the browser. When content only forms after JavaScript has been downloaded, parsed, and executed, every metric pays the same penalty. The fix is moving content assembly to the server so the browser receives finished HTML.

That change is significant, but its benefits compound: faster, more resilient on poor networks, more accessible, and it simultaneously resolves the crawling problem discussed in our technical SEO guide.

A checklist before declaring it done

Speed work is easy to feel finished when it is not. This list helps confirm the result is real rather than merely felt.

1. Field data measured for the three most important pages, not only the homepage.
2. Testing done with mobile and network throttling, not fast desktop.
3. Total page weight recorded, along with what share comes from images and what from scripts.
4. Every image has explicit dimensions, and no above-the-fold image is lazy-loaded.
5. The third-party script list reviewed, with each script still having a valid reason.
6. Cache invalidation tested: change one piece of content and confirm the change appears.
7. Before and after numbers recorded in one place, so the next round has a baseline.

Connecting speed to business numbers

For speed work to get priority, it has to be translated into the same language as other decisions. The method: compare conversion rates between visitors who experienced a fast page and those who experienced a slow one.

Most analytics tools can separate that. If not, a cruder approach still helps: compare conversion rates before and after the fix, over equivalent periods, from the same traffic sources.

An illustrative calculation — these numbers are examples, not results from any specific client. If a page receives four thousand visits a month converting at three percent, and a speed fix lifts that to three and a half percent, the gain is twenty leads a month. At a lead value of Rp1 million, that is Rp20 million a month from work that usually takes a few days. The framework is in our article on the business impact of digital projects.

Common mistakes when chasing scores

• Optimising only the homepage. Ad landing pages and articles usually receive more new visitors.
• Chasing a perfect hundred. The gap between eighty-five and a hundred is rarely felt; the gap between forty and eighty very much is.
• Testing only on desktop with fast internet. Test with mid-range phone and mobile network simulation.
• Installing a heavy monitoring tool to watch speed — the tool itself slows the page.
• Comparing scores across tools with different methodologies; compare the same tool over time.

Keeping it fast afterwards

Speed degrades slowly. Every new plugin, every uncompressed image upload, every added marketing script contributes a little. Without periodic checks, a site that was green can return to red in six months with no single large change to blame.

Two cheap and effective guards: automatic image compression on the upload path, so no raw image can get in; and a monthly check of the three most-visited pages, recorded in one place so the trend is visible.

Page priority: what to fix first

Not every page deserves equal attention. Rank them by multiplying two numbers: how many new visitors enter through that page, and how close that page sits to a buying decision. Ad landing pages usually win decisively on both axes, followed by articles bringing search traffic, and only then the homepage.

Homepages get fixed first largely because they are what site owners look at most — not what prospects look at most. Check the data before deciding: on many business sites, more than half of new visitors land somewhere other than the homepage and never open it at all.

In summary

Understand the three metrics as three visitor questions. Measure with field data, not only lab. Do images first, then third-party scripts, then fonts. Escalate to architectural change only when optimisation has run out of room. And translate the result into business numbers, so this work receives the priority it deserves.

Want your site measured and fixed? Talk to our team about a speed review.