Most site owners hear "Core Web Vitals" and assume it's a magic switch that will push them to position one. It isn't. Page speed is one of many ranking signals Google uses, and by itself it rarely outranks a page with thin or irrelevant content. What it does is remove friction that keeps otherwise-good content from converting, and it can be the deciding factor when two pages are competing on similar relevance and authority. If your site is slow, you are not being penalized so much as you are losing the tiebreaker every single time.
What Core Web Vitals Actually Measure
Core Web Vitals are three specific metrics Google uses to approximate how a real visitor experiences a page. They are part of a broader "page experience" signal, but they are the part with concrete, published targets, so they're worth understanding individually.
Google pulls these numbers from two different sources, and the distinction matters. Lab data comes from a simulated test run — this is what you see in Lighthouse or when you run PageSpeed Insights on demand. Field data (also called CrUX, the Chrome User Experience Report) comes from real Chrome users who actually visited your site over the past 28 days. Google's ranking system leans on field data, not lab scores. A site can look great in a one-off Lighthouse test and still fail Core Web Vitals in the real world if actual visitors are on weaker phones or slower connections than the test simulates.
Is Speed Really a Google Ranking Factor?
Yes, but with an important qualifier: it's a modifier, not a foundation. Google's own documentation describes page experience signals as a way to break ties between pages that are otherwise similarly relevant. A slow page with excellent, well-matched content can still outrank a fast page that doesn't answer the search intent. What speed reliably affects is everything downstream of the click — bounce rate, time on page, and whether a visitor converts, all of which feed back into how Google and users perceive the page over time.
The business case is usually stronger than the SEO case. A visitor who taps a link from Google search results and watches a blank screen for four seconds has already formed an opinion about the business before a single word of content loads. On mobile data in Indonesia, where a large share of traffic still comes from mid-range Android devices on 4G rather than fast home broadband, that gap between a fast and slow site is even more pronounced than global averages suggest.
What Actually Slows Sites Down
In practice, the same handful of causes show up on almost every slow site we audit.
Unoptimized images
Images are usually the single biggest contributor to page weight. A photo straight out of a phone camera or a stock library, dropped into a CMS at full resolution and served as JPEG or PNG, can easily be 3-5MB. Converting to WebP or AVIF and resizing to the actual display dimensions typically cuts that by 70-90% with no visible quality loss.
Web fonts loaded the wrong way
Custom fonts are a common, overlooked cause of layout shift and delayed text rendering. Loading four weights of a font family when only two are used, or not specifying `font-display: swap`, forces the browser to either hide text until the font arrives or swap it in late and shift the layout.
Third-party scripts
Chat widgets, marketing pixels, analytics tools, and embedded videos each add their own network requests and JavaScript execution, often from servers you don't control. It's common for these scripts to account for a large share of total blocking time even though they contribute nothing to the actual content.
Slow server response and no caching
If the server takes 800ms or more just to send the first byte, nothing downstream can compensate for that. Shared hosting with too many sites on one machine, no server-side caching, and no CDN are the usual culprits, especially for WordPress sites running heavy page-builder plugins.
Render-blocking CSS and JavaScript
When large CSS or JS files have to fully load and execute before the browser can paint anything, the visitor stares at a blank screen even if the server response itself was fast.
How to Measure It Properly
Don't rely on a single test run. Speed varies by device, connection, and even time of day. A reasonable process:
The Fix Checklist
The Mobile-First Reality for Indonesian SMEs
Most Indonesian consumers browse and shop primarily from a phone, often a mid-range Android device on 4G rather than a flagship on fiber wifi. Design and development decisions that look fine on a developer's laptop and fast office connection can produce a genuinely poor experience for the majority of actual visitors. Testing on throttled mobile connections, not just desktop wifi, is not optional if most of your traffic is mobile.
What We Do at KayFreyTech
Every site we build targets a 95+ average PageSpeed score across mobile and desktop before launch, using static site generation, image compression pipelines, and code splitting by default rather than as an afterthought. We treat this as a baseline requirement, not a premium add-on, because a slow site quietly undermines every other SEO and marketing effort put into it.
Speed work isn't a one-time project either. New images get added, new plugins get installed, new tracking scripts get pasted in by whoever is running a campaign that week, and scores drift back down without anyone noticing until conversions drop. A short recurring check, even quarterly, catches that before it costs you rankings or sales.