Core Web Vitals in a Mobile-First Market: A Practical Guide for UAE Websites

Google judges your website the way most of your customers meet it: on a phone. Since Google moved to mobile-first indexing, the mobile version of your site is the one it crawls and ranks — and Core Web Vitals are the three numbers it uses to judge how that version feels to a real visitor: how fast the main content appears, how quickly the page responds to a tap, and whether things jump around while it loads.

This month we ran those checks on our own website, page by page. We found the same problems we find on client sites: a main image that loaded late, blog images sized for a desktop monitor, a form-protection script loading on pages where nobody had touched a form, and text that jumped down the screen when the web font arrived. Fixing them took our blog page from roughly 1.9 MB to under 750 KB, and layout shift to zero across the site.

Below is what each metric means in plain English, the six problems we see most often on UAE sites, and the order to fix them in. If you would rather hand it over, performance is built into every site our website development team ships.

The three numbers, in plain English

• Largest Contentful Paint (LCP) — how long until the biggest thing on the screen, usually your main image or headline, has appeared. Good: 2.5 seconds or less.
• Interaction to Next Paint (INP) — how long the page takes to visibly react after a tap or click. Good: 200 milliseconds or less. It replaced the older First Input Delay metric in March 2024.
• Cumulative Layout Shift (CLS) — how much the layout jumps while the page loads. Good: 0.1 or less.

Google assesses each one at the 75th percentile of real visits, separately for mobile and desktop. In other words, a page passes only if at least three out of four visits are good — not just your own visit on fast office Wi-Fi.

1.Your main image loads too late

On most UAE business pages the largest element is an image: a hero photo, a product shot, a featured project. Two habits slow it down. The first is file size — a 200 KB, 1,200-pixel JPEG where a phone needs a 30 KB WebP. The second is lazy-loading the one image that should never wait. Lazy loading is right for images further down the page, but applied to the first image it tells the browser to fetch your most important picture last. That was the cause of a 5-second LCP on our own Our Work page.

The fix: Serve images as WebP at the size they are actually displayed, with a smaller version for phones — the srcset attribute lets the browser pick. Never lazy-load the first image on the page, and give it fetchpriority="high" so it is fetched first. Keep the first screen simple: one strong image, not a slider of five. A slow first screen is also the first conversion killer in our guide to why UAE websites don't convert.

2.Third-party scripts nobody remembers adding

Chat widgets, tag managers, analytics, heatmaps, spam protection for forms, booking widgets — each is a script from someone else's server that the phone has to download and run before the page responds properly. They accumulate over the years, and many load on every page even when they are needed on only one.

The fix: List every script your site loads — PageSpeed Insights shows them under "3rd parties" — and remove what nobody uses. Load the rest only where and when they are needed. We now load Google's form spam protection only when a visitor starts filling in a form, which took about 350 KB of JavaScript off our blog and contact pages. Check your hosting too: some hosts inject their own monitoring script into every page. Ours did, and their support team switched it off on request.

3.The page jumps while it loads

Layout shift is the button that moves just as you tap it. The usual causes are images without a width and height set, banners or cookie bars that push content down after the page appears, and web fonts. When a custom font arrives a moment after the page has painted in a fallback font, the text re-wraps: a paragraph gains a line and everything below it moves. On some of our own service pages, that alone produced layout-shift scores of 0.3 to 0.4 — three to four times the 0.1 limit for "good".

The fix: Always set a width and height on images and videos so the browser reserves the space before they arrive, and reserve room for anything that appears late. For fonts, preload the main font file and use a size-matched fallback font, or font-display: optional, so a late font never re-flows the text.

4.Bilingual sites carry two sets of fonts

An English–Arabic site needs an Arabic font as well as a Latin one, and Arabic font files are usually larger because each letter has several connected forms. Many bilingual sites load every weight of both fonts on every visit, whether the visitor reads Arabic or not.

The fix: Self-host your fonts rather than loading them from a third-party server, ship only the weights the design actually uses, and split the files by character range (the CSS unicode-range property) so the Arabic files download only when Arabic text is on screen. If you are still deciding whether to add Arabic at all, our guide to bilingual websites in the UAE covers the trade-offs.

5.Pages built for desktop and shrunk for phones

A theme or page builder that looks fine on a laptop can ship sliders, animation libraries and full-width background videos that a phone still downloads, even when they are hidden on small screens. Hidden is not the same as not loaded.

The fix: Design the phone version first and add to it for larger screens, not the other way round. Load decorative effects only once the page is usable. On our own site, the 3D elements load only after a visitor's first scroll or tap, and are skipped entirely on low-memory phones and for visitors who have switched on "reduce motion".

6.Measuring the wrong thing

Many owners test their homepage once in PageSpeed Insights, see a red number and panic — or see a green one and stop. The score at the top is a lab simulation on a throttled phone connection, and it moves from run to run; we regularly see the same page swing by ten points or more within minutes. What Google actually uses is field data from real Chrome users, and a newer or smaller site often has too few visits for any field data to show at all.

The fix: Use the Core Web Vitals report in Google Search Console, which groups your real pages into good, needs improvement and poor. Until it has data, use the lab test to find problems, and judge progress by the individual metrics rather than the headline score. Keep perspective, too: Core Web Vitals are a ranking signal, but relevance and useful content matter far more. Speed decides between pages that are otherwise close, and it decides whether visitors stay — which is why a slow site is one of the 10 SEO mistakes UAE businesses make.

What to fix first

Not every fix is worth the same effort. In order of return:

First, the first screen. Resize and convert your images, stop lazy-loading the main image and set image dimensions. On most sites this is a day's work, and it improves both loading and layout shift.

Second, the scripts. Remove the third-party scripts nobody uses and load the rest only where they are needed. This is where most slow-to-respond pages are won back.

Third, the fonts. Self-host them, trim the weights, and stop the late-font jump — especially on bilingual sites.

Last, the score. Once your pages are green in Search Console, stop. Chasing a perfect 100 in a lab test rarely changes rankings or enquiries.

If you would like to know where your own site stands, our website development team can run the same checks on your key pages.