GitHub, CSS-in-JS yerine CSS Modules'a geçerek sunucu taraflı render süresini %55 azalttı

GitHub, sitesini tarayıcılara daha az değil, daha fazla CSS göndererek nasıl hızlandırdğını anlattı. GitHub Blog'a göre, Primer tasarım sisteminin altında yatan CSS-in-JS altyapısının build zamanında çalışan CSS Modules ile değiştirilmesi, sunucu taraflı render süresini %55, bileşen başlatma süresini %25 azalttı — ve bu değişiklik ürünü görünür şekilde bozmadan hayata geçirildi.

Runtime stilleri ölçeklenmeyi bıraktığında

Primer, düğmelerden bantlara ve breadcrumb'lara kadar GitHub arayüzünün büyük bölümünün arkasındaki bileşen kütüphanesi. GitHub Blog'un anlattığına göre sorun, 2023'te, belirli sayfalardaki bileşen sayıları hızla artmaya başladığında ortaya çıktı. O dönemde kullanılan CSS-in-JS yaklaşımı stilleri runtime'da üretiyor ve topluyordu; bu maliyet her bileşenle birlikte büyüyordu: ilk sayfa yüklemeleri, stiller istemcide başlatıldığı için yavaşlıyor, stil üretimi tarayıcıdan taşındıkça sunucu taraflı render bozuluyor ve sayfalar daha fazla bileşen biriktirdikçe stil güncellemeleri yönetilemez biçimde büyüyordu.

Ekibin vardığı sonuç, herhangi bir alternatifin hem istemcide hem sunucuda runtime stil işlemeyi tamamen ortadan kaldırması gerektiğiydi — ve bunu GitHub'ı bozmadan gerçekleştirmesi gerekiyordu.

Daha fazla CSS, runtime yok

Seçtikleri alternatif CSS Modules oldu. Bileşen stilleri, bileşenin JavaScript kodunun yanında duran sıradan CSS dosyaları olarak yazılıyor; sınıf adları, global selector'ların getirdiği çakışmalardan kaçınmak için varsayılan olarak yerel kalıyor ve her şey sayfanın HTML'iyle birlikte sunulan statik stylesheet'lere derleniyor. Tarayıcı, bir runtime çözümünün üreteceğinden daha fazla CSS indiriyor; ancak sayfa yüklenirken veya render edilirken hiçbir şeyin hesaplanmasına veya enjekte edilmesine gerek kalmıyor.

Bileşen bileşen gerçekleştirilen geçiş

Değişiklik her Primer bileşenine ve aynı şekilde yazılmış her GitHub bileşenine dokunduğu için ekip artımlı olarak migrate etti. Her bileşen için, mevcut stilleri CSS Modules'a çeviren bir dosya eklediler, yeni stilleri bir feature flag'in arkasına aldılar, snapshot'ların CSS-in-JS çıktısıyla eşleştiğini doğrulamak için görsel regresyon testleri kullandılar, sonra da flag'i önce Primer ekibine, ardından GitHub çalışanlarına ve son olarak tüm kullanıcılara açtılar. Eski CSS-in-JS tekniği, ona hâlâ bağımlı olan GitHub kodu için geçiş boyunca çalışmaya devam etti.

Aralık 2024'e gelindiğinde her Primer bileşeni dönüştürülmüştü. GitHub Blog'a göre ölçülen sonuçlar: bir sayfayı sunucu tarafında render etme süresinde %55 ve bir sayfadaki bileşenlerin başlatılma süresinde %25 azalma.

sx prop'unun emekliye ayrılması

Geriye kalan engel, bileşenleri stillendirmek ve özelleştirmek için kullanılan inline nesne mekanizması olan sx prop'uydu. GitHub Blog, ona tasarım token'larına bağlı güçlü TypeScript desteği ve bileşen koduyla rahat bir arada bulunma gibi avantajlar atfediyor — ama aynı zamanda dinamik inline nesnelerin sürüklediği yüksek bir runtime maliyeti ve bir sayfadaki sx kullanan bileşen sayısı arttıkça büyüyen ölçeklenme sorunları da taşıyordu.

İki sorunu birbirinden ayırmak için ekip, migrate edilmiş bileşenlerin sx kabul etmeye devam etmesini sağlayan bir sarmalayıcı paket olan @primer/styled-react'ü geliştirdi. Sarmalayıcı üzerinden import eden kod eskisi gibi davranırken, doğrudan @primer/react'ten import eden kod performans kazançlarını anında elde etti.

Şirket genelindeki temizlik, Nisan 2025'te yaklaşık 7.760 sx prop'unun migrate edilmesiyle başladı ve Mayıs 2026'da tamamlandı. Mühendis Ian Sanders, prop bazlı dönüşümlere yardımcı olmak için bir VS Code eklentisi geliştirdi; dahili bir codemod ise dosyaların tamamını halletti. GitHub Blog bu işi büyük ölçüde otomatikleşmiş, ancak manuel gözetim ve dikkatli doğrulama gerektiren bir çaba olarak tanımlıyor. Nedenia dönüşümlü görev yapan sekiz mühendis altı ayda 6.419 prop migrate etti; sunucu taraflı render süresi sayfaya bağlı olarak %1 ile %22 arasında iyileşti. Çalışma Nisan 2026'da yeniden başladığında, son 895 prop iki kişilik bir ekibe sadece üç hafta sürdü. Bu süreçte styled-components'in bakım moduna geçtiğinin duyurulması, ekip tarafından bu yöndeki kararın dışarıdan gelen bir teyidi olarak okundu.

Neden önemli

Bu yazı, uzun süredir süren CSS-in-JS tartışmasına somut ve ölçülmüş bir argüman: GitHub'ın ölçeğinde runtime stil üretimi, onun yerine geçen daha büyük statik yükten daha maliyetliydi. Daha az byte daha hızlı site demektir gibi her zamanki sezgi burada tersine dönüyor — build zamanında üretilen daha fazla CSS göndermek, render ve başlatma metriklerinde kesin bir üstünlük sağladı.

Aktarılabilir dersler migrasyon mekaniğinde yatıyor. GitHub, platform genelindeki bir değişiklik için tasarım sistemini araç olarak kullandı; üretimi istikrarlı tutmak için feature flag'ler ve görsel regresyon testlerinden yararlandı; bağımlı uygulama kodunun ilerlemeyi engellememesi için bir uyumluluk shim'i geliştirdi ve binlerce çağrı noktasının uzun kuyruğunu otomatikleştirmek için codemod'lar ile editör araçları kullandı. Benzer bir şekilde runtime stillendirmeden uzaklaşmayı değerlendiren herhangi bir web ekibi için GitHub'ın rakamları — sadece birkaç yüzde kazanan sayfalar dahil — hem getirinin hem de gereken emeğin gerçekçi bir resmini sunuyor.