HTTP/2 Push Neden Bitti, Yerine Ne Geldi?

HTTP/2 Push'ın çözmeye çalıştığı sorun

Amaç, istemci henüz HTML'i işlerken kritik kaynakların geç keşfedilmesi sorununu önden aşmaktı. Tarayıcı normalde HTML'i okur, sonra stil dosyasını, script'i ve görseli sırayla fark eder. Bu keşif zinciri gecikirse görünür akış da yavaşlar.

Server Push ise sunucu tarafına "ben bu sayfada birazdan şu dosyaların gerekeceğini biliyorum, beklemeden göndereyim" yetkisi veriyordu. Yani sunucu istemcinin adına erken karar almaya çalışıyordu. Teoride bu, özellikle render blocking kaynakların daha erken gelmesini sağlayarak ilk ekranı hızlandırabilirdi.

Sorun şuydu: sunucu, tarayıcının o anki gerçek durumunu her zaman bilemez. İşte bütün kırılma burada başladı.

Kâğıt üstünde neden çok iyi görünüyordu

Çünkü keşif gecikmesi web performansının gerçek bir problemiydi. Bir font dosyası, hero görseli ya da kritik CSS ancak HTML işlendikten sonra fark ediliyorsa, kullanıcı gereksiz bekleme yaşar. Sunucunun bunu önceden bilip önden göndermesi kulağa doğal çözüm gibi geldi.

Özellikle aynı şablonun tekrarlandığı sayfalarda, "hangi dosyaların kritik olduğu belli" varsayımı cazipti. Sunucuya biraz inisiyatif verildiğinde, kritik kaynakların görünür akışı hızlandıracağı düşünüldü. Ancak gerçek kullanıcı dünyasında her ziyaret aynı değildi: cache durumu farklıydı, cihaz farklıydı, ağ farklıydı, hatta bazen aynı sayfanın varyantı bile farklıydı.

En büyük problemlerden biri: cache bilgisizliği

Tarayıcı bazı kaynakları zaten elinde tutuyor olabilir. Sunucu bunu her zaman sağlıklı biçimde bilemediği için, gereksiz push gönderimi ortaya çıkabiliyordu. Yani kullanıcı zaten cache'te bulunan bir dosya için ağ ve bant genişliği tekrar harcanabiliyordu.

Bu durum özellikle iyi çalışan bir browser cache stratejisi olan yapılarda daha belirgin hale geldi. Push mekanizması, "yardımcı olayım" derken bazen zaten çözülmüş bir probleme tekrar maliyet bindirdi. Bu da teorik kazancı pratikte eritebiliyordu.

Bir optimizasyonun en büyük zafiyeti, ihtiyaç olmayan yerde çalışmasıdır. HTTP/2 Push tam da bu tuzağa sık düştü.

Öncelik yönetiminin kontrolden çıkması

Sunucu, kritik olduğunu sandığı kaynağı önden göndermeye başladığında, tarayıcının kendi öncelik mantığıyla yarışmaya başlıyordu. Oysa tarayıcı görünür alan, cihaz durumu ve o anki iş akışı hakkında daha bağlama yakın bilgiye sahiptir. Sunucunun bu alanı tahminen yönetmesi her zaman avantaj üretmedi.

Bir kaynağı erkenden itmek, diğer gerçekten kritik isteklerin şeridine girmek anlamına gelebiliyordu. Üstelik bu müdahale her kullanıcı için aynı sonuç vermiyordu. Bazı ağlarda fayda gibi görünen davranış, başka koşullarda sadece gürültüye dönüşebiliyordu.

İşte bu yüzden "erken gönderelim, garanti olsun" mantığı uzun vadede güven vermedi. Sunucunun iyi niyetli tahmini, tarayıcının gerçek zamanlı kararı kadar isabetli olmadı.

Gerçek dünyada beklendiği kadar kullanılmamasının nedeni

Çünkü sistem karmaşıklaştıkça ölçüm de yönetim de zorlaştı. Hangi dosyanın push edileceği, bunun hangi varyant sayfada geçerli olduğu, cache ile nasıl çakıştığı ve farklı cihazlarda nasıl davrandığı sürekli test edilmek zorundaydı. Çoğu ekip için bu bakım maliyeti, sunduğu faydadan daha yüksek hale geldi.

Ayrıca modern performans yaklaşımı giderek daha görünür ve daha kontrollü sinyallere kaydı. Sunucunun istemci adına kör karar vermesi yerine, tarayıcıya daha şeffaf ve daha sınırlı ipuçları vermek tercih edildi. Bu geçişte resource hint yaklaşımı daha güvenilir bir çerçeve sundu.

"Neden bitti" sorusunun kısa cevabı

Çünkü mekanizma pratikte çok sık yanlış kaynak, yanlış zaman ve yanlış öncelik problemi üretti. Cache bilgisiyle zayıf ilişki kurdu, tarayıcının öncelik mantığıyla çatıştı ve ölçülmesi ile sürdürülmesi beklenenden daha zor oldu.

Chromium tarafında da bu yüzden HTTP/2 Push beklendiği kadar değer üretmediği kabul edildi ve Chrome 106 döneminde varsayılan kullanım fiilen kapatıldı. Bundan sonrası "daha akıllı push" arayışı değil, daha şeffaf yönlendirme arayışı oldu.

Yerine gelen yaklaşım

Tek bir sihirli halef yok. Ama en güçlü iki çizgi öne çıktı: `preload` gibi istemciye daha açık öncelik sinyalleri ve `103 Early Hints` gibi cevaptan önce ipucu verme yaklaşımı.

`preload`, geliştiricinin belirli bir kaynağın gerçekten kritik olduğunu açıkça işaretlemesine izin verir. Böylece tarayıcı, kaynağı öne alırken yine kendi öncelik sistemi içinde kalır. Bu yönüyle, sunucunun kör push kararından daha kontrollü bir model sunar.

`103 Early Hints` ise ana yanıt gelmeden önce belirli sinyalleri erkenden iletmeye yarar. Yani push'taki gibi dosyayı zorla itmek yerine, istemciye daha erken bilgi vermeye yaklaşır. Bu model daha görünür, daha ölçülebilir ve tarayıcıyla daha uyumlu kabul edilir.

"Yerine HTTP/3 geldi" dememek gerekir

Çünkü burada karıştırılan iki farklı konu var. HTTP/3, taşıma ve teslimat katmanında önemli iyileştirmeler getiren daha yeni bir protokol yaklaşımıdır; ama HTTP/2 Push'ın birebir mantıksal halefi değildir. Yani biri "daha yeni sürüm", diğeri ise "sunucunun istemciden önce kaynak itmesi" fikridir.

Uygulamada da sektör yönü bu tarafa dönmedi. Sunucu push fikri yeni protokol katmanında geniş ölçekli bir kurtarma hikâyesi yaşamadı. Bunun yerine daha kontrollü, tarayıcıyla daha uyumlu sinyal modelleri öne çıktı. Yani konu "HTTP/2 Push kaldırıldı, HTTP/3 aynı işi devraldı" diye okunmamalıdır.

Bu ayrım özellikle performans tartışmalarında önemlidir. Protokol yükseltmek ile yanlış öncelik stratejisini düzeltmek aynı iş değildir. Yeni protokol bazı ağ maliyetlerini azaltabilir; ama yanlış kaynak tahmini sorununu tek başına çözmez.

Bakım maliyetinin belirleyici olması

HTTP/2 Push'ın asıl zayıf noktalarından biri, sürekli doğru tutulması gereken bir karar setine dayanmasıydı. Hangi sayfada hangi kaynak push edilecek, bu karar mobilde de aynı mı kalacak, cache davranışı değişince ne olacak, şablon varyantı oluşunca hangi liste güncellenecek; bunların hepsi operasyonel yük haline geldi.

İlk bakışta küçük görünen bu yük, gerçek projelerde hızla büyüdü. Kampanya sayfası değişti, üst alan görseli yenilendi, font seti daraltıldı, üçüncü taraf servis kaldırıldı; ama push kararları aynı kaldıysa optimizasyon kısa sürede eskidi. Bu da mekanizmayı canlı tutmayı maliyetli hale getirdi.

Oysa `preload` ya da `103 Early Hints` gibi yeni yaklaşımlar, tarayıcıya daha açık ve daha lokal sinyaller verdiği için bakım tarafında daha az sürpriz üretiyor. Yani sadece teknik doğruluk değil, sürdürülebilirlik de tercih değişiminde büyük rol oynadı.

103 Early Hints'in tarayıcıyla daha uyumlu olması

Çünkü dosyayı zorla itmek yerine, istemciye erken ama daha okunabilir sinyal veriyor. Tarayıcı bu sinyali kendi öncelik sistemiyle birlikte değerlendirebiliyor. Yani sunucu "senin adına kararı verdim" demektense, "işine yarayabilecek kritik bir bilgi veriyorum" demiş oluyor.

Bu fark küçük görünse de pratikte çok büyüktür. HTTP/2 Push'ta tarayıcının elinde olan cache bilgisi ve gerçek zamanlı öncelik mantığı geriden geliyordu. Early Hints modelinde ise istemci tarafı daha çok kontrolü elinde tutar. Bu da kaynak seçimini daha esnek ve daha bağlama duyarlı hale getirir.

Aynı nedenle `preload` da daha güvenilir görünür. Çünkü kritik kaynağı işaretlersiniz ama yine de tarayıcıyla ortak çalışırsınız. Bu model, kör push mekanizmasına göre daha modern ve daha ölçülebilir bir öncelik yönetimi sunar.

Preload ve Early Hints'in daha sağlıklı görünmesi

Çünkü kaynak seçiminde daha şeffaflar. Sunucu dosyayı doğrudan dayatmak yerine, tarayıcıya erken bilgi verir veya geliştirici kritik kaynağı açıkça işaretler. Böylece karar mekanizması daha izlenebilir hale gelir.

Ayrıca tarayıcının öncelik yönetimiyle daha uyumlu çalışırlar. HTTP/2 Push, "bunu al" hissi veriyordu. Yeni yaklaşım ise daha çok "bu önemli olabilir, önceliği buna göre kur" mantığına yaslanır. Bu fark küçük görünür ama pratikte çok büyüktür.

Özellikle üst alandaki kritik kaynaklar için doğru `preload`, yanlış bir push denemesinden daha güvenli ve daha öngörülebilir sonuç üretir.

Preconnect ve DNS Prefetch'in tablodaki yeri

Bunlar HTTP/2 Push'ın birebir yerine geçen mekanizmalar değildir; ama aynı genel hedefin, yani kaynak teslimatını daha erken ve daha doğru hazırlama çabasının parçalarıdır. Özellikle dış origin gecikmesi hissediliyorsa, preconnect ve DNS prefetch farkını doğru kurmak daha sağlıklı sonuç verebilir.

Buradaki kritik ayrım şudur: push doğrudan kaynağı itmeye çalışıyordu. Preconnect ve DNS prefetch ise bağlantı ya da çözümleme hazırlığını erkene alır. Yani tarayıcının yerine karar vermez, tarayıcının kararını daha uygun zemine taşımaya çalışır.

Bugün daha mantıklı olan yaklaşım

İlk adım, gerçekten kritik kaynağı netleştirmektir. Hangi dosya üst ekranı etkiliyor, hangisi sonraki adım için gerekli, hangisi üçüncü taraf bağlantı maliyeti yüzünden geç geliyor; bunlar ayrılmadan araç seçimi yapmak doğru değildir.

Ardından daha kontrollü araçlara yönelmek gerekir:

• Preload: Yakında kesin gerekecek kritik kaynaklar için.
• 103 Early Hints: Kritik sinyali ana yanıttan önce iletmek için.
• Preconnect / DNS Prefetch: Dış origin hazırlığını erkene taşımak için.

Bu yaklaşım, hem sunucu tarafını daha öngörülebilir kılar hem de tarayıcıyla çatışmadan öncelik yönetimi kurmanızı sağlar.

Konunun hâlâ karıştırılma nedeni

Çünkü hepsi erken hızlandırma fikrine yakındır ve ilk bakışta benzer görünür. "Kaynağı erkene çekmek" cümlesi altında preload, preconnect, DNS prefetch ve geçmişte push aynı sepete atılabiliyor. Oysa aralarındaki en büyük fark, tarayıcıya ne kadar alan bıraktıklarıdır.

HTTP/2 Push daha buyurgan bir modeldi. Yeni yaklaşım ise daha işaretleyici ve daha ölçülebilir. Bu fark netleştiğinde, neden onun bittiği ve neden yenilerin tercih edildiği de daha kolay anlaşılır.