Many bilingual websites are quick in English and noticeably slower in Arabic. The cause is rarely the server alone. Heavy Arabic fonts, duplicated stylesheets, translation plugins that work in the browser and redirects between language versions all add weight that only one audience feels. Improving multilingual website speed means measuring and tuning each language as its own experience.
Speed is part of every web design decision we make, and bilingual sites have specific pressure points. This guide focuses on the front-end and plugin choices that affect Arabic and English pages differently, and complements broader website speed optimization work on hosting and caching.
Measure each language separately
A single speed score for the homepage hides the problem. Test the English and Arabic versions of your key templates independently: homepage, a service or category page, a product or article page, and the contact page.
- Lab tests: run PageSpeed Insights or Lighthouse on each language URL, on mobile settings, and compare Largest Contentful Paint, Cumulative Layout Shift and total page weight.
- Field data: where available, check real-user Core Web Vitals for each language path in Search Console, since lab tests do not capture the phones and networks your visitors actually use.
- Waterfall review: compare the network requests of both versions. Extra font files, stylesheets and scripts on the Arabic page usually stand out immediately.
Record a baseline before changing anything, so you can show which fixes made a difference in each language.
Arabic web fonts: the most common bottleneck
Arabic typefaces contain many more glyphs than Latin ones, because letters change shape depending on their position in a word. Font files are therefore larger, and loading several weights of an Arabic font alongside a Latin font can add a significant download before text appears.
- Limit weights. Most sites need two or three weights at most. Each extra weight is another file. A variable font can cover several weights in one file if the typeface offers one.
- Use WOFF2 and subset. Serve fonts in WOFF2 format and remove character sets you do not use, such as extended Persian or Urdu glyphs if your content is Arabic only.
- Load fonts by script. The CSS unicode-range descriptor lets the browser download the Arabic font only when Arabic characters appear on the page, so English pages do not pay for it.
- Preload carefully. Preload only the main text weight for the language of the page. Preloading every font on every page wastes bandwidth.
- Control swapping. Use a font-display setting that shows text quickly, and match fallback font metrics with size-adjust so text does not jump when the web font arrives. That jump is a common cause of layout shift on Arabic pages.
- Self-host where practical. Hosting fonts on your own domain or CDN avoids an extra connection to a third-party font service.
Choose a translation approach that renders on the server
How translations reach the page has a large effect on multilingual website speed.
| Approach | How it works | Speed effect |
|---|---|---|
| Server-rendered translation plugins | Translated content is stored in your database and served as normal HTML | Pages can be fully cached. Extra database queries are manageable with object caching |
| Proxy translation services | An external service translates and serves pages on its own infrastructure | Adds a dependency outside your control. Performance depends on the provider and configuration |
| Client-side JavaScript translation | A script replaces English text with translations after the page loads | Visitors see English first, then a flash of changing text. Layout shift and slower rendering are common |
For UAE businesses that want Arabic pages to rank and load well, server-rendered translation is the reliable choice. Client-side translation widgets are best avoided for anything beyond a quick internal test.
Keep the translation plugin lean
- Enable only the modules you use. String translation, translation management and media translation each add overhead.
- Avoid scanning and registering every theme and plugin string on every request. Register strings once, then disable automatic scanning.
- Use persistent object caching so repeated lookups between pages and their translations are served from memory.
Stylesheets, scripts and right-to-left layout
RTL layouts need mirrored CSS. How that CSS is delivered matters. Some themes load the full left-to-right stylesheet and then a second RTL stylesheet that overrides it, so Arabic visitors download both. Better options include CSS logical properties, which adapt to text direction automatically, or a build process that generates a separate RTL file served only to Arabic pages.
- Check that Arabic pages do not load both LTR and RTL versions of the same stylesheet.
- Remove duplicate slider, carousel or icon libraries added to fix RTL issues on individual components.
- Mirror directional images and icons with CSS rather than uploading separate files where the image allows it.
- Defer scripts that only matter after interaction, such as chat widgets, and load them the same way in both languages.
Redirects, images and page weight
Small structural choices add up across two languages.
- Avoid language redirects. If the root domain redirects every visitor to /en/ or /ar/, each first visit pays for an extra round trip. Serve a default language at the root, or link directly to language URLs in ads and social profiles.
- Do not redirect by IP or browser. Detection scripts delay the first render and can conflict with caching. Suggest a language instead of forcing one.
- Keep text out of images. Banners with baked-in text need two image files, one per language. Live text over a shared image halves the image work and loads faster.
- Size and compress images per template. Use modern formats such as WebP or AVIF, responsive sizes and lazy loading below the fold on both language versions.
- Move hreflang to the sitemap on large sites. Sites with many languages can list alternates in the XML sitemap instead of the page head, which trims HTML on every page.
Keeping multilingual website speed stable after launch
Speed tends to erode as content editors add sections, fonts and plugins, and on bilingual sites the Arabic version often degrades first because fewer people on the team check it. Build in routine checks.
- Run monthly speed tests on the same set of Arabic and English URLs and log the results.
- Test both languages on a staging site after every theme, plugin or translation plugin update.
- Review new fonts, sliders and third-party widgets before they go live, not after.
- Assign one person to review the Arabic site on a mid-range phone every month.
Frequently asked questions
Why is our Arabic site slower than the English version?
The most common causes are larger Arabic font files loaded in several weights, duplicated LTR and RTL stylesheets, and translation methods that change text in the browser after the page loads. Compare the network requests of both versions in a waterfall view. The extra files on the Arabic page usually point directly to the fix.
Does a translation plugin slow WordPress down?
A server-rendered translation plugin adds some database queries and memory use, but with page caching and persistent object caching the effect on visitors is usually small. Slowdowns tend to come from unused modules, automatic string scanning or under-powered hosting. Keep the plugin configuration lean and measure both language versions after changes.
Should we use Google Fonts for Arabic typefaces?
Google Fonts offers good Arabic typefaces and serves them efficiently, including splitting fonts by character range. Self-hosting the same fonts can still be faster, because it avoids a connection to another domain and gives you full control over preloading and caching. Whichever route you choose, limit weights and check the licensing of any font you use.
Fast pages for every visitor
Multilingual website speed improves when each language is measured and tuned in its own right: lighter Arabic fonts, server-rendered translations, clean RTL stylesheets and fewer redirects. The result is a site where Arabic and English visitors both get fast, stable pages, which supports search visibility and makes it easier for them to contact you.
If one of your language versions feels slower than the other, we would be glad to run a comparison and talk you through what would make the biggest difference.
