Tarayıcı ön yükleme tarayıcısının ne olduğunu, performansa nasıl yardımcı olduğunu ve yoldan nasıl kaçınabileceğinizi öğrenin.
Sayfa hızını optimize etme konusunda göz ardı edilen konulardan biri, tarayıcının iç öğeleri hakkında biraz bilgi sahibi olmaktır. Tarayıcılar, performansı iyileştirmek için geliştiriciler olarak yapamadığımız şekilde belirli optimizasyonlar yapar, ancak bu optimizasyonlar 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 gönderide, önceden yükleme tarayıcısının nasıl çalıştığı ve daha da önemlisi, soruna neden olmaktan nasıl kaçınabileceğiniz ele alınmaktadır.
Önceden yükleme tarayıcısı nedir?
Her tarayıcının, ham işaretlemeyi tokene alan ve bunu bir nesne modeline işleyen birincil HTML ayrıştırıcısı vardır. Ayrıştırıcı, <link> öğesiyle yüklenen stil sayfası veya async ya da defer özelliği olmayan <script> öğesiyle yüklenmiş komut dosyası gibi bir engelleme kaynağı bulduğunda bu şekilde tüm süreç devam eder.
<link> öğesine çalışır. Bu durumda, CSS indirilip ayrıştırılana kadar tarayıcının dokümanın geri kalanını ayrıştırması, hatta herhangi bir öğeyi oluşturması engellenir.
CSS dosyaları söz konusu olduğunda, biçimlendirilmemiş içeriğin flash'ını (FOUC) önlemek için hem ayrıştırma hem de oluşturma engellenir. Bu, stiller uygulanmadan önce bir sayfanın stilsiz sürümünün kısa süreliğine görünebilmesidir.
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ısı işini yaparken tarayıcının, belirli bir komut dosyasının DOM'de değişiklik yapıp yapmayacağını bilememesidir. Bu nedenle, engellenen ayrıştırma ve oluşturmanın etkilerinin marjinal hale gelmesi için JavaScript'inizi dokümanın sonunda yüklemek yaygın bir uygulamadır.
Bunlar, tarayıcının hem ayrıştırma hem de oluşturmayı engellemesi için iyi nedenlerdir. Yine de bu önemli adımlardan herhangi birinin engellenmesi istenmeyen bir durumdur çünkü diğer önemli kaynakların keşfedilmesini geciktirerek şovun devam etmesini sağlayabilirler. Neyse ki tarayıcılar, önceden yükleme tarayıcısı adı verilen ikincil bir HTML ayrıştırıcısı aracılığıyla bu sorunları azaltmak için ellerinden geleni yapar.
<body> öğesinde resim işaretlemesini işlemeye başlamadan önce CSS'yi yükleyip işlerken engellenir ancak ön yükleme tarayıcısı, bu resim kaynağını bulmak ve birincil HTML ayrıştırıcısının engeli kaldırılmadan önce yüklemek için ham işaretlemeye bakabilir.
Önceden yükleme tarayıcısının rolü tahmine dayalıdır. Bu, birincil HTML ayrıştırıcısı tarafından başka şekilde keşfedilmeden önce, uygun şekilde getirilecek kaynakları bulmak için ham işaretlemeyi incelediği anlamına gelir.
Önceden 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ırmanın engellenmesi nedeniyle mevcuttur. Bu iki performans sorunu hiç var olmadıysa, önceden yükleme tarayıcısı çok kullanışlı olmazdı. Bir web sayfasının önceden yükleme tarayıcısından yararlanıp yararlanmayacağının belirlenmesinin 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ı belirlemeye yönelik isteklere yapay bir gecikme süresi uygulayabilirsiniz.
Örnek olarak bir stil sayfası içeren temel metin ve resimlerden oluşan bu sayfayı ele alalım. CSS dosyaları hem oluşturma hem de ayrıştırma işlemlerini engellediğinden, proxy hizmeti üzerinden stil sayfası için iki saniyelik yapay bir gecikme süresi uygularsınız. Bu gecikme, önceden yükleme tarayıcısının çalıştığı ağ şelalesinde görmeyi kolaylaştırır.
Şelalede görebileceğiniz gibi, önceden yükleme tarayıcısı, oluşturma ve belge ayrıştırma işlemleri engellenmiş olsa bile <img> öğesini keşfeder. Bu optimizasyon olmadan, tarayıcı engelleme süresi boyunca öğeleri fırsatsal bir şekilde getiremez ve daha fazla kaynak isteği eşzamanlı yerine ardışık olur.
Bu oyuncak örneğini ortaya koyduğumuzda, önceden yükleme tarayıcısının bozulabileceği gerçek dünyadaki bazı kalıplara ve bunları düzeltmek için neler yapılabileceğine bakalım.
Yerleştirilen async komut dosyası
<head> içinde aşağıdaki gibi bir 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 şeklindedir. Dolayısıyla, bu komut dosyası yerleştirildiğinde, async özelliği uygulanmış gibi davranır. Bu, en kısa sürede çalışacağı ve oluşturmayı engellemeyecek anlamına gelir. Kulağa ideal geliyor, değil mi? Yine de bu satır içi <script> öğesinin harici bir CSS dosyası yükleyen bir <link> öğesinden sonra geldiğini varsayarsanız optimum olmayan bir sonuç elde edersiniz:
async komut dosyası içeriyor. Önceden yükleme tarayıcısı, komut dosyası istemciye eklendiği için oluşturma engelleme aşamasında bu komut dosyasını keşfedemez.
Burada yaşananların ayrıntılarına inelim:
- 0. saniyede ana belge istenir.
- 1,4 saniyede, gezinme isteğinin ilk baytı gelir.
- 2, 0.saniyede CSS ve resim istenir.
- Ayrıştırıcının stil sayfasını yüklemesi engellenmiş olduğundan ve
asynckomut dosyasını yerleştiren satır içi JavaScript, bu stil sayfasından 2,6.saniyede sonra geldiğinden, komut dosyasının sağladığı işlev en kısa sürede kullanılamaz.
Komut dosyası isteği yalnızca stil sayfasının indirme işlemi bittikten sonra gerçekleştiğinden bu durum optimum 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 bulunabilir olduğundan önceden yükleme tarayıcısı tarafından bulunur.
Peki, komut dosyasını DOM'ye eklemek yerine async özelliğine sahip normal bir <script> etiketi kullanırsanız ne olur?
<script src="/yall.min.js" async></script>
Sonuç şudur:
async <script> öğesi içerir. Önceden 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ği ima edilebilir. Bu kesinlikle işe yarar ancak bazı yan etkileri olabilir. Sonuçta, DOM'ye <script> öğesi yerleştirmeyerek önlenebilecek bir sorunu düzeltmek için neden rel=preload kullanmalısınız?
async komut dosyası bulunuyor. Ancak async komut dosyası, daha kısa sürede keşfedilmesi için önceden yüklenmiş.
Önceden yükleme sorunu buradaki "düzeltir" ancak yeni bir sorunu beraberinde getirir: İlk iki demodaki async komut dosyası (<head> içinde yüklü olmasına rağmen) "Düşük" öncelikte, stil sayfası ise "En Yüksek" öncelikte yüklenir. async komut dosyasının önceden yüklendiği son demoda stil sayfası hâlâ "En yüksek" öncelikte yüklenmiştir, ancak komut dosyasının önceliği "Yüksek"e yükseltilmiştir.
Bir kaynağın önceliği artırıldığında tarayıcı buna daha fazla bant genişliği ayırır. Bu durum, stil sayfası en yüksek önceliğe sahip olsa da komut dosyasının yükseltilmiş önceliğinin bant genişliği çakışmasına neden olabileceği anlamına gelir. Bu, yavaş bağlantılarda veya kaynakların çok büyük olduğu durumlarda etkileyen bir faktör olabilir.
Yanıt çok basittir: Başlatma sırasında bir komut dosyası gerekirse önceden yükleme tarayıcısını DOM'ye ekleyerek bozmayın. <script> öğe yerleşiminin yanı sıra defer ve async gibi özelliklerle gerektiğinde denemeler yapın.
JavaScript ile geç yükleme
Geç yükleme, genellikle resimlere uygulanan harika bir veri koruma yöntemidir. Ancak bazen geç yükleme, deyim yerindeyse "ekranın üst kısmı" olan resimlere yanlış bir şekilde uygulanır.
Bu durum, önceden yükleme tarayıcısının söz konusu olduğu durumlarda kaynak keşfedilebilirliğiyle ilgili olası sorunlara yol açabilir ve bir resmin referansını keşfetme, indirme, kodunu çözme ve sunma süresini gereksiz yere geciktirebilir. Bu resim işaretlemesini örnek olarak alalım:
<img data-src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
data- önekinin kullanımı, JavaScript destekli geç yükleyicilerde yaygın olarak görülen bir kalıptır. Resim, görüntü alanına kaydırıldığında geç yükleyici data- önekini kaldırır. Önceki örnekte data-src, src olur. Bu güncelleme, tarayıcının kaynağı getirmesini ister.
Bu kalıp, başlatma sırasında görüntü alanındaki resimlere uygulanana kadar sorun yaratmaz. Önceden yükleme tarayıcısı, data-src özelliğini src (veya srcset) özelliğinde olduğu gibi okumadığından, resim referansı daha önce keşfedilmez. Daha da kötüsü, geç yükleyici JavaScript'in indirilmesi, derlenmesi ve yürütülmesinden sonra resmin yüklenmesi gecikir.
Resmin boyutuna bağlı olarak (görüntü alanının boyutuna bağlı olabilir) Largest Contentful Paint (LCP) için aday öğe olabilir. Önceden yükleme tarayıcısı, resim kaynağını tahmine dayalı olarak önceden getiremediğinde(muhtemelen sayfanın stil sayfalarının oluşturmayı engellediği bir zamanda) LCP olumsuz etkilenir.
Çözüm, resim işaretlemesini değiştirmektir:
<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
Önceden yükleme tarayıcısı, resim kaynağını daha hızlı bir şekilde keşfedip getirdiğinden, bu, başlatma sırasında görüntü alanında olan görüntüler için en uygun kalıptır.
Bu basitleştirilmiş örnekte sonuç, yavaş bir bağlantıda LCP'de 100 milisaniyelik bir iyileşme sağlar. Bu çok 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 grubundan daha karmaşık olduğunu düşündüğünüzde ortaya çıkar. Bu da LCP adaylarının bant genişliği için diğer birçok kaynakla başa çıkması gerekebileceği anlamına gelir. Dolayısıyla, bunun gibi optimizasyonlar giderek daha önemli hale gelir.
CSS arka plan resimleri
Tarayıcı ön yükleme tarayıcısının işaretlemeyi taradığını unutmayın. background-image özelliği tarafından başvurulan resimler için getirme içerebilen CSS gibi diğer kaynak türlerini taramaz.
HTML gibi tarayıcılar da CSS'yi, CSSOM olarak bilinen kendi nesne modeli halinde işler. Harici kaynaklar CSSOM oluşturulurken keşfedilirse bu kaynaklar önceden yükleme tarayıcısı tarafından değil, keşif sırasında istenir.
Sayfanızın LCP adayının, CSS background-image özelliğine sahip bir öğe olduğunu varsayalım. Kaynaklar yüklenirken şunlar gerçekleşir:
background-image özelliğine sahip bir öğedir (3. satır). İstediği resim, CSS ayrıştırıcısı tarafından bulana kadar getirmeye başlamaz.
Bu durumda, önceden yükleme tarayıcısı müdahale edilmediği kadar yenilenmez. Yine de sayfadaki bir LCP adayı bir background-image CSS mülkündense 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üçük olsa da tarayıcının resmi, normalde olduğundan daha erken keşfetmesine yardımcı olur:
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 bulmasına yardımcı olur.
rel=preload ipucuyla LCP adayı daha erken keşfedilir ve LCP süresi azalır. Bu ipucu bu sorunu çözmeye yardımcı olsa da resim LCP adayınızın CSS'den yüklenip yüklenmediğini değerlendirmek daha iyi olabilir. <img> etiketiyle, önceden yükleme tarayıcısının resmi keşfetmesine izin verirken görüntü alanına uygun olan bir resmi yükleme üzerinde daha fazla kontrole sahip olursunuz.
Çok fazla kaynağı satır içine alma
Satır içine alma, bir kaynağı HTML içine yerleştirme işlemidir. Stil sayfalarını <style> öğelerinde, <script> öğelerinde komut dosyalarını ve base64 kodlamasını kullanarak neredeyse tüm diğer kaynakları satır içine alabilirsiniz.
Kaynak için ayrı bir istek gönderilmediğinden kaynakları satır içine almak, indirmekten daha hızlı olabilir. Doküman, dokümanın içinde yer alır ve anında yüklenir. Ancak, bazı önemli dezavantajlar mevcuttur:
- HTML'nizi önbelleğe almıyorsanız ve HTML yanıtı dinamikse bunu yapamıyorsanız satır içi kaynaklar hiçbir zaman önbelleğe alınmaz. Satır içi kaynaklar yeniden kullanılamadığından bu durum performansı etkiler.
- HTML'yi önbelleğe alabilseniz bile, satır içi kaynaklar dokümanlar arasında paylaşılmaz. Bu, kaynağın tamamında önbelleğe alınıp yeniden kullanılabilecek harici dosyalara kıyasla önbelleğe alma verimliliğini azaltır.
- Çok fazla satır içine yazarsanız önceden yükleme tarayıcısının belgedeki kaynakları keşfetmesini geciktirirsiniz çünkü fazladan, satır içi içeriğin indirilmesi daha uzun sürer.
Örnek olarak bu sayfayı ele alalım. Belirli koşullarda LCP adayı, sayfanın üst kısmındaki resimdir ve CSS, <link> öğesi tarafından yüklenen ayrı bir dosyada bulunur. Sayfada, CSS kaynağından ayrı dosyalar olarak istenen dört web yazı tipi de kullanılıyor.
<img> öğesinden yüklenen bir resimdir, ancak CSS ve sayfa için gereken yazı tipleri ayrı kaynaklarda yüklendiğinden, önceden yükleme tarayıcısı tarafından keşfedilir. Bu durum, ön yükleme tarayıcısının işini geciktirmesine neden olmaz.
CSS ve tüm yazı tipleri base64 kaynakları olarak satır içi içine alınmışsa ne olur?
<img> öğesinden yüklenen bir resimdir, ancak CSS'nin satır içi ve "" içinde dört yazı tipi kaynağı, bu kaynaklar tamamen indirilene kadar ön yükleme tarayıcısının resmi bulmasını geciktirir.
Satır içi satıra eklemenin etkisi, bu örnekte LCP ve genel olarak performans açısından olumsuz sonuçlar doğurur. Sayfanın hiçbir şeyi satır içi yapmayan sürümü, LCP resmini yaklaşık 3,5 saniye içinde boyar. Her şeyi satır içine alan sayfa, LCP resmini 7 saniyeden biraz daha uzun bir süreye kadar boyamaz.
Burada, önyükleme tarayıcısından daha fazlası sizi bekliyor. Base64, ikili kaynaklar için verimsiz bir biçim olduğundan yazı tiplerini satır içi yapmak ideal bir strateji değildir. Önemli bir başka faktör de CSSOM tarafından gerekli olmadığı sürece harici yazı tipi kaynaklarının indirilmemesidir. Bu yazı tipleri base64 olarak satır içine alındığında geçerli sayfa için gerekli olup olmadığına bakılmaksızın indirilir.
Önceden yükleme yapmak buradaki özellikleri iyileştirebilir mi? Elbette. LCP resmini önceden yükleyebilir ve LCP süresini azaltabilirsiniz. Ancak önbelleğe alınamayan HTML'nizi satır içi kaynaklarla doldurmak, performansla ilgili başka olumsuz sonuçlar doğurur. İlk Zengin İçerikli Boyama (FCP) de 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.
Öğeleri, özellikle base64 kodlu kaynakları HTML içine satır içine alma konusunda çok dikkatli olun. Çok küçük kaynaklar dışında, genel olarak önerilmez. Mümkün olduğunca az satır içi yapın çünkü çok fazla satır için ateş etmek gerekir.
İstemci tarafı JavaScript ile işaretleme oluşturma
Hiç kuşku yok: JavaScript, sayfa hızını kesinlikle etkiliyor. Geliştiriciler, etkileşim sağlamak için bu teknolojiden yararlanmanın yanı sıra içerik sunma konusunda da yapay zekadan yararlanma eğilimindedir. Bu bazı açılardan geliştirici deneyimini iyileştirir ancak geliştiricilere yönelik olan avantajlar her zaman kullanıcılara avantajlar sağlamaz.
Önceden yükleme tarayıcısını geçersiz kılabilecek kalıplardan biri, istemci taraflı JavaScript ile işaretlemeyi oluşturmaktır:
İşaretleme yükleri tarayıcıdaki JavaScript'in içine yerleştirildiğinde ve tamamen oluşturulduğunda, söz konusu işaretlemedeki kaynaklar önceden yükleme tarayıcısı tarafından etkili bir şekilde görünmez. Bu durum, önemli kaynakların keşfedilmesini geciktirir ve bu durum LCP'yi kesinlikle etkiler. Bu örneklerde, LCP resmine yönelik istek, JavaScript'in görünmesi için gerekli olmayan, sunucu tarafından oluşturulmuş eşdeğer deneyimle karşılaştırıldığında önemli ölçüde gecikmiştir.
Bu, bu makalenin odağından biraz saptır ancak oluşturma işaretlemesinin istemci üzerindeki etkileri, önceden yükleme tarayıcıyı geçersiz kılmanın çok ötesine geçer. Birincisi, gerektirmeyen bir deneyimi desteklemek için JavaScript'i kullanmak, Sonraki Boyamayla Etkileşimi (INP) etkileyebilecek gereksiz işleme süresine yol açar. İstemcide çok büyük miktarlarda işaretleme oluşturulduğunda, sunucu tarafından gönderilen aynı miktarda işaretleme ile karşılaştırıldığında uzun görevler oluşturulma ihtimali artar. Bunun nedeni, JavaScript'in içerdiği ekstra işlemenin yanı sıra, tarayıcıların işaretlemeyi sunucudan aktarması ve oluşturmayı, uzun görevleri sınırlama eğiliminde olacak şekilde parçalara ayırmasıdır. Diğer yandan, istemci tarafından oluşturulan işaretleme, tek bir monolitik görev olarak ele alınır ve bu görev bir sayfanın INP değerini etkileyebilir.
Bu senaryonun çö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 soruya verilen yanıt "hayır" ise, mümkün olduğunda sunucu tarafı oluşturma (SSR) veya statik olarak oluşturulan işaretleme dikkate alınmalıdır. Bu, ön yükleme tarayıcısının önemli kaynakları önceden keşfetmesine ve fırsat kapsamında önceden getirmesine yardımcı olacaktır.
Sayfanızda, sayfa işaretlemenizin bazı bölümlerine işlev eklemek için JavaScript gerekirse bunu SSR ile (vanilya JavaScript veya hidrasyon) kullanarak her iki yöntemden de en iyi şekilde yararlanabilirsiniz.
Önceden yükleme tarayıcısının size yardımcı olmasına yardımcı olun
Önceden yükleme tarayıcısı, sayfaların başlatma sırasında daha hızlı yüklenmesine yardımcı olan, son derece etkili bir tarayıcı optimizasyonudur. Önemli kaynakları önceden keşfetmesini engelleyen kalıplardan kaçınarak yalnızca geliştirmeyi kendiniz için daha basit hale getirmekle kalmaz, 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 almak isteyeceğiniz noktalar şunlardır:
- Tarayıcı önceden yükleme tarayıcısı, daha erken getirebileceği kaynakları fırsatsal olarak keşfetmesi engellenirse 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. Önceden yükleme tarayıcısını geçersiz kılma yöntemleri şunları içerebilir (ancak bunlarla sınırlı değildir):
- JavaScript ile DOM'ye kaynak (komut dosyası, resim, stil sayfası veya sunucudan gelen ilk işaretleme yükünde daha iyi olması gereken başka herhangi bir şey) yerleştirme.
- Ekranın üst kısmındaki resimleri veya iframe'leri JavaScript çözümü kullanarak geç yükleme.
- JavaScript kullanan belge alt kaynaklarına referanslar içerebilecek istemci oluşturma işaretlemesi.
- Önceden yükleme tarayıcısı yalnızca HTML'yi tarar. LCP adayları dahil olmak üzere önemli öğelere referanslar içerebilen diğer kaynakların (özellikle de CSS'lerin) içeriklerini incelemez.
Herhangi bir nedenle, önceden yükleme tarayıcısının yükleme performansını hızlandırma becerisini olumsuz etkileyen bir kalıptan kaçınamıyorsanız rel=preload kaynak ipucunu dikkate alın. rel=preload kullanıyorsanız istediğiniz etkiyi sağladığından emin olmak için laboratuvar araçlarında test edin. Son olarak da çok fazla kaynağı önceden yüklemeyin. Her şeye öncelik verdiğinizde hiçbir şey olmaz.
Kaynaklar
- Komut dosyası tarafından yerleştirilen "eş zamansız komut dosyaları" zararlı olarak kabul edilir
- Tarayıcı Ön Yükleyicisi Sayfaların Daha Hızlı Yüklemesini Nasıl Sağlar?
- Yükleme hızını iyileştirmek için önemli öğeleri önceden yükleyin
- Algılanan sayfa hızını iyileştirmek için ağ bağlantılarını erkenden oluşturun
- Largest Contentful Paint'i Optimize Etme
Mohammad Rahmani 'nin hazırladığı Unsplash'teki hero resim.