Core Web Vitals on Arab Websites: Real-User Data for 45 Brands

Most big Arab brand websites fail Core Web Vitals on phones. We read Google’s Chrome UX Report (CrUX) for 45 brand origins in Saudi Arabia, the UAE, Egypt, Qatar and Kuwait on 4 October 2026, and only 3 of 45 pass all three metrics at the 75th percentile. Slow servers, heavy tags and unstable layouts explain most of the gap.

Key takeaways

• 3 of 45 Arab brand origins (7%) pass LCP, INP and CLS together on phones, in CrUX data for the 28 days to 26 September 2026.
• Good LCP: 9 of 45. Good INP: 12 of 45. Good CLS: 26 of 45.
• Median time to first byte is 1,246 ms, about 40% of LCP for the median site.
• All 4 airlines have poor INP (514 to 1,205 ms). None of 7 banks and 2 of 8 telecoms have a good LCP.

How many Arab brand websites pass Core Web Vitals on phones?

Three of 45. A Saudi grocery chain, a UAE property portal and a UAE classifieds site pass all three Core Web Vitals on phones at the 75th percentile, in CrUX data for the 28 days ending 26 September 2026. Another 7 origins miss by a single metric, and 11 fail all three.

Google’s Web Vitals guidance sets the bar: LCP of 2.5 seconds or less, INP of 200 ms or less, CLS of 0.1 or less, all met at the 75th percentile. INP replaced First Input Delay on 12 March 2024.

Three Saudi origins (a delivery app, a hospital group and a real estate developer) fail on LCP alone, a Saudi marketplace fails only on CLS (0.12), and two Egyptian telecoms and an Egyptian airline fail only on INP. At the other end, an Egyptian bank records an LCP of 8,835 ms, 4,633 ms of it time to first byte, and a Saudi pharmacy records a CLS of 1.92, 19 times the good threshold.

How do Saudi Arabia, the UAE and Egypt compare?

No country does well. Saudi Arabia has 1 passing origin out of 15, the UAE 2 of 13 and Egypt 0 of 13. Median LCP sits between 3,446 and 3,704 ms in all three, well above the 2,500 ms line. The clearest difference is INP: 8 of 15 Saudi origins are good, against 2 UAE and 1 Egyptian.

Egypt has the most good LCPs (4 of 13): two telecoms, a marketplace and an airline that load fast and then fail on responsiveness. With 13 to 15 origins per country, one site moves a share by about 7 points, so read this as a direction, not a ranking.

Which sectors fail, and on which metric?

Every sector fails, each on its own metric. All 4 airlines have poor INP. Banks fail LCP and CLS, telecoms fail LCP and INP but keep layouts stable, and electronics retailers fail all three. Property portals and classifieds come closest, with 2 of 3 passing. Sector predicts the broken metric better than country does.

The smaller sectors are pharmacy, delivery, hospitals, grocery, fashion, a super-app and payments. Six of 7 banks fail CLS; late promo banners are where we would look first, though this data cannot show the cause.

How we checked. On 4 October 2026 the VOCTOS team read each origin in CrUX Vis, Google’s dashboard for the CrUX History API: origin level, phone, the 28-day period from 30 August to 26 September 2026, p75 values. We attempted 48 origins; one Egyptian telecom had no CrUX record and two UAE airlines were not collected because the tool stalled. VOCTOS clients are excluded. Limits: the brands are hand-picked, not a random sample; origin data blends every page and visitor country; Chrome on iOS does not report to CrUX.

Server response time takes 40% of the LCP budget

Time to first byte is where LCP starts to slip on these sites. The median origin takes 1,246 ms to deliver its first byte on phones. Only 2 of 45 meet web.dev’s rough guide of 0.8 seconds, and 14 exceed 1.8 seconds. For the median site, TTFB uses about 40% of the LCP time.

Web.dev’s TTFB article lists what that number contains: redirects, service worker startup, DNS, connection and TLS setup, and the server’s wait. TTFB is not a Core Web Vital, but the browser cannot discover the hero image until HTML arrives. Language redirects (root to an Arabic or country path) and HTML served from a distant origin both add to it. The six slowest servers in our set take 2.5 to 4.6 seconds, and four of them are Egyptian.

Regional edge capacity is not the constraint. Cloudflare’s network page, checked on 4 October 2026, lists data centers in Riyadh, Jeddah, Dammam, Dubai, Doha, Kuwait City, Manama, Muscat and Cairo, and our server-side tagging study counted 16 public cloud regions in Arab countries. Proximity helps only when the HTML is cached or rendered close to the user.

Do heavy fonts and ad pixels line up with failing scores?

In our small samples, yes. All 6 homepages that loaded 500 KB or more of web fonts in our 2 October crawl fail LCP on phones, and all 4 that ran Meta, TikTok, Snap and X pixels together fail INP. These are correlations from 6 and 4 sites, not proof that fonts or pixels caused the failures.

The font group’s median LCP is 4,315 ms against 3,678 ms for all 45; our Arabic web fonts study covers subsetting and weight cuts. Fonts are one cause among several: the 8,835 ms bank also has the slowest server. The four-pixel group’s median INP is 375 ms against 261 ms overall; our consent mode and tracking study found pixel stacking common on Arab homepages. Scope differs, too: the crawl read one Arabic homepage on desktop from Cairo, while CrUX covers every page for real phone users.

If you want a developer to turn your own CrUX numbers into a ranked fix list, get my site’s Core Web Vitals reviewed.

Do Core Web Vitals affect Google rankings?

Yes, as one input among many. Google’s page experience documentation states that “Core Web Vitals are used by our ranking systems.” The same page warns that good scores do not guarantee top positions, and that Google still shows the most relevant result when page experience is weak. Passing removes a handicap, but it does not replace relevance.

The page experience FAQ adds that Google evaluates pages one by one, with some site-wide assessments, and the Core Web Vitals page on Search Central points to Search Console for monitoring.

How do you read your own CrUX data?

Use three free Google tools, in this order. CrUX Vis shows 40 weeks of origin or URL history. PageSpeed Insights shows the latest 28-day field data next to a lab test. Search Console groups your own URLs by status. All three read the same CrUX dataset, so differences come from scope, not from different users.

Open cruxvis.withgoogle.com, enter the exact canonical origin and set the device to Phone. The CrUX History API behind it updates every Monday, and each weekly point covers 28 days. Its loading view splits LCP into image subparts (time to first byte, load delay, load duration, render delay), which tells you which team owns the fix.

No data usually means ineligibility. The CrUX methodology requires a root page that returns 200 without noindex, plus enough Chrome traffic. In the Search Console Core Web Vitals report, a URL group takes the status of its worst metric.

Fixing TTFB for Arab audiences

Bring the HTML closer to the user and stop rebuilding it on every request. Serve the document from a Gulf or Cairo location that matches your traffic, remove redirect hops from the first visit, and let a CDN cache HTML for anonymous pages. Then check CrUX again, because lab tests run from Europe hide regional latency.

Compare TTFB with the round trip time metric in CrUX Vis. High RTT with a fast server points to distance; low RTT with slow TTFB points to the backend or a poor cache-hit rate. Cache logged-out templates at the edge for a few minutes, and keep personalised fragments (cart counts, account menus) out of that cache.

Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=60

Fixing LCP: hero image first, fonts second

Make the LCP element discoverable in the HTML and fetch it at high priority. Images start at low priority in Chrome and are boosted only after layout, according to web.dev’s Fetch Priority guide. Adding fetchpriority=”high” lets the hero start early, and a CSS background hero also needs a preload.

<!-- Hero as an img: high priority, never lazy-loaded -->
<img src="/img/hero-ar-800.avif"
     srcset="/img/hero-ar-480.avif 480w, /img/hero-ar-800.avif 800w"
     sizes="100vw" width="800" height="600"
     alt="Autumn offers on phones and laptops"
     fetchpriority="high">

<!-- Hero as a CSS background: preload it at high priority -->
<link rel="preload" as="image" href="/img/hero-ar-800.avif"
      fetchpriority="high">

If a slider stays, give the first slide high priority and the rest fetchpriority=”low”. Then fix fonts: some homepages in our crawl preloaded eight or nine font files, which compete with the hero for bandwidth. Preload one or two at most.

Fixing INP: tags, long tasks and yielding

INP measures how quickly the page paints after a tap. On many sites the main thread is still busy with third-party tags, widgets and framework code when users tap. Cut tags nobody uses, delay the rest until after the first interaction, and break your own long tasks so the browser can paint between them.

A long task is any main-thread task over 50 ms, per web.dev’s guide to optimising long tasks. Lighthouse cannot measure INP because nobody taps in a lab run, so use Total Blocking Time as the lab proxy and CrUX as the truth. In your own handlers, update the UI first and yield before background work.

function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function onSearchSubmit(form) {
  showLoadingState(form);          // user sees a response first
  await yieldToMain();             // let the browser paint
  renderResults(filterFares(form));
  await yieldToMain();
  sendAnalytics('search', form);   // tags run after the paint
}

scheduler.yield() works in Chrome and Edge 129+ and Firefox 142+, not Safari, hence the setTimeout fallback.

Fixing CLS: fonts, images and banners

Layout shift on Arab sites comes from three places: Arabic web fonts swapping in with different metrics, images and sliders without reserved space, and cookie, app or promo banners inserted above content. Reserve space for all three. CLS is the metric most sites here already pass (26 of 45), so the remaining failures are usually single components.

Give the fallback font size-adjust and ascent-override values so it occupies the same space as the brand font (our fonts article has the CSS). Set width and height, or aspect-ratio, on every image. Overlay banners instead of pushing content down, then find each shift in the DevTools Performance panel.

A 30-minute audit routine

Thirty minutes is enough to learn which metric fails, on which template and why. Read field data first, reproduce the problem in the lab, then write three tickets. Do not start from a Lighthouse score, which tests one simulated load; Search Console’s report runs on field data.

1. Minutes 0 to 5. CrUX Vis, origin, Phone: note p75 LCP, INP, CLS, TTFB and RTT, and the trend.
2. Minutes 5 to 10. PageSpeed Insights on home, a listing and a detail page.
3. Minutes 10 to 18. DevTools with CPU and network throttling: check the hero’s Priority column reads High, and find the LCP element and layout shifts.
4. Minutes 18 to 25. Record while tapping the menu, search and forms; note interactions over 200 ms and the scripts behind them.
5. Minutes 25 to 30. Write tickets for the server, the LCP element and the worst interaction or shift.

Our read

The first problem on Arab brand websites is the server, and the second is tag governance; front-end polish comes after both. With a median TTFB of 1,246 ms on phones, the rest of the page has about 1.25 seconds to reach a good LCP. Image compression cannot rescue HTML that arrives at 2.5 seconds.

INP is organisational. The four-pixel homepages and the airlines fit the pattern of marketing, booking and analytics scripts sharing the main thread with nobody owning the total. A tag budget signed off by whoever owns conversion fixes more INP than any single code change.

The Saudi INP lead (8 of 15 good, against 2 of 13 in the UAE and 1 of 13 in Egypt) could be sector mix; this sample cannot tell, and a retest of the same 45 origins would.

What to do next

A better question than your lab score is how the slowest quarter of your real phone visitors experience the site. If your origin already passes in CrUX, protect it with real-user monitoring through the web-vitals library, a tag budget and separate tracking for iPhone users. If it fails, fix TTFB first, then the LCP element, then INP.

When the fixes span hosting, templates and tags, I want a technical SEO plan built around my field data.

FAQ

My PageSpeed score is high but Search Console says my pages are poor. Why?

The score comes from a Lighthouse lab run: one simulated load with no real taps. Search Console uses CrUX field data, the 75th percentile of real Chrome visits over 28 days. Real phones, networks and interactions are slower than the lab, and Lighthouse cannot measure INP at all. Fix the field numbers, not the score.

Does CrUX data include iPhone users in the Gulf?

No. CrUX collects from Chrome on desktop and Android, including Custom Tabs. Chrome on iOS, Android apps using WebView and other Chromium browsers such as Edge do not contribute. If many of your visitors use iPhones, add your own real-user monitoring with the web-vitals library and segment it by device and country.

Will passing Core Web Vitals improve my Google rankings?

It can help, but it guarantees nothing. Google says Core Web Vitals are used by its ranking systems, and also that good scores do not guarantee top positions. Relevance comes first. Treat passing as removing a handicap on queries where several pages answer equally well, and as a direct gain in user experience.

How long after a fix will CrUX show the improvement?

About four weeks for the full effect. Each CrUX data point covers the previous 28 days, and the History API behind CrUX Vis updates every Monday, so each weekly point moves part of the way. Search Console’s validation runs its own 28-day monitoring window after you click Start Tracking on the issue.