Arabic web fonts in production: loading, subsetting and fallback

An Arabic checkout can pass its layout review and still fail when the font request is blocked. A customer name may use a character missing from the subset. Diacritics may shift after an optimization strips positioning data. A late font swap may move the confirmation button just as someone reaches for it.

These are font delivery and shaping problems. Correct direction, accessible controls and sensible wrapping remain necessary, but they cannot repair an incomplete font file. Treat the font as a release artifact with its own coverage policy, build recipe and failure tests.

Cover: SultanByte editorial artwork showing Arabic font delivery, shaping and fallback checks.

The decisions below are product recommendations unless explicitly attributed to a specification or tool. Browser behavior comes from the cited references; your team still owns which visual compromises are acceptable.

Define coverage before reducing the file

Start with the text the product accepts, not the text on today's landing page. Separate fixed interface labels from names, addresses, search results and messages that arrive after deployment. A finite corpus can support a tightly controlled static asset. It is unsafe as the sole coverage definition for dynamic names.

Write down the supported languages and scripts. Arabic support does not automatically establish Persian or Urdu support. Include Latin fragments, the digit forms your product accepts, punctuation and combining marks. Use representative synthetic fixtures rather than exporting customer records into a font build.

The W3C Arabic and Persian Layout Requirements describes context-dependent letter shapes and connections that vary with neighboring letters. It is a layout reference, not a certification that a particular font renders every language correctly. For this release decision, the implication is practical: an alphabet specimen is insufficient evidence.

Ask a fluent reviewer to inspect complete words at the actual interface sizes. Include marked text such as مُسْتَخْدِم, ordinary names, mixed Arabic and English labels, and punctuation beside numbers. Keep the fixture set versioned. When a supported language or content source changes, review the coverage policy before regenerating the font.

Subset the font without removing its shaping

Unicode characters and rendered glyphs are different things. A character may need different glyphs depending on its context. Microsoft's Arabic OpenType development guide describes contextual substitutions, required ligatures, cursive positioning and mark positioning. Its shaping-engine account explains why retaining only the glyph initially mapped to each character is not enough.

Preserve layout closure during subsetting: retain glyphs reached through the OpenType layout features you keep, rather than stopping at the initial character set. Also preserve the relevant positioning data. A subset can contain every requested character and still render badly if its shaping rules have been damaged.

The fontTools subset documentation explains that --no-layout-closure disables that glyph expansion. Its default feature selection includes script-shaping features, while --layout-features='*' retains all features. Missing Unicode characters are ignored by default; --no-ignore-missing-unicodes turns those omissions into build failures.

For a first production subset, keep closure enabled and avoid aggressive feature removal. Do not copy a size-saving recipe that drops mark, mkmk or whole layout tables without understanding the effect. Keeping all features can be a conservative starting point, but it does not recover characters excluded from your input policy.

Record the source font version, tool version, character policy and build options beside the output. Compare the subset against the original using identical fixtures and browser settings. File-size reduction is worth recording, but a smaller artifact does not pass release if joining or mark placement changes unexpectedly.

Keep CSS ranges separate from physical subsets

unicode-range does not cut bytes out of a font. It declares which codepoints a face may serve and helps the browser decide whether that resource is needed. The CSS Fonts Level 4 working draft defines effective coverage as the intersection of that declaration and the font's own character map. Declaring a character cannot manufacture its glyph.

If several rules point at the same complete file, the declarations have not created smaller files. Physical subsetting is a build step. CSS then describes how the resulting resources participate in font selection.

Start with fewer, understandable resources. Only split Arabic and Latin delivery when there is a reason to maintain separate files and matching declarations. Review shared punctuation, marks and mixed text when deciding the boundaries. Do not split a cursive script into arbitrary tiny pieces just because the request waterfall looks tidy.

The example below uses an invented family and file path. Replace both with a verified regular face. It deliberately omits unicode-range: no universal Arabic range list can stand in for your language and coverage policy.

/* Illustrative path and family, not a downloadable font. */
@font-face {
  font-family: "Product Arabic";
  src: url("/fonts/product-arabic-regular.v1.woff2") format("woff2");
  font-style: normal;
  font-weight: 400;
  font-display: optional;
}

.arabic-copy {
  font-family: "Product Arabic", Tahoma, Arial, sans-serif;
}

Those fallback names are candidates to test, not a claim that either is installed everywhere. Define other weights with files that actually contain them. Keep the first integration simple enough that a reviewer can match each CSS face to its deployed artifact.

Choose the loading compromise deliberately

In the specification's display model, swap uses a very short blocking period and permits a later replacement with the downloaded face. optional allows the browser to keep fallback for the page rather than replace already-painted text; the browser may deprioritize or skip the download. Exact timing and browser decisions should not be treated as an application timer.

For body copy and transaction forms, consider optional when the approved fallback is fully usable and late visual replacement is undesirable. Choose swap for selected text when eventual use of the brand face matters enough to accept the change. This is a product tradeoff, not a universal performance ranking. If fallback is unreadable, neither setting fixes the underlying coverage failure.

Chrome's font-display guidance distinguishes keeping text visible from avoiding layout shifts. It also warns that excessive preloading can harm loading performance. Do not preload every weight and subset by habit. Establish which resource the initial view actually needs, then test whether the preload helps that view.

Do not promise zero cumulative layout shift. Choosing optional avoids a late swap in its specified behavior, but it does not stabilize images, asynchronous content or the rest of the page. With swap, inspect differences in line wrapping and component height between fallback and the final font. Treat metric adjustments as measured tuning, not a substitute for checking Arabic marks and text at zoomed sizes.

Approve fallback as a supported appearance

The fallback must cover Arabic. A Latin font that looks close to the brand face is not an adequate fallback plan for Arabic text. Nor does a computed font-family value prove which face supplied each glyph.

Block the custom font request and review the actual page on supported platforms. Inspect customer names, form errors, buttons, mixed-script content and diacritics. The goal is readable, usable text, not pixel identity with the preferred typeface. Allow enough vertical room for the fallback instead of hiding its differences with clipping.

For MENA products, choose device, browser and language coverage from the audience you serve and the devices you support. Include relevant mobile platforms and embedded webviews where they are part of the product. Test delayed and failed requests without assigning a fictional network profile to an entire country. A regional label is not a substitute for evidence about your users.

Visual: SultanByte editorial decision guide, “Keep text readable,” connecting coverage, shaping, loading, fallback and release checks. The cards summarize product recommendations, not a standards conformance test.

Test loading separately from rendering correctness

A warm developer session is a poor place to approve a loading strategy. Use a cold load, a warm repeat visit, a delayed response and a blocked request. Navigate to content that was absent from the initial page. Check that text stays usable while the preferred font is unavailable, then inspect any transition when it arrives.

The CSS Font Loading specification provides useful synchronization tools. document.fonts.ready settles after the relevant loading and layout work completes, but it is not proof that every requested face succeeded. Later content can trigger more loading. document.fonts.check() can return true even for a nonexistent family because fallback needs no new font load.

Use those APIs to coordinate a loaded-state screenshot, not to certify Arabic coverage or shaping. Keep that screenshot separate from the cold-load test: waiting for readiness before every capture can hide the exact transition you need to review. Pair resource inspection with visual comparison and language review.

Release the recipe and the failure state

Give the font release a short acceptance record: approved language coverage, reproducible subset settings, matching CSS declarations and evidence from cold, warm and failed loads. Keep the previous artifact available for rollback. If a subset introduces broken joining, shipping the known-good larger font is preferable to accepting the defect for a smaller download.

Before self-hosting or modifying a font, have the responsible owner check its licensing terms for the intended use. Self-hosting is a delivery choice, not a legal guarantee. This guide does not determine permissions for a particular file.

Approve the release when the preferred font shapes correctly, fallback remains readable, and the chosen loading behavior matches the product decision. Keep those checks attached to future font updates, not just the first Arabic launch.