Website Speed and Core Web Vitals, Explained for Owners

Picture a potential customer finding your business on Google, tapping the link, and then staring at a blank white screen that won't fill in. Most likely they hit back and open the next result, which might belong to a competitor. Website speed isn't just a technical concern. It decides whether a buyer ever gets to see your products, especially in Indonesia, where many people browse on their phones over mobile data that isn't always stable.

Why speed affects sales

Every second of waiting is a chance for the visitor to change their mind. A slow site also feels less trustworthy, which makes people hesitate to fill in a form or make a payment. On top of that, Google uses page experience, including speed, as one of the signals when ranking search results. A fast website helps on both fronts: it's easier to find and more likely to turn visits into chats or orders.

Core Web Vitals in plain language

Core Web Vitals are three measurements Google uses to judge what it's like for a visitor to open a page. All three measure something a real person notices, not just a technical number.

• LCP (Largest Contentful Paint): how quickly the main content, such as a large product photo or the headline, appears on screen. It answers the visitor's question: has this page loaded yet?
• INP (Interaction to Next Paint): how quickly the page responds when someone taps a button, opens a menu, or types into a form. It answers: is this page listening to me?
• CLS (Cumulative Layout Shift): how much the layout jumps around while the page loads. Ever gone to tap a button, only for it to drop down because an image popped in above it? That's what CLS measures.

Google sets thresholds for good, needs improvement, and poor on each measurement. You don't need to memorise them, because the testing tools flag the problem areas for you.

How to measure your website's speed

1. Open Google's PageSpeed Insights, enter your site's address, and look at the mobile results first.
2. Note the difference between field data and lab data. Field data comes from real visitors, while lab data is a one-off simulation.
3. If your site is set up in Google Search Console, open the Core Web Vitals report to see which groups of pages have problems.
4. Also test it yourself on an ordinary phone over mobile data, not just on the office Wi-Fi.

Practical fixes that usually make the biggest difference

1. Sort out your images

Images are the most common cause of slow pages. Photos straight from a phone camera are often far larger than any screen needs. Ask your developer to compress them, use modern formats such as WebP or AVIF, serve different sizes for small and large screens, and delay loading images that sit far down the page. Setting an image's width and height also stops the layout from jumping, which improves CLS.

2. Use static pages where you can

Static pages are built once at build time and then delivered as-is to every visitor, without the server having to process them again. For company profiles, catalogues, and articles that don't change by the minute, this approach fits very well. The website for Devans Egg, our client from Cirebon, is built as a static Next.js site hosted on Cloudflare Workers. Edge services like this serve pages from a spread-out network of data centres, so pages are delivered from somewhere relatively close to the visitor.

3. Cut back on third-party scripts

Chat widgets, several trackers at once, heavy sliders, and pop-ups tend to get added one at a time without anyone noticing the cost. Every script has to be downloaded and run by the visitor's phone, which makes the page sluggish to respond. Review every script installed and remove the ones nobody uses. On both the Devans Egg and Numekara websites, tracking scripts are built to load only after the visitor gives consent, so they don't run for visitors who haven't agreed.

4. Load heavy features only when needed

Not every visitor needs every feature. On the Numekara learning platform, interactive 3D scenes load only when needed and only on devices that support them. Other devices get a lightweight SVG illustration instead. The same principle applies to videos, maps, or large galleries on a business website.

Speed is also about lean infrastructure

Beyond what visitors see, the server-side code should stay lean too. At Numekara, large content is read at build time to keep the app bundle small, and the Worker handler shrank from 102 MB to 16.6 MB. That figure is the size of the deployed bundle, not page load time, but it reflects the same habit: only ship what's truly needed.

Next steps

Test your home page and one product page in PageSpeed Insights today, and note which measurements are flagged. Take that list to your developer and ask for a prioritised set of fixes, starting with images and unnecessary scripts. Re-test after every major change, because speed tends to slip little by little without anyone noticing.