Page speed for UAE company websites: what counts and what to fix

What does page speed mean for a UAE company website?

For many UAE companies, the first visit to the website does not start on a desk. It starts on a phone, from a link someone sent on WhatsApp, an Instagram profile or a Google search in a taxi between Dubai Marina and Business Bay. Page speed is how long that visitor waits before the page shows what they came for, and whether it stays still once it does.

Take a typical case. A prospective client taps the link to a Dubai interior design studio. The logo appears, then a grey box, then a full-width photo of a villa that was exported straight from the photographer's camera. On mobile data that photo is the page. Until it arrives, the visitor sees nothing worth staying for, and the back button is closer than the contact form.

That is the practical meaning of speed. It is not a score. It is the time between a tap and the moment the visitor can read, decide and act.

Which page speed numbers actually count?

Speed tools show a dozen figures. Three of these metrics are the ones Google calls Core Web Vitals, and each answers one plain question:

• Largest Contentful Paint (LCP): when does the main content appear? Good is 2.5 seconds or less, according to web.dev.
• Interaction to Next Paint (INP): when someone taps a button, how quickly does the page respond? Good is 200 milliseconds or less, per web.dev on INP.
• Cumulative Layout Shift (CLS): does the page jump around while it loads? Good is 0.1 or less, per web.dev on CLS.

Google measures these at the 75th percentile of real visits, split by mobile and desktop, as the Web Vitals overview explains. In plain terms: three out of four visits should be good, not just your own visit on office Wi-Fi.

A fourth number helps with diagnosis. Time to First Byte (TTFB) is how long the server takes to start answering. web.dev puts good at 0.8 seconds or less. A slow TTFB usually points at hosting or a slow backend, not at the page design.

One thing to know when reading a test: a lab tool like Lighthouse cannot measure INP, because nobody taps anything during the test. It reports Total Blocking Time instead, which web.dev describes as a proxy for INP. If your report shows a low Total Blocking Time, that is a good sign for INP, not proof of it. On our own home page, for example, the lab test showed an LCP of 1.3 seconds and a Total Blocking Time of 70 milliseconds; the INP of real visitors is a separate question the lab cannot answer.

Does page speed affect Google ranking?

Yes, but less than most speed tools suggest. Google's own documentation says plainly that "Core Web Vitals are used by our ranking systems", in its guide to page experience. The same page adds the sentence that matters more: "Google Search always seeks to show the most relevant content, even if the page experience is sub-par."

Picture a Dubai clinic with a fast site and thin service pages, competing for the same search with a second clinic whose site is slower but answers the question the patient actually typed. The second one will usually win. Speed decides between pages that are otherwise close. It does not lift a page that does not answer the search.

That is why we treat speed as SEO hygiene rather than a ranking strategy. Fix it so it never costs you a position. Do not expect it to earn one on its own. Google's Core Web Vitals guide points to the Search Console report as the place to see where your own pages stand.

Does a slow website lose visitors and enquiries?

The honest answer is yes, and the best evidence comes from controlled tests rather than from the statistics that circulate in agency slide decks.

Take the case of Vodafone, which is worth knowing in detail. The company ran an A/B test on a landing page with traffic split evenly between two versions, documented in a web.dev case study from 2021. Speed work was the only difference: server-rendered content, smaller images and less render-blocking JavaScript. In the field, the faster version had a 31% better LCP, and sales were 8% higher. The lead-to-visit rate improved by 15%.

That result is from one large company with paid traffic, so it does not transfer one to one to a small Dubai firm. What does transfer is the mechanism. A visitor who sees the main content sooner is more likely to read it, and a visitor who reads it is more likely to get in touch.

You will also find a widely shared figure about bounce probability rising with load time, attributed to Google research from 2017. We do not quote it here, because the original page is no longer available at its source address and we could not check the method behind it. A number you cannot trace back is not a number to build a decision on.

Usability suffers in a quieter way. A page that shifts while loading makes people tap the wrong button. A menu that reacts late makes people tap twice. Neither shows up as a bounce, but both show up as frustration, and frustration rarely turns into an enquiry.

How fast is our own website, measured?

Before writing about speed, we measured orentara.com. We used Lighthouse 12.6.1 on 28 October 2026, two runs per page, because a single run is noise.

• Home page, mobile: performance score 99 in both runs. LCP 1.3 and 1.2 seconds, CLS 0.056 and 0.048, Total Blocking Time 70 and 100 milliseconds.
• A blog article, mobile: score 100 in both runs, LCP 1.2 seconds, total page weight around 339 KiB.
• The same article, desktop: score 100 in both runs, LCP 0.4 and 0.5 seconds.

Every value sits inside the good thresholds from web.dev. Lighthouse itself rates 90 to 100 as good, per its scoring documentation.

We also found something to fix. Typing the bare address orentara.com triggers a redirect to the English version before anything loads, and Lighthouse estimates that redirect costs around 0.9 seconds on mobile (880 and 940 milliseconds in the two runs). The Lighthouse documentation on redirects explains why: each one adds a network round trip. Links from search and social go straight to the English pages and skip it, but anyone typing the domain pays the delay.

Two limits apply to these figures. They are lab values from a simulated mid-range phone, not field data from real visitors. And our site does not yet have enough traffic for a Chrome UX Report dataset, which needs a statistically significant number of visits. The field picture will tell us more once it exists. The article from web.dev on lab and field data explains why the two often disagree.

What slows a company website down?

When a company site is slow, look first at what was added after launch, not at the framework it was built on.

Images uploaded as they came from the camera. Say a restaurant in Jumeirah puts its dish photos on the home page exactly as the phone saved them. A hero photo straight from a phone or a photographer can be several megabytes. Resized to the width it is shown at and saved in a modern format, the same image often shrinks to a small fraction of that. web.dev's LCP guide treats the hero image as the first place to look.

Third-party scripts. A chat widget, a booking plugin, two analytics tools and a social feed each load their own code. Each one also competes with your content for the phone's processor, which is what pushes Total Blocking Time up. Our cookie tracking study looked at which scripts load on UAE company homepages before a visitor agrees to anything. Every one of them also costs loading time.

Redirect chains. http to https, bare domain to www, then to a language folder. Each hop is another round trip, as our own redirect shows.

Slow first response. If TTFB is poor on every page, the problem is the server or the way pages are built on it, not the content.

Layout that waits for fonts or banners. A cookie banner or a web font that arrives late pushes content down and raises CLS.

Frequently asked questions about page speed

Do I need a Lighthouse score of 100?

No. A score in the green range is good enough, and chasing the last points rarely changes what visitors experience. Watch the Core Web Vitals on real visits instead. A score varies between runs for reasons outside your site, as the Lighthouse scoring page explains.

Which speed test should I trust?

Start with PageSpeed Insights. It shows field data from real Chrome users when your site has enough traffic, and a Lighthouse lab test underneath. Test the pages people actually land on, not only the home page, and always test mobile.

Will better hosting fix a slow site?

Only if the server is the bottleneck. That shows up as a slow first response on every page, the TTFB described above. If the main content still takes seconds to appear after the server has answered, the delay sits in the page itself: heavy images, blocking scripts, late fonts. A bigger hosting plan then changes the invoice, not the load time.

Will a speed plugin fix my WordPress site?

A caching plugin can help with server response. For example, it can serve a stored copy of a page instead of building it on every visit. It cannot undo a five-megabyte photo or a widget that blocks the page. Measure before and after; if nothing changed, the plugin is only another script.

What does page speed optimization involve?

On most company sites it comes down to a short list: images resized and compressed, scripts the browser does not need for the first view loaded later, the CSS needed above the fold delivered first, and pages cached so the server does not rebuild them for every user. The LCP optimization guide walks through each step in the order that matters.

How often should I check page speed?

After every change that adds something: a new plugin, a new tracking tag, a redesigned hero section. Speed is rarely lost at launch. It is lost one addition at a time.

Where page speed fits in a website check

In practice, speed is one of the things we look at when we check how a company website performs, next to forms, mail delivery and consent. The technical website check describes the full sequence, and what our offer includes shows how speed is handled when we build a site.