Core Web Vitals for Saudi Websites: A Practical Speed Guide

Most Saudi websites test well on a laptop over office fibre and badly on a mid-range Android phone over a mobile network. The second scenario is the one your customers are in, and the one Google measures.

The three metrics, in plain terms

• Largest Contentful Paint (LCP) — how long until the main content is visible. Target under 2.5 seconds.
• Interaction to Next Paint (INP) — how quickly the page responds when someone taps. Target under 200 milliseconds.
• Cumulative Layout Shift (CLS) — how much the page jumps around while loading. Target under 0.1.

Google measures these from real Chrome users, not from your test run. That means your score reflects the devices and networks your actual audience uses. In Saudi Arabia that skews toward mobile, and toward network conditions that vary considerably outside major city centres.

Test the way your users browse

Before optimising anything, get an honest baseline. Run PageSpeed Insights and read the field data section, not the lab score — field data is what Google uses for ranking. Then throttle Chrome DevTools to a mid-tier mobile device on slow 4G and load your homepage. The gap between that and your usual experience is usually the entire problem, revealed in one test.

Arabic fonts are the most common LCP culprit on Saudi sites

Arabic web fonts are large. A full Arabic family can be several hundred kilobytes, and loading two weights of Arabic alongside two weights of Latin is a substantial blocking cost on a mobile connection.

1. Subset aggressively. Ship only the glyph ranges you use. Full Arabic fonts include ranges most sites never render.
2. Use font-display: swap. Text renders immediately in a fallback rather than staying invisible while the font downloads.
3. Preload the critical face only. One weight, the one used for the largest visible text.
4. Self-host with WOFF2. Third-party font hosting adds a DNS lookup, a connection and a request chain on the critical path.
5. Match fallback metrics. Use size-adjust and ascent-override so the fallback occupies similar space and the font swap does not cause layout shift.

Images: the second biggest win

Saudi sites frequently ship hero images at 3000px wide because that is what came out of the camera. On a 390px-wide phone that is roughly eight times more pixels than needed, downloaded over a mobile network.

• Serve AVIF with WebP fallback
• Use srcset and sizes so phones download phone-sized images
• Set explicit width and height on every image to prevent layout shift
• Lazy-load everything below the fold, and never lazy-load the LCP image
• Preload the LCP image with fetchpriority="high"
• Compress to the point where a difference is only visible under scrutiny

On a Saudi mobile connection, every 100KB you do not send is worth more than every optimisation you apply to the 100KB you do.

JavaScript and INP

Interaction to Next Paint punishes heavy main-thread work. The usual causes on business websites are third-party tags, oversized frameworks for simple pages, and event handlers doing too much synchronously.

• Audit third-party scripts ruthlessly — analytics, chat widgets, heatmaps, ad pixels and tag managers compound quickly
• Load non-essential scripts after interaction or on idle
• Break long tasks with scheduler.yield() or explicit yielding
• Avoid shipping a full SPA framework for a page that is fundamentally a document
• Defer hydration of components below the fold

A brochure website does not need 400KB of JavaScript. A meaningful share of the Saudi corporate sites we audit ship a client-side framework to render content that could have been static HTML, and pay for it in INP on every interaction.

Hosting, CDN and latency

Physical distance costs milliseconds on every request. A Saudi audience served from a European origin with no CDN starts every page load at a disadvantage that no amount of front-end optimisation recovers.

• Use a CDN with GCC or Middle East points of presence
• Consider in-Kingdom hosting where data residency requirements exist anyway
• Enable HTTP/2 or HTTP/3, Brotli compression and sensible cache headers
• Cache HTML at the edge for anonymous visitors where the page is not personalised
• Keep the critical request chain shallow — every additional round trip on a high-latency connection is expensive

Layout shift is usually four fixable things

1. Images without dimensions — set width and height, always
2. Web fonts swapping with different metrics — use metric-adjusted fallbacks
3. Ads, embeds and iframes without reserved space — reserve it
4. Content injected above existing content, such as cookie banners and promotional bars — overlay rather than push

A realistic optimisation order

Work in this sequence and most sites reach passing scores without a rebuild.

1. Measure field data and establish a mobile baseline
2. Fix images — format, sizing, dimensions, lazy-loading
3. Fix fonts — subset, self-host, preload one face, metric-adjust the fallback
4. Remove or defer third-party scripts that do not earn their weight
5. Add a CDN with regional presence and correct cache headers
6. Eliminate layout shift sources
7. Only then consider architectural changes such as static generation or server-side rendering

Keep it from regressing

Performance decays. A new tag here, an uncompressed image there, and six months later you are back where you started. Set a performance budget in CI that fails the build when the page weight or LCP crosses a threshold, and review field data monthly. Treating speed as a standing requirement rather than a project is the only approach that holds.