En hızlı ve en iyi optimize edilmiş kaynak, gönderilmeyen kaynaktır. Gereksiz kaynakları uygulamanızdan kaldırmalısınız. Gizli ve açık varsayımları ekibinizle birlikte sorgulamak ve düzenli aralıklarla gözden geçirmek iyi bir uygulamadır. Aşağıda birkaç örnek verilmiştir:
- Sayfalarınıza her zaman X kaynağını ekliyorsunuz. Peki bu kaynağı indirmenin ve göstermenin maliyeti, kullanıcıya sağladığı değeri dengeliyor mu? Ürünün değerini ölçebiliyor ve kanıtlayabiliyor musunuz?
- Kaynak (özellikle üçüncü taraf bir kaynaksa) tutarlı bir performans sağlıyor mu? Bu kaynak kritik yolda mı veya olmalı mı? Kaynak kritik yoldaysa sitede soruna yol açan tek bir nokta olabilir mi? Yani kaynağın kullanılamaması, sayfalarınızın performansını ve kullanıcı deneyimini etkiliyor mu?
- Bu kaynağın HDS'si var mı? Bu kaynak en iyi performans uygulamalarına (sıkıştırma, önbellek vb.) uygun mu?
Çoğu zaman sayfalarda gereksiz ve hatta ziyaretçiye ya da barındırdıkları siteye fazla değer katmadan sayfa performansını engelleyen kaynaklar bulunur. Bu, birinci taraf ve üçüncü taraf kaynaklar ile widget'lar için aynı şekilde geçerlidir:
- A Sitesi, ziyaretçilerin tek tıklamayla birden çok fotoğrafı önizleyebilmeleri için ana sayfasına bir fotoğraf bandı yerleştirmeye karar vermiştir. Sayfa yüklendiğinde tüm fotoğraflar yüklenir. Kullanıcı, fotoğraflar arasında ilerler.
- Soru: Kaç kullanıcının ruloda birden fazla fotoğraf görüntülediğini ölçtünüz mü? Çoğu ziyaretçinin hiçbir zaman görüntülemediği kaynakların indirilmesi, yüksek düzeyde ek yüke neden olabilir.
- B Sitesine alakalı içerikleri görüntülemek, sosyal medya katılımını iyileştirmek veya başka bir hizmet sunmak için üçüncü taraf bir widget yüklemeye karar verilmiştir.
- Soru: Kaç ziyaretçinin widget'ı kullandığını veya widget'ın sağladığı içeriği tıkladığını izlediniz mi? Bu widget'ın oluşturduğu etkileşim, ek yükünü haklı çıkarmaya yetecek kadar mı? Ayrıca ihtiyaca kadar komut dosyasının yüklenmediğinden emin olmak için bir yükleme stratejisi kullanmanız mümkün mü?
Gereksiz indirmelerin kaldırılıp kaldırılmayacağına karar verirken genellikle dikkatlice düşünmek ve ölçümler yapmak gerekir. En iyi sonuçlara ulaşmak için düzenli olarak envanter hazırlayın ve sayfalarınızdaki her öğe için bu soruları gözden geçirin.
Core Web Vitals üzerindeki etkiler
Core Web Vitals ilkesi, kullanıcıların web'i kullanırken yaşadıkları deneyimi yansıtan bir dizi metrik sağlamak amacıyla Google tarafından kullanıma sunulmuştur. Core Web Vitals için pek çok optimizasyon stratejisi olsa da bir sayfaya belirli bir kaynağın yüklenip yüklenmeyeceğini sorgulamak, web sitenizdeki bu metrikleri iyileştirmenin yolunu açabilir. Aşağıda, her bir Core Web Vitals'a göre gruplandırılmış ve üzerinde düşünülmeye değer birkaç örnek verilmiştir. Bu listenin her şeyi kapsamadığını (ve bununla ilgili çok sayıda örnek olduğunu) düşünebilirsiniz. Bu örnekleri okumak size biraz fikir verebilir.
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) en büyük içeriğin (ör. hero resim veya başlık) yüklendiği zamanı ölçer. Kullanıcıya sitenin hızlı yüklendiği izlenimini veren önemli bir algısal metrik olarak kabul edilir.
Genel olarak daha az kaynak indirmek, kullanıcının sahip olduğu bant genişliğinin daha az kaynakta dağıtılacağı anlamına gelir ve LCP'de iyileşme sağlayabilir. Klasik bir örnek olarak geç yükleme yöntemi, sayfa yükleme sırasında görüntü alanının dışında kalan resimlerin tarayıcı tarafından kullanıcının görme olasılığının daha yüksek olduğunu belirleyene kadar indirilmez. Söz gelimi 50 resim içeren büyük bir küçük resim galeriniz varsa, ilk onsu hariç tümünün geç yüklenmesi, tarayıcının mevcut bant genişliğini daha verimli bir şekilde kullanabileceği ve kullanıcının göreceği ilk resimlerin daha hızlı yükleneceği anlamına gelir.
Ancak burada amaç daha az resim yüklemek değildir. Tarayıcıda, her kaynağın ne kadar bant genişliği alacağını belirleyen dahili bir önceliklendirme şeması bulunur. Ancak bu tüm kaynaklar, özellikle de yüksek öncelikte indirilenler ile bile potansiyel bir LCP öğesinin bağımlı kaynağından yoksun olabilir. Bu durum özellikle yavaş ağ bağlantılarında geçerlidir. Bu bağımlı kaynak, sayfanın LCP öğesini temsil eden bir resim dosyası olabileceği gibi, tarayıcının, sayfanın LCP öğesi olarak belirlenebilecek bir metin düğümünü oluşturması için gereken bir web yazı tipi kaynağı da olabilir.
Web sitenizde çok fazla metin varsa bir sayfanın LCP öğesi metin düğümü olabilir. Birçok iyi yazı tipi optimizasyonu ve yükleme stratejisi olsa da, metin düğümleri olan LCP öğelerinin bir web yazı tipi kaynağına bağımlı olmadan yüklenebilmesi ve CSS ve HTML sunucudan geldiği anda boyanabilmesi için bir sistem yazı tipinin web sitenizin ihtiyaçları için yeterli olup olmadığını değerlendirmek yararlı olabilir.
Cumulative Layout Shift (CLS)
Yüklediğiniz her kaynak, özellikle ilk boyama sırasında indirme işlemi bitmemişse bir sayfanın Cumulative Layout Shift (CLS) ayarına katkıda bulunabilir. Resimler için, açık boyutları ayarlama gibi işlemler içeren CLS'lerden kaçının. Yazı tiplerinde, yazı tipi yükleme ve potansiyel olarak yedek yazı tipi eşleştirmeyi yönetmek, web yazı tipinin değiştirme süresi boyunca kaymaları en aza indirebilir. JavaScript için bu komut dosyasının DOM'yi nasıl değiştirdiğini yöneterek düzen kaymalarının kabul edilebilir bir miktara düşmesini sağlayabilir.
Bir sayfanın CLS'sine katkıda bulunan her kaynak, sayfa düzeninin yeterince kararlı olmasını sağlamak için bir miktar çalışma gerektirir. Belirli bir kaynağa ihtiyacınız olup olmadığını sorgulayarak yalnızca sayfa yüklemelerini hızlandırmakla kalmaz, sayfa düzeninin kararlılığını korumak için gereken bilişsel çabayı da azaltmış olursunuz. Böylece daha az can sıkıcı kullanıcı deneyimi sunmakla kalmaz, projelerinizde diğer hedeflere ulaşmak için daha fazla zamanınız olacağı için daha az rahatsız edici bir geliştirici deneyimi yaşarsınız.
Sonraki Boyamayla Etkileşim (INP)
Sonraki Boyamayla Etkileşim (INP), bir sayfanın kullanım süresi boyunca kullanıcı girişlerine verilen duyarlılığı ölçer. Bir sayfanın INP'si, yüklediği JavaScript'ten büyük ölçüde etkilenebilir. Bunun nedeni, JavaScript'in web'de deneyimlediği etkileşimin çoğunu yönlendirmesidir. Özellikle sayfa yükleme sırasında indirilen komut dosyası kaynaklarının miktarı, komut dosyası değerlendirme ve derleme işlemlerinin gerektirdiği yüksek maliyetli olabilecek çalışmalara yol açabilir. Başlatma sırasında ne kadar az JavaScript yüklerseniz tarayıcı, sayfa deneyimindeki kullanıcıların etkileşimde bulunmaya çalışabileceği kritik noktada o kadar az işlem yapar.
Başlatma sırasında indirilen JavaScript kaynaklarının boyutunu azaltmaya yönelik stratejiler (kod bölme ve ağaç sallama gibi) olsa da, gerekli olup olmadıklarını görmek için projelerinizde kullandığınız paketleri denetlemeniz önerilir. Örneğin, lodash bugün hâlâ yararlı olan birçok yönteme sahiptir, ancak tarayıcının kullanıma hazır olarak sağladığı, eşleme, küçültme ve filtreleme için Array
'ye özgü işlevler ve diğer birçok yöntem gibi yöntemlerle birlikte sunulur.
Progresif geliştirme aynı zamanda JavaScript'e faydalı bir yaklaşımdır. Bu sayede, kullanıcılara daha güçlü cihazlara ve daha hızlı ağ bağlantılarına sahip kullanıcılara ekleyebileceğiniz bir temel (ama yine de işlevsel) deneyim sunabilirsiniz. Progresif geliştirme ilkesine bağlı kalsanız da kalmasanız da önemli bir nokta var: İndirmekten kaçınabileceğiniz her JavaScript kaynağı, kullanıcı etkileşimlerine daha hızlı yanıt veren bir deneyim sağlayabilir. Bu, web performansının çok önemli bir parçasıdır.
Sonuç
Web sitenizi gereksiz indirmelere karşı denetlemek, hızlı kullanıcı deneyimleri sunmanın yalnızca bir tarafı olabilir ancak yüksek etki potansiyeli taşıyan bir yöntemdir. Özetle:
- Sayfalarınızda kendi öğelerinizin ve üçüncü taraf öğelerinizin envanterini çıkarın.
- Her öğenin performansını (değerini ve teknik performansını) ölçün.
- Kaynakların yeterli değer sağlayıp sağlamadığını belirlemek.
- Gereksiz indirmelerin Core Web Vitals'a ve destekleyici metrikler üzerindeki etkisini anlayın.
Bu şekilde içerik verimliliğini optimize ettiğinizde yalnızca performansı genel olarak iyileştirmekle kalmaz, aynı zamanda kullanıcıların bant genişliğini kaybetmemeye ve kullanıcı merkezli metrikleri potansiyel olarak iyileştirmeye ve daha iyi bir kullanıcı deneyimi sunmaya özen göstermiş olursunuz.