15kB’lık bir sayfaya kıyasla 14kB’lık bir sayfa çok daha hızlı yüklenebilir (2022)

• Bir web sitesinin boyutunu 14kB’ın altında tutmak, 15kB olduğuna kıyasla yükleme hızını önemli ölçüde artırabilir
• Bu durum TCP slow start algoritması nedeniyle ortaya çıkar; ilk veri aktarımındaki sınır, algılanan hız farkına yol açar
• 14kB, çoğu sunucunun başlangıçta gönderdiği 10 TCP paketinin kapasitesine karşılık gelir
• Uydu interneti gibi yüksek gecikmeli ortamlarda, fazladan bir gidiş-dönüş (RTT) 612ms’ten fazla gecikmeye neden olabilir
• Pratikte, ana içeriği 14kB’ın altına sığdırmak veya ilk 14kB içine kritik kaynakları yerleştirmek web performansı optimizasyonunda etkilidir

---

Genel bakış ve temel prensipler

• Web sitesinin boyutu küçüldükçe daha hızlı yüklendiği iyi bilinen bir gerçektir
• Ancak 14kB’dan 15kB’a geçildiği anda, ilk yanıt hızında çarpıcı bir fark oluşması beklenmedik bir durumdur
• 15kB ile 16kB’lık sayfalar arasındaki hız farkı küçüktür, ancak 14kB ile 15kB arasında en fazla 612ms fark oluşabilir

TCP nedir

• Transmission Control Protocol (TCP), IP (Internet Protocol) üzerinde çalışır ve paketlerin güvenilir şekilde iletilmesini sağlar
• Web tarayıcısı bir HTTP isteği gönderdiğinde birden fazla TCP paketi iletir
• Yalnızca IP kullanıldığında paketlerin ulaşıp ulaşmadığı doğrulanamaz; bu nedenle TCP, paket alındısını onaylama (ACK) işlevini sağlar
• Sunucu önce az sayıda paket gönderir, ardından tarayıcıdan ACK alırsa ek paketleri iletir
• ACK gelmezse, paket yeniden gönderme süreci devreye girer

TCP slow start nedir

• TCP slow start, sunucunun ağ bağlantısının kalitesini (bant genişliğini) anlamak için gönderdiği paket miktarını kademeli olarak artırdığı bir algoritmadır
• Bağlantının başlangıcında sunucu yalnızca küçük bir miktar paket gönderir (genellikle 10 paket)
• Ziyaretçinin bilgisayarı ACK’yi düzgün şekilde gönderirse, paket gönderim miktarı iki katına çıkarılır
• ACK kaybı yaşanırsa, sonrasında paketler daha yavaş bir hızda gönderilir
• Gerçek algoritma uygulamaya göre ayrıntılarda farklılık gösterse de, temel fikir aynıdır

14kB eşiğinin dayanağı

• Çoğu sunucu slow start sırasında bir seferde 10 TCP paketi gönderir
• TCP paketinin azami boyutu 1500 bayttır, ancak başlıklar (40 bayt) çıkarıldığında gerçek veri miktarı 1460 bayttır
• Dolayısıyla 10 x 1460 = 14600 bayt (yaklaşık 14kB) ilk aktarımın üst sınırıdır
• Web sitesini veya kritik kaynakları 14kB’ın altında tutarsanız (sıkıştırma uygulanıyorsa özgün veri onlarca kB olabilir), başlangıçta ek bir gidiş-dönüş gecikmesi olmadan görüntülenebilir

Tek bir gidiş-dönüş ne kadar büyük gecikmeye yol açar

Uydu interneti örneği

• Yüksek gecikmeli ortamlara tipik bir örnek olarak uydu interneti kullanıcıları verilebilir (petrol sondaj platformları, yolcu gemileri vb.)
• Telefonda ana sayfa isteği yapılırken yönlendirici → uydu anteni → uzaydaki uydu → yer istasyonu → sunucu hattındaki her aşama onlarca ila yüzlerce ms sürebilir
• Toplam aktarım gidiş-dönüşü; uzaya iki kez gidip gelmeyi, ağ bölümlerindeki hareketi ve sunucu işlemesini içerdiğinden yaklaşık 612ms ek gecikme yaratır
• HTTPS kullanıldığında, ek handshake nedeniyle bu süre 1836ms’ye kadar çıkabilir

Karasal ağlarda gecikme

• 2G, 3G gibi mobil ağlarda da 100~1000ms düzeyinde gecikme oluşabilir
• Yoğunluk, sunucu aşırı yükü, paket kaybı gibi çeşitli koşullarda ek gecikmeler meydana gelebilir

14kB kuralını uygulayan web sitesi optimizasyon stratejileri

• Temel nokta, web sitesini ya da sayfayı mümkün olduğunca küçük tutmaktır
• Her sayfanın sıkıştırılmış aktarım boyutunun 14kB veya altında olacak şekilde tasarlanması idealdir
  • Sıkıştırma kullanıldığında gerçek içerik ~50kB’a kadar çıkabilir
• Otomatik oynatılan videolar, açılır pencereler, izleyiciler, gereksiz JS/CSS gibi çoğu gereksiz öğeyi azaltarak bu hedefe ulaşmak mümkündür
• Eğer tüm sayfayı 14kB içine sığdırmak zorsa, ilk 14kB içinde kritik kaynakları ve ana içeriği (CSS, JS, temel metin vb.) öncelikli olarak yerleştirmek önemlidir
• HTTP başlıkları (sıkıştırılamaz) ve görseller de (yalnızca gerekli minimum kısmı yükleme veya placeholder kullanma) bu 14kB sınırına dahildir

14kB kuralının istisnaları ve modern protokol meseleleri

• 14kB kuralı aşırı bir genelleme değildir, ancak bazı istisnalar vardır
  • Bazı sunucular initial window değerini 30 pakete kadar genişletir
  • TLS handshake üzerinden daha büyük bir pencereye izin verilmesi mümkün olabilir
  • Rota bazında gönderilebilecek paket sayısı önbelleğe alınarak sonraki bağlantılarda daha fazla veri gönderilebilir
• HTTP/2’de de sunucunun TCP slow start nedeniyle 10 paketle başlama pratiği genel olarak değişmemiştir
• HTTP/3, QUIC tarafında da 14kB kuralı resmî olarak tavsiye edilmektedir

Özet ve referans materyalleri

• Teknik gerekçeler ve ek açıklama materyalleri her bağlantı üzerinden incelenebilir
• İlk yayın: 2022-08-25, son düzenleme: 2022-08-26, yazar: Nathaniel, ilgili etiketler: web performansı, HTTP, TCP

Referans bağlantıları

• Ethernet çerçeveleri ve TCP başlık yapısı, gecikme ve bant genişliğiyle ilgili ek materyaller, TCP/QUIC spesifikasyonları vb.

[GN⁺]

Hacker News yorumu

• Yazılım geliştiricilerin medya katmanına biraz daha fazla ilgi göstermesi gerekiyor; özellikle de yazarın 3G/5G güvenilirliği ve gecikmesi hakkında vurguladıkları etkileyici. Radyoda neredeyse her zaman yeniden iletim olur ve çoğu HTTP iletişiminde UI'ın güncellenebilmesi için paketlerin sırayla ulaşması gerekir. Hatta tek bir REST isteği bile, istek ve yanıt 1400 bayttan küçük olduğunda gerçekten tek paket olarak işlenir. Bunun üstünde, 'tekil' istek aslında birden fazla pakete bölünür. Bunlardan biri bile sorun yaşarsa, ekranın düzgün güncellenmesi için tüm paketlerin sırayla gelmesi gerekir. Denemek isterseniz Chrome geliştirici araçlarında 3G modu ve paket kaybını açıp test ederek, tek bir küçük optimizasyonla bile UI tepkiselliğinin büyük ölçüde iyileştiğini görebilirsiniz. Bu yüzden API ve UI'ı olabildiğince küçük tutmak için ikna edici bir neden var

• Ana sayfamın aktarım boyutu sıkıştırılmış hâliyle 7.0kB

  • /
  • main.css
  • favicon.png
  • toplam 7.0kB Blog listesi ve tüm web sitesi, benim özel statik site üretecimle yapılıyor (açık kaynak: site.lisp, Common Lisp kullanıyor). Matematikle ilgili gönderilerde istemci tarafı render için KaTeX kullanıyorum; bu durumda ek olarak 347.5kB geliyor
  • katex.min.css 23.6kB
  • katex.min.js 277.0kB
  • auto-render.min.js 3.7kB
  • KaTeX_Main-Regular.woff2 26.5kB
  • KaTeX_Main-Italic.woff2 16.7kB
  • ek toplam 347.5kB Bir gün KaTeX'i sunucu tarafı render'a geçirsem mi diye düşünüyorum. Bu blog, üniversite yurdu günlerimden beri sürdürdüğüm kişisel bir tutku projesi. Tüm HTML, şablonlar ve CSS'i kendim yazdım; her sayfaya yalnızca gerçekten gerekli öğeleri koymak için her zaman dikkatli kurguladım, böylece boyutu küçük tutuyorum
  • Ana sayfam
  • Matematik gönderileri koleksiyonu
    • Mutlaka daha iyi bir yöntem kullanmayın demiyorum, ama LaTeX gösterimi gibi dinamik bileşenler yüklenirken istemci tarafı render'da oluşan gecikme, sıradan kullanıcılar tarafından neredeyse hiç (hatta hiç) fark edilmiyor. Aşırı optimizasyon da bir sorun. Tüm bu SEO temelli performans arayışı, milyonlarca görüntülenmesi olan bir servis değilseniz, harcanan zamana göre çok az getiri sağlıyor. Açık denizde küreksiz bir tekneyi gelgitlerle yönlendirirken aerodinamiği de dert etmek gibi. Kaynakların sınırlı olduğu durumda toplam maliyet ve faydayı düşününce, optimizasyon her zaman en iyi seçenek olmuyor
    • Matematik içeriği azsa ama yine de KaTeX kullanmak istiyorsanız, alternatif olarak MathML(mathml-core) değerlendirmeye değer olabilir
    • Matematik formüllerini veya LaTeX ifadelerini neden istemci tarafı js ile render ettiğinizi anlamıyorum. Neden önceden HTML/CSS'ye dönüştürüp önceden render edilmiş hâlde koymuyorsunuz, merak ediyorum
    • Ağır kütüphaneleri ilk sayfa render'ından sonra yüklemek ya da yalnızca viewport'ta göründüklerinde formül grafiklerini SVG olarak getirmek de bir fikir olabilir. Benim düşüncem bu

• 14kB hedefi biraz iddialı, ama ilk 10 paket içinde kalma fikri de ilginç. Benim gibi site boyutuna odaklanan projelerden biri 512kb.club. Site boyutunu golf skoru gibi karşılaştıran bir yer. Benim sitemin(anderegg.ca) kayıt öncesi tüm kaynakları toplandığında 71kB çıktı. Bu proje sayesinde Cloudflare Radar da öğrendim; site analizi ve sayfa boyutu ölçümü için iyi araçları var. Asıl amacı tüm internet için bir gösterge paneli ama sayfa boyutu analiz aracı da içeriyor

  • Kullanıcı açısından sormak istiyorum, kalan 500kB ne için kullanılıyor? Benim için %90 metin yeterli ve geri kalanı da vektör grafik olsa kâfi. 14 kB ile bile hayli metin ve grafik sığıyor; peki kalan 500 neye gidiyor?
  • 512kb gerçekçi bir ölçüt. Ben de kendi web siteme bunu uyguluyorum. 14kb seviyesindeki web siteleri artık web standartlarının da ötesine geçmiş durumda
  • Kişisel web sitesi için 512kb gayet ulaşılabilir. Bir sonraki hedefim 99kb (100kb altı). Birkaç hafta sonu ayırınca rahatça olur. Sitem 512kb'de Orange seviyesinde

• Bunu biraz daha eğlenceli deneylerle test etmek isterseniz, başlangıç penceresi (IW) boyutu sunucu tarafında ayarlanabilir. Örneğin şöyle değiştirilebilir

  • ip route change default via <gw> dev <if> initcwnd 20 initrwnd 20 Araştırırsanız bugün bazı CDN'lerin başlangıç penceresini 30 pakete (45kb) kadar verdiğini de görebilirsiniz
  • 13 yıl önce 10 paket bile 'hile' sayılıyordu. İlgili içerik için buraya ve Ben Strong bloguna (arşiv) bakabilirsiniz
  • CDN'lerin başlangıç penceresinin 30 paket olduğuna dair kaynak var mı, merak ediyorum
  • İsterseniz tam bir 'kötü vatandaş' gibi bunu 1000 pakete de ayarlayabilirsiniz... ama dezavantajı, birilerinin dial-up ya da bufferbloat olan bağlantıda darboğaz yaşaması olabilir

• Aşağıdaki yazıda anlatılanlar da burada geçerli: Cloudflare blogu - Rus ISP'lerin yalnızca ilk 16KB'ye izin vererek web gezintisinin büyük kısmını kullanılamaz hâle getirmesi. Cloudflare analizine göre Rus ISP'ler, yerel kullanıcıların internetini throttling uygulayarak web varlığı başına yalnızca ilk 16KB'nin yüklenmesine izin verecek şekilde sınırlandırıyor

• TCP Slow Start'ın ne olduğunu bilmeyenlerle, web sitesi yüklenme gecikmesini milimetrik düzeyde önemseyecek kadar ilgili olanların kesişimi çok küçük. Startupların önce startup işine odaklanması gerekir; bu tür optimizasyon takıntılarına ancak büyük şirketlerin ayıracak zamanı olur

  • "Önemli şeylere odaklandığımız için performans optimizasyonuna sıra gelmiyor" diye yaklaşırsanız, ona asla sıra gelmez. Bu yüzden bugün çoğu uygulama ve site yavaş ve berbat
  • Eğer bu doğruysa, Microsoft gibi yerlerin yazılımları her zaman kusursuz biçimde en verimli şekilde çalışmalıydı
  • Kavramsal olarak kulağa doğru geliyor. Ama Figma'dan Evan Wallace performansa takıntılı olmasaydı, Figma bugünkü hâline gelemezdi. Bazen 'performans' doğrudan ürünün ana özelliği olur
  • Bu bir tercih olmak zorunda değil; varsayılan olarak da beraberinde gelebilir. Ben hem 1 milyar hücreli hem de checkbox demosunu[1] datastar ile yaptım ve toplamda biraz 10kb'ı ancak geçiyor. Mobil ağda ve 3G'de fark büyük. Benim deneylerimde 14kb'ı geçince düşük kaliteli bağlantılarda 3 saniye daha sürüyordu. datastar bakımcısı TCP slow start'ı bile düşündüğü için, ben özellikle uğraşmasam da bundan fayda gördüm
    • checkboxes.andersmurphy.com
  • Şirket ölçeğinin performans optimizasyonuyla çok ilgili olduğunu sanmıyorum. Hatta büyük şirketler çoğu zaman daha yavaş oluyor

• Ana sayfam 17.2KB! (bağımlılıklar hariç) Kişisel sayfam için gerçekten çok optimizasyon yaptım ve Lighthouse'ta da tam 100 puan aldım. Eskiden imkânsız sanıyordum ama başardım. Bu arada Rails ile yapıldı. Böyle bir optimizasyonun gerçekten değdiğini söyleyebilirim. Tepkisiz hissettirmeden şimşek gibi açılan bir sayfa deneyimi başlı başına çok tatmin edici

  • news.ycombinator.com'un anında yüklenmesini yaşayınca psikolojik olarak da çok rahatlatıcı oluyor; molalarda otomatik olarak açıyorum
  • Binlerce site için şablon kodunu inanılmaz düzeyde optimize edip Lighthouse 100/100/100/100 puan aldım. Mobilde de tam 100. İlk yükleme 17.2kB'den çok daha büyük, yaklaşık 120kB, ama püf noktası tüm gereksiz HTTP isteklerini kaldırmak ve yalnızca "above-the-fold" alanında JS çalıştırmak; geri kalanını lazy eval, defer vb. ile mümkün olduğunca ertelemek. JS/CSS inline, üçüncü taraf widget'lar bile popup ikonları gibi 'facade' yöntemiyle gerçek isteği sonradan yapıyor. SSR backend'in de büyük katkısı var. Vimeo arka plan videosuyla bile 100 puandı ama Youtube ile imkânsız. Mükemmel puan almanın yolu Lighthouse sonuçlarını yorumlayıp kod tabanını en baştan tamamen yeniden yazmaktı. Bunun sayesinde hızla ilgili müşteri şikâyetleri tamamen bitti ve SEO ile gerçek puanlar açısından da büyük bir rekabet avantajı sağladı
  • Rails'in render optimizasyonuyla doğrudan ilgisi yok. Mükemmel Lighthouse puanı için tebrikler

• Yazıda iki mantıksal zayıflık olduğunu düşünüyorum

  1. Uydu iletişiminde tek bir paket göndermenin yaklaşık 1600ms sürdüğüne dair bir hesap var, ama bu 14kb kuralı için zayıf bir dayanak. Büyük web siteleriyle bir karşılaştırma olmadığı için 10 paket ≠ 16 saniye sonucunu göstermiyor
  2. Web sayfası görsellerinin de 14kb kuralına dahil edildiği söylenmiş, ama görseller ilk yüklemede ne sıklıkla inline ediliyor? Gerçekte bu çok nadir bir istisna; bu yüzden %99.9 durumda geçerli olmadığını daha açık söylemek gerek - "<i>Görseller inline mı ediliyor?</i>" derseniz, örneğin ilk ekranda görünen düşük çözünürlüklü küçük görsellere CSS blur ekleyip asıl görseli sonradan asenkron şekilde fade in etmek gibi yöntemler var. Düzgün yapılırsa sadece 1-200 bayt civarı ek maliyet getirir. Ben blogumda uyguladım; Wordpress, Medium gibi platformlarda da yaygın. Bu daha çok ticari frontend hiperoptimizasyonu için kullanılan bir numara - Kullanıcıların çoğunun düşük gecikmeli uydu bağlantısı kullandığını varsaymaya da katılmıyorum; ayrıca tüm siteler birkaç MB iken benim sayfamın tek başına dayanılmaz olacağı öncülüne de katılmıyorum

• Yeni neslin, basit statik siteleri bile Next.js gibi framework'lerle yapma eğiliminde olduğunu görüyorum. HTML+CSS+js döneminin geride kalıyor olması biraz üzücü

  • Katılıyorum. Ben de minimum kaynak, elle JavaScript optimizasyonu ve 14kb kuralına uygun site işlerini yaptım ama bu yaklaşım sonunda tasarım ve mimari kısıtlara dönüşüyor. Özellikler arttıkça o günün 'minimal' kararları teknik borcun tamamına dönüşüyor. Çoğu insan 'framework'süz saf web'e romantik yaklaşıyor, sonra bir noktada bunun daha zahmetli olduğunu görüyor. Ama isomorphic JS framework kullanırsanız statik sayfa olarak başlayıp makul ölçüde optimize ettikten sonra gerekirse thick client JS'e geçebilirsiniz
  • Aslında trend şimdiden geri dönüyor. Bugünün framework'lerinin çoğu statik siteleri de çok iyi destekliyor. Astro gibi bazıları zaten doğrudan statik siteler için ortaya çıktı
  • Bunu yeni fark etmiş gibisiniz ama aslında jQuery'nin popülerliğinin patladığı 2010'dan çok önce de durum buydu
  • Next.js, bundle kodunu çok agresif şekilde optimize ediyor; bu yüzden lambda ya da küçük sunucu kurulumları için de uygun. Next ile yapılmış statik siteler de bundle'ı oldukça küçük tutuyor

• Gecikmenin yanı sıra kaynak tüketimini en aza indirmek de sürdürülebilir bir gelecek için gerekli. Ağın çevreye etkisi de kesinlikle küçük değil. Yorumların biraz alaycı bir tona kayması üzücü. Bu optimizasyonlar nihai çözüm değil belki ama enerji kullanımını azaltma etkisi daha fazla vurgulanabilirdi

  • İnternet trafiğinin çoğu video akışından oluşuyor. Web sayfalarında birkaç megabayt optimize etseniz bile pek fark yaratmaz. Verimlilik yine de tartışılmalı ama her alanda optimizasyon çabası, aslında optimizasyona daha çok ihtiyaç duyan alanlardan kaynak çekebilir
  • Bu yerde duran düşük meyve bile değil. Bir web sayfasında 1-2mWh tasarruf etmek için uğraşırken, tek bir arama motoru sorgusu 100 kat, tek bir chatbot kullanımı ise 10 bin kat daha fazla harcıyor. Cache ve lazy loading ile de bunun önemli bir kısmı zaten hafifliyor
  • Sayfa boyutunu küçültmeye kafa yormak neredeyse tamamen boş iş. Web gezintisinin yıllık elektrik tüketimini güvenlik payıyla 10 kat fazla saysanız bile, tek bir hamburger üretmek için gereken enerjiden hâlâ çok daha az olur. Hatta bir geliştiricinin bir hafta optimizasyon yapmak yerine bir öğün salata yemesi çevresel etki açısından daha büyük olabilir
  • Kesinlikle katılıyorum. Bir zamanlar BBC'ye gidip küçücük bir metin haberinin cache'te 120MB tuttuğunu görünce şok olmuştum. Bu, gereksiz enerji kullanımını ve israf kültürünü teşvik ediyor. Ben de kendi web sitemi mümkün olduğunca minimal yaptım ve YouTube'a 4K yerine yalnızca 1080P yüklemeye çalışıyorum. 4K ve 8K'nın var olması bile gerekmiyor. İnsanlar genelde birkaç MW daha güneş enerjisi eklemekten söz ediyor ama aslında 'daha az üretmek' için çabalamayı düşünmek gerekir. 56K modem dönemindeki küçük web'i özlüyorum; bir yerde makul bir orta nokta vardı ama onu çoktan geçtik
  • İnsanlar ancak kendilerini doğrudan etkilemeye başladığında önemsemeye başlar. Ben de çevreyi önemseyen biriyim. Yapay zekanın daha kötü olduğu yönündeki karşı argümanı da anlıyorum; ama sonuçta yapay zeka da bu ağır sayfaları tarıyor. Ayrıca 14kb ölçütü, mobil ortalama sayfa payload'ının %1'ine bile denk gelmiyor