Every millisecond matters. Google's Core Web Vitals make it official: if your website is slow, you rank lower. If you rank lower, you lose traffic. If you lose traffic, you lose customers.
Adding multilingual support traditionally meant adding server-side processing, larger JavaScript bundles, or slower page loads. In 2026, that tradeoff no longer exists. Edge translation — delivering translated content through a global CDN at the network edge — makes multilingual performance a solved problem.
This article explains how edge translation works, why it outperforms server-side and client-side approaches for multilingual sites, and how LingoJS achieves an average translation delivery time of 26 milliseconds.
The Performance Problem with Traditional i18n
When you internationalize a website the traditional way, you add overhead at every layer of the stack.
Server-side rendering (SSR) with i18n
If your server renders pages with translations, each request triggers locale file loading, message resolution, and template interpolation — before the HTML is sent to the browser. For a Next.js or Nuxt site, this means:
- The server loads the correct locale JSON file from disk (or a remote source)
- The i18n library resolves each translation key against the locale data
- The framework interpolates translations into the component tree
- The rendered HTML is sent to the client
Adding 3 languages to a page with 200 translatable strings can add 50-150ms of server processing time per request — before the first byte reaches the browser.
Client-side i18n bundles
If you ship translations to the browser, every locale adds to your JavaScript bundle. A typical i18next setup with 2 namespaces and 3 languages adds roughly 15-25KB (gzipped) to your client bundle. More languages, more namespaces, more bytes. Users on slow connections or mobile devices pay the cost for languages they will never see.
The worst of both worlds
Some architectures load translations client-side after the page renders, causing a "flash of untranslated content" — the page appears in the source language, then flickers to the user's language after the translation payload arrives. This is a terrible user experience and can negatively impact Cumulative Layout Shift (CLS) scores.
What Is Edge Translation?
Edge translation moves the translation layer out of your application and onto a globally distributed CDN. Instead of your server processing translations or your client loading locale bundles, a lightweight JavaScript snippet running at the edge:
- Detects the user's language from the browser or IP
- Fetches pre-translated content from the nearest CDN edge node
- Applies translations to the page DOM in real time
- Caches everything for repeat visitors
The key insight: translation is a data problem, not a compute problem. You do not need to re-translate the same sentence on every page load. You translate once, cache at the edge, and serve from the node closest to the user.
How LingoJS Edge Translation Works
LingoJS is built from the ground up for edge delivery. Here is the full flow:
Step 1: Script loads (non-blocking)
The LingoJS snippet loads asynchronously from jsDelivr's global CDN. Because it uses the async attribute (or Next.js's afterInteractive strategy), the browser does not wait for it before rendering the page. Your content appears instantly in the source language.
User requests page → HTML renders immediately → LingoJS loads in background
Step 2: Language detection at the edge
LingoJS checks the user's Accept-Language header and IP-based geolocation. The detection happens at the CDN edge, not on your server. The correct language version is identified in single-digit milliseconds.
Step 3: Translation payload delivered from nearest edge node
jsDelivr operates over 750 edge nodes across 6 continents. When a user in Tokyo requests a French translation, the payload comes from the Tokyo edge node — not from a server in Virginia. Round-trip time is typically under 10ms.
Step 4: DOM application
The translation is applied to the page DOM. Text nodes are swapped with their translated equivalents. The operation is batched and uses requestAnimationFrame to avoid layout thrashing. Total DOM application time: under 10ms.
Step 5: Cache persistence
Translated content is cached in the browser's localStorage. On the next page visit, translations load from local cache in under 1ms. The CDN cache also persists across visitors in the same region, so popular language pairs are served from memory at the edge node without touching the origin.
Measured Performance: ~26ms Average
Here is the breakdown of where those 26 milliseconds go:
| Phase | Duration | Location |
|---|---|---|
| Language detection | < 2ms | CDN edge |
| Cache lookup | < 2ms | CDN edge / localStorage |
| Payload fetch | < 10ms | CDN edge (regional) |
| DOM parsing | < 5ms | Browser |
| Text replacement | < 7ms | Browser |
| Total | ~26ms |
This is faster than a single server-side i18n resolution cycle for a moderately complex page.
Core Web Vitals impact
| Metric | Without translation | With LingoJS | Delta |
|---|---|---|---|
| LCP (Largest Contentful Paint) | 1.8s | 1.8s | 0ms |
| INP (Interaction to Next Paint) | 45ms | 46ms | +1ms |
| CLS (Cumulative Layout Shift) | 0.02 | 0.02 | 0 |
| TTFB (Time to First Byte) | 180ms | 180ms | 0ms |
LingoJS adds zero impact to LCP, TTFB, and CLS because the script loads asynchronously after the page renders. The only measurable difference is a ~1ms increase in INP, which is within measurement noise.
Why CDN-Based Translation Beats Server-Side
| Factor | Server-side i18n | Edge translation (LingoJS) |
|---|---|---|
| TTFB impact | +50-150ms per request | 0ms (async) |
| Server CPU | Template interpolation per request | None (offloaded to CDN) |
| Bundle size | +15-25KB per locale | 0KB (external) |
| Geographic latency | Depends on server location | Nearest of 750+ edge nodes |
| Cache efficiency | Per-request server cache | Multi-layer (CDN + browser) |
| Scale | Server handles every request | CDN absorbs cache hits |
Who Benefits Most from Edge Translation?
Content-heavy websites — marketing sites, documentation, blogs, news sites — benefit the most. These sites have lots of text that does not change frequently, making them ideal for edge caching. Translating 50 blog posts into 5 languages through server-side rendering means 250 rendered pages competing for server resources. With edge translation, the CDN handles it.
SaaS dashboards with dynamic data also benefit because LingoJS detects and translates only the static UI elements (navigation, labels, buttons) while leaving the dynamic data (charts, tables, user-specific content) untouched or translated on the fly.
E-commerce stores with thousands of product pages see the biggest win. Translating product descriptions server-side for 10,000 SKUs across 5 languages means 50,000 rendered pages. With edge translation, the product text is translated once, cached at the edge, and served from the nearest CDN node.
Getting Started with Edge Translation
You do not need to configure a CDN, set up edge functions, or manage cache invalidation rules. LingoJS handles all of that.
- Create a free account
- Add one script tag to your site
- Choose your target languages
- Done — your content is translated and served from the edge
The script is delivered through jsDelivr (750+ global edge nodes), translation payloads are cached multi-layer (CDN + browser localStorage), and the average delivery time is 26ms. Your Core Web Vitals stay unchanged, your server stays idle, and your users see translated content with no perceptible delay.
