International site speed: The Complete 2026 Guide

International site speed is a multivariate problem. A page loading in 1.5 seconds in London may take 6 seconds in Sydney due to geographic latency, cold CDN caches, and larger resource payloads from locale-specific assets. This guide covers the five key areas of international site speed optimization in 2026.

A CDN with global edge coverage is non-negotiable for international sites. Use Vary: Accept-Language to cache separate responses per language and Vary: Accept-Encoding, Accept-Language to prevent cache collisions between compressed variants. Avoid Vary: User-Agent as it fragments the cache too aggressively.

Configure your CDN to pre-warm edge nodes in every target region. For Cloudflare, use Cache Reserve or Argo Smart Routing; for AWS CloudFront, use Origin Shield. Pre-warming should hit each locale's entry points from each regional edge node (Cloudflare, 2025).

If your origin is in a single region (e.g., us-east-1), users in Asia or Australia suffer high TTFB even with a CDN because cache misses trigger cross-ocean origin fetches. Deploy origin servers in at least three continents (Americas, Europe, Asia-Pacific), use a global load balancer, and implement stale-while-revalidate (SWR) caching.

Google's 2025 Web Vitals update confirmed that TTFB thresholds (under 800ms for good) apply equally regardless of user geography. A high TTFB in Brazil from a US-only origin will be scored as "poor" (Google Search Central, 2025).

Core Web Vitals must be tracked per country and per language variant. Google Search Console's Core Web Vitals report in 2025 added a URL group breakdown by country, making it possible to spot regional issues directly.

Key metrics per region: LCP is affected by CDN cache hit rate per region and locale-specific hero images. INP is affected by locale JavaScript bundle size and third-party scripts loaded per region. CLS is affected by locale-specific font loading and ad placement differences across markets.

Set up Real User Monitoring (RUM) with CrUX API integration to collect per-region data programmatically using the country dimension (web.dev, 2025).

Each locale may require different asset sizes and formats. Hero images for a French page may differ from the German variant; ensure all locale-specific images are compressed and served in WebP or AVIF format. Custom fonts should use font-display: swap to prevent invisible text during load. Subset fonts to include only the characters needed for each language; a Latin-only subset is roughly 40KB smaller than a full Unicode set. Extract locale ICU message files into separate chunks rather than loading translations for all 10 languages on every page. Use loading="lazy" on below-the-fold images but ensure the LCP image has loading="eager" and fetchpriority="high" (web.dev, 2025).

Set separate performance budgets per locale. A budget might specify LCP under 2.5 seconds in every target region, TTFB under 800ms from the 90th percentile edge node per region, JavaScript bundle per locale under 150KB (gzipped), and total page weight under 1MB per locale variant.

Enforce budgets in CI/CD using Lighthouse CI to test each locale variant and fail the build if any variant exceeds the budget. Catch international performance problems before deployment (Calic, 2025).

• [ ] CDN configured with Vary: Accept-Language for per-locale caching.
• [ ] Origin servers deployed in at least three global regions.
• [ ] TTFB under 800ms in every target market (measured with CrUX).
• [ ] Core Web Vitals segmented by country in Search Console.
• [ ] Locale-specific images optimized in WebP/AVIF with correct sizing.
• [ ] Font subsetted per language; font-display: swap applied.
• [ ] Performance budgets set per locale and enforced in CI/CD.