X says its rebuilt web app can show the first post in 2.7 seconds instead of 23.9 seconds on a simulated slow connection. The interesting part is how: fewer browser round trips, not just faster JavaScript.
What X changed
In a November 4, 2026 engineering report, X described replacing three overlapping web-rendering services with a unified application built around React, Relay/GraphQL, Fastify and Platformatic Watt.
The old logged-out site first loaded a shell, downloaded JavaScript, then fetched profile and post data. The replacement streams useful HTML from the server while data arrives, so visitors can see content before the entire client app finishes loading.
Three audiences, one rendering system
- Visitors: streamed HTML, with data reused during browser hydration.
- Verified search crawlers: complete HTML with structured data and correct status codes, rather than JavaScript placeholders.
- Link-preview bots: lightweight metadata responses instead of rendering an unnecessary page body.
X says crawler identification uses verification at its network edge, not merely a spoofable User-Agent string. It also preserved redirects, canonical behavior, language alternates and 404 handling while migrating.
The performance result—and the caveat
In X’s November 3 lab comparison, using a throttled Slow 4G connection and median runs, the first post appeared at 2.7 seconds in the new app versus 23.9 seconds in the old one. These are X’s measurements, not an independent benchmark; real-world results will vary.
The new application already serves logged-out pages and search crawlers. Signed-in traffic is still migrating country by country, so not everyone sees the same experience yet.
What developers can take away
- Measure the time until meaningful content appears, not just bundle size.
- Remove sequential data-fetching waterfalls where server rendering can supply content earlier.
- Test human, crawler and preview responses for parity during migrations.
- Roll out gradually, with a rollback path and checks for canonical URLs, metadata and HTTP status codes.
A full rewrite is not automatically the right fix: X had multiple rendering stacks to consolidate. Start by profiling your own site’s bottlenecks before changing frameworks.