X, 4 Kasım'da x.com'un yeniden inşasını anlatan bir mühendislik yazısı yayımladı ve yazıdaki ilk sayı işin çoğunu görüyor. Kısıtlanmış bir bağlantıda eski web uygulaması ilk gönderi görünene kadar 22 saniyeden fazla bekletiyordu. Yenisi 2,7 saniyede yapıyor.
Baş mühendis Yagiz Nizipli'nin yazısı nedenini açıklıyor. x.com üç sunucu çalıştırıyordu: rweb uygulamayı tarayıcıda render ediyor, rweb SSR arama motoru tarayıcıları için render ediyor, Jetfuel SSR ise indekslenen çıkış yapmış sayfalar — etkinlikler, Spaces, Communities, Trends, haber makaleleri — için ayrı bir sunucu taraflı site sunuyordu. Her biri işini iyi yapıyordu. Sorun, tek bir URL'nin üç farklı biçimde inşa edilebilmesi, her SEO düzeltmesinin üç kod tabanına inmesi gerektiği ve çıkış yapmış ziyaretçilerin — yani insanların — en yavaş yolu almasıydı: önce uygulama kabuğu, sonra JavaScript, sonra GraphQL isteği, sonra render. Tarayıcılar bitmiş HTML alıyordu. İnsanlar almıyordu.
Yeni uygulama üç kitleye de tek sunucudan hizmet ediyor: Vite ve Rolldown, streaming sunucu render'ı ve Suspense ile React, istek hattı olarak Fastify, Platformatic Watt üzerinden worker thread'lerde Node.js 26, GraphQL ile Relay ve XDS adlı kendi bileşen kütüphanesi. TypeScript, TypeScript derleyicisinin Rust portu olan `tsrs` ile denetleniyor.
Tek sunucu nasıl karar veriyor
İnsanlar streaming HTML alıyor: kabuk hemen, sayfanın her parçası verisi geldiğinde ve sunucunun aldığı her GraphQL yanıtı sayfada bir kez taşınıyor; böylece tarayıcı tekrar sormadan onu yeniden oynatabiliyor. Doğrulanmış arama motoru tarayıcıları hiç hydrate olmayan eksiksiz bir doküman alıyor: istemci paketi yok, router durumu yok, yer tutucu yok. Doğrulama edge'de tarayıcının User-Agent başlığına değil IP adresine bakılarak yapılıyor. X'in iki gerekçesi var: başlık kontrolü Lighthouse koşularını da pahalı yola sokardı ve herkes başlıkta yalan söyleyerek o yolu isteyebilirdi. Slack, iMessage, Discord, WhatsApp ve benzerlerinin link önizleme botları yalnızca başlık, açıklama ve kart görselini alıyor; sayfa gövdesi tamamen atlanıyor. Kendini tarayıcı olarak tanıtan başka her şey, çıkış yapmış bir ziyaretçinin aldığının aynısını alıyor.
Sayılar
3 Kasım'da aynı hesapla giriş yapılarak kaydedilen laboratuvar karşılaştırması — Lighthouse'un Slow 4G profili, boş önbellek, service worker kapalı: yeni uygulama sayfayı 2,4 saniyede, ilk gönderiyi 2,7'de gösteriyor; rweb splash ekranını 1,0'da gösterip ilk gönderi 23,9'da gelene kadar tutuyor. Sayfalar genelinde, giriş yapmış profiller ve gönderiler yavaş bağlantıda 8 ila 13 kat daha erken geliyor. En az kazanan Home: yeni uygulama giriş yapmış akışı yalnızca tarayıcıda render ettiği için 24,6 yerine 14,1 saniye. İlk gönderiden önce indirilen JavaScript'te rweb 3,0–3,6 MB sıkıştırılmış veri taşıyor; yeni uygulama profil ve gönderide hiç taşımıyor — çünkü gönderi zaten HTML'in içinde — Home'da 1,9 MB. Tam sayfa yüklemesinde yeni uygulama 1,3–2,3 MB indiriyor, rweb 4,1–4,8 MB.
Asıl kazanç altyapıda. Çıkış yapmış rweb filosu veri merkezi başına 1.400'den 700 örneğe, rweb SSR 2.400'den 1.200'e indi ve sonra kapatıldı. Tarayıcı trafiği önce taşındı: Jetfuel SSR 1 Ağustos'ta devreden çıktı, Eylül başında yeni uygulama tüm tarayıcı yükünü aldı ve rweb SSR de onunla gitti; yalnızca onun deploy ve build hattının kaldırılması rweb'den yaklaşık 36.000 satır sildi. Jetfuel'in render ve görsel servisleri Eylül ortasında kendi deposundan çıkarıldı.
Arama motorları her şeyi fark ettiği için ekip eski sunucuları şartname olarak aldı ve aynı yolu iki sunucudan doğrulanmış Googlebot olarak isteyen bir parity betiği yazdı: durum kodu ve yönlendirme, başlık, açıklama, canonical, robots etiketleri, Open Graph ve X kart etiketleri, dil alternates sayısı ve yapısal veri tipleri karşılaştırıldı. Googlebot bir yanıtın yalnızca ilk 2 MB'ını okuyor; uzun thread'ler 2,2–3,5 MB'a çıkıyor ve kesme noktasından sonraki yanıtlar, onlara işaret eden yapısal verilerle birlikte kayboluyordu. Üç değişiklik çözdü: gönderi başına yedi satır içi aksiyon ikonu yerine build sırasında üretilen bir ikon sprite'ı (@elonmusk profilinde 165 KB, uzun bir thread'de 340 KB tasarruf), yinelenen fotoğraf yapısal verisinin tekilleştirilmesi (fotoğraf ağırlıklı thread'de 450 KB) ve yalnızca JavaScript çalıştıktan sonra anlamlı çıktının çıkarılması (54 KB).
Beş mühendis, çok fazla ajan işi
İlk sürüm, yapay zekâ kodlama ajanlarıyla çalışan beş mühendis tarafından altı aydan kısa sürede yapıldı; Eylül sonundan bu yana 20'den fazla kişi commit'ledi. Hızdan daha ilginç olan, bunun nasıl güvenli hale getirildiği. Depo kökündeki bir `AGENTS.md` kuralları koyuyor: adlandırılmış export'lar, barrel dosya yok, dış veriyi güven sınırlarında doğrula, lint, typecheck ve ilgili testler geçmeden hiçbir şey commit'lenmez. 25'ten fazla tekrar eden iş akışı kodun yanında skill olarak duruyor. Özel oxlint eklentileri Relay kullanımını, Tailwind sınıflarını, testleri ve çevirileri denetliyor; bunlara ajanların üretmeye eğilimli olduğu kalıpları reddeden bir "anti-slop" eklentisi de dahil: zincirlenmiş tip iddiaları, `unknown` tipli parametreler, boş nesnelerin koşullu spread'i. Pre-commit kancası her değişikliği biçimlendiriyor, lint'liyor ve tip denetiminden geçiriyor.
Göç ajanlara tam da eski sunucular çalışan şartnameler olduğu için uygundu. Bir ajan rweb SSR'ın bir URL'yi nasıl işlediğini okuyabiliyor, davranışı port edebiliyor ve bir testle sabitleyebiliyordu; inceleyen de sonucu orijinalle karşılaştırabiliyordu. Nizipli insanlar için kaymayı açıkça anlatıyor: kod yazmaya daha az, sistemin ne yapması gerektiğine karar vermeye ve sonra gerçek bir tarayıcıda gerçekten yaptığını kontrol etmeye daha çok zaman.
Dağıtım edge yönlendirmesi ve bir feature switch üzerinden, ülke ülke ilerliyor; her grup deploy gerektirmeden geri alınabiliyor. rweb herkes taşınana kadar açık kalıyor — bu da Nizipli'nin kendi aktardığı itiraza doğrudan yanıt: Joel Spolsky'nin büyük yeniden yazımların, eski ürün ilerlemeye devam ettiği için tıkandığı uyarısı. Burada eski ürün ilerlemeye devam etti ve ajanlar yarışı kısalttı.
