Arabic web fonts slowing down a website, and the measurement

The received wisdom on Arabic sites is that the fonts are the problem. Arabic needs more glyphs, the argument goes, so the files are large, so the page is slow. It is repeated often enough that teams start subsetting before they have measured anything.

So we measured. The numbers below are file sizes we downloaded while writing this, from Google Fonts, in November 2026. They do not support the premise.

What the files actually weigh

Three families, each at weight 400, taking the woff2 files Google Fonts serves and the full variable font from the Google Fonts repository.

Read the first two rows again. For Cairo and Tajawal the Arabic subset is smaller than the Latin subset of the same font at the same weight. The script is not the problem.

The third row is the one that matters, and it is not about Arabic at all. Cairo's full variable font is 599,548 bytes. The Arabic subset is 13,292. That is a factor of forty five, and the difference between those two numbers is the entire argument.

Where the weight really comes from

Four causes, in the order we usually find them. None of them is the alphabet.

• Self-hosting the whole family. Somebody downloaded the font, put the ttf in /assets, and shipped 586 KB to deliver one heading. This is the single most common cause and it is the easiest to fix.
• Loading weights nobody uses. Four weights plus italics, when the design uses two. Each is another request and another file.
• Loading a high-coverage family when a display family would do. Noto Naskh Arabic's Arabic subset is 52,668 bytes against Cairo's 13,292, roughly four times, because it covers far more. If you are setting a marketing page rather than scholarly text, you are paying for coverage you will never render.
• A second Arabic font for headings. Doubles everything above, for a decision nobody can see on a phone.

What the specification already gives you

The mechanism that makes those small subsets possible is unicode-range, and the useful thing is that it is not an optimisation you have to build. Google's guide to reducing web font size describes it as telling the browser which characters a font can be used for, so a font file is downloaded only if the page contains one or more characters in that range. It accepts a single codepoint, an interval or a wildcard, and it notes that nearly all browsers support it.

The same page puts the compression gain on record: WOFF 2.0 uses Brotli internally and offers up to 30 per cent better compression than WOFF. So if you are self-hosting anything other than woff2 in 2026, that is a free reduction before you touch the glyph set.

The relevant caveat is in Google's font best practices: preload ignores unicode-range. Preloading an Arabic font on a page that happens to be in English therefore downloads it anyway, which is a real own goal on a bilingual site.

The font-display table, and what each value costs

This is where Arabic genuinely does get worse, and not for the reason people expect. The fallback stack for Arabic on most systems looks less like the web font than a Latin fallback does, so a swap is more visible and the layout moves further. The published behaviour is specific:

Two facts from that page are worth holding onto. Chromium-based browsers and Firefox block text for up to three seconds when a web font has not loaded, and Safari blocks text rendering indefinitely. That second one is the reason a site can look fine on a Pixel and show nothing on an iPhone on a bad connection.

And optional is stricter than most people realise: text render is delayed for no longer than 100ms, with no swap-induced layout shift, but the web font is skipped entirely if it arrives late. On an Arabic site that is a real trade, because the fallback may be visibly worse than the font you chose.

The three fixes, in order

Do them in this order, because the first one usually removes the need for the rest.

• Stop shipping the full family. Either serve the subsets a font provider already generates, or subset the file yourself to the ranges your pages actually contain. This is the forty-five-times reduction in the table above, and nothing else you do will beat it.
• Cut the weights. Count the weights the design renders, not the weights the brand guide lists. Two is usually the honest answer.
• Set font-display deliberately, per font. Body text and headings do not want the same answer, and the default is not a decision.

If you are arriving here because a page is slow rather than because fonts are a known problem, fonts are not where to start. The order to check things in is in why a website is slow on mobile, and the thresholds any of this gets measured against are in what Core Web Vitals actually measure. If the platform itself is the suspicion, the measured comparison is in static site versus WordPress performance.

What is genuinely harder about Arabic

Having argued the file size down, three things really are harder, and none of them is fixed by subsetting.

• Subsetting by hand is riskier. Arabic letters change shape by position and join to their neighbours, so a subset that drops the wrong presentation forms or breaks the shaping tables produces text that renders but reads wrong. The ranges Google Fonts ships for its Arabic subset include the main block, Arabic Supplement and Extended ranges, the presentation forms blocks and the zero-width joiners. Removing anything from that set is a decision, not a cleanup.
• The fallback is worse. A missing Latin font falls back to something close enough that most visitors never notice. A missing Arabic font often does not, which raises the cost of every value in the table above.
• Bilingual pages pay twice. Two scripts, two subsets, usually two families, and the preload caveat above waiting for whoever adds a performance tweak without reading it.

Legibility belongs in the same conversation rather than after it: text that renders but is hard to read is a different failure with the same cause, and the criteria worth meeting are in what accessibility compliance actually requires.

On the business side of the same question, the commercial read on page experience for Arabic sites, including what Google says about the limits of its ranking effect, is in KF Agency's Arabic article on whether optimising for Core Web Vitals is worth the effort, which is in Arabic.

Honest limits

Three.

These are six files, not a survey. We measured three families at one weight on one day. A different Arabic family, especially one with wide coverage or many stylistic sets, can be far heavier, and the Noto row shows the spread is real. Measure your own files rather than quoting ours.

We did not count glyphs. We measured bytes, because bytes are what the network carries. Google's documentation notes that Latin fonts typically have about 100 to 1,000 glyphs while CJK fonts may have over 10,000, and does not give an Arabic figure. We are not going to supply one we did not count.

None of this says fonts are your bottleneck. On most business sites they are not. Images, third-party scripts and server response time are usually ahead of them, and the honest sequence is to measure before changing anything. If you subset a font and the page is still slow, the font was never the answer.