Bir Web Sayfası Tarayıcıda Saniyeler İçinde Nasıl Yükleniyor? Perde Arkasında Gerçekte Ne Oluyor

Adres çubuğuna bir adres yazıp Enter'a basıyorsun ve sayfa bir saniye bile geçmeden yükleniyor. O yüklenme sürecinin içinde aslında art arda düzinelerce iş oluyor: bir isim bir adrese çevriliyor, bir sunucuyla el sıkışılıyor, yüzlerce dosya indiriliyor, bir belge satır satır işleniyor ve en sonunda ekranda gördüğün şekle dönüşüyor. Bu yazıda bir web sayfasının tarayıcıda tam olarak nasıl yüklendiğini adım adım açacağız — tarayıcı gerçekte ne yapıyor, hız nerede kazanılıyor, nerede kaybediliyor.

##Adresi Yazınca İlk Ne Oluyor: DNS ve Bağlantı Kurma

Tarayıcıya yazdığın "ornek.com" insan için bir isim, ama internetin çalışma şekli IP adresleri üzerine kurulu — 93.184.216.34 gibi bir dizi sayı. Bu çeviriyi yapan sistemin adı DNS (Domain Name System) ve aslında katmanlı bir telefon rehberi gibi çalışır: tarayıcı önce kendi önbelleğine bakar, yoksa işletim sisteminin önbelleğine, yoksa internet servis sağlayıcının DNS sunucusuna sorar, o da gerekirse kök sunuculardan başlayıp ".com" sunucusuna, oradan da senin alan adının asıl sunucusuna kadar iner. Bu zincirin tamamı önbellekte hiçbir şey yoksa 20-120 milisaniye sürebilir; önbellekte varsa pratikte sıfıra yakındır.

İP adresi elde edilince tarayıcı sunucuyla bir TCP bağlantısı kurar — bu, "merhaba, beni duyuyor musun, ben de seni duyuyorum" şeklinde üç adımlık bir el sıkışmadır (SYN, SYN-ACK, ACK). HTTPS kullanan bir site ise (ki bugün hemen hemen hepsi kullanıyor) bu bağlantının üzerine bir de TLS el sıkışması biner: tarayıcı ve sunucu hangi şifreleme yöntemini kullanacaklarına, sunucunun kimliğinin gerçek olduğuna (sertifika) ve bir oturum anahtarına karar verirler. DNS, TCP ve TLS toplamda kullanıcıya görünmeden geçen 100-400 milisaniyeyi oluşturabilir — sayfa içeriği gelmeden önce harcanan, ama atlanamayan bir maliyettir bu.

##Sunucudan Gelen HTML Bir Sayfaya Nasıl Dönüşüyor?

Bağlantı kurulduktan sonra tarayıcı sunucudan HTML belgesini ister ve genelde ilk baytların gelmesi (Time to First Byte / TTFB) 100-500 milisaniye içinde olur — sunucunun ne kadar yük altında olduğuna, veritabanı sorgusu çalıştırıp çalıştırmadığına, bir CDN'den mi yoksa uzak bir sunucudan mı geldiğine bağlı olarak bu süre uzayabilir. HTML gelmeye başladığı anda tarayıcı onu yukarıdan aşağı satır satır okumaya başlar ve bunu DOM (Document Object Model) denen bir ağaç yapısına dönüştürür — sayfadaki her etiketin, her metnin bir düğüm olduğu bir hiyerarşi.

Ama HTML tek başına yetmez. Tarayıcı, HTML'i okurken içinde geçen her stylesheet bağlantısını, her script etiketini, her görsel etiketini gördüğü anda o dosyalar için de ayrı indirme istekleri başlatır. Modern bir sayfa genelde CSS, JavaScript, font ve görsel dosyalarından 40-150 arası ayrı istek içerir. Bunların hepsi aynı anda indirilmez — tarayıcı bir alan adına karşı aynı anda açabileceği bağlantı sayısını sınırlar (tarayıcıya göre altı civarı), bu yüzden çok fazla küçük dosya, çok az sayıda büyük dosyadan bazen daha yavaş olabilir.

##Kritik Render Yolu: Sayfa Neden Bazen Beyaz Ekranda Kalıyor

HTML'den DOM çıkınca, CSS dosyalarından da CSSOM denen benzer bir ağaç çıkar — hangi elemanın hangi stile sahip olduğunun haritası. Tarayıcı bu ikisini birleştirip bir render tree oluşturur, sonra her elemanın ekranda tam olarak nerede, ne boyutta duracağını hesaplar (layout) ve en sonunda pikselleri gerçekten boyar (paint) ve katmanları birleştirir (composite). Bu dört adıma — DOM, CSSOM, layout, paint — kritik render yolu denir ve bir sayfanın ne zaman görünür hale geldiğini belirleyen tam olarak budur.

İşte beyaz ekranın sebebi burada gizli: CSS, varsayılan olarak render-blocking'dir — tarayıcı, sayfanın nasıl görüneceğini bilmeden hiçbir şeyi boyamak istemez, bu mantıklı çünkü aksi halde kullanıcı önce stilsiz bir sayfa, sonra bir anda stillenmiş hâlini görür (buna flash of unstyled content denir). JavaScript ise varsayılan olarak hem indirilirken hem çalışırken HTML ayrıştırmasını tamamen durdurur, çünkü script sayfanın kendisini değiştirebilir ve tarayıcı önce onu çalıştırıp sonuca göre devam etmek zorundadır. Head içine konan, async veya defer etiketlenmemiş büyük bir JavaScript dosyası, teknik olarak sayfanın geri kalanının görünmesini saniyelerce geciktirebilir — bu, neden bazı sitelerin bir anda değil parça parça açıldığı sorusunun da cevabıdır.

##Gerçek Bir Örnek: Bir Ürün Sayfasının Yüklenme Zaman Çizelgesi

Soyut kalmasın — tipik bir orta ölçekli e-ticaret ürün sayfasını ele alalım ve zaman çizelgesini adım adım görelim:

• ▸0-80ms: DNS çözümleme önbellekte yoksa tamamlanır ve TCP ile TLS el sıkışması biter.
• ▸80-250ms: Sunucu isteği işler, veritabanından ürün bilgisini çeker ve HTML'in ilk baytı gelir.
• ▸250-600ms: HTML indirilip ayrıştırılırken CSS, kritik JavaScript ve font dosyaları için istekler başlar; tarayıcı render-blocking CSS'i beklerken henüz hiçbir şey boyamaz.
• ▸600-900ms: CSSOM ve DOM birleşip render tree oluşur, layout hesaplanır, ilk piksel boyanır — kullanıcı artık bir şey görür (First Contentful Paint).
• ▸900-1800ms: Görseller, ürün galerisi scriptleri, öneri widget'ları gibi render-blocking olmayan kaynaklar devam eder; sayfa görsel olarak tamamlanır (Largest Contentful Paint).
• ▸1800-2500ms: Geri kalan JavaScript çalışır, butonlar tıklanabilir hale gelir (Time to Interactive).

Buradaki en önemli gözlem şu: kullanıcının "sayfa açıldı" dediği an ile tarayıcının son işi bitirdiği an aynı şey değil. Bir sayfa görsel olarak tamam görünüp hâlâ etkileşime kapalı olabilir — tam da bu yüzden Core Web Vitals gibi ölçümler tek bir "yüklendi" anına değil, First Contentful Paint, Largest Contentful Paint ve Interaction to Next Paint gibi birden fazla ana bakar.

##Yükleme Hızını Gerçekte Ne Belirliyor — ve Nerede Kazanılıyor

Yukarıdaki zaman çizelgesine bakınca hız kazanmanın birkaç belirli yerde toplandığını görürsün:

• ▸Sunucu yanıt süresi: veritabanı sorgularını hızlandırmak, sunucu tarafı önbellekleme, kullanıcıya coğrafi olarak yakın bir sunucu veya CDN kullanmak.
• ▸Kaynak sayısı ve boyutu: görselleri sıkıştırmak ve modern formatlar (WebP/AVIF) kullanmak, kullanılmayan CSS ve JavaScript'i ayıklamak, font sayısını azaltmak.
• ▸Render-blocking kaynaklar: kritik olmayan CSS'i sonraya bırakmak, script'leri defer veya async ile işaretlemek, kritik CSS'i HTML içine gömmek.
• ▸Bağlantı sayısı: HTTP/2 veya HTTP/3 kullanmak, tek bağlantı üzerinden çoklu istek eski tarayıcı limitini aşar.
• ▸Tarayıcı önbelleği ve CDN: statik dosyaları kullanıcıya coğrafi olarak yakın sunuculardan ve ikinci ziyarette hiç indirmeden sunmak.

Bu sayılar kesin bir yasa değil, sektör genelinde kabul gören yaklaşık eşikler — gerçek sonuç kullanıcının bağlantı hızına, cihazına ve sunucunun coğrafi konumuna göre değişir. Ama yön göstermeleri açısından faydalılar: TTFB'n 300 ms'yi aşıyorsa önce sunucu tarafına bakmalısın, LCP 2.5 saniyeyi aşıyorsa önce görsellere ve render-blocking kaynaklara bakmalısın.

##Tarayıcıya İpucu Vermek: preconnect, preload ve prefetch Ne İşe Yarar

Tarayıcı HTML'i okuyarak kaynakları keşfettiği için, bir kaynağın ihtiyacı HTML'in ortasında bir satırda ortaya çıkana kadar o kaynak için hiçbir şey yapmaz — isteği başlatmadan önce sırasını bekler. Geliştiriciler bu gecikmeyi kısaltmak için tarayıcıya önceden ipucu verebilir. preconnect, bir alan adına bağlantının (DNS, TCP, TLS) HTML'in o kaynağa ihtiyaç duymasından önce kurulmasını söyler — özellikle üçüncü taraf bir font sağlayıcısı veya ödeme sağlayıcısı gibi ayrı bir alan adına bağlanılan durumlarda saniyenin onda birini kazandırabilir. preload ise "bu dosyaya kesin ihtiyacım olacak, normal sıranı beklemeden şimdi indir" demektir — genelde hero görseli veya kritik bir font için kullanılır. prefetch daha gevşek bir sinyaldir: "kullanıcı büyük olasılıkla bir sonraki sayfaya gidecek, boşta kalan bantla onu şimdiden indir" anlamına gelir, bir sonraki tıklamanın anında açılmasını sağlar. Bu üç ipucu doğru kullanıldığında kritik render yolunu kısaltır; yanlış kullanıldığında (örneğin her şeyi preload etmek) tarayıcının öncelik sırasını bozar ve asıl kritik kaynağı geciktirir.

##Sık Sorulan Sorular

>Sayfa yükleme hızı gerçekten SEO'yu etkiliyor mu?

Evet, doğrudan. Google, Core Web Vitals'ı sıralama sinyallerinden biri olarak kullanıyor — tek belirleyici o değil, içerik kalitesi çok daha ağır basıyor, ama iki içerik eşit kalitedeyse daha hızlı açılan sayfa küçük bir avantaj kazanıyor. Daha somut etki ise kullanıcı tarafında: sayfa açılması bir saniyeden üç saniyeye çıktığında terk oranının ciddi şekilde arttığı pek çok bağımsız ölçümde tekrar tekrar görülüyor.

>Tarayıcı önbelleği ikinci ziyareti nasıl hızlandırıyor?

Sunucu, bir dosyayı gönderirken yanıtına "bu dosya şu kadar süre değişmeyecek, tekrar isteme" anlamına gelen başlıklar ekleyebilir. Tarayıcı bu dosyayı diskine kaydeder ve aynı siteye ikinci kez girdiğinde CSS, JavaScript, logo gibi değişmeyen dosyaları sunucudan hiç istemeden doğrudan diskten kullanır. Bu yüzden bir sitenin ilk açılışı ile ikinci açılışı arasındaki fark genelde çok büyük olur — ikincisinde indirilecek neredeyse hiçbir şey kalmamıştır.

>CDN kullanmak küçük bir site için de fark yaratır mı?

Ziyaretçi profiline bağlı. Ziyaretçilerin büyük kısmı sunucunun bulunduğu ülkeye yakınsa CDN'in kazandıracağı süre sınırlıdır, çünkü mesafe zaten kısa. Ama ziyaretçiler coğrafi olarak dağınıksa CDN statik dosyaları kullanıcıya yakın bir noktadan sunarak yüzlerce milisaniye kazandırabilir — ve bunun maliyeti küçük sitelerde genelde göz ardı edilebilir seviyede, çoğu CDN'in ücretsiz katmanı bu trafiği karşılar.

>Mobil bir sayfa neden masaüstünden daha yavaş açılıyor?

Üç sebep üst üste biniyor: mobil bağlantılar masaüstü kablolu veya güçlü Wi-Fi bağlantısına göre daha yüksek gecikmeye sahip, mobil işlemciler JavaScript çalıştırmada masaüstü işlemcilerden belirgin şekilde daha yavaş, ve çoğu site görseli masaüstü ekranına göre tasarlayıp mobile aynı veya benzer boyutta gönderiyor. Bu üçü birleşince mobildeki gerçek yüklenme süresi, aynı sayfanın masaüstündeki süresinin iki-üç katına kolayca çıkabiliyor.

>HTTP/2 veya HTTP/3 sayfa hızını nasıl değiştiriyor?

HTTP/1.1'de tarayıcı bir alan adına aynı anda sadece altı civarı bağlantı açabiliyordu, bu yüzden çok sayıda küçük dosya sırada bekliyordu. HTTP/2, tek bir TCP bağlantısı üzerinden onlarca isteği aynı anda multiplexing ile gönderebiliyor, yani dosyalar artık birbirini bağlantı sırası için beklemiyor. HTTP/3 ise TCP yerine QUIC denen UDP tabanlı bir protokol kullanıyor — bu, özellikle paket kaybı olan mobil ağlarda bağlantının bir paketin kaybı yüzünden tamamen durmasını önlüyor. Pratikte HTTP/2'ye geçiş çoğu site için TTFB'den sonraki en büyük tek kazançlardan biri oluyor, çünkü sunucu veya kod değişikliği gerektirmeden sadece sunucu yapılandırmasıyla gelir.

Bu zincirin her halkası — DNS'ten render'a — bir web uygulamasının gerçekte ne kadar hızlı hissettiğini belirliyor; sayfa hızını iyileştirmek çoğu zaman tek bir büyük değişiklik değil, bu zincirdeki birkaç küçük darboğazı bulup teker teker kapatmaktır. Bir projede neyin nerede tıkandığını konuşmak istersen iletişim sayfam açık; cache'in bu zincirde tam olarak nasıl devreye girdiğini merak ediyorsan ilgili yazıma da bakabilirsin.