Speed conversations usually begin with a score out of a hundred and end in an argument about which tool is right. A more useful place to start is the person loading the page. Across the Egyptian accounts we manage, the typical visit comes from a mid range Android phone that is two to four years old, on mobile data, often on a bundle the owner is rationing until payday. That person is not evaluating your Largest Contentful Paint. They are deciding whether the page is worth the wait and the megabytes.
Site speed for MENA audiences is a weight budget, not a score target
Scores move for reasons nobody can explain to a client. Page weight does not. We hold new builds to under one megabyte transferred on a first visit to a content page, and tighter than that for anything sitting behind paid traffic, where every wasted second is money already spent. Write the number into the brief, hold the design to it, and check it on every release, because pages never get heavy in one decision. They get heavy one plugin, one tracking tag and one hero video at a time.
Data cost changes behavior in ways you can see in analytics. Heavy pages get abandoned before the hero image resolves. Autoplaying video on a landing page is not a bold creative choice, it is a bill handed to a stranger. And traffic here has sharp peaks, evenings and the hour around iftar in Ramadan among them, which is exactly when networks are congested and the slowest version of your site is the one most people meet.
The five things that make pages heavy in this market
Images uploaded at camera resolution. A four thousand pixel product photo dropped straight into a content system is the single most common cause of a slow Egyptian site. Resize on upload, serve WebP, set explicit width and height, and lazy load everything below the fold.
Arabic webfonts. Large glyph sets, several weights nobody uses and no subsetting. Load two weights at most, subset them, preload the one used above the fold and set font display to swap so text is readable while the file arrives.
Sliders. Heavy, bad for layout stability, and on mobile almost nobody swipes past the first frame. One well chosen image beats five in a carousel on every metric we track.
Third party scripts. The average site we inherit carries a chat widget, two analytics tags, a heatmap tool, a pixel from a campaign that ended last year and a consent banner that blocks rendering. Audit the container quarterly and delete anything nobody has read a report from.
Hosting distance. A server far from your visitors adds latency to every request before a byte of content moves. Put a content delivery network in front of the site so connections terminate closer to the user. It is one of the few fixes that takes an afternoon and helps every page at once.
Test on the device your customer is holding
A laptop on office fiber tells you almost nothing. Throttle to a slow connection profile, test on a real mid range Android, and judge by field data from actual visits rather than by a lab number, because the slowest third of your audience decides whether the site feels fast. Google now uses those field metrics as a ranking input, but ranking is the smaller half of the argument. The commercial half shows up in bounce rate, in how far paid traffic gets before it gives up, and in checkout completion.
When the problem is a handful of loose scripts, a week of cleanup fixes it. When the template itself is the problem, and on inherited sites it often is, tuning will not save it, and that is a conversation our website and app development team would far rather have in month one than in year three.
