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

Tarayıcı ön yükleme tarayıcısının ne olduğunu, performansa nasıl yardımcı olduğunu ve bu tarayıcının yolundan nasıl kaçabileceğinizi öğrenin.

Sayfa hızını optimize etmenin göz ardı edilen bir yönü, tarayıcıların iç işleyişiyle ilgili biraz bilgi sahibi olmaktır. Tarayıcılar, performansı geliştirirken geliştiriciler olarak yapamayacağımız şekilde belirli optimizasyonlar yapar. Ancak bu optimizasyonlar yanlışlıkla engellenmediği sürece bu işlemler gerçekleşir.

Anlaşılması gereken dahili tarayıcı optimizasyonlarından biri tarayıcı ön yükleme tarayıcısıdır. Bu yayında, ön yükleme tarayıcısının işleyiş şekli ve daha da önemlisi, tarayıcının önüne geçmekten nasıl kaçınacağınız ele alınacaktır.

Ön yükleme tarayıcı nedir?

Her tarayıcıda, ham işaretlemeyi tokenize eden ve nesne modeli olarak işleyen birincil bir HTML ayrıştırıcı bulunur. Tüm bu işlemler, ayrıştırıcı bir <link> öğesiyle yüklenen stil sayfası veya async ya da defer özelliği olmayan bir <script> öğesiyle yüklenen komut dosyası gibi bir engelleyici kaynak bulana kadar devam eder.

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

CSS dosyalarında, stil uygulanmamış içeriğin kısa süreliğine gösterilmesi (FOUC) durumunu önlemek için oluşturma işlemi engellenir. Bu durum, bir sayfaya stil uygulanmadan önce sayfanın stil uygulanmamış sürümünün kısa süreliğine gösterilmesidir.

web.dev ana sayfası, stil uygulanmamış durumda (solda) ve stil uygulanmış durumda (sağda).
Şekil 2: FOUC'nin simüle edilmiş bir örneği. Sol tarafta, web.dev'in stil içermeyen ana sayfası gösterilmektedir. Sağ tarafta, stillerin uygulandığı aynı sayfa gösterilmektedir. Bir stil sayfası indirilip işlenirken tarayıcı oluşturmayı engellemezse stilsiz durum kısa sürede ortaya çıkabilir.

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

Bunun nedeni, birincil HTML ayrıştırıcı hâlâ işini yaparken tarayıcının belirli bir komut dosyasının DOM'u değiştirip değiştirmeyeceğini kesin olarak bilememesidir. Bu nedenle, engellenen ayrıştırma ve oluşturma işlemlerinin etkilerinin marjinal hale gelmesi için JavaScript'inizi dokümanın sonuna yüklemek yaygın bir uygulamadır.

Bunlar, tarayıcının hem ayrıştırmayı hem de oluşturmayı engellemesi için iyi nedenlerdir. Ancak bu önemli adımların herhangi birinin engellenmesi istenmez. Çünkü diğer önemli kaynakların keşfini geciktirerek yayını aksatabilir. Neyse ki tarayıcılar, önceden yükleme tarayıcı adı verilen ikincil bir HTML ayrıştırıcı kullanarak bu sorunları azaltmak için ellerinden geleni yapıyor.

Hem birincil HTML ayrıştırıcının (solda) hem de ikincil HTML ayrıştırıcı olan ön yükleme tarayıcısının (sağda) şeması.
Şekil 3: Öğeleri tahmini olarak yüklemek için ön yükleme tarayıcısının birincil HTML ayrıştırıcı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 ön yükleme tarayıcı, bu resim kaynağını bulmak ve birincil HTML ayrıştırıcının engellemesi kaldırılmadan önce yüklemeye başlamak için ham işaretlemeye bakabilir.

Ön yükleme tarayıcısının rolü spekülatiftir. Diğer bir deyişle, birincil HTML ayrıştırıcı bunları keşfetmeden önce fırsatçı bir şekilde getirilecek kaynakları bulmak için ham işaretlemeyi inceler.

Ön yükleme tarayıcısının ne zaman çalıştığını anlama

Önceden yükleme tarayıcı, engellenen oluşturma ve ayrıştırma işlemi nedeniyle mevcuttur. Bu iki performans sorunu hiç yaşanmamış olsaydı ön yükleme tarayıcı pek faydalı olmazdı. Bir web sayfasının ön yükleme tarayıcısından yararlanıp yararlanamayacağını belirlemenin anahtarı bu engelleme fenomenlerine bağlıdır. Bunu yapmak için ön yükleme tarayıcısının nerede çalıştığını öğrenmek üzere istekler için yapay bir gecikme uygulayabilirsiniz.

Stil sayfası içeren temel metin ve resimlerin yer aldığı bu sayfayı örnek olarak alın. CSS dosyaları hem oluşturma hem de ayrıştırma işlemlerini engellediği için bir proxy hizmeti aracılığıyla stil sayfası için iki saniyelik yapay bir gecikme eklersiniz. Bu gecikme, ön yükleme tarayıcısının çalıştığı yeri ağ şelalesinde daha kolay görmenizi sağlar.

WebPageTest ağ şelalesi grafiği, stil sayfasına uygulanan 2 saniyelik yapay bir gecikmeyi gösterir.
Şekil 4: 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. Stil sayfası, yüklenmeye başlamadan önce bir proxy aracılığıyla yapay olarak iki saniye geciktirilmiş olsa da işaretleme yükü içinde daha sonra bulunan resim, ön yükleme tarayıcı tarafından bulunur.

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

Bu oyuncak örneğini bir kenara bırakarak, ön yükleme tarayıcısının atlatılabileceği bazı gerçek dünya kalıplarına ve bunları düzeltmek için neler yapılabileceğine göz atalım.

Enjekte edilen async komut dosyaları

<head> öğenizdeki HTML'de aşağıdaki gibi bazı satır içi JavaScript'lerin bulunduğunu varsayalım:

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

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

Enjekte edilen komut dosyaları varsayılan olarak async olduğundan bu komut dosyası enjekte edildiğinde async özelliği uygulanmış gibi davranır. Bu, mümkün olan en kısa sürede çalışacağı ve oluşturmayı engellemeyeceği anlamına gelir. Kulağa iyi 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 en uygun olmayan sonucu alırsınız:

Bu WebPageTest grafiği, bir komut dosyası eklendiğinde ön yükleme taramasının devre dışı bırakıldığını gösterir.
Ş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. Sayfada tek bir stil sayfası ve enjekte edilmiş bir async komut dosyası vardır. Ön yükleme tarayıcı, istemciye enjekte edildiği için oluşturma engelleme aşamasında komut dosyasını keşfedemez.

Burada ne olduğunu ayrıntılı şekilde inceleyelim:

  1. 0. saniyede ana doküman istenir.
  2. 1, 4 saniyede gezinme isteğinin ilk baytı gelir.
  3. 2, 0 saniyede CSS ve resim istenir.
  4. Ayrıştırıcı, stil sayfasını yüklemesi engellendiğinden ve async komut dosyasını enjekte eden satır içi JavaScript, 2,6 saniyede bu stil sayfasının ardından geldiğinden, komut dosyasının sağladığı işlev mümkün olan en kısa sürede kullanılamaz.

Komut dosyası isteği yalnızca stil sayfası indirildikten sonra gerçekleştiği için bu durum en uygun durum değildir. Bu, komut dosyasının en kısa sürede çalışmasını geciktirir. Buna karşılık, <img> öğesi sunucu tarafından sağlanan işaretlemede bulunabilir olduğu için ön yükleme tarayıcı tarafından bulunur.

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

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

Sonuç şudur:

Bir stil sayfası indirilip 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 asynkron komut dosyasının tarayıcı ön yükleme tarayıcısıyla nasıl bulunabileceğ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ı, oluşturma engelleme aşamasında komut dosyasını bulur ve CSS ile eşzamanlı olarak yükler.

Bu sorunların rel=preload kullanılarak çözülebileceğini öne sürmek cazip gelebilir. Bu yöntem kesinlikle işe yarar ancak bazı yan etkileri olabilir. Sonuçta, DOM'ye <script> öğesi eklenmeyerek önlenebilen bir sorunu düzeltmek için neden rel=preload kullanılsın?

rel=preload kaynak ipucunun, istenmeyen yan etkileri olabilecek bir şekilde olsa da eşzamansız olarak enjekte edilen bir komut dosyasının keşfini desteklemek için nasıl kullanıldığını gösteren bir WebPageTest şelalesi.
Şekil 7: 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 enjekte edilmiş bir async komut dosyası bulunur ancak async komut dosyası, daha erken keşfedilmesini sağlamak için önceden yüklenir.

Ön yükleme, buradaki 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" öncelikli olarak yüklenir. Stil sayfası ise "En yüksek" öncelikli olarak yüklenir. async komut dosyasının önceden yüklendiği son demoda stiller kitabı hâlâ "En yüksek" öncelikte yükleniyor ancak komut dosyasının önceliği "Yüksek" olarak yükseltildi.

Bir kaynağın önceliği yükseltildiğinde tarayıcı buna daha fazla bant genişliği ayırır. Bu, stil sayfası en yüksek önceliğe sahip olsa bile komut dosyasının yükseltilmiş önceliğinin bant genişliği çekişmesine neden olabileceği anlamına gelir. Bu durum, yavaş bağlantılarda veya kaynakların oldukça büyük olduğu durumlarda bir faktör olabilir.

Yanıt basittir: Başlatma sırasında bir komut dosyasına ihtiyaç duyuluyorsa bu komut dosyasını DOM'ye ekleyerek önyükleme tarayıcısını atlatmayın. Gerektiği gibi <script> öğesi yerleşimi ve defer ve async gibi özelliklerle denemeler yapın.

JavaScript ile geç yükleme

Verileri korumak için genellikle resimlere uygulanan harika bir yöntem olan yavaş yükleme, Ancak bazen, "ekranın üst kısmında" olan resimlere yavaş yükleme yanlışlıkla uygulanır.

Bu, ön yükleme tarayıcısıyla ilgili kaynak bulunabilirliğiyle ilgili olası sorunlara yol açar ve bir resme ait referansı bulma, indirme, kodunu çözme ve sunma süresini gereksiz yere uzatabilir. Örnek olarak bu resim işaretlemesini ele alalım:

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

data- ön ekinin kullanılması, JavaScript destekli yavaş yükleyicilerde yaygın bir kalıptır. Resim, görüntü alanına kaydırıldığında, data- ön ekinden data-src kaldırılır. Bu nedenle, önceki örnekte data-src, src olur. Bu güncelleme, tarayıcının kaynağı getirmesini ister.

Bu desen, başlangıç sırasında görüntü alanındaki resimlere uygulanana kadar sorun oluşturmaz. Ön yükleme tarayıcı, data-src özelliğini src (veya srcset) özelliğini okuduğu gibi okumadığından resim referansı daha önce keşfedilmez. Daha da kötüsü, resim, JavaScript'in indirilip derlenip yürütülmesinden sonra yüklenir.

Tarayıcı ön yükleme tarayıcı, resim kaynağını bulamadığı için başlangıç sırasında görüntü alanında bulunan ve yalnızca yavaş yüklemenin çalışması için gereken JavaScript yüklendiğinde yüklenen yavaş yüklenmiş bir resmin nasıl gecikmeli olarak yüklendiğini gösteren bir WebPageTest ağ şelalesi grafiği. Resim olması gerekenden çok daha geç 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ğ şelalesi grafiği. Resim kaynağı, başlangıçta görüntü alanında görünmesine rağmen gereksiz yere yavaş yükleniyor. Bu, ön yükleme tarayıcısını geçersiz kılar ve gereksiz bir gecikmeye neden olur.

Görüntünün boyutuna (görüntü alanı boyutuna bağlı olabilir) bağlı olarak Largest Contentful Paint (LCP) için uygun bir öğe olabilir. Ön yükleme tarayıcı, resim kaynağını önceden tahmini olarak getiremediğinde(muhtemelen sayfanın stil sayfalarının oluşturmayı engellediği noktada) LCP olumsuz etkilenir.

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

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

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

Başlangıç sırasında görüntü alanındaki bir resim için yükleme senaryosunu gösteren bir WebPageTest ağ şelalesi grafiği. Resim, üşengeç şekilde yüklenmez. Yani, yüklenmek için komut dosyasına bağlı değildir. Bu nedenle, ön yükleme tarayıcı tarafından daha erken keşfedilebilir.
Şekil 9: 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ı, CSS ve JavaScript yüklenmeye başlamadan önce resim kaynağını keşfeder. Bu sayede tarayıcı, kaynağı yükleme konusunda avantaj elde eder.

Bu basitleştirilmiş örnekte, yavaş bir bağlantıda LCP'de 100 milisaniyelik bir iyileşme elde edilmiştir. Bu, büyük bir iyileştirme 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 örnek gruplarından daha karmaşık olduğunu göz önünde bulundurduğunuzda bu durum önemli bir gelişmedir. Bu, LCP adaylarının bant genişliği için diğer birçok kaynakla rekabet etmesi gerekebileceği anlamına gelir. 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 işaretleme taradığını unutmayın. background-image mülkü tarafından başvurulan görsellerin getirilmesini içerebilecek CSS gibi diğer kaynak türlerini taramaz.

Tarayıcılar, HTML gibi CSS'yi CSSOM olarak bilinen kendi nesne modelinde işler. CSSOM oluşturulurken harici kaynaklar bulunursa bu kaynaklar, ön yükleme tarayıcısından değil, bulundukları sırada istenir.

Sayfanızın LCP adayı, CSS background-image özelliğine sahip bir öğe olduğunu varsayalım. Kaynaklar yüklenirken aşağıdakiler gerçekleşir:

background-image mülkü kullanılarak CSS&#39;den yüklenen bir LCP adayı içeren bir sayfayı gösteren WebPageTest ağ şelalesi grafiği. LCP aday resmi, tarayıcı ön yükleme tarayıcısının inceleyebileceği bir kaynak türünde olmadığından, CSS indirilip işlenene kadar kaynağın yüklenmesi gecikir. Bu da LCP aday resminin 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ı, istenen resmi bulana kadar getirme işlemine başlamaz.

Bu durumda, ön yükleme tarayıcı devre dışı bırakılmadığı için daha çok devre dışı bırakılmıştır. Yine de sayfadaki bir LCP adayı background-image CSS mülkünden geliyorsa bu resmi önceden yüklemeniz gerekir:

<!-- 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 normalden daha erken keşfetmesine yardımcı olur:

rel=preload ipucunun kullanılması nedeniyle CSS arka plan resminin (LCP adayı) ç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: 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 keşfetmesine kıyasla yaklaşık 250 milisaniye daha erken keşfetmesine yardımcı olur.

rel=preload ipucu sayesinde LCP adayı daha erken bulunur ve LCP süresi kısalır. Bu ipucu bu sorunu düzeltmeye yardımcı olsa da daha iyi seçenek, resim LCP adayınızın CSS'den yüklenip yüklenmemesi gerektiğini değerlendirmek olabilir. <img> etiketi sayesinde, ön yükleme tarayıcısının görseli keşfetmesine izin verirken görüntü alanına uygun bir görsel yükleme konusunda daha fazla kontrole sahip olursunuz.

Çok fazla kaynağı satır içi olarak ekleme

Satır içi, bir kaynağı HTML'nin içine yerleştiren bir uygulamadır. Base64 kodlamayı kullanarak <style> öğelerinde stil sayfalarını, <script> öğelerinde komut dosyalarını ve neredeyse diğer tüm kaynakları satır içine alabilirsiniz.

Kaynak için ayrı bir istek gönderilmediğinden, kaynakları satır içine yerleştirmek indirmekten daha hızlı olabilir. Doğrudan belgede bulunur ve anında yüklenir. Ancak bu yöntemin önemli dezavantajları vardır:

  • HTML'nizi önbelleğe almıyorsanız (ve HTML yanıtı dinamikse bunu yapamazsınız) satır içi kaynaklar hiçbir zaman önbelleğe alınmaz. Satır içi kaynaklar yeniden kullanılamadığı için bu durum performansı etkiler.
  • HTML'yi önbelleğe alabilseniz bile satır içi kaynaklar dokümanlar arasında paylaşılmaz. Bu durum, tüm kaynakta önbelleğe alınabilen ve yeniden kullanılabilen harici dosyalara kıyasla önbelleğe alma verimliliğini azaltır.
  • Çok fazla içeriği satır içi olarak eklerseniz ek satır içi içeriğin indirilmesi daha uzun süreceği için ön yükleme tarayıcı, belgenin sonraki bölümlerindeki kaynakları keşfetmeyi geciktirir.

Bu sayfayı örnek alalım. Belirli koşullarda LCP adayı, sayfanın üst kısmındaki resimdir ve CSS, bir <link> öğesi tarafından yüklenen ayrı bir dosyadadır. Sayfada ayrıca, CSS kaynağından ayrı dosyalar olarak istenen dört web yazı tipi de kullanılıyor.

Dört yazı tipine referans veren harici bir CSS dosyası içeren sayfanın WebPageTest ağ şelalesi grafiği. LCP aday resmi, ön yükleme tarayıcı tarafından uygun zamanda bulunur.
Şekil 12: 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ı, bir <img> öğesinden yüklenen bir resimdir ancak sayfanın yüklenmesi için gereken CSS ve yazı tipleri ayrı kaynaklarda yüklendiğinden önceden yükleme tarayıcı tarafından bulunur. Bu durum, önceden yükleme tarayıcısının işini yapmasını geciktirmez.

CSS ve tüm yazı tipleri Base64 kaynakları olarak satır içi olarak eklenirse ne olur?

Dört yazı tipine referans veren harici bir CSS dosyası içeren sayfanın WebPageTest ağ şelalesi grafiği. Önceden yükleme tarayıcı, LCP resmini keşfetmede önemli ölçüde gecikme yaşıyor .
Ş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ğ şelalesi 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, ön yükleme tarayıcısının bu kaynaklar tamamen indirilene kadar resmi keşfetmesini geciktirir.

Satır içi eklemenin etkisi, bu örnekte LCP ve genel performans açısından olumsuz sonuçlara yol açmaktadır. Sayfanın satır içi hiçbir öğe içermeyen sürümü, LCP resmini yaklaşık 3,5 saniyede boyar. Her şeyi satır içi olarak yerleştiren sayfa, LCP resmini 7 saniyenin biraz üzerine kadar boyamaz.

Burada, ön yükleme tarayıcısından daha fazlası söz konusudur. Base64, ikili kaynaklar için verimsiz bir biçim olduğundan yazı tiplerini satır içine yerleştirmek iyi bir strateji değildir. Etkili olan bir diğer faktör de, harici yazı tipi kaynaklarının CSSOM tarafından gerekli olarak belirlenmediği sürece indirilmemesidir. Bu yazı tipleri base64 olarak satır içi olarak eklendiğinde, geçerli sayfa için gerekli olup olmadığına bakılmaksızın indirilir.

Ön yükleme yaparak bu durumu iyileştirebilir miyiz? Elbette. LCP resmini önceden yükleyebilir ve LCP süresini kısaltabilirsiniz ancak önbelleğe alınamayan HTML'nizi satır içi kaynaklarla şişirmek, performans açısından başka olumsuz sonuçlara da yol açar. İlk Zengin İçerikli Boyama (FCP) da bu kalıptan etkilenir. Sayfanın hiçbir şeyin satır içi yerleştirilmediği sürümünde FCP yaklaşık 2, 7 saniyedir. Her şeyin satır içi olarak yerleştirildiği sürümde FCP yaklaşık 5, 8 saniyedir.

Özellikle base64 kodlu kaynaklar olmak üzere öğeleri HTML'ye yerleştirirken çok dikkatli olun. Genel olarak, çok küçük kaynaklar dışında önerilmez. Çok fazla satır içi eklemek riskli olduğundan mümkün olduğunca az satır içi ekleyin.

İşaretleri istemci tarafı JavaScript ile oluşturma

JavaScript'in sayfa hızını etkilediğine şüphe yok. Geliştiriciler yalnızca etkileşim sağlamak için değil, içerik yayınlamak için de bu platforma güveniyor. Bu, bazı açılardan geliştirici deneyimini iyileştirir ancak geliştiricilere sunulan avantajlar her zaman kullanıcılara da avantaj sağlamaz.

Ön yükleme tarayıcısını atlatabilecek bir yöntem, işaretlemeyi istemci tarafı JavaScript ile oluşturmaktır:

Resim ve metinlerin tamamen istemcide JavaScript&#39;de oluşturulduğu temel bir sayfayı gösteren WebPageTest ağ şelalesi. İşaretleme JavaScript içinde bulunduğundan önceden yükleme tarayıcı hiçbir kaynağı algılayamaz. JavaScript çerçevelerinin gerektirdiği ek ağ ve işleme süresi nedeniyle tüm kaynaklar da geciktirilir.
Şekil 14: Mobil cihazda Chrome'da simüle edilmiş 3G bağlantısı üzerinden çalıştırılan istemci tarafından oluşturulan bir web sayfasının WebPageTest ağ şelalesi grafiği. İçerik JavaScript'te bulunduğu ve oluşturulması için bir çerçeveye ihtiyaç duyduğundan, istemci tarafından oluşturulan işaretlemedeki resim kaynağı ön yükleme tarayıcısından gizlenir. Eşdeğer sunucu tarafından oluşturulan deneyim Şekil 9'da gösterilmektedir.

İşaretçi yükü, tarayıcıda JavaScript tarafından tamamen oluşturulduğunda ve içerdiğinde, bu işaretçideki tüm kaynaklar ön yükleme tarayıcısından görünmez. Bu durum, önemli kaynakların keşfedilmesini geciktirir ve LCP'yi kesinlikle etkiler. Bu örneklerde, LCP resmine yönelik istek, JavaScript'in görünmesini gerektirmeyen eşdeğer sunucu tarafından oluşturulan deneyime kıyasla önemli ölçüde gecikmektedir.

Bu konu, makalenin odak noktasından biraz uzaklaşıyor olsa da işaretlemeyi istemcide oluşturmanın etkileri, ön yükleme tarayıcısını atlatmanın çok ötesine geçer. Örneğin, JavaScript'i gerektirmeyen bir deneyimi desteklemek için JavaScript'i kullanmak, Interaction to Next Paint (INP)'i etkileyebilecek gereksiz işlem süresi oluşturur. İstemcide çok büyük miktarlarda işaretleme oluşturmanın, sunucu tarafından gönderilen aynı miktardaki işaretlemeye kıyasla uzun görevler oluşturma olasılığı daha yüksektir. Bunun nedeni, JavaScript'in gerektirdiği ek işleme dışında, tarayıcıların işaretlemeyi sunucudan aktarması ve oluşturmayı uzun görevleri sınırlayacak şekilde parçalara ayırmasıdır. Öte yandan istemci tarafından oluşturulan işaretleme, tek ve monolitik bir görev olarak ele alınır. Bu da sayfanın INP'sini etkileyebilir.

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

Sayfanızın işaretlemesinin bazı bölümlerine işlev eklemek için JavaScript'e ihtiyacı varsa bu işlemi SSR ile, standart JavaScript ile veya her iki dünyanın da en iyisini elde etmek için hidratasyon ile yapabilirsiniz.

Ön yükleme tarayıcısından size yardımcı olmasını sağlama

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

Özetlemek gerekirse bu gönderiden edinmeniz gereken bilgiler şunlardır:

  • Tarayıcı ön yükleme tarayıcısı, daha önce getirebileceği kaynakları fırsatçı bir şekilde keşfetmek için engellenirse birincil tarayıcıdan önce tarayan ikincil bir HTML ayrıştırıcısıdır.
  • İlk gezinme isteğinde sunucu tarafından sağlanan işaretlemede bulunmayan kaynaklar, ön yükleme tarayıcı tarafından bulunamaz. Önyükleme tarayıcısını atlatmanın yolları şunlardır (ancak bunlarla sınırlı değildir):
    • JavaScript ile DOM'ye kaynak ekleme (ör. komut dosyaları, resimler, stil sayfaları veya sunucudan gelen ilk işaretleme yükünde olması daha iyi olan başka herhangi bir şey).
    • JavaScript çözümü kullanarak sayfanın üst kısmındaki resimleri veya iFrame'leri gecikmeli yükleme.
    • JavaScript kullanarak doküman alt kaynaklarına referanslar içerebilecek işaretlemeyi istemcide oluşturma.
  • Ön yükleme tarayıcı yalnızca HTML'yi tarar. LCP adayları da dahil olmak üzere önemli öğelere referanslar içerebilecek diğer kaynakların (özellikle CSS) içeriklerini incelemez.

Herhangi bir nedenle, ön yükleme tarayıcısının yükleme performansını hızlandırma özelliğini olumsuz yönde etkileyen bir kalıbı önleyemiyorsanız rel=preload kaynak ipucunu kullanabilirsiniz. rel=preload'yi kullanıyorsanız istediğiniz etkiyi sağladığından emin olmak için laboratuvar araçlarında test edin. Son olarak, her şeye öncelik verdiğinizde hiçbir şeye öncelik vermemiş olursunuz. Bu nedenle, çok fazla kaynağı önceden yüklemeyin.

Kaynaklar

Mohammad Rahmani tarafından Unsplash'tan alınan lokomotif resim .