Why Your Business Website Is Slow and How to Fix It with Core Web Vitals

Open your company website on a two million rupiah Android phone, on mobile data, in a busy food court at lunchtime. That is how a large share of your visitors see it. On office fibre and a MacBook the homepage feels instant. On that phone the headline often takes six or seven seconds to appear, and the contact button jumps down just as someone tries to tap it. Most of the slow sites we audit share the same handful of problems, and most of them can be fixed in a few weeks without a redesign.

Why Speed Costs You Money

A 2020 Deloitte study commissioned by Google found that cutting mobile load time by a tenth of a second raised retail conversions by around 8 percent. Your numbers will differ, but the direction holds. People leave slow pages before they read your offer. Speed also feeds into Google rankings through the page experience signals. Our honest view is that the ranking effect is modest. Relevant content wins first, and speed decides between pages that are otherwise close. The bigger cost is the visitor who gave up.

Indonesian traffic makes this harder. Most visits come from phones, and many of those phones run a mid-range chip that executes JavaScript three to five times slower than a laptop. 4G coverage is wide, but speed drops sharply in crowded places and outside big cities. If the server sits in the United States or Europe, every round trip adds latency on top of that.

The Three Core Web Vitals

Google judges a page on real visits over the past 28 days, at the 75th percentile. In other words, at least three out of four visits must meet the threshold for the page to pass. Largest Contentful Paint (LCP) measures when the biggest element above the fold, usually the hero image or headline, appears. Interaction to Next Paint (INP), which replaced First Input Delay in March 2024, measures how quickly the page responds to taps and clicks. Cumulative Layout Shift (CLS) measures how much the layout jumps while loading. Time to First Byte (TTFB) is not a Core Web Vital, but a slow server drags LCP down with it.

Lab Data and Field Data Are Different Things

Lighthouse, in Chrome DevTools or in PageSpeed Insights, loads the page once on an emulated mid-range phone with a throttled 4G connection. That is lab data. It is useful for debugging because you can repeat it and see exactly which file is slow. Field data comes from the Chrome User Experience Report (CrUX), which collects timings from real Chrome users. PageSpeed Insights shows it at the top of the page when your site has enough traffic, and the Core Web Vitals report in Search Console groups your URLs into good, needs improvement, and poor.

Rankings use field data. A site can score 60 in Lighthouse and pass in the field, or score 95 and fail because real visitors use slower phones than the emulator. Do not spend a week chasing a perfect 100. If your site is too small to have CrUX data, add the open source web-vitals library and send the numbers to Google Analytics 4, so you see what your own visitors experience.

The Usual Culprits

• A 3 to 5 MB hero photo straight from the photographer, or a slider with five full-size images when visitors only see the first one.
• A Google Tag Manager container full of tags: Meta Pixel, TikTok Pixel, Hotjar, two analytics tools, and a chat widget that loads half a megabyte of JavaScript on every page.
• Two Google Fonts families in four weights each, loaded in a way that blocks rendering.
• Cheap shared hosting with a TTFB of 1.5 to 3 seconds, no page cache, and a server on another continent.
• A page builder such as Elementor or WPBakery with forty plugins, each adding its own CSS and JavaScript to every page whether it is used there or not.

Fixes That Make the Biggest Difference

Images first. Serve AVIF or WebP, use srcset so phones get an 800 pixel version and desktops a 1600 pixel one, and keep the hero under about 200 KB. Add width and height attributes to every image so the browser can reserve space. Lazy-load images below the fold with loading lazy, but never the LCP image. Give that one fetchpriority high instead. We regularly find WordPress lazy-load plugins applied to the hero as well, which alone delays LCP by a second or more.

Fonts next. Self-host one family in two weights as WOFF2, preload the main file, and set font-display to swap or optional. System fonts are a perfectly good choice for body text. For scripts, sit down with marketing and go through every tag in Tag Manager. Anything nobody has looked at in three months goes. Load the rest with defer or after the page is interactive, and replace the live chat widget with a simple button that loads the real widget only when someone clicks it.

Then the server. A page cache, from LiteSpeed Cache or WP Rocket on WordPress or at the server level, often cuts TTFB from two seconds to under 300 ms. Put a CDN such as Cloudflare in front, enable Brotli compression and HTTP/3, and move hosting to a data centre in Jakarta or Singapore. If the site is built on a heavy page builder and still fails after all this, rebuilding the five or six main templates is often cheaper than another month of tuning plugins.

A Step-by-Step Plan

1. 1Measure the baseline: run PageSpeed Insights on mobile for the homepage and the five landing pages with the most traffic in GA4. Write down both field and lab numbers, and export the Search Console report.
2. 2Fix TTFB first. If the server takes more than 0.8 seconds to answer, front-end work will not save you. Add caching or change hosting.
3. 3Fix the LCP element on each page template: right-sized image, modern format, no lazy loading, fetchpriority high.
4. 4Audit third-party scripts with the people who asked for them. Remove what is unused and delay the rest.
5. 5Fix layout shifts: image dimensions, reserved space for cookie bars and promo banners, and matched fallback font sizes.
6. 6Retest in the lab, then wait for the 28-day field window to roll over and press Validate fix in Search Console.
7. 7Set a budget to stop regressions, for example a hero under 200 KB and under 300 KB of JavaScript per page, checked by Lighthouse CI in the deployment pipeline.

Every script a vendor asks you to paste into the head of your site is a cost paid by every visitor on every page.

Speed is easiest to keep when someone owns it. When we build or take over a website, we set the budget at the start, check field data every month, and ask what a new script is for before it reaches production. Cleaning up afterwards always takes longer.