NEW YORK — People opening an X profile on a slow connection could spend less time staring at the platform’s splash screen as the company rolls out a rebuilt website. But the improvement is not uniform: X’s own measurements show a much bigger change for individual posts and profiles than for the Home feed.
Principal engineer Yagiz Nizipli says the new app already serves visitors who are not signed in, along with search-engine crawlers. Signed-in users are moving across one country at a time, with the older website remaining available while the migration continues. X has not provided a completion date in its engineering account.
The distinction matters because the biggest number is not a promise about every visit. X’s headline demonstration cuts the wait for a profile’s first post from 23.9 seconds to 2.7 seconds under simulated slow-network conditions. That measures when useful content appears, rather than when a logo first lights up the screen.
In its engineering report, X describes a November 3 recording made while signed in to the same account on both versions. It used an empty cache, disabled service workers and a connection limited to 1.6 megabits per second downstream, with a 150-millisecond round trip. Each app was recorded three times, and the company used the median run.
Those conditions make the comparison more specific than a general claim that X is now eight times faster. The recording did not slow the processor, and X separately ran broader benchmarks with the processor slowed fourfold. The report explicitly calls the recording a lab illustration and warns that real devices and networks will differ.
The reason for the change is less cosmetic than the splash screen suggests. The previous app sent visitors a largely empty shell, followed by JavaScript that had to download and run before requesting the data needed to display a profile. On a weak connection, each stage added another wait before the first post could appear.
The rebuilt app moves more of that work to the server. It sends page content as streaming HTML, allowing a profile or post to become visible before the browser has downloaded the JavaScript needed for later interaction. Data already fetched by the server travels with the page, rather than being requested again by the browser.
There is a trade-off. X says the new server takes longer to send its first byte on signed-in profiles and posts because it gathers data and renders content before responding. The older app answers sooner, but with a shell that still leaves the browser waiting for something useful. A faster initial response, in other words, is not necessarily a faster readable page.
Home exposes the limit of that approach. X still renders the signed-in Home timeline in the browser, so both versions must wait for JavaScript there. In the separate slow-profile benchmarks, the new Home feed showed its first post after 14.1 seconds, against 24.6 seconds for the old app. Without throttling, the comparison narrowed to 1.8 seconds against 2.2.
Profiles and individual posts improved much more in those tests. X reports that a SpaceX post appeared 12.8 times sooner and its profile 8.2 times sooner under the slower setting. These results came from fresh headless Chromium sessions, seven loads per app and setting, alternating between the two versions. They remain company-run tests on one laptop, not independent measurements of the wider user base.
Behind the browser changes sits a consolidation of systems that had grown apart. X previously maintained separate rendering paths for ordinary visitors, search crawlers and logged-out pages indexed by search engines. Nizipli says this meant a correction to a description, redirect or missing-page response could need to be repeated across different codebases.
The new application handles those audiences through a common server system, while tailoring what it sends. People receive streamed pages; verified search crawlers receive complete documents; link-preview bots receive the titles, descriptions and images they need without the full page body. X says existing URLs, redirects and language alternates have been retained.
That is a continuation of an older ambition, rather than the first attempt to unify the service. In its 2019 account of rebuilding Twitter.com, the company described one responsive codebase for different devices and network conditions. The latest rewrite keeps that principle while changing when and where the page gets its content. X’s engineering changes have also extended to mobile, including X’s Android app rebuild in Kotlin.
X also credits AI coding agents with much of the implementation, including porting behavior, converting pages and writing tests. Engineers set the architecture and reviewed changes, according to the report. That account supports a claim about how this team worked, not a broader conclusion that agents can independently replace the engineers maintaining a service.
For users, availability remains a separate question from the benchmark. X can select who receives the new app through its routing system and move a group back to the older version if problems appear. The company says the old app still serves most signed-in traffic in the comparison described in the report.
The platform also collects real-visit performance measurements, but the published speed comparisons largely come from controlled tests. Its engineering account does not yet establish whether the gains hold across the devices, countries and everyday Home-feed visits that will make up the completed rollout.
