Why your WordPress site is slow in Dubai, and how to actually fix it

Measure the right thing first

Before changing anything, separate two numbers that people constantly confuse.

Lab data is what PageSpeed Insights and Lighthouse give you: a simulated page load on throttled hardware. It is repeatable and useful for diagnosis. It is not what Google ranks on.

Field data is the Core Web Vitals report in Google Search Console, collected from real Chrome users on real devices on real networks. That is the data Google actually uses. A site can score 95 in Lighthouse and still fail field data, usually because real users are on mid-range Android phones over mobile networks while Lighthouse simulated something kinder.

One more thing worth knowing: test from the region your customers are in. A site that loads in 1.2 seconds from a European test node can take three times that from Dubai if the hosting is far away. If your testing tool lets you pick a location, pick the Gulf.

Core Web Vitals in plain English

Three metrics, and it is worth understanding what each one is actually measuring rather than treating them as a score to game.

LCP: Largest Contentful Paint

How long until the biggest visible thing finishes rendering. On most sites that is the hero image or the main heading. Target is under 2.5 seconds. This is the metric most affected by hosting distance and image weight, which is why it is usually the one failing on UAE sites hosted abroad.

INP: Interaction to Next Paint

How quickly the page responds when someone taps or clicks. Target is under 200 milliseconds. INP replaced First Input Delay as a Core Web Vital in March 2024, and it is a harsher test: FID only measured the first interaction, INP looks at responsiveness across the whole visit. Sites loaded with tracking scripts, chat widgets and page-builder JavaScript tend to fail here.

CLS: Cumulative Layout Shift

How much the page jumps around while loading. Target is under 0.1. Usually caused by images without width and height attributes, ads or embeds injected after load, or web fonts swapping in and reflowing the text.

CLS is the one clients notice emotionally, it is the reason someone taps the wrong button, and it is often the cheapest to fix.

The seven things that actually slow UAE sites down

In rough order of how often I find them as the primary cause.

1. The server is in the wrong hemisphere

This is the big one and it is invisible from a dashboard. A lot of UAE businesses are on cheap shared hosting with data centres in the US or Western Europe. Every single request, HTML, CSS, images, API calls, makes that round trip. You cannot optimise your way out of physics. Either host closer to the region, or put a CDN in front so static assets come from an edge node near the user. A CDN is usually the faster, cheaper intervention.

2. Page-builder bloat

Elementor, WPBakery and similar tools are genuinely useful for getting a site built quickly. The cost is the output: deeply nested div structures, multiple stylesheets, and JavaScript loaded on every page whether a page uses those widgets or not. A builder-heavy page can ship several hundred kilobytes of CSS to render a layout that needs a fraction of it.

3. Images nobody optimised

Especially on fashion, jewellery and hospitality sites, which is a lot of the UAE market. A product photograph straight from the camera at 4000px wide, served to a 390px phone screen, in JPEG rather than WebP or AVIF. Serve appropriately sized images in a modern format and lazy-load anything below the fold, this alone often moves LCP more than everything else combined.

4. Plugin sprawl

Thirty-five plugins where twelve would do. Each one potentially adds queries, scripts and stylesheets. The worst offenders are the ones that load their assets globally, a contact-form plugin injecting its CSS and JS onto every page including ones with no form on them.

5. No caching, or caching configured wrong

Without page caching, WordPress rebuilds every page from the database on every request. With it, you serve a pre-built file. This is the single highest-return change on most sites. But caching configured badly, caching logged-in sessions, or caching cart and checkout pages on a WooCommerce store, causes bugs that are worse than the slowness.

6. Render-blocking fonts, and the Arabic problem

Web fonts block rendering until they download. This gets more expensive on bilingual UAE sites, because an Arabic font file is typically much heavier than its Latin equivalent, more glyphs, and contextual forms where letters change shape depending on position in the word. Loading a full Arabic family on an English page is a common and costly mistake. Subset the fonts, use font-display: swap, and only load the Arabic face on Arabic pages.

7. A database nobody has cleaned

Three years of post revisions, expired transients, orphaned metadata, spam comments, and tables left behind by plugins that were deleted. On a WooCommerce store carrying order history this gets heavy quickly. Database work is unglamorous and it is often where a stubborn last chunk of load time is hiding.

The fix order that works

Order matters, because some fixes make others unnecessary and some make diagnosis harder. This is the sequence I use.

1. Back up first. Full files and database, verified restorable. Performance work touches caching, the database and sometimes the theme. Do not start without a way back.

2. Fix hosting and add a CDN. Deal with distance before anything else. If this is the problem, fixing it changes every subsequent measurement, so doing it first saves you from optimising against a moving baseline.

3. Page caching. Biggest single win. On WooCommerce, exclude cart, checkout and account pages explicitly and test a full purchase afterwards.

4. The image pipeline. Convert to WebP or AVIF, generate correct responsive sizes, lazy-load below the fold, and add width and height attributes to every image, that last one costs nothing and fixes a large share of CLS problems.

5. Audit plugins. Deactivate anything unused. For what remains, check whether it loads assets site-wide when it only needs to load on one page. Measure after each removal rather than removing twelve things at once and guessing which helped.

6. Fonts. Subset, self-host, preload the one face used above the fold, font-display: swap. Split Arabic and Latin loading.

7. Database cleanup. Revisions, transients, orphaned meta. Limit future revisions so it does not grow back.

8. Then measure again, lab and field. Give field data 28 days to catch up; it is a rolling window and will not update the moment you deploy.

When optimisation is not enough

There is a ceiling. If a site was built on a heavy page builder with a bloated multipurpose theme, you can do everything above and land somewhere in the 60s or 70s on mobile. Past that point you are fighting the foundation, and every further gain costs more than the last.

The honest signals that you have hit the ceiling:

• You have done caching, CDN, images and plugin cleanup and mobile is still below 70.
• The theme ships more CSS and JavaScript than your actual content weighs.
• Every design change requires another plugin.
• The site uses a multipurpose theme with demo content imported and never cleaned out.

At that point a rebuild on a lean custom theme, keeping your content, your URLs and your design, is usually cheaper over two years than continuing to pay for optimisation that keeps hitting the same wall. It is also the only version where the result holds, because nothing is fighting the foundation any more.

This is the work I do most and the work I am best at. If you want a view on which side of that line your site sits, send me the URL and I will run the audit and tell you honestly, including when the answer is "your site is fine, spend the money elsewhere".

How to check you got what you paid for

If you hire anyone for performance work, me or anybody else, ask for these four things. A developer who cannot produce them has not done the work properly.

1. Before and after Lighthouse reports, mobile, on the same pages. Not the homepage alone. A category page and a product page, because those are the heavy ones.
2. The three Core Web Vitals numbers specifically, LCP, INP, CLS, not just the overall score. The score is a weighted average and can be moved without fixing what matters.
3. A written list of what changed and why. If a plugin was removed you should know which and what replaced its function.
4. Confirmation that checkout still works. Non-negotiable on a store. Performance work regularly breaks carts, and it is usually discovered by a customer rather than the developer.

Then recheck field data in Search Console after four weeks. Lab scores improve the day the work ships; field data tells you whether real customers felt it.

Related reading

• Why your WordPress site is slow in Dubai, how speed fits into the wider ranking picture
• WordPress vs Shopify for a UAE business, platform choice and what it means for performance
• How much does a website cost in Dubai?
• Web developer in Dubai · WooCommerce developer in Dubai