Site speed reports have a habit of arriving as a red score with no explanation, which sends teams chasing whichever number is easiest to move rather than whichever problem is costing them enquiries. Core Web Vitals are more useful than that if you read them as three separate questions about the visitor’s experience: did the page appear quickly, did it respond when touched, and did it stay still while being read. Answering those honestly usually points at a handful of causes, not a hundred.
What the three measures actually describe
The first concerns loading — how long a visitor waits before the main content is visible. The second concerns responsiveness — the delay between tapping something and seeing the interface react. The third concerns visual stability — whether content jumps around as images and adverts arrive. All three are experienced, not theoretical, which is why field data from real visitors is more trustworthy than a single lab test on a fast connection.
Lab data and field data are not interchangeable
A test run from a desktop on office wifi tells you what is possible. Field data tells you what is happening. If your audience is largely on mobile networks and mid-range devices — which describes a great many UAE sites — the gap between the two can be substantial. Trust the field data for decisions and use lab tools for diagnosing what to change.
Why UAE sites fail these tests so often
The causes repeat across projects with striking consistency:
- Uncompressed hero images, frequently uploaded straight from a camera or a designer’s export.
- Multiple webfonts, often including separate Arabic and Latin families with several weights each.
- Marketing tags accumulated over years, with nobody able to say which ones are still in use.
- Slider and animation libraries loaded on every page to serve a component that appears on one.
- Servers or CDN configurations located far from the audience, adding latency before anything is even sent.
Fix in the order that pays
Sequence matters, because the cheap fixes often remove the need for the expensive ones.
- Audit and compress images, serve modern formats, and set explicit dimensions so nothing shifts on load.
- Reduce font families and weights, and make text visible while fonts are still downloading.
- Remove tags and scripts nobody can justify, then defer whatever survives that review.
- Move rendering work off the critical path — load below-the-fold components only when needed.
- Check hosting and caching, including edge delivery for visitors across the GCC.
- Re-measure with field data over a few weeks before deciding whether deeper work is warranted.
Who owns which fix
Performance stalls when it belongs to everybody. Assign it explicitly.
| Cause | Typical owner | Effort |
|---|---|---|
| Oversized images | Content team, with a build-time safeguard | Low |
| Font loading strategy | Front-end developer | Low |
| Third-party marketing tags | Marketing, with developer review | Medium |
| Layout shift from adverts or embeds | Front-end developer | Medium |
| Server response time | Hosting or platform team | Higher |
Keeping the gains
Performance regresses quietly. A page rebuilt for a campaign, a new tracking script, a plug-in update — any of these can undo a quarter of careful work. Two habits prevent most of it. First, set a page weight budget for key templates and check it as part of release, so a regression fails before it ships. Second, keep field data visible somewhere the team already looks, rather than in a tool that is only opened when something feels slow.
Where this connects to revenue
Faster pages help search visibility, but the more direct effect is on behaviour. Visitors on mobile connections abandon slow pages before they have seen your proposition, and a form that stutters on tap loses people who were ready to enquire. Treat performance as part of the conversion path rather than a technical hygiene score, and it becomes much easier to fund.
Start here
Pull the field data for your three highest-traffic templates and identify which of the three measures is weakest on each. Fix only that one thing per template, then re-measure after a fortnight. This narrow approach beats a general clean-up because it produces evidence — and evidence is what gets the next round of work approved.
