Technical
Page speed and Core Web Vitals for Arabic sites: what matters on mobile
Ilyes Massoudi7 min readThe short answer
Site speed is measured by three metrics Google relies on: LCP, the time until the largest element on screen appears, which should stay within 2.5 seconds; INP, the page's response time to a tap, within 200 milliseconds; and CLS, how much elements jump during loading, within 0.1. They are measured from real users on mobile in the Page Experience report in Search Console, not from a lab score. On Arabic sites the first two causes are heavy Arabic web fonts and uncompressed images, and fixing both improves LCP directly.
Why mobile, and why the Gulf specifically
The overwhelming majority of visits to Gulf websites come from a phone, many over mobile networks rather than wifi, and from inside Instagram, Snapchat and WhatsApp, whose in-app browsers are slower. A page that feels fast on an office desktop over fibre is an entirely different page on a phone in a car.
That is why everything in this article is measured on mobile from real users. A lab test on a desktop tells you the causes; it does not deliver the verdict.
The three metrics, in a business owner’s language
Google condenses the speed experience into three numbers it calls Core Web Vitals:
| Metric | What it measures | Good threshold | What it means to the visitor |
|---|---|---|---|
| LCP | Time until the largest visible element appears: the main heading or the cover image | 2.5 seconds or less | “Has the page started to show?” |
| INP | The page’s response time to any tap or click | 200 milliseconds or less | “Does the button work when I touch it?” |
| CLS | How much elements jump while loading | 0.1 or less | “Did the button move under my finger?” |
The verdict is based on what 75% of real visitors experience. A page meeting the thresholds for three quarters of its visitors counts as good.
Where to measure
The Page Experience report in Search Console. It shows your pages classed as good, needs improvement, or poor, on mobile and desktop, from real-user data. This is the verdict.
PageSpeed Insights. Paste one page URL. The top section is real-user data for the page, or for the whole site if the page has few visits. The bottom section is a lab test with a score out of 100 and a list of causes ordered by impact. Read the top for the verdict and the bottom for the causes.
Never judge by the score. A site scoring 40 with green real-user metrics is fine; a site scoring 90 with red metrics is not.
The first cause on Arabic sites: the font
This is what English checklists never mention. An Arabic font, with its connected letterforms, weighs twice a Latin one, and the typical site loads four weights of it on every page before drawing the main heading. The result is a late LCP whatever the hosting.
What to ask the developer for:
- Two weights only: regular and bold.
- WOFF2 format, subset to the Arabic letters, numerals and basic Latin.
font-display: swapso text shows in a system font until the web font arrives.- A preload for the font that draws the main heading only.
- A ceiling of 60 KB per weight.
This item alone moves many Arabic sites from “poor” to “good” on LCP.
The second cause: images
A 4 MB studio cover image on every page, and product photos at the camera’s original size. What to ask for:
- WebP or AVIF instead of JPG and PNG.
- Dimensions sized for mobile, not a 4,000-pixel-wide image shrunk in the browser.
- A ceiling of 200 KB for a normal image and 150 KB for the first cover image.
- Lazy loading for images below the first screen, never for the first image.
- Explicit dimensions for every image in the code so elements do not jump as they load, which fixes CLS.
The third cause: scripts
Chat widgets, ad pixels, embedded maps, a second and third analytics tool, theme add-ons. Every script delays the response to a tap and raises INP. Ask for a list of every script on the page and the reason it is there, delete whatever cannot answer “what decision does this help me make?”, and defer the rest until after the first interaction.
The fourth cause: hosting and time to first byte
If the server’s time to first byte stays above 800 milliseconds after all of the above, the problem is hosting or missing caching. The fix: page caching, a content delivery network with a node near the Gulf, and hosting that does not share its server with hundreds of sites. This item comes last, not first.
What to ask the developer for, in order
| Priority | Item | Expected effect |
|---|---|---|
| 1 | Font: two weights, WOFF2, preload for the heading | LCP |
| 2 | First cover image: WebP, under 150 KB, no lazy loading | LCP |
| 3 | Explicit dimensions for every image and ad | CLS |
| 4 | Remove unnecessary scripts and defer the rest | INP |
| 5 | Caching and a content delivery network | Time to first byte |
Send this table to the developer as it is, then measure again after 28 days, because real-user data accumulates over 28 days and does not change the next morning.
This site as a sample
The site you are reading is built with a performance budget that fails the build if exceeded: two fonts of limited weight, a cover image under 160 KB, and few scripts. Test it in PageSpeed Insights yourself; anyone selling SEO with a slow site exposes themselves faster than any testimonial. In the Digital Presence Audit, mobile speed from real-user data is a fixed item in the technical diagnosis, with the causes listed in order for the developer.