Site hızı

Tarayıcı sayfayı nasıl kurar

Tarayıcı HTML'i ilk bayttan okur ve ilerledikçe sayfa ağacını kurar, ama CSS'i anlayana kadar ekrana hiçbir şey çizmez ve sıradan bir betiğe ulaşırsa tam orada durur. Bu yolun devamında duyacağınız her hız tavsiyesi bu iki cümleden çıkar.

Ders 2 / 10
Başlangıç
Ücretsiz, kayıt yok

HTML'in gelişinden gördüğünüz ilk şeye

Tarayıcının her sayfa için attığı beş adım. İlk üçü yavaşlatılabilir; son ikisi sonuçtur.

1
İstek

HTML'in ilk baytı gelmeden tarayıcının başlayacağı bir şey yoktur.
2
Ayrıştırma ve DOM kurulumu

Kademeli ilerler ve sıradan bir betikte durur.
3
CSS okuma

İkinci harita kurulur. Bu hazır olmadan hiçbir şey çizilmez.
4
Oluşturma ağacı ve yerleşim

İki harita birleşir ve ekrandaki her şeyin yeri hesaplanır.
5
Boyama

Okurun gördüğü ilk şey. Önceki üç adımdaki her gecikme burada kendini gösterir.

Bu sıra basitleştirilmiştir. Gerçek tarayıcılar bu adımların bir kısmını paralel ve tahmine dayalı yürütür; bir değişikliğin etkisinin her zaman bu resmin beklettiği kadar büyük olmamasının nedeni budur.

Son kontrol: 30 Eylül 2026 Bu dersteki bilgiler ve araç adları bu tarihte kaynaklarıyla yeniden doğrulanır.

HTML geldiği andan itibaren ne olur

Kafanızdan çıkarmanız gereken ilk şey, tarayıcının dosyanın tamamının gelmesini beklediğidir. Beklemez. İlk bayttan okumaya başlar ve sayfanın geri kalanı hâlâ yoldayken yapısını kurar.

Yaptığı işin bir adı var: ayrıştırma. Tarayıcı baytları karakterlere, karakterleri burada bir paragraf açıldı gibi belirteçlere ve o belirteçleri düğümlere çevirir. Düğümler birbirine bağlanıp DOM denen bir ağaç kurar; bu, tarayıcının bellekte tuttuğu sayfa yapınızın haritasıdır. JavaScript'in sonradan değiştirdiği her şey dosyanızda değil, o ağaçta değişir.

Bu işin en önemli özelliği kademeli olmasıdır. Tarayıcının kapanış etiketini beklemesi gerekmez; gösterilecek bir şey hazırsa gösterir. Bu yüzden bazen üstü gelmiş, altı hâlâ gelmekte olan bir sayfa görürsünüz. Yavaş bir site, zorunlu olarak her şeyi geç gelen bir site değildir; çoğu zaman o kademeli başlangıcın önüne bir şeyin geçtiği sitedir.

Ve bütün hız konusunu anlaşılır kılan tam olarak budur. Doğru soru sayfam ne kadar ağır değil, tarayıcının daha erken başlamasını ne engelledi sorusudur. Sonraki iki bölüm bu sorunun iki ana yanıtıdır.

Tarayıcı sayfayı nasıl kurar: oluşturma yolu sade dille

CSS gösterimi neden tutar da görsel tutmaz

Sayfa ağacına sahip olmak çizmek için yetmez. Tarayıcı burada bir başlık olduğunu bilir, ama boyutunu, rengini ya da görünmesinin gerekip gerekmediğini bilmez. Bunu CSS'ten öğrenir ve ondan CSSOM denen ikinci bir harita kurar. Ancak iki harita da hazır olduğunda tarayıcı oluşturma ağacını kurup boyayabilir.

Peki neden bekler? Çünkü diğer seçenek daha kötüdür. Metni CSS hazır olmadan boyasaydı, bir an beyaz üzerine biçimsiz siyah metin görür, hemen ardından her şey yerine sıçrardı. Tarayıcılar bunu biraz beklemekten daha kötü bir deneyim sayar; bu yüzden CSS varsayılan olarak gösterimi engeller. Bu bir kusur değil, bir karardır.

Şimdi birçok kişiyi yakalayan ayrım: görsel bunu yapmaz. Bir resim henüz gelmediyse metnin görünümü değişmez, dolayısıyla tarayıcının onu beklemek için nedeni yoktur; sayfayı boyar, görsel sonra yerine oturur. Elbette o görsel için yer ayırmadıysanız, geldiğinde içeriğin geri kalanını iter ve okuru her şeyden çok rahatsız eden o sıçrama olur.

Şu anda kontrol edebileceğiniz pratik bir örnek: bu sitenin ön sayfasında hiç link rel=stylesheet etiketi yok. Temanın bütün CSS'i HTML yanıtının kendi içinde gönderilir, yani ilk boyama için ağda gidiş dönüş gerekmez. Bu tek doğru yol değil ve kendi maliyeti var, ama CSS dosyasını iyileştirelim seçeneğinin masadaki tek seçenek olmadığını gösteriyor.

JavaScript bu yolun neresinde durur

Ayrıştırıcı sıradan bir script etiketine ulaştığında HTML okumayı durdurur, dosyayı getirir, çalıştırır ve ancak ondan sonra devam eder. Bu olurken ağaca yeni bir düğüm eklenmez; yani sayfanın geri kalanı, ne kadar hazır olursa olsun bekler.

Nedeni mantıklı. Betiğin o anda sayfaya yazma ya da ağacı değiştirme izni vardır ve tarayıcı bunun öyle yapıp yapmayacağını önceden bilemez. Bu yüzden en temkinli şeyi yapar ve bekler. Daha az dile getirilen bir nokta da var: head içinde duran bir betik, ayrıştırıcıyı engellemenin yanı sıra CSS'i de bekleyebilir, çünkü bir öğenin şu anda ne kadar büyük olduğunu sorabilir ve tarayıcı CSSOM hazır olmadan yanıt veremez.

İki kelime bunu değiştirir. defer, tarayıcıya dosyayı şimdi, HTML okumayla paralel getirmesini, ama çalıştırmayı ayrıştırma bitene kadar bırakmasını ve betikleri sırada tutmasını söyler. async ise getir ve nereye düşerse orada çalıştır der, sıra konusunda hiçbir güvence vermeden. Sayfanıza ait hemen her betik için doğru yanıt defer'dir; async, kodunuzun geri kalanıyla ilgisi olmayan bir analitik etiketi gibi bağımsız şeyler için mantıklıdır.

Ve dosya ağırlığının sizi yanılttığı yer burasıdır. Sayfanın altındaki iki megabaytlık bir görsel hiçbir şeyi tutmaz. head içinde defer olmadan duran ve kontrol etmediğiniz bir üçüncü taraftan gelen dört kilobaytlık bir betik, bütün sayfanın ilk boyamasını o sunucuya tam bir gidiş dönüş kadar geciktirir. Boyut önemlidir, ama konum daha çok önemlidir.

Tek betik, yolda iki farklı yer

Aynı dosya, aynı boyut. Tek fark bir kelime ve o kelime okurun ne zaman bir şey göreceğini belirler.

head icinde siradan bir betik

ayrıştırıcı orada durur ve sayfa ağacı büyümeyi bırakır
dosya başka bir sunucudan geliyorsa tam bir gidiş dönüş beklemeye harcanır
yalnızca ayrıştırıcıyı engellemekle kalmayıp CSS'in hazır olmasını da bekleyebilir
okur bunların hepsi bitene kadar boş sayfa görür

Ayni betik defer ile

indirme hemen, HTML okumayla paralel başlar
ayrıştırıcı durmaz ve sayfa ağacı tamamlanır
çalıştırma ayrıştırmadan sonra olur ve betiklerin sırası korunur
okur, o dosya hâlâ yoldayken sayfayı görür

Gerçek bir istisna var: ilk boyamadan önce çalışması gereken bir betik, örneğin açık ya da koyu temayı belirleyen, sayfa bir an beyaz yanıp sonra koyulaşmasın diye bilerek engelleyici bırakılır.

Yani once CSS sonra JavaScript bir efsane degil

Bu tavsiye eskidir ve tekrarlandığı çoğu yerde gerekçesi yanlış verilir. Gerçek neden JavaScript'in ağır olması değildir. Gösterimin CSS'i beklemesi, dolayısıyla CSS'in erken gelmesi gerektiğidir; ve ayrıştırıcının betikleri beklemesi, dolayısıyla bir betiğin yolun ortasında durmaması gerektiğidir. Bu, dosya ağırlığıyla ilgili değil, iki beklemenin sırasıyla ilgili tek bir cümledir.

Bu sitenin ön sayfasında o sırayı sayabilirsiniz. head içinde sıfır betik var. Sayfada yedi betik etiketi var ve yedisi de belgenin son yüzde üçünde, yani okurun görmesi beklenen bütün içerikten sonra duruyor. CSS ise ayrı bir dosya bile değil, yanıtın kendi içinde geliyor. Sonuç şu: ilk boyama için tarayıcı ağdan hiçbir şey beklemiyor.

Şimdi bu dersin en dürüst kısmı: yukarıdaki düzen çözümün eski biçimidir. Betikleri gövdenin sonuna koymak işe yarar, çünkü ayrıştırıcı onlara ulaştığında her şey çoktan kurulmuştur. Ama bugün daha iyi biçim genelde aynı betiği head içine defer ile koymaktır, çünkü o zaman indirme daha erken başlar ve çalıştırma yine sona düşer. Bu değişikliği bu sitede henüz yapmadık; kazanç küçük ve betikleri zaten bu kadar geride olan bir sayfada değişikliğin riskine değmedi.

Ve bilinmeye değer bir sınır: birkaç betiğin gerçekten ilk boyamadan önce çalışması gerekir; örneğin sayfanın bir an beyaz yanıp sonra koyulaşmaması için açık ya da koyu temayı belirleyen parça. O, bilerek engelleyici bırakılır ve bu doğru karardır. Her şeyi geriye at kuralının bir istisnası vardır ve o da budur.

İlk boyamayı ne tutar ve ne yalnızca ağırdır

Head denetim sayfasıbir kez bakın

Bunlar gösterimi tutmaz

görseller, ne kadar büyük olurlarsa olsunlar
defer ya da async ile işaretlenmiş betikler
HTML yanıtının kendi içinde gönderilen CSS

Bunlar gösterimi tutar

head içinde bağlanmış her CSS dosyası
head içinde ne defer ne async taşıyan her betik
üçüncü taraf bir alan adından gelen ve head içinde duran betik

Sağ sütun, bunların ilk boyamayı tutmadığı anlamına gelir; bedelsiz olduğu değil. Yer ayrılmamış büyük bir görsel, geldiğinde içeriği kaydırır ve bu başka bir sorundur.

Bunu kendi sitenizde nasıl görürsünüz

Bunun için hiçbir araca ihtiyacınız yok. Sayfa kaynağını açın ve yalnızca head içine bakın. İki şeyi sayın: kaç link rel=stylesheet etiketi var ve src taşıyan kaç script etiketinde ne defer ne async var. Bu iki sayının toplamı, sayfanızın ilk boyamasını tutan şeylerin listesidir. İkinci sayı sıfır değilse, ilk ve en ucuz iş genelde oradadır.

Bunu komut satırından yapmayı tercih ederseniz, bu komut o etiketleri yazdırır; böylece hangisinin defer ya da async taşıdığını kendiniz görürsünüz:

curl -s https://example.com/ | tr '\n' ' ' | sed 's/<\/head>.*//' | grep -oE '<link[^>]*stylesheet[^>]*>|<script[^>]*src=[^>]*>'

Bu komutun head aralığını sed ile satır satır kesen daha basit sürümü, küçültülmüş sayfalarda yanlış yanıt verir; biz de bunun üzerinde vakit harcadık. Küçültülmüş HTML genelde tek bir uzun satırdır, dolayısıyla o aralık belgenin sonuna kadar açık kalır ve gövdenin sonundaki betikleri de sayar. Yukarıdaki komut önce </head> sonrasındaki her şeyi atar; iki durumda da bu yüzden çalışır.

Sonucu okurken bir uyarı: modern tarayıcılarda, ana ayrıştırıcı bir betikte dururken ileriye bakan ve sonraki dosyaları daha erken getirmeye başlayan ayrı bir tarayıcı vardır. Yani ayrıştırıcı durur, ağ boş oturur demek değildir. Engelleyici bir betiği kaldırmanın bazen beklenenden az etki etmesinin nedenlerinden biri budur ve öncesini sonrasını ölçmenin yerine akıl yürütmenin konulamamasının da nedeni budur.

Ve bir sonraki adım şu: buraya kadar gösterimi neyin tutabileceğini biliyorsunuz, ama sitenizde bunlardan hangisinin gerçekten tuttuğunu ve ne kadar tuttuğunu bilmiyorsunuz. O soru ölçümle yanıtlanır ve bu yoldaki site hızı ölçme dersi onu üstlenir. Sayfanızdan hemen şimdi gerçek bir sayı istiyorsanız, site hızlandırma sayfasındaki test aracı Lighthouse motoruyla çalışır.

Yapay zekayla hızlı yol

Bir sayfa yavaşken alışılmış hamle, geliştirici araçlarında şelale grafiğini açıp en uzun çubuğu aramaktır. Sorun şu ki en uzun çubuk genelde suçlu değildir; suçlu, diğer her şeyin beklediği şeydir ve o çoğu zaman başlangıca yakın kısa bir çubuktur. Bir dil modeli tam da bu tür okumada iyidir: birkaç düzine zamanlama satırını birlikte görür ve şu şunu bekledi örüntüsünü gözünüzden önce bulur. Bütün iş on dakika sürer ve ilk koşulu, ham dosyayı modelin önüne koymamanızdır.

Tarayıcıda geliştirici araçlarını açın, ağ sekmesine gidin, önbelleği devre dışı bırakın ve sayfayı bir kez sıfırdan yükleyin. Çıktıyı HAR dosyası olarak kaydedin.
HAR dosyasını olduğu gibi hiçbir yere yapıştırmayın. O dosya her istek başlığını taşır; yani oturum çerezleriniz ve oturum belirteçleriniz de içindedir. Yalnızca beş sütunu çıkarın: adres, dosya türü, başlangıç anı, süre ve head içinde olup olmadığı. İlk elli satır yeter.
Tabloyu aşağıdaki tarifle verin ve iki şey arasında açıkça ayrım yapmasını isteyin: kendisi uzun süren bir dosya ile başka bir şeyi beklediği için geç başlayan bir dosya. Bütün değer bu ayrımdadır. Bu, muhakeme gerektirdiği için güçlü bir model ister; her sınıftaki güncel seçim yapay zekâ referansımızda tutulur.
Yanıta inanmayın, sınayın. Yalnızca tek bir şeyi, modelin adını verdiği şeyi değiştirin ve yeniden ölçün. Sayı kımıldamıyorsa hipotez yanlıştı ve bu da bir sonuçtur. Aynı anda iki değişiklik, hangisinin işe yaradığını hiç öğrenememek demektir.

Kopyalamaya hazır şablon

Rolün bir web performans uzmanı. Yalnızca aşağıdaki tabloya göre karar ver ve bu site hakkında belleğinden hiçbir şey ekleme.

Aşağıdaki tablo {sayfa adresi} sayfasının bir tam yüklemesinden alındı. Her kaynak için: adres, tür, yüklemenin başından itibaren milisaniye cinsinden başlangıç anı, milisaniye cinsinden süre ve head içinde olup olmadığı.

{kaynak tablosu}

Beş şey yaz:
1. İlk boyamayı tutmuş olabilecek kaynakları ayır: yalnızca CSS ve head içinde bulunan, defer ya da async taşımayan betikler. Gerisini bir kenara koy ve neden koyduğunu söyle.
2. Bunların her biri için hangi durum olduğunu söyle: kendisi mi uzun sürdü, yoksa başka bir kaynağı beklediği için mi geç başladı. İkinci durumda o diğer kaynağın adını ver.
3. İlk boyamaya en büyük gecikmeyi eklemiş olması en olası tek kaynağı adlandır ve tablonun hangi sütunlarının seni oraya götürdüğünü tek cümlede söyle.
4. Tek başına yapılıp sonra ölçülebilecek belirli bir değişiklik öner.
5. Bu tabloda olmayan ve olsaydı yanıtını değiştirebilecek şeyi yaz.

Kurallar: tabloda olmayan hiçbir sayı uydurma ve tabloda olmayan hiçbir kaynağı varsayma. Dosya boyutu tek başına engelleme nedeni değildir; boyuta dayanmak istiyorsan bu durumda neden önemli olduğunu söyle. Tablo sonuca varmak için yetmiyorsa bunu yaz ve bunun yerine hangi sütuna ihtiyacın olduğunu söyle. "head içinde engelleyici kaynak yoktu" kabul edilebilir bir yanıttır.

Çıktıya güvenmeden önce: Hiçbir modelin kaldırmadığı içsel bir sınır var: şelale grafiği neyin ne zaman olduğunu söyler, nedenini değil. Zaman sırası nedenselliğe benzer ama o değildir ve model de tam olarak aynı sırayı görür. Dolayısıyla bu çalışmanın çıktısı bir teşhis değil bir hipotezdir; onu teşhise çeviren tek şey, o tek maddeyi değiştirip yeniden ölçmektir. Bir de bu derste geçen bir nokta: tarayıcılar ayrıştırıcının önünden tahminle dosya getirmeye başlar, bu yüzden engelleyici bir betiği kaldırmak bazen grafiğin ima ettiğinden az etki eder. Değişiklikten sonra sayı kımıldamıyorsa bu sizin başarısızlığınız değildir; ölçümün işini yapmasıdır.

Bu işte yapay zeka

Bu konuda bir dil modelinin bambaşka iki davranışı var ve aralarındaki fark, vaktinizin boşa gidip gitmeyeceğini belirliyor. Sayfanızın gerçek zamanlama tablosunu önüne koyun, mükemmeldir: birkaç düzine satırı birlikte görür ve aralarındaki bekleme ilişkisini sizden önce bulur. Önüne bir şey koymayıp yalnızca sitemi nasıl hızlandırırım diye sorun, her site için yazılmış ve hiçbiri için doğru olmayan alışıldık genel listeyi alırsınız.

Gerçekten işe yarayan araçlar

Claude Hızlı yoldaki işe uygundur: tabloyu alır ve her şeyi sıralamak yerine tek bir kaynağı adlandırıp hangi sütunun kendisini oraya götürdüğünü söyler. İran, Anthropic'in desteklenen ülkeler listesinde değil; resmî bir kayıt ya da ödeme yolu yok.
Gemini Tablonuz büyükse ve satırları kısmak istemiyorsanız, uzun girdileri iyi işler. İran, bu hizmetin sunulduğu bölgeler arasında değil.
OpenAI En yaygın seçim ve elli satırlık bir tabloyu okumaya yeter. İran'dan erişim ya da ödeme konusunda bir iddiada bulunmuyoruz ve bağlantı bir ürün sayfasına değil üretici sayfasına gidiyor: bu sunucudan hiçbir OpenAI tüketici sayfası açılmıyor ve kendimizin göremediği bir şey hakkında yazmıyoruz.

Nerede geri teper

İki risk ve birincisi özellikle bu konuya ait. Model, en büyük dosyayı suçlu olarak adlandırmaya güçlü biçimde eğilimlidir, çünkü eğitildiği metinde ağır ile yavaş neredeyse eş anlamlıdır. Ama bu derste gördüğünüz gibi engelleme, boyutla değil konum ve kaynak türüyle ilgilidir: sayfanın altındaki büyük bir görsel hiçbir şeyi tutmaz, head içindeki küçük bir betik her şeyi tutar. Yanıt yalnızca tablodaki en büyük satırı adlandırıyorsa, muhtemelen sizin verinizden değil örüntüden yanıtlamıştır. İkinci risk güvenlik riskidir ve geri alması daha zordur: bir HAR dosyası her istek başlığını, yani oturum çerezlerinizi ve oturum belirteçlerinizi taşır. O dosyayı ham hâliyle herhangi bir çevrimiçi araca yapıştırmak, pratikte hesabınızın anahtarını dışarıdaki bir hizmete göndermektir ve Anthropic'in kendi güvenlik rehberi, bağlam penceresine giren her şeyin güvenilmez girdi gibi ele alınması gerektiğini söyler. Tutumumuz: tabloyu elle beş sütuna indirin ve modelin adlandırdığı hiçbir kaynağa inanmadan önce onu bir kez kendiniz değiştirip ölçün.

Kaynaklar: MDN: critical rendering path MDN: the script element, defer and async Anthropic: mitigate jailbreaks and prompt injections Anthropic: supported countries Google: where Gemini Apps are available

Bu tavsiyenin sınırı

Bu beş adımlı resim klasik yoldur ve anlamak için yeterlidir, ama iki yerde gerçeğin gerisinde kalır. Birincisi, modern tarayıcılar bu adımları kesin olarak birbiri ardına yürütmez: ayrı bir tarayıcı ayrıştırıcının önünden gider ve sonraki dosyaları tahminle getirmeye başlar, yerleşim ve boyamanın bir kısmı paralel olur; bu yüzden bir değişikliğin etkisi her zaman bu şemanın beklettiği büyüklükte olmaz. İkincisi ve daha önemlisi: siteniz tek sayfa uygulamasıysa ve içeriği tarayıcıda JavaScript kuruyorsa, bu resim hikâyenin yalnızca başlangıcını açıklar. Orada ilk boyama sayfa hâlâ boşken hızlıca gerçekleşebilir ve gerçek zaman, bu dersin ele almadığı bir yere gider.

Kendi işimizden

Bu dersteki sayılar bu sitenin 7 Eylül 2026 tarihli ön sayfasından geliyor ve her biri sayfa kaynağı görüntülenerek kontrol edilebilir: sıfır link rel=stylesheet etiketi, head içinde sıfır betik ve yedi betik etiketi; yedisi de belgenin son yüzde üçünde. Temanın bütün CSS'i yaklaşık 91 kilobayt ve HTML yanıtının kendi içinde gönderiliyor. Şimdi bu dersi yazarken gerçekten öğrendiğimiz ve o sayılardan daha değerli olan şey: beşinci bölümdeki komutun ilk sürümü head aralığını sed ile satır satır kesiyordu ve tam da bu sayfada yanlış yanıt verdi. Bu sitenin HTML'i küçültülmüş ve neredeyse tek uzun bir satır, dolayısıyla o aralık hiç kapanmadı ve belgenin sonuna kadar sürdü; sonuç olarak gövdenin sonundaki o yedi betiği head içindeki betikler olarak saydı. O komutu sınamadan yayımlasaydık, sitesinde önbellek olan herkese yanlış yanıt verecekti ve tam da bu dersin uyardığı hata olacaktı: kendiniz kontrol etmediğiniz veri üzerinde doğru akıl yürütmek.

Gerçek devam soruları

Sayfam neden bir an biçimsiz görünüyor?

Çünkü CSS'inizin bir kısmı gösterimi engellemeyen bir biçimde yükleniyor; örneğin JavaScript ile ya da bir biçem dosyasını engelleyici olmaktan çıkaran hilelerle. Tarayıcı beklemez, metni boyar, sonra biçem gelir ve her şey kayar. Çözüm, ilk ekran için gereken biçemlerin normal ve engelleyici biçimde gelmesi, gerisinin sonra gelmesidir.

Her betiğe defer koyarsam bir şey bozulur mu?

Bozulabilir ve en yaygın durum, sayfadaki satır içi bir parçanın artık daha geç çalışan bir kitaplığa bağlı olmasıdır. Satır içi kod defer kuralına uymaz ve yerinde çalışır; böylece sıra bozulur ve bir şey tanımlı değil hatası alırsınız. Teker teker ilerleyin ve her değişiklikten sonra sayfayı gerçekten açıp hata konsoluna bakın.

Öyleyse CSS'i sizin yaptığınız gibi sayfanın içine mi gömmeliyim?

Zorunlu olarak değil ve bu saf bir iyileştirme değil, bir takastır. Gömmek bir ağ gidiş dönüşünü kaldırır, ama aynı baytlar her yanıtta yeniden gönderilir ve artık sayfalar arasında önbelleklenmez. Bizim için değiyor, çünkü bu sitenin HTML'i uçta önbellekleniyor ve ziyaretçi genelde arka arkaya birkaç sayfa açmıyor; siteniz dinamikse ve kullanıcı sırayla on sayfa geziyorsa, ayrı ve önbelleklenmiş bir dosya muhtemelen daha iyi seçimdir.