Three numbers, in plain language

Core Web Vitals are Google's attempt to put numbers on something shoppers feel instantly: does this store respond, or does it make me wait? There are three of them, and each has a documented threshold that Google publishes openly.

LCP — Largest Contentful Paint. How long until the biggest thing on the screen actually shows up. On a product page that is usually the product photo; on a home page, the hero image. Google's threshold for "good" is 2.5 seconds. Past that, the shopper is staring at a blank rectangle wondering whether the page is broken.

INP — Interaction to Next Paint. How long the page takes to visibly react after someone taps something — a size selector, "add to cart", the quantity stepper. The threshold is 200 milliseconds. Above it, taps feel ignored, and people tap again, which on a checkout button is exactly the behaviour you do not want.

CLS — Cumulative Layout Shift. How much the page jumps around while loading. The threshold is 0.1. This is the metric behind the classic e-commerce failure: the shopper reaches for "continue", a late-loading banner shoves the layout down, and their thumb lands on something else.

Why this bites harder in the Gulf

Lab tests on an office fibre connection and a flagship phone will tell you your store is fine. Your customers are not shopping in those conditions. A large share of GCC e-commerce traffic is mobile-first, and a meaningful slice of it arrives on mid-range Android devices — phones with slower processors that take longer to parse and execute every script your store ships. The same page that feels instant on a new iPhone over Wi-Fi can feel sluggish on a mid-range device on a busy mobile network.

Network conditions vary too: signal quality inside malls, towers under load in dense areas, connections that drop from 5G to 4G mid-session. None of this is exotic — it is the normal shopping environment across the UAE and Saudi Arabia. It just means the margin for waste is thinner than a desktop test suggests. Google measures Core Web Vitals from real user visits (field data), not from your office. If your customers are on mid-range phones, your scores are set by mid-range phones.

The usual suspects

After enough performance audits, the same offenders keep turning up. Before commissioning anything expensive, check these four:

  • Unoptimized hero and product images. A 3 MB photo scaled down by the browser is the single most common LCP killer. Serve modern formats (WebP or AVIF), size images for the screens that actually load them, and let the first image load with priority instead of lazily.
  • Render-blocking fonts. Custom fonts loaded the wrong way hold the whole page hostage until they arrive — and bilingual stores often ship both a Latin and an Arabic typeface, doubling the cost. Preload the fonts you use, subset them, and show fallback text while they load.
  • Third-party scripts. Chat widgets, analytics tags, heatmaps, retargeting pixels — each one seemed harmless when it was added. Together they can consume more of a mid-range phone's processing budget than your actual store, and they are the most common cause of poor INP. Audit the list twice a year and delete what nobody reads.
  • Images and embeds without dimensions. When an image tag has no width and height, the browser cannot reserve space for it, so the layout jumps when it arrives. This is most of CLS, and the fix is close to free.

The order matters: fix images first, then fonts, then third-party scripts, then missing dimensions. That sequence attacks LCP, INP, and CLS roughly in proportion to how much each usually costs a storefront — and the first two fixes need no redesign at all.

Dashboard theatre vs money pages

There is a version of performance work that produces impressive screenshots and no revenue. A perfect score on a near-empty home page is dashboard theatre: the number goes green, everyone relaxes, and the pages where purchases actually happen stay slow. Shoppers do not buy on your home page. They buy on product pages, the cart, and the checkout — pages heavy with images, variant logic, and payment scripts, which is precisely why they score worst.

So weight your attention by money, not by vanity. A modest improvement to product-page LCP or checkout INP is worth more than a flawless score anywhere else, because that is where hesitation turns into abandonment. The honest caveat: speed is not a magic lever. If your product photos are poor or your delivery promise is vague, a fast page just delivers the disappointment sooner. Performance removes friction; it does not create demand. That is also why we treat it as one ingredient of web design work in Dubai rather than a service you bolt on afterwards.

Check your own store, free, this afternoon

You do not need to hire anyone to find out where you stand. Two free tools cover it:

  1. PageSpeed Insights (pagespeed.web.dev). Paste in a URL — a product page, not just your home page — and read the top section first: that is field data from real visitors when enough traffic exists. The lab section below it helps diagnose, but the field data is what Google actually uses.
  2. Search Console's Core Web Vitals report. If your store is verified in Google Search Console, this report groups your URLs into good, needs improvement, and poor — so you can see whether it is one template (usually the product page) dragging everything down, rather than guessing page by page.

Run both, note which metric fails on which template, and compare against the suspects above. In most audits, the diagnosis takes an afternoon; it is the fixing that takes engineering time.

When not to obsess over this

If your store is pre-launch, has little traffic, or your field data is already comfortably green, deep performance work is the wrong place to spend money — the SEO basics most UAE businesses skip or clearer product content will move revenue further. Core Web Vitals are a hygiene bar, not a growth strategy: clear it, then compete on things customers consciously notice.

But if shoppers are arriving and leaving, the field data is red on your money pages, and your third-party script list has grown for years without an audit — that is the moment this work pays for itself. It is also why we build fast by default on modern stacks like React and Next.js rather than retrofitting speed later; performance engineering is part of how we scope every build, with a transparent quote before work starts.