Core Web Vitals for UAE sites: what the numbers mean and what to fix first
Core Web Vitals pass or fail on real visits, not on a lab score. What LCP, INP and CLS mean, what to fix first on a UAE site, and when to stop.
The short answer
Core Web Vitals are three measures of real visits: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, each judged at the 75th percentile on mobile and desktop separately. Fix the biggest image and the server response first, then third-party scripts, then layout jumps, and stop once all three are good.
The score at the top of a PageSpeed Insights report isn't the test. Core Web Vitals are judged on real visits to your pages, and the pass or fail sits in the field data box, once the page has enough traffic to fill it. A high lab score with failing field data is still a fail, and a modest lab score with passing field data is a pass.
What do the three numbers mean?
| Measure | Good means | What a visitor feels | Common cause of failing |
|---|---|---|---|
| Largest Contentful Paint (LCP) | The main content appears within 2.5 seconds of the page starting to load | The page looks ready | A large hero image, a slow server response, or a web font holding back the headline |
| Interaction to Next Paint (INP) | The page responds to a tap, click or key press in 200 milliseconds or less | Taps feel instant | Heavy JavaScript, often from tags, widgets and chat tools |
| Cumulative Layout Shift (CLS) | A layout shift score of 0.1 or less, which has no unit | Nothing jumps while you read or tap | Images, banners and embeds that load without reserved space |
Google's web.dev judges each at the 75th percentile of real page loads, separately for mobile and desktop. In plain terms, at least three in four visits must be good for the page to pass. Interaction to Next Paint replaced First Input Delay as a Core Web Vital, so any report still quoting FID is out of date.
Why test on mobile first?
Because Google uses the mobile version of a page for indexing, which is what mobile-first indexing means, and because the thresholds are assessed separately for each device type. A desktop pass tells you nothing about the phone visit.
Heavy scripts also tend to hurt most on phones, which have less processing power than the laptop a developer tests on. If you only have time for one test, run the mobile one.
What should you fix first?
- Test four pages, not one: the home page, a category or service page, a product or detail page and an article, all on mobile. Problems repeat across a template, so fix the template and not the single page. If a page has no field data, use the busiest page on the same template, or the site-wide figures PageSpeed Insights offers.
- Find the LCP element. PageSpeed Insights names it in its diagnostics, and on most pages it's the top image or the headline. If it's an image, that image is your first fix: web.dev's guidance is never to lazy-load it and to give it high fetch priority, and you should serve a size that suits a phone as well. If it's text, check whether a web font is delaying it, because an Arabic headline waits on its font file like any other web text.
- Check the server response before polishing anything else. web.dev splits LCP into four parts: the server's first response, the delay before the image starts loading, the download itself, and the delay before it's drawn. The two delays should be close to zero, which leaves the server response and the download as the places to look, so ask your host or platform how fast your busiest pages respond.
- Audit third-party scripts. List every script that isn't yours: the tag manager, ad pixels, chat and WhatsApp widgets, review tools, payment widgets such as Tabby or Tamara, and the cookie banner. Switch them off one at a time in the tag manager and re-test INP. If one costs more than it earns, delay it until the visitor first interacts, or remove it.
- Reserve space for everything that loads late. Give images and embeds a width and height, hold a fixed slot for banners and cookie notices, and don't insert content above what the visitor is already reading. That's the usual cure for layout shift.
- Check fonts on bilingual pages. An Arabic font file can be much larger than a Latin one, a bilingual page may load both, and a fallback font with different proportions makes text jump when the real font arrives. Load only the weights you use, preload the one that appears above the fold, and test the Arabic page separately.
- Re-measure after the field data catches up. Field data reflects roughly the previous 28 days, so a fix shows gradually. Use lab tests to confirm a fix works today and field data to confirm that visitors feel it.
When should you stop?
When all three measures are good at the 75th percentile on mobile. Nobody outside Google can tell you what the next improvement is worth to rankings, and Google doesn't publish a weight for these measures. What you can measure is what faster pages do to enquiries and sales on your own site.
A perfect lab score is also a trap, because you can reach it by stripping out the tracking, chat and design features that bring in enquiries. A page that passes and converts beats a page that scores 100 and doesn't, and why your website gets visits but no enquiries is the better next read if speed is already good.
Core Web Vitals decide very little on their own: a fast page with nothing to say still won't rank. They sit inside the wider technical SEO checklist for UAE websites, and working through them with your developers is part of our SEO service.
Run your busiest page on mobile in PageSpeed Insights, read the field data box first, and write down which of the three failed. That one word tells you which fix to start with.
Questions people ask
What are Core Web Vitals?
Three measures of real-visit page experience: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. Google's web.dev sets good thresholds of 2.5 seconds, 200 milliseconds and 0.1, each assessed at the 75th percentile of page loads.
What is a good Core Web Vitals score?
There's no single score. A page passes when LCP is within 2.5 seconds, INP is 200 milliseconds or less and CLS is 0.1 or less, at the 75th percentile of real visits, measured separately on mobile and desktop. A lab score alone doesn't decide it.
Do Core Web Vitals affect rankings?
Google counts them as part of how it assesses page experience but doesn't publish how much weight they carry, and nobody outside Google can measure it. Treat passing as a baseline for visitors and conversions rather than a lever that lifts a weak page.
Why is my PageSpeed Insights score low when Search Console says my Core Web Vitals are good?
Search Console and the field data box use real visits over roughly 28 days, while the headline score comes from a lab test on a simulated device. The field data decides pass or fail. Use the lab test to find causes, not to judge the result.
What should I fix first on a slow UAE website?
The largest image on the page and the server response, then third-party scripts such as chat, WhatsApp, payment-widget and ad-pixel tags, then anything that loads late without reserved space. Test mobile first, and fix the template instead of single pages.