X Rebuilds Its Web App on One Server, Cutting Slow-Connection Load Times From 22 Seconds to 2.7

YuSMP Group Editorial Team Editorial team, YuSMP Group

The short version

What exactly did X rebuild?

For most of the last decade, X.com ran on rweb, a client-side React app that grew out of the 2017 Twitter Lite progressive web app. Over time, X added two more servers beside it: rweb SSR, which rendered pages for search crawlers, and Jetfuel SSR, a separate server-rendered site for indexable logged-out pages such as events, Communities, Trends and search. A single URL on X.com could therefore be built in three different ways.

Nizipli’s post lists the costs of that setup. The servers drifted, so an SEO fix could land in one and miss the others. Logged-out visitors got the slowest path: their browser downloaded an application shell, then JavaScript, ran it, called the GraphQL API and only then rendered the profile. “The bots got the better deal,” he wrote. The new app serves every audience from one server, with three behaviors decided per request:

X kept its existing URLs and redirects, ported rweb SSR’s URL clean-up rules and rebuilt Jetfuel’s structured data, language alternates and real 404 pages as shared components. Jetfuel SSR was retired on August 1, 2026, and rweb SSR was shut down in early September, which deleted almost 36,000 lines from the old codebase.

How much faster is the new X web app?

In a lab recording made on November 3, 2026 on Lighthouse’s Slow 4G profile, the new app showed a profile’s first post at 2.7 seconds. The old app put up its splash screen at 1.0 second and kept it there until the first post appeared at 23.9 seconds. In separate signed-in benchmarks with a slowed CPU, profiles and posts appeared 8 to 13 times sooner. The Home timeline, which is still rendered only in the browser, improved least: 14.1 seconds versus 24.6.

Several of the fixes are directly reusable by other teams:

• Fewer startup files. Default chunking produced 754 startup files for the signed-in entry. Packing shared modules into three chunks cut that to 182, and the logged-out entry from 582 files to 10.
• Crawler HTML under 2 MB. Long threads produced 2.2–3.5 MB of HTML, past the 2 MB Googlebot reads. An icon sprite and leaner structured data recovered 13–14% on large pages.
• Stylesheet first. Delaying JavaScript until the CSS loaded cut first contentful paint for a logged-out post from 7,216 ms to 1,804 ms in lab runs.
• Less infrastructure. As traffic moved, X halved rweb’s logged-out fleet from 1,400 to 700 instances per data center.

X stresses that these are lab numbers and that real devices and networks will vary. The company also notes a trade-off: the new server does more work before it answers, so time to first byte is slightly higher than on the old app.

How did a small team ship it so fast?

X says fewer than five engineers, working with AI coding agents, built the first version in under six months; more than 20 people have committed to the app since late September. Engineers set the architecture and reviewed every change, while agents ported behavior from the old servers, converted pages and wrote tests. Three controls made that output trustworthy: a shared AGENTS.md file with coding rules, more than 25 workflow “skills” stored in the repository, and custom lint rules, including an “anti-slop” plugin that rejects patterns agents tend to produce. The old servers acted as working specifications, and a parity script compared what Googlebot saw from old and new servers page by page.

What it means for US & EU software teams

The clearest lesson is not “rewrite everything.” It is that separate rendering paths for users, bots and previews quietly multiply SEO bugs and maintenance cost. Many US and EU companies run exactly that pattern: a client-rendered app for users, a prerender service or separate marketing site for crawlers, and ad-hoc handling for social previews. If your title tags, canonicals, hreflang or 404s are fixed in one place and broken in another, X’s experience says consolidation pays for itself.

Second, streaming server rendering is now a mainstream answer to slow mobile networks. Frameworks such as Next.js, Remix and React Router already offer streaming and Suspense, so most teams can get much of X’s gain without building a custom server. The custom work at X, edge-verified crawler detection and payload trimming for Googlebot’s 2 MB limit, matters mainly at very large scale or for pages with long, data-heavy content such as marketplaces, forums and catalogs.

Third, the way X used AI agents is a template for legacy modernization: keep the old system running as the specification, migrate traffic gradually behind feature switches, and turn team conventions into lint rules so agent output can be checked automatically. That lowers the classic risk of a full rewrite, without removing the need for senior engineers to own architecture and review.

How should teams check their own web app now?

1. Count your rendering paths. List every service that produces HTML for users, crawlers and previews, and check whether meta tags, structured data and status codes come from one source.
2. Test on a slow profile. Measure time to first meaningful content on Slow 4G with an empty cache, not only Lighthouse scores on fast office Wi-Fi.
3. Check crawler HTML size. Make sure your largest pages stay well under 2 MB of HTML so search engines see all of the content.
4. Audit startup requests. Count the JavaScript files a page needs before it becomes interactive; hundreds of small chunks cost round trips on mobile.
5. Migrate gradually. If you rebuild, route traffic per path and audience at the edge so you can move users over and back without a big-bang release.

Frequently asked questions

Sources

X Engineering — Rebuilding the global town square from scratch, by Yagiz Nizipli (primary source, November 4, 2026)
The Verge — X says its updated web app is way faster (November 5, 2026)