Tarayıcının önceden yükleme tarayıcısıyla mücadele etmeyin

Tarayıcı önceden yükleme tarayıcısının ne olduğunu, performansa nasıl yardımcı olduğunu ve tarayıcının çalışmasını nasıl engelleyebileceğinizi öğrenin.

Sayfa hızını optimize etmeyle ilgili gözden kaçırılan bir yön, tarayıcıların iç işleyişi hakkında biraz bilgi sahibi olmayı içerir. Tarayıcılar, geliştiriciler olarak bizim yapamayacağımız şekilde performansı artırmak için belirli optimizasyonlar yapar. Ancak bu optimizasyonlar yalnızca istemeden engellenmediği sürece geçerlidir.

Anlaşılması gereken dahili tarayıcı optimizasyonlarından biri tarayıcı önceden yükleme tarayıcısıdır. Bu yayında, önceden yükleme tarayıcısının işleyiş şekli ve daha da önemlisi, tarayıcının işini engellemeyi nasıl önleyeceğiniz açıklanmaktadır.

Ön yükleme tarayıcısı nedir?

Her tarayıcının, ham işaretlemeyi belirteçlere ayıran ve bir nesne modeline dönüştüren birincil bir HTML ayrıştırıcısı vardır. Bu işlem, ayrıştırıcı <link> öğesiyle yüklenen bir stil sayfası veya async ya da defer özelliği olmadan <script> öğesiyle yüklenen bir komut dosyası gibi bir engelleme kaynağı bulduğunda duraklayana kadar devam eder.

HTML ayrıştırıcı diyagramı.
Şekil 1: Tarayıcının birincil HTML ayrıştırıcısının nasıl engellenebileceğini gösteren bir diyagram. Bu durumda ayrıştırıcı, harici bir CSS dosyası için <link> öğesiyle karşılaşır. Bu öğe, CSS indirilip ayrıştırılana kadar tarayıcının belgenin geri kalanını ayrıştırmasını, hatta herhangi bir bölümünü oluşturmasını engeller.

CSS dosyalarında, stiller uygulanmadan önce sayfanın stil içermeyen bir sürümünün kısa süreliğine görünmesi durumu olan stil içermeyen içeriklerin anlık olarak görünmesini (FOUC) önlemek için oluşturma engellenir.

web.dev ana sayfasının stil uygulanmamış (sol) ve stil uygulanmış (sağ) durumu.
Şek. 2: FOUC'nin simüle edilmiş bir örneği. Solda, web.dev'in stiller olmadan oluşturulmuş ön sayfası gösteriliyor. Sağdaki resimde, aynı sayfanın stiller uygulanmış hali gösterilmektedir. Tarayıcı, bir stil sayfası indirilirken ve işlenirken oluşturmayı engellemezse stil uygulanmamış durum anlık olarak görünebilir.

Tarayıcı, defer veya async özelliği olmayan <script> öğeleriyle karşılaştığında sayfanın ayrıştırılmasını ve oluşturulmasını da engeller.

Bunun nedeni, birincil HTML ayrıştırıcı işini yapmaya devam ederken tarayıcının, belirli bir komut dosyasının DOM'u değiştirip değiştirmeyeceğinden emin olamamasıdır. Bu nedenle, engellenen ayrıştırma ve oluşturmanın etkilerini en aza indirmek için JavaScript'inizi belgenin sonuna yüklemek yaygın bir uygulamadır.

Bunlar, tarayıcının hem ayrıştırmayı hem de oluşturmayı engellemesi için geçerli nedenlerdir. Ancak bu önemli adımlardan birinin engellenmesi, diğer önemli kaynakların bulunmasını geciktirerek gösteriyi aksatabileceğinden istenmeyen bir durumdur. Neyse ki tarayıcılar, önceden yükleme tarayıcısı adı verilen ikincil bir HTML ayrıştırıcısı kullanarak bu sorunları azaltmak için ellerinden geleni yapıyor.

Birincil HTML ayrıştırıcının (sol) ve ikincil HTML ayrıştırıcı olan önceden yükleme tarayıcısının (sağ) şeması.
Şekil 3: Önceden yükleme tarayıcısının, öğeleri spekülatif olarak yüklemek için birincil HTML ayrıştırıcısıyla paralel olarak nasıl çalıştığını gösteren bir şema. Burada, birincil HTML ayrıştırıcı, <body> öğesindeki resim işaretlemesini işlemeye başlamadan önce CSS'yi yükleyip işlediği için engellenir. Ancak önceden yükleme tarayıcısı, ham işaretlemede ilerleyerek bu resim kaynağını bulabilir ve birincil HTML ayrıştırıcının engeli kaldırılmadan önce yüklemeye başlayabilir.

Önceden yükleme tarayıcısının rolü spekülatiftir. Yani, birincil HTML ayrıştırıcısı bunları keşfetmeden önce fırsatçı bir şekilde getirmek için kaynakları bulmak üzere ham işaretlemeyi inceler.

Ön yükleme tarayıcısının çalıştığını nasıl anlarsınız?

Önceden yükleme tarayıcısı, oluşturma ve ayrıştırma işlemlerinin engellenmesi nedeniyle vardır. Bu iki performans sorunu hiç olmasaydı önceden yükleme tarayıcısı pek kullanışlı olmazdı. Bir web sayfasının ön yükleme tarayıcısından yararlanıp yararlanmadığını anlamanın anahtarı, bu engelleme olgularına bağlıdır. Bunu yapmak için, önceden yükleme tarayıcısının nerede çalıştığını öğrenmek üzere isteklere yapay bir gecikme ekleyebilirsiniz.

Stil sayfası içeren temel metin ve resimlerden oluşan bu sayfayı örnek olarak ele alalım. CSS dosyaları hem oluşturmayı hem de ayrıştırmayı engellediğinden, bir proxy hizmeti aracılığıyla stil sayfası için iki saniyelik yapay bir gecikme oluşturursunuz. Bu gecikme, önceden yükleme tarayıcısının çalıştığı yeri ağ şelalesinde görmeyi kolaylaştırır.

WebPageTest ağının sıralı grafik tablosu, stil sayfasına uygulanan 2 saniyelik yapay gecikmeyi gösterir.
Şekil 4: Bir mobil cihazda Chrome'da simüle edilmiş 3G bağlantısı üzerinden çalıştırılan bir web sayfasının WebPageTest ağ sıralı grafiği. Stil sayfası, yüklenmeye başlamadan önce bir proxy üzerinden iki saniye boyunca yapay olarak geciktirilse de işaretleme yükünde daha sonra bulunan resim, önceden yükleme tarayıcısı tarafından keşfedilir.

Şelalede de görebileceğiniz gibi, ön yükleme tarayıcısı <img> öğesini oluşturma ve belge ayrıştırma engellenmiş olsa bile keşfeder. Bu optimizasyon olmadan tarayıcı, engelleme süresi boyunca fırsatçı bir şekilde öğe getiremez ve daha fazla kaynak isteği eşzamanlı değil, art arda olur.

Bu basit örneği inceledikten sonra, önceden yükleme tarayıcısının devre dışı bırakılabileceği gerçek dünya kalıplarına ve bunları düzeltmek için yapılabilecek işlemlere göz atalım.

Yerleştirilmiş async komut dosyaları

<head> içinde aşağıdaki gibi satır içi JavaScript içeren HTML'niz olduğunu varsayalım:

<script>
  const scriptEl = document.createElement('script');
  scriptEl.src = '/yall.min.js';

  document.head.appendChild(scriptEl);
</script>

Yerleştirilen komut dosyaları varsayılan olarak async olduğundan bu komut dosyası yerleştirildiğinde async özelliği uygulanmış gibi davranır. Bu, komutun mümkün olan en kısa sürede çalışacağı ve oluşturmayı engellemeyeceği anlamına gelir. Kulağa harika geliyor, değil mi? Ancak bu satır içi <script> öğesinin, harici bir CSS dosyası yükleyen bir <link> öğesinden sonra geldiğini varsayarsanız ideal olmayan bir sonuç elde edersiniz:

Bu WebPageTest grafiğinde, bir komut dosyası yerleştirildiğinde ön yükleme taramasının başarısız olduğu gösteriliyor.
Şekil 5: Mobil cihazda Chrome'da simüle edilmiş 3G bağlantısı üzerinden çalıştırılan bir web sayfasının WebPageTest ağ şelalesi grafiği. Sayfa, tek bir stil sayfası ve yerleştirilmiş bir async komut dosyası içeriyor. Ön yükleme tarayıcısı, istemciye yerleştirildiği için oluşturma engelleme aşamasında komut dosyasını keşfedemez.

Burada neler olduğuna bakalım:

  1. 0 saniyede ana belge istenir.
  2. Gezinme isteğinin ilk baytı 1, 4 saniyede gelir.
  3. 2, 0 saniyede CSS ve resim isteniyor.
  4. Ayrıştırıcı, stil sayfasının yüklenmesini engellediği ve async komut dosyasını yerleştiren satır içi JavaScript, bu stil sayfasından sonra 2,6 saniyede geldiği için komut dosyasının sağladığı işlev, olabildiğince hızlı bir şekilde kullanılamaz.

Bu durum, komut dosyası isteği yalnızca stil sayfası indirildikten sonra gerçekleştiği için ideal değildir. Bu, komut dosyasının mümkün olan en kısa sürede çalışmasını geciktirir. Buna karşılık, <img> öğesi sunucu tarafından sağlanan işaretlemede bulunabildiği için önceden yükleme tarayıcısı tarafından keşfedilir.

Peki, komut dosyasını DOM'a yerleştirmek yerine async özelliğiyle normal bir <script> etiketi kullanırsanız ne olur?

<script src="/yall.min.js" async></script>

Sonuç:

Bir stil sayfası indirilirken ve işlenirken tarayıcının birincil HTML ayrıştırıcısı engellenmiş olsa bile, HTML komut dosyası öğesi kullanılarak yüklenen bir eş zamansız komut dosyasının tarayıcı ön yükleme tarayıcısı tarafından nasıl keşfedilebileceğini gösteren bir WebPageTest ağ şelalesi.
Şekil 6: Mobil cihazda Chrome'da simüle edilmiş 3G bağlantısı üzerinden çalıştırılan bir web sayfasının WebPageTest ağ şelalesi grafiği. Sayfa tek bir stil sayfası ve tek bir async <script> öğesi içeriyor. Ön yükleme tarayıcısı, oluşturma engelleme aşamasında komut dosyasını keşfeder ve CSS ile eşzamanlı olarak yükler.

Bu sorunların rel=preload kullanılarak giderilebileceğini önermek cazip gelebilir. Bu kesinlikle işe yarar ancak bazı yan etkileri olabilir. Sonuçta, DOM'a <script> öğesi eklenmeyerek önlenebilecek bir sorunu düzeltmek için neden rel=preload kullanılsın?

rel=preload kaynak ipucunun, eşzamansız olarak yerleştirilen bir komut dosyasının keşfedilmesini sağlamak için nasıl kullanıldığını gösteren bir WebPageTest şelalesi (istenmeyen yan etkileri olabilecek bir şekilde).
Şekil 7: Bir mobil cihazda Chrome'da simüle edilmiş 3G bağlantısı üzerinden çalıştırılan bir web sayfasının WebPageTest ağ şelalesi grafiği. Sayfada tek bir stil sayfası ve yerleştirilmiş bir async komut dosyası bulunur. Ancak async komut dosyası, daha erken keşfedilmesini sağlamak için önceden yüklenir.

Önceden yükleme burada sorunu "düzeltir" ancak yeni bir sorun ortaya çıkarır: İlk iki demoda async komut dosyası, <head> içinde yüklenmesine rağmen "Düşük" önceliğinde yüklenirken stil sayfası "En yüksek" önceliğinde yüklenir. async komut dosyasının önceden yüklendiği son tanıtımda, stil sayfası yine "En yüksek" önceliğinde yüklenir ancak komut dosyasının önceliği "Yüksek" olarak yükseltilmiştir.

Bir kaynağın önceliği yükseltildiğinde tarayıcı, bu kaynağa daha fazla bant genişliği ayırır. Bu, stil sayfasının en yüksek önceliğe sahip olmasına rağmen komut dosyasının yükseltilmiş önceliğinin bant genişliği anlaşmazlığına neden olabileceği anlamına gelir. Bu durum, bağlantıların yavaş olduğu veya kaynakların çok büyük olduğu durumlarda bir faktör olabilir.

Buradaki cevap basittir: Başlangıç sırasında bir komut dosyası gerekiyorsa bunu DOM'a yerleştirerek önceden yükleme tarayıcısını devre dışı bırakmayın. Gerektiğinde <script> öğe yerleşimiyle ve defer ile async gibi özelliklerle denemeler yapın.

JavaScript ile geç yükleme

Geç yükleme, verileri korumak için harika bir yöntemdir ve genellikle resimlere uygulanır. Ancak bazen geç yükleme, "ekranın üst kısmında" bulunan resimlere yanlışlıkla uygulanır.

Bu durum, önceden yükleme tarayıcısıyla ilgili olarak kaynakların bulunabilirliğiyle ilgili olası sorunlara yol açar ve bir resme yapılan referansın bulunması, indirilmesi, kodunun çözülmesi ve sunulması için gereken süreyi gereksiz yere uzatabilir. Örnek olarak şu resim işaretlemesini ele alalım:

<img data-src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">

data- önekini kullanmak, JavaScript destekli geç yükleyicilerde yaygın bir yöntemdir. Resim görünüm alanına kaydırıldığında, geç yükleyici data- önekini kaldırır. Bu nedenle, önceki örnekte data-src, src olur. Bu güncelleme, tarayıcıyı kaynağı getirmeye yönlendirir.

Bu desen, başlangıç sırasında görüntü alanında bulunan resimlere uygulanana kadar sorunlu değildir. Ön yükleme tarayıcısı, data-src özelliğini src (veya srcset) özelliğiyle aynı şekilde okumadığından resim referansı daha önce keşfedilmez. Daha da kötüsü, resmin yüklenmesi, geç yükleyici JavaScript'i indirilip derlenip yürütülene kadar ertelenebilir.

Başlangıç sırasında görüntü alanında olan geç yüklenmiş bir resmin, tarayıcı önceden yükleme tarayıcısı resim kaynağını bulamadığı için nasıl geciktiğini ve yalnızca geç yüklemenin çalışması için gereken JavaScript yüklendiğinde yüklendiğini gösteren bir WebPageTest ağ sıralı grafiği. Resim, olması gerekenden çok sonra keşfedilir.
Şekil 8: Mobil cihazda Chrome'da simüle edilmiş 3G bağlantısı üzerinden çalıştırılan bir web sayfasının WebPageTest ağ şelale grafiği. Resim kaynağı, başlangıçta görüntü alanında görünür olmasına rağmen gereksiz yere geç yükleniyor. Bu durum, önceden yükleme tarayıcısının çalışmasını engeller ve gereksiz gecikmeye neden olur.

Görüntü alanının boyutuna bağlı olabilecek resmin boyutuna göre, Largest Contentful Paint (LCP) için aday öğe olabilir. Ön yükleme tarayıcısı, resim kaynağını önceden spekülatif olarak getiremediğinde(ör. sayfanın stil sayfalarının oluşturmayı engellediği sırada) LCP olumsuz etkilenir.

Çözüm, resim işaretlemesini değiştirmektir:

<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">

Bu, önceden yükleme tarayıcısı resim kaynağını daha hızlı keşfedip getireceğinden, başlangıç sırasında görüntü alanında bulunan resimler için en uygun kalıptır.

Başlangıç sırasında görüntü alanındaki bir resmin yüklenme senaryosunu gösteren WebPageTest ağ şelale grafiği. Resim tembel yüklenmez. Bu nedenle, yüklenmek için komut dosyasına bağlı değildir. Bu da önceden yükleme tarayıcısının resmi daha erken keşfedebileceği anlamına gelir.
Şekil 9: Bir mobil cihazda Chrome'da simüle edilmiş 3G bağlantısı üzerinden çalıştırılan bir web sayfasının WebPageTest ağ şelalesi grafiği. Ön yükleme tarayıcısı, CSS ve JavaScript yüklenmeye başlamadan önce resim kaynağını keşfeder. Bu sayede tarayıcı, resmi yüklemeye daha erken başlayabilir.

Bu basitleştirilmiş örnekteki sonuç, yavaş bağlantıda LCP'de 100 milisaniyelik bir iyileşmedir. Bu, büyük bir gelişme gibi görünmeyebilir ancak çözümün hızlı bir işaretleme düzeltmesi olduğunu ve çoğu web sayfasının bu örnekler grubundan daha karmaşık olduğunu göz önünde bulundurduğunuzda bu gelişmenin önemini anlayabilirsiniz. Bu nedenle, LCP adayları bant genişliği için diğer birçok kaynakla rekabet etmek zorunda kalabilir. Bu nedenle, bu tür optimizasyonlar giderek daha önemli hale gelir.

CSS arka plan resimleri

Tarayıcı ön yükleme tarayıcısının biçimlendirmeyi taradığını unutmayın. background-image özelliği tarafından referans verilen resimler için getirme işlemleri içerebilen CSS gibi diğer kaynak türlerini taramaz.

HTML gibi, tarayıcılar da CSS'yi CSSOM olarak bilinen kendi nesne modeline dönüştürür. CSSOM oluşturulurken harici kaynaklar keşfedilirse bu kaynaklar, keşfedildikleri sırada önceden yükleme tarayıcısı tarafından değil, istenecektir.

Sayfanızın LCP adayı, CSS background-image özelliğine sahip bir öğe olduğunu varsayalım. Kaynaklar yüklenirken olanlar:

Arka plan resmi özelliği kullanılarak CSS&#39;den yüklenen bir LCP adayının bulunduğu sayfayı gösteren bir WebPageTest ağ şelalesi grafiği. LCP adayı resim, tarayıcı önceden yükleme tarayıcısının inceleyemediği bir kaynak türünde olduğundan kaynak, CSS indirilip işlenene kadar yüklenmez. Bu durum, LCP adayının boyama süresini geciktirir.
Şekil 10: Mobil cihazda Chrome'da simüle edilmiş 3G bağlantısı üzerinden çalıştırılan bir web sayfasının WebPageTest ağ şelalesi grafiği. Sayfanın LCP adayı, CSS background-image özelliğine sahip bir öğedir (3. satır). CSS ayrıştırıcı bulana kadar istenen resim getirilmeye başlanmaz.

Bu durumda, önceden yükleme tarayıcısı yenilmez ancak dahil olmaz. Bununla birlikte, sayfadaki bir LCP adayı background-image CSS özelliğinden geliyorsa bu resmi önceden yüklemek isteyebilirsiniz:

<!-- Make sure this is in the <head> below any
     stylesheets, so as not to block them from loading -->
<link rel="preload" as="image" href="lcp-image.jpg">

Bu rel=preload ipucu küçüktür ancak tarayıcının resmi normalde bulacağından daha erken bulmasına yardımcı olur:

Bir CSS arka plan resminin (LCP adayı) rel=preload ipucu kullanılması nedeniyle çok daha erken yüklendiğini gösteren bir WebPageTest ağ şelalesi grafiği. LCP süresi yaklaşık 250 milisaniye iyileşir.
Şekil 11: Bir mobil cihazda Chrome'da simüle edilmiş 3G bağlantısı üzerinden çalıştırılan bir web sayfasının WebPageTest ağ şelalesi grafiği. Sayfanın LCP adayı, CSS background-image özelliğine sahip bir öğedir (3. satır). rel=preload ipucu, tarayıcının resmi ipucu olmadan yaklaşık 250 milisaniye daha erken keşfetmesine yardımcı olur.

rel=preload ipucu sayesinde LCP adayı daha erken keşfedilir ve LCP süresi kısalır. Bu ipucu sorunu düzeltmeye yardımcı olsa da daha iyi bir seçenek, resim LCP adayınızın CSS'den yüklenmesi gerekip gerekmediğini değerlendirmektir. <img> etiketiyle, önceden yükleme tarayıcısının keşfetmesine izin verirken görüntü alanına uygun bir görüntünün yüklenmesi üzerinde daha fazla kontrol sahibi olursunuz.

Çok fazla kaynağın satır içi olarak eklenmesi

Satır içi yerleştirme, bir kaynağı HTML'nin içine yerleştirme uygulamasıdır. <style> öğelerindeki stil sayfalarını, <script> öğelerindeki komut dosyalarını ve base64 kodlaması kullanarak neredeyse tüm diğer kaynakları satır içine alabilirsiniz.

Kaynaklar için ayrı bir istek gönderilmediğinden satır içi kaynaklar, indirilmekten daha hızlı olabilir. Doğrudan belgede yer alır ve anında yüklenir. Ancak önemli dezavantajları vardır:

  • HTML'nizi önbelleğe almıyorsanız (HTML yanıtı dinamikse bunu yapamazsınız) satır içi kaynaklar hiçbir zaman önbelleğe alınmaz. Bu durum, satır içi kaynaklar yeniden kullanılamadığından performansı etkiler.
  • HTML'yi önbelleğe alabilmenize rağmen, satır içi kaynaklar dokümanlar arasında paylaşılmaz. Bu durum, tüm kaynak genelinde önbelleğe alınabilen ve yeniden kullanılabilen harici dosyalara kıyasla önbelleğe alma verimliliğini azaltır.
  • Çok fazla satır içi içerik kullanırsanız bu ek satır içi içeriğin indirilmesi daha uzun sürdüğünden önceden yükleme tarayıcısının belgenin ilerleyen kısımlarındaki kaynakları keşfetmesini geciktirirsiniz.

Bu sayfayı örnek olarak ele alalım. Bazı durumlarda LCP adayı, sayfanın üst kısmındaki resimdir ve CSS, <link> öğesi tarafından yüklenen ayrı bir dosyada bulunur. Sayfada ayrıca CSS kaynağında ayrı dosyalar olarak istenen dört web yazı tipi kullanılıyor.

Dört yazı tipinin referans verildiği harici bir CSS dosyası içeren sayfanın WebPageTest ağ şelalesi grafiği. LCP aday resmi, önceden yükleme tarayıcısı tarafından zamanında keşfedilir.
Şekil 12: Bir mobil cihazda Chrome'da simüle edilmiş 3G bağlantısı üzerinden çalıştırılan bir web sayfasının WebPageTest ağ şelalesi grafiği. Sayfanın LCP adayı, <img> öğesinden yüklenen bir resimdir ancak sayfa yüklemesi için gereken CSS ve yazı tipleri ayrı kaynaklarda yüklendiğinden önceden yükleme tarayıcısı tarafından keşfedilir. Bu durum, önceden yükleme tarayıcısının işini yapmasını geciktirmez.

Peki CSS ve tüm yazı tipleri Base64 kaynakları olarak satır içine yerleştirilirse ne olur?

Dört yazı tipinin referans verildiği harici bir CSS dosyası içeren sayfanın WebPageTest ağ şelalesi grafiği. Önceden yükleme tarayıcısının LCP resmini bulması önemli ölçüde gecikiyor .
Şekil 13: Mobil cihazda Chrome'da simüle edilmiş 3G bağlantısı üzerinden çalıştırılan bir web sayfasının WebPageTest ağ şelale grafiği. Sayfanın LCP adayı, bir <img> öğesinden yüklenen bir resimdir ancak CSS'nin ve dört yazı tipi kaynağının `` içine yerleştirilmesi, bu kaynaklar tamamen indirilene kadar önceden yükleme tarayıcısının resmi keşfetmesini geciktirir.

Bu örnekte satır içi yerleştirmenin etkisi, LCP ve genel performans açısından olumsuz sonuçlar doğuruyor. Sayfanın satır içi olmayan sürümü, LCP resmini yaklaşık 3,5 saniyede oluşturur. Her şeyi satır içi olarak içeren sayfa, LCP resmini 7 saniyeden biraz daha uzun bir süre sonra oluşturur.

Burada sadece önceden yükleme tarayıcısından daha fazlası söz konusudur. Base64, ikili kaynaklar için verimsiz bir biçim olduğundan satır içi yazı tipleri kullanmak iyi bir strateji değildir. Bir diğer faktör de CSSOM tarafından gerekli olmadığı belirlenmediği sürece harici yazı tipi kaynaklarının indirilmemesidir. Bu yazı tipleri Base64 olarak satır içi yapıldığında, geçerli sayfa için gerekli olup olmadıklarına bakılmaksızın indirilir.

Ön yükleme bu durumda işe yarar mı? Elbette. LCP resmini önceden yükleyerek LCP süresini azaltabilirsiniz ancak önbelleğe alınamayan HTML'nizi satır içi kaynaklarla şişirmenin başka olumsuz performans sonuçları vardır. İlk Zengin İçerikli Boyama (FCP) da bu kalıptan etkilenir. Sayfanın hiçbir şeyin satır içi olmadığı sürümünde FCP yaklaşık 2, 7 saniyedir. Her şeyin satır içi olduğu sürümde FCP yaklaşık 5, 8 saniyedir.

Özellikle Base64 kodlu kaynaklar olmak üzere, HTML'ye satır içi ekleme yaparken çok dikkatli olun. Çok küçük kaynaklar dışında genellikle önerilmez. Mümkün olduğunca az satır içi kullanın. Çok fazla satır içi kullanmak risklidir.

İstemci tarafı JavaScript ile işaretleme oluşturma

JavaScript'in sayfa hızını etkilediği kesin. Geliştiriciler, etkileşim sağlamak için bu teknolojiden yararlanmanın yanı sıra içeriklerin kendisini sunmak için de bu teknolojiyi kullanma eğilimindedir. Bu durum, bazı açılardan daha iyi bir geliştirici deneyimi sunar ancak geliştiricilere sağlanan avantajlar her zaman kullanıcılara da yansımayabilir.

Ön yükleme tarayıcısını devre dışı bırakabilecek bir kalıp, istemci tarafı JavaScript ile işaretleme oluşturmaktır:

Resim ve metin içeren temel bir sayfanın JavaScript&#39;te istemcide tamamen oluşturulduğunu gösteren bir WebPageTest ağ şelalesi. İşaretleme JavaScript içinde yer aldığından, önceden yükleme tarayıcısı kaynakların hiçbirini algılayamaz. JavaScript çerçevelerinin gerektirdiği ek ağ ve işleme süresi nedeniyle tüm kaynaklar ayrıca gecikir.
Şekil 14: Bir mobil cihazda Chrome'da simüle edilmiş 3G bağlantısı üzerinden çalıştırılan istemci tarafında oluşturulmuş bir web sayfasının WebPageTest ağ şelale grafiği. İçerik JavaScript'te yer aldığından ve oluşturmak için bir çerçeveye bağlı olduğundan, istemci tarafında oluşturulan işaretlemedeki resim kaynağı önceden yükleme tarayıcısından gizlenir. Bunun sunucu tarafında oluşturulmuş eşdeğer deneyimi Şekil 9'da gösterilmektedir.

Biçimlendirme yükleri tarayıcıda JavaScript tarafından tamamen içerilip oluşturulduğunda, bu biçimlendirmedeki tüm kaynaklar ön yükleme tarayıcısı için görünmez olur. Bu durum, önemli kaynakların keşfedilmesini geciktirir ve LCP'yi etkiler. Bu örneklerde, LCP resmi isteği, görünmek için JavaScript gerektirmeyen eşdeğer sunucu tarafında oluşturulmuş deneyime kıyasla önemli ölçüde gecikiyor.

Bu, makalenin odak noktasından biraz uzaklaşsa da istemcideki işaretlemeyi oluşturmanın etkileri, önceden yükleme tarayıcısını devre dışı bırakmanın çok ötesine geçer. Örneğin, JavaScript'i gerektirmeyen bir deneyimi desteklemek için JavaScript'i kullanmak, Interaction to Next Paint (INP) metriğini etkileyebilecek gereksiz işlem süresine yol açar. İstemcide çok büyük miktarlarda işaretleme oluşturmak, aynı miktarda işaretlemenin sunucu tarafından gönderilmesine kıyasla uzun görevler oluşturma olasılığı daha yüksektir. Bunun nedeni, JavaScript'in içerdiği ek işleme dışında, tarayıcıların sunucudan işaretleme akışı yapması ve oluşturmayı uzun görevleri sınırlayacak şekilde parçalamasıdır. Diğer taraftan, istemci taraflı oluşturulan işaretleme tek ve yekpare bir görev olarak işlenir. Bu durum, sayfanın INP'sini etkileyebilir.

Bu senaryonun çözümü şu sorunun yanıtına bağlıdır: Sayfanızın işaretlemesinin istemcide oluşturulmak yerine sunucu tarafından sağlanamamasının bir nedeni var mı? Bu sorunun cevabı "hayır" ise mümkün olduğunda sunucu tarafında oluşturma (SSR) veya statik olarak oluşturulan işaretleme kullanılmalıdır. Bu yöntemler, önceden yükleme tarayıcısının önemli kaynakları önceden keşfedip fırsatçı bir şekilde getirmesine yardımcı olur.

Sayfanızın, sayfa işaretlemenizin bazı bölümlerine işlevsellik eklemek için JavaScript'e ihtiyacı varsa, bunu SSR ile yapmaya devam edebilirsiniz. Bu durumda, hem vanilla JavaScript'i hem de hydration işlemini kullanarak her iki yöntemin avantajlarından yararlanabilirsiniz.

Ön yükleme tarayıcısının size yardımcı olmasına izin verme

Önceden yükleme tarayıcısı, başlangıç sırasında sayfaların daha hızlı yüklenmesine yardımcı olan oldukça etkili bir tarayıcı optimizasyonudur. Önemli kaynakları önceden keşfetme yeteneğini engelleyen kalıplardan kaçınarak yalnızca geliştirme sürecini basitleştirmekle kalmaz, aynı zamanda bazı web verileri de dahil olmak üzere birçok metrikte daha iyi sonuçlar sağlayacak daha iyi kullanıcı deneyimleri oluşturursunuz.

Özetlemek gerekirse bu yayından çıkarmanız gereken önemli noktalar şunlardır:

  • Tarayıcı ön yükleme tarayıcısı, daha önce getirilebilecek kaynakları fırsatçı bir şekilde keşfetmek için engellendiğinde birincil tarayıcıdan önce tarama yapan ikincil bir HTML ayrıştırıcısıdır.
  • İlk gezinme isteğinde sunucu tarafından sağlanan işaretlemede bulunmayan kaynaklar, önceden yükleme tarayıcısı tarafından keşfedilemez. Ön yükleme tarayıcısının devre dışı bırakılabileceği yöntemler arasında şunlar yer alır (ancak bunlarla sınırlı değildir):
    • JavaScript ile DOM'a kaynak yerleştirme (komut dosyaları, resimler, stil sayfaları veya sunucudan gelen ilk işaretleme yükünde daha iyi olacak başka bir şey).
    • JavaScript çözümü kullanarak ilk bakışta görünen alanın üst kısmındaki resimleri veya iFrame'leri geç yükleme.
    • İstemcide, JavaScript kullanarak doküman alt kaynaklarına referanslar içerebilecek işaretleme oluşturuluyor.
  • Ön yükleme tarayıcısı yalnızca HTML'yi tarar. Bu araç, LCP adayları da dahil olmak üzere önemli öğelere referanslar içerebilecek diğer kaynakların (özellikle CSS) içeriğini incelemez.

Herhangi bir nedenle, önceden yükleme tarayıcısının yükleme performansını hızlandırma yeteneğini olumsuz etkileyen bir kalıptan kaçınamıyorsanız rel=preload kaynak ipucunu kullanmayı düşünebilirsiniz. rel=preload kullanıyorsanız istediğiniz etkiyi sağladığından emin olmak için laboratuvar araçlarında test edin. Son olarak, çok fazla kaynak önceden yüklemeyin. Her şeye öncelik verdiğinizde hiçbir şey öncelikli olmaz.

Kaynaklar

Mohammad Rahmani tarafından Unsplash'ten alınan hero resim.