Temel performans sorunları

Şu an için resimler, hem toplam aktarım boyutu hem de sayfa başına istek sayısı açısından web'deki en büyük öğelerdir. Ortanca web sayfasının toplam aktarım boyutu Haziran 2022 itibarıyla yaklaşık 2 MB'tır ve yalnızca resimler bunun yaklaşık yarısını oluşturmaktadır. Resim isteklerini optimize etmenin, yapabileceğiniz en büyük performans optimizasyonu olabileceğini söylemek abartı değildir.

Daha sonra, tüm etkinlikler için tek bir resim sunmaya çalışıldığında ortaya çıkan sorunlara yardımcı olmak üzere duyarlı resimlerin nasıl geliştiğini öğreneceksiniz. Bu bölümde, resimlerle ilgili önemli performans metriklerini ve bunları nasıl iyileştirebileceğinizi öğreneceksiniz.

Resim isteklerini erteleme

Resim isteklerinizin olabildiğince küçük ve verimli olmasını sağlamanın çeşitli yollarını öğrenmek üzere olsanız da en hızlı resim isteği her zaman hiç yapılmayan resim olacaktır. Bu yüzden, en başta, kullanıcılarınıza resim öğeleri sunma şeklinde yapabileceğiniz en etkili değişikliğin ne olduğunu paylaşmak istiyorum: loading="lazy" özelliği.

<img src="image.jpg" loading="lazy" alt="…">

Bu özellik, resim isteklerinin kullanıcının görüntü alanına yakın bir yere düşene kadar istenmemesini sağlar ve bu istekleri ilk sayfa yüklemesinden (tarayıcının en yoğun olduğu zamandan) erteler ve bu istekleri kritik oluşturma yolundan kaldırır.

Pratikte olduğu kadar basit bir işlem ise bu özelliğin kullanılmasının performans üzerinde çok büyük bir olumlu etkisi olabilir: Kullanıcının görüntü alanında asla yer almayan bir resim hiçbir zaman istenmez ve bant genişliği kullanıcının hiçbir zaman göremeyeceği resimler için boşa harcanmaz.

Ancak önemli bir nokta var: Bu istekleri ertelemek, mümkün olan en kısa sürede resim isteğinde bulunmak için tarayıcıların hiper optimize edilmiş işlemlerinden yararlanmamak anlamına gelir. img öğelerinde düzenin üst kısmında loading="lazy" kullanılıyorsa ve dolayısıyla sayfa ilk yüklendiğinde kullanıcının görüntü alanında bulunma olasılığı daha yüksekse bu resimler son kullanıcıya önemli ölçüde daha yavaş gelebilir.

Getirme Önceliği

loading özelliği, geliştiricilere web tarayıcılarının isteklere öncelik verme şekli konusunda daha fazla güç sağlamak için yürütülen daha kapsamlı web standartları çalışmasına örnektir.

Tarayıcıların getirme önceliğine ilişkin temel yaklaşımlarını muhtemelen biliyorsunuzdur: Örneğin, bir dokümanın <head> öğesindeki harici bir CSS dosyası isteği, oluşturma işlemini engelleyecek kadar önemli olarak değerlendirilir. </body>'in hemen üzerindeki bir harici JavaScript dosyası için yapılan istek ise oluşturma işlemi tamamlanana kadar ertelenir. Bir <img> öğesindeki loading özelliğinin değeri "geç" ise ilişkili resim isteği, tarayıcı resmin bir kullanıcıya gösterileceğini belirleyene kadar ertelenir. Aksi takdirde, bu resim, sayfadaki diğer resimlerle aynı önceliğe sahip olur.

fetchpriority özelliği, geliştiricilere öğelerin önceliği üzerinde daha ayrıntılı bir kontrol sunarak kaynakları aynı türdeki kaynaklara göre "yüksek" ve "düşük" öncelikli olarak işaretlemenizi sağlar. fetchpriority için kullanım alanları loading özelliğine benzer ancak çok daha geniştir. Örneğin, sayfanın başka bir yerindeki görünür resimlere öncelik vermek için fetchpriority="low" özelliğini yalnızca kullanıcı etkileşiminden sonra ortaya çıkan (söz konusu resmin kullanıcının görüntü alanına denk gelip gelmemesinden bağımsız olarak) veya sayfa oluşturulur oluşturulmaz görüntü alanında hemen görüneceğini önceliklendirmek için fetchpriority="high" kullanabilirsiniz.

fetchpriority tarayıcısının, tarayıcı davranışını temelden değiştirmemesi açısından loading uygulamasından farklı olduğunu unutmayın. Tarayıcıya, belirli öğeleri diğerlerinden önce yüklemesi talimatını vermez. Bunun yerine, öğe istemeyle ilgili verdiği kararlar açısından kritik öneme sahiptir.

Resimlerin etkisini ölçme

Resim öğeleri optimize edilirken algılanan performans genellikle tek başına toplam aktarım boyutundan daha önemlidir ve ölçülmesi daha zordur.

Web Verileri; web sunucusundan yavaş yanıt süresi, oluşturma sorunları ve etkileşim gecikmeleri gibi sorunları vurgulayarak kullanıcıların web deneyimini iyileştirmek için ölçülebilir, üzerinde işlem yapılabilir metrikler ve kılavuzlar sağlar. Önemli Web Verileri, bu hedeflerin bir alt kümesidir. Kullanıcının tek bir sayfadaki doğrudan deneyimine odaklıdır. Birlikte, bir deneyimin kullanıcı için ne kadar hızlı hissettiğini belirleyen teknik ölçümlerdir.

Cumulative Layout Shift

Cumulative Layout Shift (CLS), görsel kararlılık ölçüsüdür. Öğeler yüklendikçe ve sayfa oluşturuldukça sayfadaki içerik düzeninin ne kadar değiştiğini gösteren bir metriktir. Gecikmeli bir web yazı tipinin veya resim kaynağının aniden oluşturulması ya da etkileşimli bir öğenin işaretçinizden uzaklaşması nedeniyle bir sayfanın "atlaması" nedeniyle web'i kullanarak önemli ölçüde zaman geçiren kişiler, uzun metin içinde yerlerini kaybettiler. CLS'nin yüksek olması can sıkıcı bir durum, en kötü de kullanıcı hatasının nedenidir. Örneğin, kullanıcı tıkladığında "iptal" düğmesi, daha önce "onayla" düğmesinin bulunduğu bir alana kaydırılır.

Yüksek yükleme süreleri ve bir düzende kaplayabilecekleri alan nedeniyle, görüntülerin yüksek CLS puanlarının yaygın bir nedeni olması buna neden olabilir.

Modern tarayıcılardaki nispeten son değişiklikler sayesinde, resimler nedeniyle yüksek CLS puanlarından kaçınmak düşündüğünüzden daha kolaydır.

Birkaç yıldır ön uç üzerinde çalışıyorsanız <img> üzerindeki width ve height özelliklerine aşinasınızdır: CSS'nin yaygın bir şekilde kullanılmaya başlamasından önce, bir resmin boyutunu kontrol etmenin tek yolu bunlardı.

<img src="image.jpg" height="200" width="400" alt="…">

Özellikle duyarlı web tasarımı, CSS aracılığıyla yüzdeye dayalı boyutlandırmayı belirtmeyi gerekli kıldığı için, biçimlendirmeyle ilgili endişelerimizi işaretlememizden ayrı tutmak amacıyla bu özellikler kullanımdan kaldırıldı. Duyarlı web tasarımının ilk günlerinde, CSS'mizde (max-width: 100% ve height: auto) belirttiğimiz değerler bunları geçersiz kılacağından, "kullanılmayan width ve height özelliklerini kaldırın" yaygın bir tavsiyeydi.

<img src="image.jpg" alt="…">
img {
  max-width: 100%;
  height: auto;
}

Önceki örnekte olduğu gibi height ve width özelliklerini kaldırdıktan sonra, bu durumda tarayıcının resmin yüksekliğini belirlemek için kullandığı tek yöntem kaynak istemek, resmi ayrıştırmak ve stil sayfaları uygulandıktan sonra düzende kapladığı alanın genişliğine bağlı olarak gerçek en boy oranında oluşturmaktır. Bu sürecin büyük kısmı sayfa oluşturulduktan sonra gerçekleşir ve yeni hesaplanan yükseklik ek düzen kaymasına neden olur.

2019'dan itibaren tarayıcı davranışı, width ve height özelliklerini farklı şekilde işleyecek şekilde güncellendi. Düzendeki bir img öğesinin sabit, piksel tabanlı boyutunu belirlemek için bu özelliklerin değerlerini kullanmak yerine, söz dizimi aynı olsa da bu özelliklerin resmin en boy oranını temsil ettiği düşünülebilir. Modern tarayıcılar, bir img öğesinin içsel en boy oranını sayfa oluşturulmadan önce belirlemek için bu değerleri birbirine bölerek, düzen oluşturulurken resmin kaplayacağı alanı ayırmasını sağlar.

Kural olarak, HTML özelliğindeki yüksekliği geçersiz kılmak için max-width: 100% ile birlikte height: auto değerini belirttiğinizden, <img> üzerinde her zaman height ve width özelliklerini resim kaynağınızın gerçek boyutuyla eşleşen değerlerle kullanmanız gerekir.

<img src="image.jpg" height="200" width="400" alt="…">
img {
  max-width: 100%;
  height: auto;
}

<img> öğelerinizde width ve height özelliklerini kullandığınızda CLS puanının yüksek olmasını önlersiniz.

Bu yaklaşımın köklü tarayıcı davranışına dayalı olduğu için bu yaklaşımın olumsuz bir yönü yoktur. Temel CSS'yi destekleyen tüm tarayıcılar, her zaman olduğu gibi çalışır. İşaretlemenizdeki height ve width özellikleri, stilleriniz tarafından geçersiz kılınır.

width ve height özellikleri, resimleriniz için gerekli düzen alanını ayırarak CLS sorunlarını ustaca önlese de, kullanıcılara bir resmin aktarılmasını ve oluşturulmasını beklerken boş bir boşluk veya düşük kaliteli yer tutucu sunmak da ideal değildir. Yavaş yüklenen görüntülerin ölçülebilir ve algılanabilir etkilerini azaltmak için yapabileceğiniz işlemler olsa da tamamen oluşturulmuş bir görüntüyü kullanıcıya daha hızlı sunmanın tek yolu aktarım boyutunu küçültmektir.

Largest Contentful Paint

Largest Contentful Paint (LCP), kullanıcının görüntü alanındaki en büyük "contentful" öğesini (görünür sayfanın en büyük yüzdesini kaplayan içerik öğesi) oluşturmak için gereken süreyi ölçer. Bu, yüzeyde aşırı spesifik bir metrik gibi görünebilir, ancak kullanıcının perspektifinden sayfanın büyük kısmının oluşturulduğu nokta için pratik bir gösterge işlevi görür. LCP, (algılanan) performansın hayati bir ölçüsüdür.

DOMContentLoaded veya window.onload etkinliği gibi metrikler, geçerli sayfayı yükleme işleminin teknik olarak ne zaman tamamlandığını belirlemek için yararlı olabilir ancak kullanıcının sayfadaki deneyimine karşılık gelmeyebilir. Bir öğenin kullanıcının görüntü alanı dışında oluşturulmasındaki küçük bir gecikme, bu metriklerden herhangi birinde hesaba katılır, ancak gerçek kullanıcılar tarafından büyük olasılıkla tamamen fark edilmez. Uzun bir LCP, kullanıcının bir sayfayla ilgili ilk izleniminin (mevcut görüntü alanının içindeki en önemli içerik) sayfanın yavaş veya tamamen bozulmuş olması anlamına gelir.

LCP tarafından yakalanan kullanıcı algısının, kullanıcı deneyimi üzerinde doğrudan etkisi vardır. Kısa bir süre önce Vodafone tarafından yapılan bir deneme, LCP'deki %31'lik iyileşmenin yalnızca %8 daha fazla satış (kendi başına güçlü bir sonuç) sağlamakla kalmayıp toplam kullanıcı sayısını, potansiyel müşteriye dönüşen ziyaretçi sayısında ("ziyaretçiden potansiyel müşteri oranı") ve alışveriş sepetlerini ziyaret eden kullanıcı sayısında %11'lik bir artış ("alışveriş sepetini ziyaret eden kullanıcı oranı") elde ettiğini ortaya koymuştur.

Web sayfalarının %70'inden fazlasında, ilk görüntü alanındaki en büyük öğe, bağımsız <img> öğesi veya arka plan resmi olan bir öğe olarak resim içerir. Başka bir deyişle, sayfaların LCP puanlarının% 70'i resim performansına dayanır. Bunun nedenini anlamak için fazla hayal gücüne gerek yoktur: Büyük, dikkat çekici resimlerin ve logoların "ekranın üst kısmında" bulunma olasılığı yüksektir.

Web.dev sayfasının konsolunda vurgulanmış LCP

LCP gecikmelerini önlemek için atabileceğiniz birkaç adım vardır: Öncelikle "ekranın üst kısmındaki" bir resimde loading="lazy" belirtmeyin. Çünkü isteği, sayfa oluşturulana kadar geciktirmek, LCP puanınız üzerinde büyük olasılıkla çok olumsuz bir etkiye sahip olabilir. İkinci olarak, fetchpriority="high" kullanıldığında tarayıcıya, bu resmin aktarımının sayfada başka bir yerdeki resimlerden daha öncelikli olması gerektiği konusunda bilgi edinebilirsiniz.

Bu kuralları tam anlamıyla göz önünde bulundurarak, bir sayfanın LCP puanını iyileştirmek için yapabileceğiniz en önemli şey, bu resimleri aktarmak ve oluşturmak için gereken süreyi azaltmaktır. Bunu yapmak için resim kaynaklarınızı mümkün olduğunca küçük ve verimli (kalitelerinden ödün vermeden) tutmanız ve kullanıcıların yalnızca göz atma bağlamları için en anlamlı resim öğelerini aldığından emin olmanız gerekir.

Sonuç

Resim öğeleri, kullanıcılarınızın bant genişliğini en çok kullanan unsurlardır. Bir sayfayı oluşturmak için gereken diğer tüm öğelerin aktarımı sırasında kaybedilen bant genişliği en fazla olan kısımdır. Resimler, etrafındaki sayfa düzeninin oluşturulması sırasında ve oluşturulduktan sonra algılanan performans açısından önemli sorunlar oluşturur. Kısacası, resim öğeleri zarar verir.

Bu kulağa korkutucu olsa da, "web'de daha az resim olması daha iyi olurdu" sözü tek başına performans açısından kesinlikle doğrudur, ancak kullanıcılarına büyük bir zarar da getirir. Görseller web'in önemli bir parçasıdır ve yalnızca performans uğruna anlamlı içeriğin kalitesinden ödün vermemelisiniz.

Bu kursun geri kalanında, resim öğelerimizi destekleyen teknolojiler ve kaliteden ödün vermeden performans üzerindeki etkilerini azaltmak için teknikler hakkında bilgi edineceksiniz.