How I Optimise Next.js Performance for UAE Audiences on Slow Mobile Networks

Last year, a construction company in Abu Dhabi called me panicked. Their Next.js app’s homepage was timing out for users on 3G networks in rural UAE areas, and bounce rates were spiking. After running a Lighthouse audit, I saw the culprit: a 2.8MB JavaScript bundle choking mobile devices.

This wasn’t an isolated case. Over the last 3 years, I’ve optimized 15+ Next.js apps for UAE-based clients, from real estate platforms to luxury transport booking systems. Slow mobile networks aren’t unique to the GCC, but the region’s uneven adoption—5G in Dubai skyscrapers, 3G out in Al Ain—demands compromises many Western developers never face.

Image Optimization Isn't Just About Compression

Early in my career, I naively assumed WebP conversion was enough. A Saudi retail client taught me otherwise. Their homepage had a 1.2MB hero banner that even 5G couldn’t load fast enough in Jeddah’s mobile congestion.

Here’s what worked:

• •Lazy loading every image beyond the fold: Even with WebP, a 500KB image is a problem at 150KBps. loading="lazy" isn’t optional here.
• •Blur placeholders for content below the fold: placeholder="blur" helps users perceive speed. One client’s bounce rate dropped 22% after implementing it.
• •Font optimization isn’t free: The Arabic language support in Next.js’s next/font uses auto-scaling, but I disabled it for a D3.js dashboard. The tradeoff between fidelity and performance was worth it.

Code Splitting: The 3-Year War

Dynamic imports were a revelation until they became a headache. For Tawasul Limo (a luxury transport booking app I built last year), I split the map component and 3rd-party payment widget into separate chunks. Page load time dropped from 7.8s to 3.1s in Sharjah’s network tests.

But there’s a catch. One project had a dynamic() import for a localization helper… which blocked the entire render when Arabic translation loaded late. The fix? A skeleton screen with Suspense. I’ll be real: React’s docs make this sound simpler than it is when dealing with right-to-left (RTL) layouts.

Server-Side Caching ≠ Static Generation

Here’s where I wasted 3 weeks last year: I assumed getStaticProps was magic. A real estate client’s listing pages were rebuilt on every deployment, missing the point of pre-rendering.

The fix:

• •Use revalidate to enable incremental regeneration instead of rebuilding the entire site.
• •Cache API data at the edge with Redis, set regionally (more on that later).
• •Generate static pages with common filters predefined (e.g., "properties in Dubai", "off-plan in Abu Dhabi").

I didn’t get this right the first time. A client’s listing page for Ras Al Khaimah properties timed out during regeneration because I used too many nested Promise.all() calls.

The CDN Argument: Dubai vs. Dusseldorf

A US-based CDN works fine until your users are in Fujairah. For Reach Home Properties, I switched from a New York-based CDN to Cloudflare’s Saudi Arabian Points of Presence (PoPs). DNS lookup time dropped from 320ms to 98ms.

Here’s what that meant:

• •Use next.config.js to set unstable_noStore: Prevents large files from flooding Redis caches in shared enterprise environments.
• •Enable Brotli compression (level 11) in Nginx config. Some of my older Laravel backends didn’t do this by default.
• •Geo-route assets via Route53 latency routing. It’s messy, but users in Kuwait and Bahrain also benefited.

Third-Party Scripts Are a Tax

A Bahraini e-commerce client once asked why their 1MB page weight was tanking performance. The Lighthouse report blamed 5 analytics trackers, a chatbot, and a weather API.

We cut it down:

• •Removed a loyalty widget from the critical path (300KB saved)
• •Replaced the weather API call with a 2KB Web Component that fetched only on mount
• •Delayed the chatbot load until user scroll

The weather widget change alone shaved 1.8s off First Contentful Paint in Riyadh.

The UAE-Specific Hurdles You Don’t See Coming

Localizing Arabic content isn’t just dir="rtl". I once used a high-end SVG animation for a Ramadan promotion site. It worked on iPhones in Dubai, but crashed budget Android devices in Medina. We replaced it with CSS parallax—hacky, but it worked.

Font size creep also kills performance. A Kuwaiti news app I audited loaded 4 full WOFF2 font sets for a single article view. We reduced it to 2 (Arabic + English) with font-display: swap.

The Real Metric: Human Patience

You’ll optimize LCP and CLS all day, but users in the GCC still abandon pages that don’t feel fast. For Greeny Corner (a React Native app I cross-compiled with Expo SDK 54), we used Next.js to prerender SEO content and load the app shell in 1.2s. The difference between a 2.5s page load and a 3s one? 23% higher retention in Saudi Arabia’s Google Analytics data.

This stuff isn’t easy. You’ll mess up a dynamic import, misconfigure a Brotli setting, or rage-quit when font loading breaks an RTL layout. But if you’re optimizing for the 12MBps 4G speeds in Abu Dhabi and the 0.5MBps 3G connections in Hail, compromise isn’t lazy—it’s necessary.

If you’ve ever argued over font face hierarchies at midnight, I’m on sarahprofile.com/contact.