Core Web Vitals for Saudi Websites: A Business Guide
- Targets at the 75th percentile: LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less, judged separately for mobile and desktop.
- Google treats page experience as one signal; relevance comes first, and good scores do not guarantee rankings.
- Judge success on field data (CrUX, Search Console) over 28 days, not on the Lighthouse lab score alone.
- Fix high-traffic templates first: hero media, third-party tags, web fonts and unsized images are common culprits.
Core Web Vitals are three measurements Google uses to describe how a page feels to a real visitor: how fast the main content appears, how quickly the page reacts when someone taps, and whether things jump around while it loads. You do not need to be a developer to manage them, but you do need to know what each metric means, where the numbers come from, and what to ask your developer or agency for.
The three metrics in plain language
Google's thresholds are measured at the 75th percentile of page loads, separately for mobile and desktop. Each metric is assessed on its own, and a page passes when it meets the target at the 75th percentile for all three, according to web.dev's Web Vitals overview.
| Metric | What the visitor experiences | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How long until the biggest visible element, usually the hero image or headline, appears | 2.5 s or less | Over 4 s |
| INP (Interaction to Next Paint) | How quickly the screen responds after a tap, click or key press, such as opening a menu or submitting a form | 200 ms or less | Over 500 ms |
| CLS (Cumulative Layout Shift) | How much content moves unexpectedly, such as a button sliding away just as the visitor taps it | 0.1 or less | Over 0.25 |
The definitions and ranges come from web.dev's pages on LCP, INP and CLS. INP is the newer metric; it replaced First Input Delay, so older reports that mention FID are out of date.
How much this matters for Google rankings
Be realistic here. Google says its core ranking systems "look to reward content that provides a good page experience", but also that Search "always seeks to show the most relevant content, even if the page experience is sub-par" (Google Search Central: page experience). Google also warns that good results in the Core Web Vitals report do not guarantee top rankings (Google Search Central: Core Web Vitals). Page experience is one signal among many; relevance comes first.
The stronger business case is about people. A visitor on mobile data who waits for a slider to load, or taps "WhatsApp us" and hits a shifting banner instead, may simply leave. Treat Core Web Vitals as a measure of that friction, not a ranking trick.
Field data vs lab data
- Field data comes from real Chrome users through the Chrome UX Report (CrUX). It reflects actual devices and networks over a trailing 28-day period. This is what Google's assessment uses.
- Lab data comes from a single simulated test (Lighthouse). PageSpeed Insights documentation explains that lab data is useful for debugging but "may not capture real-world bottlenecks".
PageSpeed Insights shows both on one screen: field data at the top when it exists, and a Lighthouse score below. The 0 to 100 performance score is lab data. A developer who reports "we reached 95" has not necessarily fixed what your visitors experience.
The Search Console Core Web Vitals report uses CrUX field data, groups similar URLs together and splits results by mobile and desktop. It is the best place to see which page types are failing across the whole site.
What usually slows down Saudi business websites
Loading (LCP)
- Heavy hero images and background videos. Full-width photos uploaded straight from a camera or design file, or an autoplaying video behind the headline.
- Sliders and carousels that load several large images and a script before the first slide appears.
- Lazy-loading the main image. web.dev advises never lazy-loading the LCP image and giving it high priority (optimize LCP).
- Render-blocking CSS and JavaScript, common with page builders and themes that load every feature on every page.
- Web fonts. Font files add weight to the page, and bilingual sites may load Arabic and Latin families in several weights. Ask for only the weights you use, subset where practical, and font files served from your own domain.
Responsiveness (INP)
- Too many third-party tags: several ad pixels, analytics, heatmaps, chat widgets and WhatsApp buttons all competing for the browser's main thread.
- Heavy page-builder JavaScript and very large pages with thousands of elements, which web.dev lists among the causes of slow interactions (optimize INP).
Visual stability (CLS)
- Images and videos without width and height, so the browser cannot reserve space before they arrive (optimize CLS).
- Cookie and consent banners, promo bars and chat pop-ups injected at the top of the page after it has rendered.
- Font swaps, where a fallback font is replaced by the web font and the text reflows.
How to prioritise
- Start with mobile. Check your analytics for the device split; on many consumer-facing sites phones lead. Connections range from home Wi-Fi and 5G in city centres to weaker coverage on the road, so test on a mid-range phone over mobile data, not only office Wi-Fi.
- Fix templates, not pages. Search Console groups URLs with a similar experience. Fixing the service-page or product template can improve every page built on it, although page-specific images, embeds and scripts can still produce different results.
- Rank templates by traffic and value. The homepage, top landing pages used in ads, and pages with contact or booking forms come first.
- Audit third-party tags before rewriting code. Removing a pixel for a campaign that ended months ago is cheaper than any optimisation.
What to ask your developer or agency for
- A baseline: current PageSpeed Insights field data for the key templates (mobile and desktop) and a screenshot of the Search Console report.
- The LCP element on each key template and why it is slow, in plain terms.
- A list of every third-party script, who owns it, and whether it is still needed.
- Hero images served in modern formats at sensible sizes, not lazy-loaded; no autoplay video above the fold on mobile unless it is essential.
- Explicit dimensions on images, embeds and banners, with space reserved for consent and promo bars.
- A font plan covering Arabic and English: which families, which weights, and how swapping is handled.
- A before/after report that separates lab results from field results.
Measuring before and after
Record the baseline before any work starts. After changes go live, lab tests can be rerun immediately, which helps check loading and layout fixes. Lab tools such as Lighthouse cannot measure INP, because there is no real user input; they report Total Blocking Time as a lab proxy for INP, so responsiveness fixes are only confirmed by field data. Field data takes longer, because CrUX and Search Console use a rolling 28-day window. Judge success on the field numbers roughly a month after release, and note release dates so a later change (a new chat widget, a new campaign pixel) does not get confused with the original fix.
When not to obsess
CrUX only includes pages and origins with enough visitors to be statistically meaningful. For a new or low-traffic site, Search Console may show no data, which Google explains means the property is new or "there is not enough data available in the CrUX report" (Search Console Help). PageSpeed Insights likewise falls back to origin-level data, or shows none at all. In that case, use lab tests as a guide, fix the obvious problems listed above, and put the rest of your effort into content, relevance and conversion.
For the wider picture, pair this with a technical SEO audit. Eclipse Advertising Agency in Riyadh offers website development services in Saudi Arabia; contact us if you would like to discuss your site.
Frequently asked questions
Do Core Web Vitals directly decide my Google ranking?
No. Google says its ranking systems reward good page experience, but relevance comes first and a good Core Web Vitals report does not guarantee top positions. Treat them as one signal among many and as a measure of visitor friction.
Why is my PageSpeed Insights score different every time I test?
The 0 to 100 score is lab data from a single simulated run, so network and server conditions cause variation. The field data section, based on real Chrome users over 28 days, is more stable and is what Google's assessment uses.
My site shows no Core Web Vitals data in Search Console. Is something broken?
Usually not. The report relies on CrUX, which only covers pages and sites with enough real visitors. New or low-traffic sites often have no field data; use lab tests to catch obvious issues in the meantime.
Sources: web.dev · web.dev · web.dev · web.dev · developers.google.com · developers.google.com · developer.chrome.com · developers.google.com · support.google.com · web.dev · web.dev · web.dev