Website Speed and Core Web Vitals: A Practical Guide for Dubai Business Owners

Core Web Vitals are three measurements Google uses to judge how a web page feels to real visitors: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. According to web.dev, a page is good when LCP is within 2.5 seconds, INP is 200 milliseconds or less and CLS is 0.1 or less, measured at the 75th percentile of visits and assessed separately for mobile and desktop.

On most Dubai and UAE business websites, the biggest gains come from a handful of fixes rather than a rebuild. Start with the hero image, then the tracking tags and widgets, then hosting and fonts.

• LCP asks how quickly the main content appears. INP asks how quickly the page reacts to a tap. CLS asks whether things jump around.
• Field data from real visitors is what Google assesses. Lab data is for diagnosing problems.
• Use PageSpeed Insights for single pages and the Search Console report for the whole site.
• The usual culprits are oversized hero images and sliders, too many tags, slow hosting far from visitors, heavy fonts and chat widgets.
• Fix in order of impact, measure, then move to the next item.

The three Core Web Vitals in plain language

Each metric has a “good” threshold, a “needs improvement” band and a “poor” band. These are the ranges Google’s PageSpeed Insights documentation uses to classify results.

Largest Contentful Paint

LCP marks the moment the biggest visible element finishes rendering. The web.dev LCP reference lists the elements that count, including images, video, background images loaded through CSS and blocks of text. On a typical business homepage that element is the hero photo or the main headline. If visitors stare at a blank or half loaded screen, LCP is what captures it.

Interaction to Next Paint

INP measures the delay between a visitor acting and the page visibly responding. The web.dev INP reference explains that it observes mouse clicks, taps on a touchscreen and key presses, not scrolling or hovering, and that it covers the full chain from input delay through running the page’s code to painting the next frame. INP replaced First Input Delay as a Core Web Vital on 12 March 2024, so older articles that still talk about FID are out of date.

Cumulative Layout Shift

CLS captures that frustrating moment when you go to tap a button and it moves because a banner loaded above it. The web.dev CLS reference names the usual causes: images or videos without set dimensions, web fonts that render at a different size from their fallback, ads or widgets that resize themselves, and content inserted above what is already on screen. Shifts that happen within 500 milliseconds of a click or key press are excluded, because the visitor expects those.

Do Core Web Vitals affect Google rankings in the UAE?

Google’s Search Central documentation recommends that site owners achieve good Core Web Vitals for success with Search, and says they align with what its core ranking systems seek to reward. It does not say good scores will lift a page above more relevant content, and nobody honest can promise that.

The more practical reason to care is commercial. A clinic’s booking page that reacts slowly to a tap, or a property listing whose enquiry button jumps as photos load, loses people who were ready to act. Improving the metrics is mostly a proxy for removing those moments.

Treat Core Web Vitals as a measure of lost enquiries, not as a score to show off.

Field data and lab data: why your two scores disagree

This is the part that confuses most business owners, and it explains why an agency can show you a green score while Search Console reports problems.

The PageSpeed Insights documentation confirms both halves: field data is powered by CrUX over the previous 28 day collection period, while lab analysis uses Lighthouse in a simulated environment. The 0 to 100 performance score belongs to the lab side. It is useful for diagnosis, but it is not the same thing as passing Core Web Vitals.

A practical rule: judge success on field data, and use lab data to find out what to fix.

How to read PageSpeed Insights without getting lost

1. Test the pages that make money

   The homepage, your main service or product page, and whichever page holds the enquiry form or checkout. A fast homepage with a slow booking page is still a problem.

2. Read the mobile tab first

   Field data is split by device, and phones usually have slower processors and less reliable connections than office laptops. Desktop results can look healthy while mobile fails.

3. Check the field data box at the top

   If it says the page passes, you are in good shape even if the lab score below is amber. If there is no field data, the page does not yet have enough visits, so work from the lab results.

4. Find the LCP element in the diagnostics

   The report names the element responsible for LCP. On business sites it is very often a hero image or slider, which tells you exactly where to start.

5. Look at the third party list

   The diagnostics show how much time scripts from other domains take. This is where tag managers, chat tools and embedded maps appear.

The Search Console Core Web Vitals report

PageSpeed Insights looks at one URL. Search Console looks at your whole site. The Core Web Vitals report help page explains that it uses real world field data from CrUX, groups URLs that offer a similar experience, and gives each group the status of its slowest metric. If LCP is good but CLS is poor, the group is poor.

• Review mobile and desktop separately.
• Open each “Poor” or “Need improvement” issue to see an example URL, then test that URL in PageSpeed Insights.
• Groups without enough data do not appear, so a small site may show little or nothing at first.
• After deploying a fix, start tracking on the issue. Google describes this as a 28 day monitoring session, so results are not instant.

If you do not yet have Search Console set up, it is worth doing regardless of speed. It is also where indexing and search performance problems surface, which our SEO service page covers in more depth.

Why UAE business websites are often slow

The causes below come up again and again on local business sites. None is unique to the UAE, but together they explain most of the slow pages we are asked to look at.

Oversized hero images and sliders

A full width photograph of a skyline, a villa or a restaurant interior uploaded straight from a camera or a stock library can be several times larger than the screen needs. Sliders make it worse by loading several of those images, often through JavaScript, so the browser cannot find the first one until scripts have run. Google’s LCP optimisation guide recommends that the LCP image is discoverable in the initial HTML, given fetchpriority="high", never lazy loaded, and compressed in a modern format such as WebP or AVIF.

Too many tracking tags

Meta Pixel, Google Ads, GA4, TikTok, LinkedIn, Snapchat, a heatmap tool and a call tracking script, each added by a different person at a different time. Google Tag Manager helps, but the web.dev guidance on third party JavaScript warns that excessive tags and auto event listeners make the browser send more requests than it needs to. Heavy scripts also hurt INP, because the page is busy running code when the visitor taps.

Cheap shared hosting far from visitors

The first thing a browser waits for is the server’s response. web.dev’s Time to First Byte article suggests most sites aim for 0.8 seconds or less. TTFB is not a Core Web Vital itself, but the LCP guide notes that content delivery networks cut the geographic distance between visitors and your files. A slow shared server on another continent, with no CDN in front, puts a delay under every other metric.

Unoptimised fonts, including Arabic

Bilingual sites often load several weights of an English font and several of an Arabic one, on every page, whichever language is showing. The web.dev font best practices recommend WOFF2 files, fewer font files or a variable font, subsetting with unicode-range so each script only downloads when needed, and a deliberate font-display choice, because font swapping can cause layout shift. Our bilingual website guide covers the wider Arabic layout issues.

Chat widgets, pop ups and embeds

WhatsApp buttons, live chat tools, cookie banners, review carousels and embedded Google Maps are all third party code. Many load their full script on every page before anyone needs them, and some push content down as they appear, which harms CLS as well.

Core Web Vitals fixes in priority order

Work down this list, measuring after each step. The order reflects typical impact against effort on a small or medium business site, not a fixed rule. If your diagnostics clearly point elsewhere, follow the data.

1. Fix the LCP element

   Resize and compress the hero image to the dimensions actually displayed, serve WebP or AVIF, add fetchpriority="high", remove lazy loading from it, and replace a homepage slider with a single strong image where the business can live with that.

2. Audit every tag and widget

   List each script, who added it and whether anyone still uses the data. Remove the dead ones. Load the rest with async or defer, and delay chat widgets and map embeds until a visitor scrolls or clicks.

3. Reserve space for everything that loads late

   Set width and height on images and video, give banners and embeds a fixed container, and avoid inserting notices above content that has already rendered.

4. Improve server response

   Turn on page caching, put a CDN in front of the site, and if TTFB is still slow, move to better hosting. For WordPress sites, remove plugins that load code on every page for a feature used on one.

5. Trim fonts

   Cut to the weights the design actually uses, self host WOFF2 files, subset Arabic and Latin separately, and preload only the one or two files needed above the fold.

6. Reduce JavaScript for INP

   Heavy page builders, animation libraries and large theme bundles slow responses to taps. This is usually the most technical fix, and sometimes the point at which a website redesign is cheaper than patching.

What to ask your developer or agency

You do not need to make these changes yourself, but you should be able to hold a developer to them. These questions work for a new build and for reviewing an existing site.

• Which element is the LCP on our key pages, on mobile, and how is it being loaded?
• What does our field data show in Search Console, not just the lab score?
• Which third party scripts load on every page, and which can be delayed or removed?
• Where is the site hosted, is there a CDN, and what is our TTFB?
• How many font files load on a page, and are Arabic and English subset separately?
• How will you stop a new plugin, tag or widget from undoing this work after launch?

When you are comparing agencies for a new project, performance belongs in the proposal, not as an afterthought. Our guide on how to choose a web design company in Dubai explains how to check a portfolio site’s speed before you sign.

Keeping the site fast after launch

Most speed problems are not built in on day one. They arrive gradually: a campaign adds a new pixel, marketing uploads a large banner, someone installs a plugin for a single landing page. A site that passed at launch can drift into “needs improvement” within months without anyone noticing.

• Keep a short written list of approved scripts and who owns each one.
• Set a maximum upload size for images in the CMS, or resize automatically on upload.
• Run PageSpeed Insights on your key pages after every significant change.
• Check the Search Console Core Web Vitals report once a month.
• Review tags and plugins at least twice a year and remove what nobody uses.

At Codeeo every site is tested on real devices and browsers before launch, but the habit that keeps a site fast afterwards has to sit with whoever manages it day to day. If your site runs a shop, the same discipline matters even more on product and checkout pages, as covered in our notes on ecommerce website development.