Should you host your website in the UAE? We measured it from Dubai

The question arrives in three shapes. "Should I host my website in the UAE?" "Will a server in Dubai make my site rank better here?" "My hosting is in Germany and my customers are in Dubai, is that a problem?"

Short answer, for a company website, a shop or a booking system: the server's country is a small effect wrapped in a large myth. It is worth a measurable number of milliseconds, it is not the largest number on the page, and it is not what decides whether you rank in the UAE. There are cases where UAE hosting is the right call and one of them can be legally binding, so the answer is not "never" but "for specific reasons, and none of them is SEO".

Most pages ranking for this question are published by companies that sell UAE hosting, and their numbers are absent or unattributed. So we measured it, and this article publishes the protocol before the result, because a number without a protocol is a claim.

The protocol

Date and time. The network measurements below were taken on 27 August 2026 in five runs between 22:45 and 23:37 UTC, which is 02:45 to 03:37 Gulf Standard Time on 28 August. That is one night. It says nothing about how these paths behave at 11:00 on a working Tuesday, and it is not a guarantee about tomorrow. The file sizes in the second half were read separately on 28 August 2026.

Tool. Globalping by jsDelivr, through its public REST API api.globalping.io/v1. Every probe used reported software version 0.50.2. Two measurement types: ping (ICMP, 16 packets per probe per run) and http (one HTTPS GET per probe per run). The same six probes were pinned across all five runs by reusing the first measurement's probe set, so the table columns are comparable row by row.

Origin under test. schroerdigital.ae, resolving to 157.90.23.210, announced by AS24940 Hetzner Online, physically in Germany. That is this site's actual production origin, a single server, no CDN in front of it. It is the machine that served you this page.

In-UAE reference host. We operate no infrastructure in the UAE and will not pretend otherwise, so "our server in Dubai" was not measurable. What is measurable is the network distance between a visitor in the UAE and a machine definitely inside the country: s3.me-central-1.amazonaws.com. That name does not resolve to a single address. Across five runs and six probes it resolved to 16 different addresses in 60 measurements, which is ordinary behaviour for a regional S3 endpoint. All 16 sit inside three prefixes: 3.5.48.0/22, 52.95.187.0/24 and 52.95.188.0/23. Two checks on the country. AWS's endpoint documentation lists the region code me-central-1 as "Middle East (UAE)", and AWS's own published address file ip-ranges.json (retrieved 28 August 2026, createDate 2026-08-27-21-17-05) assigns all three prefixes to region me-central-1. The addresses are in the UAE according to the operator of the addresses, not according to a geolocation database.

Measurement points. Six Globalping probes in the UAE:

#	City	Network	ASN	Probe type
1	Dubai	M247	AS9009	eyeball
2	Abu Dhabi	Oracle	AS31898	eyeball (OCI me-abudhabi-1)
3	Fujairah	Melbikomas	AS8849	datacenter
4	Al Fujairah City	BFB ONE FZ-LLC	AS59878	datacenter
5	Dubai	BrainStorm Network	AS136258	datacenter
6	Fujairah	Medianova	AS21245	monitoring node

Control. The same HTTPS request was also issued to the same origin from three probes in Germany (Falkenstein/Hetzner, Nuremberg/Hetzner, Nuremberg/netcup), five runs each. Same application, same server, same TLS configuration, minus the distance. That is what isolates the distance.

Quantities, kept separate. Round-trip time (RTT) is ICMP, the average over 16 packets per run. Time to first byte (TTFB) is built from the HTTP phases as Globalping defines them: dns (the lookup), tcp (lookup to TCP connection established), tls (TCP connection to TLS session established), firstByte (connection to the first response byte). We report TTFB as tcp + tls + firstByte and give DNS separately, because DNS is a property of the probe's resolver, not of the server being measured.

File sizes, measured separately. The byte counts later in this article were read on 28 August 2026 by requesting each file from the live origin with curl, sending Accept-Encoding: br, gzip the way a browser does, and recording the bytes actually transferred. Sizes do not depend on where you request from. Times do, and we report no times from that run.

Limits of the method, stated before the results.

• One night, one hour, five runs. Nothing here establishes a daily or seasonal pattern.
• Globalping probes are volunteer-hosted. Four of our six sit on datacenter networks, better connected than a phone on mobile; two are tagged eyeball networks. Real consumer paths in the UAE are probably worse than these numbers, not better.
• Probe 6 (Medianova, Fujairah) measured about 100 ms even to the in-country reference host, so its path to that host leaves the country and comes back. Its values to our own origin are unremarkable. It appears in full in every table and is excluded from the medians for the in-UAE reference host only, for that reason.
• Probe 3 (Melbikomas) showed 12.5 to 18.75 percent ICMP packet loss to our origin in all five runs while every one of its HTTPS requests succeeded: the signature of rate-limited ICMP, not of a broken route.
• Our origin and the AWS reference host run entirely different software, so their TTFB values are not comparable to each other. Only the RTT values are, because RTT is network and nothing else. For the application-level comparison, use the German control.
• One HTTPS GET is not a page load. This measures the first byte of the first document, which is the part server location can affect.

The raw values

Table 1. ICMP round-trip time to our origin in Germany. Average of 16 packets, milliseconds.

Probe	Run 1	Run 2	Run 3	Run 4	Run 5	Median
Dubai / M247	115.30	114.58	111.99	111.91	114.49	114.49
Abu Dhabi / Oracle	116.35	116.46	116.36	116.34	116.34	116.35
Fujairah / Melbikomas	116.70	116.70	116.74	116.86	116.61	116.70
Al Fujairah / BFB ONE	111.95	112.03	112.05	112.06	112.03	112.03
Dubai / BrainStorm	109.43	109.45	109.43	109.64	109.33	109.43
Fujairah / Medianova	111.74	111.77	111.79	111.80	111.72	111.77

All 30 values: minimum 109.33, maximum 116.86, median 112.04. Spread across five runs on the same probe is under 4 ms everywhere, so the path was stable in the window.

Table 2. ICMP round-trip time to the in-UAE reference host. Average of 16 packets, milliseconds.

Probe	Run 1	Run 2	Run 3	Run 4	Run 5	Median
Dubai / M247	11.96	10.45	11.22	11.16	12.49	11.22
Abu Dhabi / Oracle	7.39	9.03	9.08	9.32	7.27	9.03
Fujairah / Melbikomas	4.63	4.66	4.55	6.22	4.62	4.63
Al Fujairah / BFB ONE	4.82	3.13	4.69	3.10	3.19	3.19
Dubai / BrainStorm	4.76	3.21	3.32	3.24	4.78	3.32
Fujairah / Medianova	100.66	100.23	100.86	101.02	101.68	100.86

Excluding Medianova: 25 values, minimum 3.10, maximum 12.49, median 4.78.

Difference of the two medians, per probe: 103.3, 107.3, 112.1, 108.8 and 106.1 ms, median 107.3 ms. That is the cost of the distance, one round trip at a time.

Table 3. HTTPS time to first byte to our origin, tcp + tls + firstByte. Milliseconds.

Probe	Run 1	Run 2	Run 3	Run 4	Run 5
Dubai / M247	382	315	368	371	344
Abu Dhabi / Oracle	362	365	364	363	369
Fujairah / Melbikomas	385	380	403	373	416
Al Fujairah / BFB ONE	411	371	391	402	397
Dubai / BrainStorm	359	358	382	381	378
Fujairah / Medianova	353	366	345	367	347

30 values: minimum 315, maximum 416, median 370. DNS, reported separately, ranged from 0 to 212 ms across the same requests, and that is the probe's resolver, not our server.

Table 4. The same request, same server, from Germany. Control, tcp + tls + firstByte, milliseconds.

Probe	Run 1	Run 2	Run 3	Run 4	Run 5
Falkenstein / Hetzner	21	26	19	25	20
Nuremberg / Hetzner	25	16	18	27	16
Nuremberg / netcup	14	20	17	18	11

15 values: minimum 11, maximum 27, median 19. For completeness, the same request to the AWS reference host from the five in-country-routed probes gave a TTFB median of 34 ms (range 19 to 53), on different software, so read that as an order of magnitude and not as a comparison with our 370.

What the numbers mean, and what they do not

The distance costs about 107 ms per round trip and about 351 ms on a cold connection. Median TTFB from the UAE to our origin was 370 ms; the identical request to the identical server from inside Germany was 19 ms. That difference, 351 ms, is the whole price of the origin being about 4,600 km away in a straight line. Divide it by the 107.3 ms round trip and you get 3.3, which is exactly the shape of a cold HTTPS request: one round trip for the TCP handshake, one for the TLS 1.3 handshake, one for the request and the first byte back. The application itself contributed almost nothing, and the control proves it: 19 ms for handshake, render and first byte together.

That 351 ms is an upper bound, and it is paid once. It applies to the first connection; everything after it on the same connection skips both handshakes, and a browser opening a page makes one connection and reuses it. Static files and anything cacheable can be answered from a CDN edge without moving the origin at all.

Now put it next to what the page itself sends. Compressed bytes have to be compared with compressed bytes, so every figure below is what actually crossed the network, not what the file weighs on disk. The HTML document of this site's home page is 43,600 bytes as written and 10,507 bytes on the wire, because the server sends it with content-encoding: br. Here is the rest of a first visit with an empty cache:

File	Bytes on the wire	Compressed by server
HTML document	10,507	brotli
styles.css	19,440	brotli
main.js	3,804	brotli
2 web fonts (woff2)	68,856	no, format already is
Vireon client logo (PNG)	189,797	no
video poster (JPEG)	71,139	no
3 other client logos (WebP)	64,732	no
Small logos, badges, icons	39,830	mixed
Total	468,105

The largest single file is a client logo stored as a 2,560 by 993 pixel PNG and displayed in a small strip: 189,797 bytes, eighteen times the HTML document, 41 percent of the page. Nothing forces it to be that size. That is a fault on our own page, measured on our own page on 28 August 2026, and we would rather name it than pick a stranger's site as the example.

The background video is not in that total, and this is the part that gets misreported. The file is 2,398,783 bytes, but it sits in a video element with preload="none", controls and a play button, so the browser does not fetch it until somebody presses play. What is fetched is its poster image, 71,139 bytes, which is in the table above. A big file that nobody downloads costs nothing, and counting it would have made our own argument look better than it is.

Turning bytes into milliseconds needs a throughput figure, and we did not measure throughput: Globalping truncates response bodies, and the API marked every one of our own responses truncated: true, so any number we produced from that run would be invented. Do the division with your own line speed instead. 468,105 bytes is 3.74 megabits, so the whole page takes about 75 ms at 50 Mbit/s, 187 ms at 20 Mbit/s and 749 ms at 5 Mbit/s to transfer. The one oversized PNG is 1.52 megabits: 30, 76 and 304 ms on the same three lines. Those figures are arithmetic on an assumed line speed, not measurements of ours.

Set that against the 351 ms of distance and the honest result is not a knockout in either direction. Neither number dwarfs the other on this page. What separates them is what you can do about each:

• The 351 ms is paid once per connection, and the only ways to reduce it are moving the origin or putting a CDN in front of it. Both cost money every month.
• Of that 468 KB, the client logos further down the page carry loading="lazy", so a visitor who never scrolls that far does not pay for roughly 254 KB of it. The rest is paid by every visitor who scrolls the page with a cold cache, and 41 percent of the total disappears by resizing one image. That costs an afternoon, once.
• The two are not independent. A connection with a 107 ms round trip needs several round trips before it reaches full speed, so the same file takes longer from far away than the division above suggests. We did not measure that effect and put no number on it.

Third-party scripts are the same story, and we measured that too. In a supplementary single run at 22:52 UTC, from the same six probes, one HTTPS GET to www.googletagmanager.com took 271 to 844 ms to first byte on the same tcp + tls + firstByte definition, and one to fonts.googleapis.com took 253 to 789 ms. On five of the six probes the TCP handshake to those hosts finished in 0 to 8 ms, so a Google front end answers inside or very near the country, yet the TLS handshake on the same connection then took 118 to 133 ms. We will not speculate about why. Either way the point holds: one render-blocking third-party tag can cost more than everything server location could ever save. Count the ones on your own site before you shop for a server.

Ranked by the size of the numbers we actually measured: a render-blocking request to a host you do not control, up to 844 ms. Then what your own page sends, which on a slow line is the largest thing the page does to itself. Then where the server is, 351 ms once per connection. Server location is real, it is last, and it is the only one of the three you cannot fix by editing files.

The myth: that Google treats the server's country as a local relevance signal

Search results for this question are full of one sentence: host in the UAE and Google will rank you better for UAE searches. What Google actually publishes is more specific, and more useful.

Google's page Managing multi-regional and multilingual sites (retrieved 27 August 2026) lists the signals it uses to work out which country a site is aimed at. Server location is on that list, described like this:

Server location (through the IP address of the server). The server location is often physically near your users and can be a signal about your site's intended audience.

The next sentence is the one that does not make it into the agency blog posts:

Some websites use distributed content delivery networks (CDNs) or are hosted in a country with better webserver infrastructure, so it is not a definitive signal.

The honest reading: it is one weak input into geotargeting, the question of who a site is for, and not an input into ranking position for a site whose target country is already unambiguous. The same page names the stronger inputs first: country-code top-level domains and "hreflang statements, whether in tags, headers, or sitemaps", then local addresses, phone numbers, language, currency, links from local sites and the Business Profile.

A .ae domain is a ccTLD. If you have one you have already sent the strongest geotargeting signal Google names, and an IP address Google itself calls not definitive adds little on top of a signal that is unambiguous by definition. On a .com, hreflang and the on-page signals do that job, more reliably than an IP address does.

Two further details from Google's own pages close the argument:

• Google removed country targeting. Its help page The International Targeting report is deprecated (retrieved 27 August 2026) states that the ability to target search results to specific countries using Search Console country targeting "was determined to have little value for the ecosystem, and is no longer supported", while hreflang stays supported. A control Google withdrew because it added little is not a reason to buy hosting.
• Google does not crawl from several countries to see what changes: "We do not attempt to vary the crawler source used for a single site in order to find any possible variations in a page." The same page says Google ignores locational meta tags such as geo.position.

There is a real link between speed and ranking, and it deserves stating precisely rather than denying. Google's page experience documentation (retrieved 27 August 2026) says "Core Web Vitals are used by our ranking systems" and, in the same passage, "There is no single signal." Those are measured in a real visitor's browser across the whole page. Server distance contributes the slice sized above; files, scripts and caching contribute the rest, and on a slow line the rest is larger. If ranking in the UAE is the actual question behind the hosting question, what moves the needle is on the other side of the site.

When hosting in the UAE is the right answer

In some cases this stops being a performance question and becomes a compliance or product question, and then the answer is yes, without argument.

Health data. Federal Law No. (2) of 2019 concerning the use of information and communications technology in health fields regulates health-sector ICT in the UAE, "including its free zones", in the words of the UAE Government's own portal (u.ae, retrieved 28 August 2026). That law is widely described as restricting the storage and processing outside the country of health data belonging to services provided inside it, subject to exceptions granted by the health authority.

We could not verify that clause at the source, and we are saying so rather than quoting a translation as if we had. The official legislation portal's page for this law answered our requests with HTTP 403 on 27 and 28 August 2026, and the Ministry of Health's published copy of the English text would not load either. Every English wording circulating online is an unofficial translation of an Arabic original, so we neither reproduce it here nor cite an article number we have not read in the register.

What follows from that is a procedure, not a legal opinion. If your site carries a clinic booking form that collects anything about a patient's condition, treat the location of the database as a legal question before you treat it as a hosting preference, put it to a lawyer and to your health authority, and get the answer in writing. We name the law so you know to ask. We do not interpret it for you.

A regulator or a contract that says so. One example at the strict end, verified in the primary text: the Central Bank of the UAE's Outsourcing Regulation for Banks, Article 6 (Circular C 14/2021, in force since 15 July 2021, retrieved 28 August 2026) requires that a bank's "Master System of Record, which includes all Confidential Data, is continuously maintained and stored within the UAE". Article 6.2 lets branches of foreign banks meet that with a copy inside the country, updated at least daily, subject to Central Bank approval. Note what it covers: a licensed bank's system of record, not its brochure website, and banks, not everyone. We have not counted how often in-country hosting clauses appear in UAE tenders or private contracts, and we will not guess at a frequency. The general rule is narrower and duller: if your contract or your regulator names a hosting location, that decides it and there is nothing left to measure.

Applications where a round trip is part of the interaction. The measured penalty is about 107 ms per round trip. A page load spends three or four of them and is dominated by other things. An application in which user and server exchange messages continuously, such as live voice, collaborative editing, a game, a trading screen or remote machine control, pays that 107 ms on every exchange, and there it becomes the product. Build those close to the users. A company website, a shop and a booking form are none of them: they are request-response and they cache. The same goes for a heavy application you genuinely cannot slim down whose audience is entirely in the Gulf, where moving the origin closer is a legitimate last lever.

Not on this list: rankings, "local trust", and the belief that a UAE IP address makes a heavy page light.

The question behind the question: is anyone watching the server at all

Server location is decided once and then never thought about again. What decides whether your site is up and fast on a random Tuesday is recurring, and it is the part bought last and dropped first. The failures that take small company sites down are boring and the same everywhere.

• A certificate expires, and nobody notices until a customer sends a screenshot of the browser warning. Renewal has to be automatic, and something has to alert you when the automation fails, because eventually it does.
• A dependency gets a security advisory and nothing updates it. On a typical CMS that is the most common route to a defaced or spam-injected site.
• A backup exists but has never been restored. That is a claim about a file, not a recovery plan.
• The site is down and nobody knows. A health check on the same machine as the site is not a health check. It has to run elsewhere and reach a person.
• A change breaks something quietly: a form that stops delivering, a tracking script blocked by a policy header, a phone link missing a digit. None of them produces an error page. They produce silence, and silence looks like a quiet week.

None of that depends on which country the server is in. All of it depends on whether a named person is looking.

Since the whole article is an argument for measuring instead of asserting, here is the state of this site, checked on 28 August 2026 rather than remembered.

• The origin is a single server at Hetzner in Germany, 157.90.23.210, with no CDN in front of it.
• The TLS certificate is issued by Let's Encrypt and obtained and renewed automatically by the reverse proxy. The one that served the measurement run was issued on 19 August 2026 and expires on 17 November 2026, which Globalping recorded independently in the same run.
• The /srv tree, which holds this site's code and data, is copied every night at 03:00 to an off-site repository on separate hardware. It is a tree-level backup with build artefacts excluded, not a full-server image. The last run before publication finished on 27 August 2026 at 03:05.
• The container has a restart policy, not a health check. Docker restarts it if the process exits, and docker inspect reports no health check defined on it, so a process that is running but no longer answering would not be restarted on its own.
• No external monitor is watching this domain from outside the machine today. Nothing on the server does it and no external service is configured for it.

The last two entries are the ones worth reading. We listed the failure modes above because they are work we owe ourselves as well, not because they are all solved here. The operating scope we sell, and the price it belongs to, is on the website package page.

If you would rather have numbers for your own site than read ours, the tools are free and they are the ones we use: PageSpeed Insights, SSL Labs, securityheaders.com, and Search Console on your own domain. Our standing rule is that performance and security figures should come from somebody who is not selling you anything, which is why we normally publish other people's measurements instead of our own. This article is the exception, and the protocol above is what the exception costs.

Network values here were measured on 27 August 2026 between 22:45 and 23:37 UTC and describe those paths in that window only. File sizes and the state of the server were read on 28 August 2026. Routes change, providers change capacity, and pages get edited. If this matters to your project, run the measurement again on the day, and write the protocol down before you write the number down.