2020'de sayfa hızını ölçmek için gelişmiş kavramlar

Yayınlanan: 2020-04-09

2020'de sayfa hızını neyin etkilediğini anlamak için önce bir tarayıcının bir web sayfasını nasıl oluşturduğunu anlamamız gerekiyor. DOM, CSSOM, oluşturma ağacı, yeniden akış maliyeti ve DOM türleri gibi sayfa hızı ve web teknolojisi kavramlarına aşina değilseniz, muhtemelen yukarıda bağlantısı verilen makaleyi okuyarak başlamak istersiniz.

Web siteleri ve web tarayıcıları daha karmaşık hale geldikçe, sayfa hızı, bir sayfanın ne kadar büyük olduğundan veya bir sunucunun ne kadar hızlı yanıt verebileceğinden daha fazlası haline gelir. Bu makalede, 2020 ve sonrasında sayfa hızı için yeni ve ortaya çıkan bazı metriklere bakacağız: kaynak isteklerinin sayısı ve boyutu, kritik oluşturma yolu, LCP, CLS ve toplam engelleme süresi.

Bu makale, sayfa hızıyla ilgili dört makaleden oluşan bir dizinin ikincisidir. İlk makaleyi burada bulabilirsiniz: Bir tarayıcı nasıl bir web sayfası oluşturur?

Kaynak isteklerinin sırasını, boyutunu ve sayısını yönetme

Oluşturma işleminin her adımı zaman alır. Web sitenizin nerede yavaş olduğunu ve nasıl hızlandırılacağını bulmanın yolu, sayfayı oluşturma sürecinde tarayıcının kaynakları nasıl kullandığına bakmaktır.

Bu, isteklerin sırasının, sayısının ve boyutunun bugün sayfa hızının ölçülmesinde önemli bir rol oynadığı anlamına gelir.

Kaynak sırası ve kaynak yükü ipuçları optimizasyonunun en önemli katkısı, En Büyük İçerikli Boyama yoluyla TTI'yi (Etkileşim Zamanı) azaltmaktır. Kaynak sıralaması optimizasyonu ile aynı numara ve aynı boyuttaki dosyaları daha kısa sürede yükleyebilir, kullanıcılara ve arama motorlarına ulaştırabilirsiniz.

Kritik İşleme Yolu nedir?

Kritik oluşturma yolu, web sayfasının ekranın üst kısmındaki bölümünü oluşturacak tüm kaynakları içerir.

Sayfanızın toplam yükleme boyutu nedeniyle web sayfanız rakiplerinizin web sayfasından daha yavaş olabilir. Ancak işin püf noktası şu: Diğer iş departmanları sayfanın yükleme boyutunu düzeltmenize izin vermese bile, kritik oluşturma yolunu optimize ederek içeriğinizi rakiplerinizden daha hızlı sunabilirsiniz.

Kritik oluşturma yolu nasıl optimize edilir

Bu, Sergey Chernyshev tarafından oluşturulmuş bir sayfa hızı ve dönüşüm oranı korelasyon simülatörüdür. Web sayfam kullanıcılar için 0,5 saniye daha hızlı yüklenirse ne olur sorusunun cevabını bulabilir ve her milisaniyenin dönüşümü iyileştirebileceğini belirtmek için geliştirici ekibinize gösterebilirsiniz.

Kritik işleme yolunu optimize etmek için, ekranın üst kısmındaki parçanızı oluşturmak için hangi kaynaklara ihtiyacınız olduğunu belirlemeniz gerekir. Bundan sonra sorulması gereken birkaç küçük soru var:

  1. Hangi kaynaklar kritik kaynakların tarayıcı tarafından indirilmesini engelliyor?
  2. Kritik kaynakların boyutu ve sayısı azaltılabilir mi?
  3. Kritik kaynaklar sıralanabilir mi?
  4. DNS arama sürecini sınırlamak için kritik işleme yolu kaynakları birleştirilebilir mi?

Bir örneğe bakacağız. Ayrıca CSS, JS ve HTML'yi hızlandırmak için bazı önerilerde bulunacağız.

İşte bir Amazon web sayfasından kritik bir parça örneği. DevTools ile gerekli CSS kodlarıyla birlikte sayfanın kritik bölümünde en önemli <div> öğesini görebilirsiniz. Bu şekilde, oluşturma engelleme kaynakları tarayıcıyı rahatsız etmeden önce bir satır içi CSS kod bloğu oluşturabilirsiniz. Altta kullanılmayan kod yığınlarını da görebilirsiniz. Amazon, optimize edilmemiş olsalar bile farklı kategoriler için her zaman aynı CSS/JS kaynak modellerini kullanır.

Burada hızın yanında başka bir sorun daha var. Farklı boyutlarda cep telefonu ekranları ile web sayfasının kritik kısmı modelden modele değişir. Bazı ekranlar fiyatı göstermez, bazıları hisse senedi bilgisini göstermez. Bu önemli bir tasarım hatasıdır, ancak kritik işleme yolu optimizasyonunu da zorlaştırır. Ayrıca bu alanda bir bağlantı varsa PageRank değerini de böler ve dönüşüm olasılığını azaltır.

Bu tür bir sorunu incelemek ve her akıllı telefon/tablet modeli için otomatik ekran görüntüsü almak ve web sayfasının kritik bölümünün tasarımını kontrol etmek için Puppeteer'ı (Googlebot'un Tarama Motoru) kullanabilirsiniz. Jean-Francois Lagarde, kontrol etmek isteyebileceğiniz bu görev için güzel bir Kuklacı kitaplığına sahiptir.

Her cihaz görüntüleme aracı için Puppeteer otomatik ekran görüntüsünde cihaz yapılandırması için hızlı bir ekran görüntüsü burada.

En Büyük İçerikli Boya Nedir?

En Büyük İçerikli Boyama (LCP), bir web sayfasındaki bayt ve boyut açısından en büyük alandır. Her web sayfasında çok sayıda “div” öğesi vardır ve bunların hepsi farklı sayfa bileşenleri içerir. Ve bu bileşenlerin farklı sayfa yükleme değerleri vardır.

Google'a göre En Büyük İçerikli Boya, çoğunlukla sayfanın en önemli öğesinden etkilenir. Google, size LCP'nin önemi hakkında bir fikir vermek için bu yeni metriği gelecekte Lighthouse raporlarına eklemeye karar verdi.

Bu aynı zamanda Gerçek Kullanıcı Metrikleri (RUM) ile birlikte kullanılacağı ve özellikle kritik işleme yolu söz konusu olduğunda önemli bir ölçü olacağı için LCP hakkında giderek daha fazla şey duyacağımız anlamına geliyor.

İşte Lendio'dan En Büyük İçerikli Boya örneği. Gördüğünüz gibi DevTools, LCP'yi bir sayfada türü, boyutu ve yükleme süresiyle ilgili verilerle birlikte gösterir. En Büyük Contentful Paint'inizin içeriği, her zaman en önemli işlevsellik veya CTA ile birlikte sayfanın amacını ve değerini içermelidir ve en önemlisi, ilk olarak da yüklenmelidir!

Bu örnekte, yalnızca metindir. İşlevsel bir araçla birleştirmek, yalnızca bir metin/resim LCP'sinden daha iyi olacaktır.

LCP, yalnızca belirli kaynak türlerini dikkate alır. Bunun temel nedeni, başlangıçta LCP ölçümünü basit tutmaktır. Aşağıda, LCP giriş listesini oluşturmak için damgalanmış bir "Komut Dosyası Örneği" bulunmaktadır. Bu kod parçalarını incelemek, Google Developers'ın bir sayfayı yüklerken neye ve nasıl dikkat ettiğini size öğretecektir.

[Exposed=Pencere]
arayüz LargestContentfulPaint : PerformanceEntry {
salt okunur öznitelik DOMHighResTimeStamp renderTime;
salt okunur öznitelik DOMHighResTimeStamp loadTime;
salt okunur özellik imzasız uzun boyut;
salt okunur öznitelik DOMString kimliği;
salt okunur özellik DOMString url'si;
salt okunur özellik Öğe? eleman;
[Varsayılan] nesne toJSON();
};

Bu listede gördükleriniz, LCP giriş listesine giren aday öğelerin karşılaştırılması için gerekli olan ölçeklerdir. Aşağıda, LCP adaylarını seçmek için bir metodoloji göstereceğim (“büyük gövde metni” ve “büyük resim”).

LCP'nizi tanımlamaya yönelik ilkeleri ve süreci anlama

LCP'yi belirleme ilkeleri son derece önemlidir:

  • Bir sayfa yüklenirken LCP saniyeler içinde değişebilir. Bazen bir sayfa bileşeni ekranda LCP olarak yeterince uzun kalsa bile, arkaya yüklenen daha büyük bir sayfa öğesi bile önceki durumu değiştirmez.
  • Bazen, ekranın altındaki daha büyük bir öğe (web sayfasının kritik olmayan kısmı) yerine LCP olarak ekranın üst kısmındaki bir öğe (web sayfasının kritik bölümünde) seçilir.
  • Bileşenleri ekranda bölünmüşse daha büyük bir<div> öğesi LCP olarak seçilemez. Bunun yerine, LCP olarak bir blok <div> öğesi seçilecektir. Aşağıda bunu gösteren bir örnek göreceksiniz.

Bu örnekte, en büyük bileşenin dört farklı görüntü içeren <div> olduğunu görüyoruz. Ancak, bu bağımsız görüntülerin hiçbiri Oncrawl Logosu ve onunla aynı <div> öğesinde bulunan metinden daha büyük değildir. Her ikisi de web sayfasının kritik kısmında olduğundan, ikinci unsur LCP olacaktır.

LCP zamanlamasını hesaplarken ve Google Developers'ın bakış açısını belirlerken “bileşik” tasarıma da odaklanmalısınız. Bir <div> öğesi bileşik ve birleşik tasarım duygusuna/görünümüne sahip değilse, muhtemelen LCP olarak seçilmeyecektir.

Seçilse bile Google Chrome, ileride LCP API'sine katacağı yeni kodlarla bunun sağlıklı bir LCP olmadığını düşünebilir. UX ile ilgili nedenlerle ve sayfa hızının daha iyi anlaşılması için Google, bu yöntemleri kullanarak kendi algısını geliştirmeye devam edecektir.

Düzen Kaydırma ve Kümülatif Düzen Kaydırma nedir?

Mizanpaj kaydırma, bir sayfa tarayıcı tarafından indirilirken, sayfa öğelerinin kullanıcı için rahatsız edici olabilecek şekilde konumlarını değiştirmesi fikridir.

Bir sayfa indirilirken, her sayfa bölümü belirli bir sırayla tek tek görünür olacaktır. Bu normal. Ancak bu parçalar, sonraki parçalar nedeniyle başlangıç ​​konumlarını değiştirirse, bu yerleşim düzenini değiştirir.

Kümülatif Düzen Kaydırma (CLS), tüm düzen değiştirme olaylarının toplamıdır.

Chrome Kullanıcı Deneyimi'nde ayrıca CLS puanıyla ilgili bir bölüm vardır. Ama bu sadece UX ile ilgili değil. Düzen kaydırma, ışığa duyarlı epilepsi hastaları için zararlı olabilir. Bir “sağlık şirketi” olarak Google, kullanıcıların sağlığına da değer vermelidir; mümkün olan her yerde “web stresini” azaltmaya çalışırlar.

“Google'ın zaten bir sağlık şirketi olduğuna inanıyorum. En başından beri şirketin DNA'sında var”
David Feinberg – Google Sağlık Başkanı

Bu seride daha önce gördüğümüz aynı sitelerden birinden basit ve kararlı bir yerleşim değiştirme örneği. Türkiye'den bir ana haber sitesi ve bu onların ana sayfası…

Sağlık için tehlikeli olan Düzen Kaydırma, Titreme, Flaşlar ve Renk Varyasyonları hakkında daha fazla bilgiyi Moz Developers'tan okuyabilirsiniz.

Web sitenizde değişen kümülatif düzen nasıl bulunur?

Web sayfalarınızın değişen düzen kısımlarını görmek için Google Chrome DevTools'u kullanabilir veya tüm web sayfalarınız için süreci ölçeklendirmek için Layout Instability API'yi kullanabilirsiniz.

Kümülatif Mizanpaj Kaydırma veya tüm mizanpaj değiştirme olaylarının toplamı, 2020 ve sonrasında hem sayfa hızı hem de UX için önemli bir kriterdir. Web sayfasının ekranın üst kısmındaki kısım yükleme sırasında kayıyorsa, hız için optimize ederken de optimize etmeniz gerekir.

Aşağıda, Düzen Değiştirme Formülü'nü, ayrıca size CLS'nin katkısına ilişkin bir bakış açısı ve Düzen Değiştirme Puanınızı hesaplamak için bir yöntem sunan Düzen Kararsızlığı API Kodu örneğini bulacaksınız.

Düzen Kaydırma Formülü aşağıdadır:
düzen kaydırma puanı = etki oranı * uzaklık oranı

Düzen Kaydırma puanı, iki faydalı yeni terim olan Etki Kesri ve Mesafe Kesri ile hesaplanır:

  • Etki oranı , kaydırmadan etkilenen ekranın yüzdesidir. Mobil cihazlarda görüntü alanının %50'sini kaplayan sayfa öğesi düzen kayması oluşturursa CLS'nizin yüksek olacağını bilirsiniz, çünkü onu hareket ettirmek ekranın en az %50'sinden fazlasını etkiler.
  • Mesafe fraksiyonu , kaydırma elemanının kaydırma sırasında kaydığı yönde orijinal noktasından ne kadar uzaklaştığı ile ölçülür. İlk ve son konum arasındaki mesafe fazlaysa, Mesafe fraksiyonu da aşırı olacaktır.

Bu, CLS Puanınızı tahmin etmenizi ve BT ve UX ekiplerinize tavsiyede bulunmanızı kolaylaştıracaktır.

Yukarıda, bir CLS API Kod parçacığını ve aşağıda, Kümülatif Düzen Kaydırmasının nasıl hesaplanacağını gösteren bir GIF görebilirsiniz.

Baktığımız aynı Türkçe haber sitesinde CLS'miz 0,47. 0 ile 1 arasında hesaplandığı düşünülürse bu oldukça kötü bir puandır.
CLS'nizi Webpagetest.org'un Gelişmiş Özel Metrik Sistemi ile hesaplayabilirsiniz. “Bilgi Bölümünü Gönderir”e kadar CLS API kodlarını kullanmalısınız. Bundan sonra, URL'nizi root/results/ yerine root/custom_metrics.php?test={Same Result Number} olarak değiştirmeniz gerekir.

Toplam Engelleme Süresi Nedir?

Web sayfanızın ekranın üst kısmındaki kısmı, herhangi bir düzen değişikliği olmadan hızlı bir şekilde indirebilirsiniz, ancak kullanıcının girişine yanıt vermiyorsa, Google Algoritmaları başka bir UX ve sayfa hızı sorununuz olduğunu iddia ediyor. Toplam Engelleme Süresi bu aşamada kaybedilen süredir.

Kümülatif Düzen Kaydırma ve En Büyük İçerikli Boyama gibi, Toplam Engelleme Süresi de 2020 ve sonrası için yeni bir sayfa hızı ve UX ölçümüdür.

Toplam Engelleme Süresi (TBT) için önemli olan, İlk Boyama (FP) ile Etkileşim Süresi (TTI) arasındaki, tarayıcının (veya cihazın) ana iş parçacığını 50 milisaniyeden fazla bloke eden ve kullanıcıların bunu yapmasını engelleyen herhangi bir yükleme olayıdır. herhangi bir işlemi gerçekleştirmek.

TBT nasıl hesaplanır ve optimize edilir

Long Tasks API ile Toplam Engelleme Sürenizi (TBT) hesaplayabilirsiniz.

TBT puanınızı optimize etmek için, isteklerin sayısı ve boyutunun yanı sıra kaynakları yükleme sırasına ve tercihlerine de odaklanmalısınız.

Bu daha önce aynı siteden. Fark edebileceğiniz gibi, ana iş parçacığı 5 saniyeden fazla kesintisiz olarak tamamen meşgul. LCP'leri yaklaşık 2,5 saniye sonra hala yükleniyor… Burada dikkat edilmesi gereken en önemli şey, en uzun görev talebinin 350 MS'den daha uzun olmasıdır. Bu, 300 MS'den fazla ana iş parçacığını engellediği anlamına gelir.

Ayrıca, tüm bloke süreleri, Toplam Blokaj Süresinin bir parçası olarak sayılır. Bu, yalnızca ekranın üst kısmındaki öğeleri içermekle kalmaz, tüm web sayfası bileşenleri için de geçerlidir. Web siteniz için zararlı bir tarayıcı geçmişi oluşturur.

TBT'niz 300 Milisaniyeden fazlaysa, bu muhtemelen kullanıcı tutma ve dönüşüm oranınıza önemli ölçüde zarar verecektir.

Yukarıdaki ana iş parçacığı için TBT için bir hesaplama örneği görebilirsiniz. Bu örnekte, dört istek vardır. Google Chrome, aynı sunucudan aynı anda 6 istek oluşturabilir. Yalnızca ilk 50 MS'si sorunsuz gidecek; bundan sonra CPU/Ağ gücünün izin verdiği ölçüde aynı anda birden fazla görevi yapmaya başlayacaktır. Unutmayın, bir insan her 16 MS'de bir kare görebilir. Google, kullanıcılar için her milisaniyeyi önemser.

Bu örnekte, Toplam Engelleme Süresi 1 saniye ve 100 MS'dir.

Sayfa hızı optimizasyonunda sonraki adımlar

Şimdiye kadar bu dizide, tarayıcıların web sayfalarını nasıl oluşturduğunu inceledik ve bu makalede, sayfaların tarayıcılarda nasıl yüklendiğiyle ilgili yeni metriklerin sayfa hızını nasıl etkileyebileceğini görmemize olanak sağladı. En iyi yeni metriklerden birkaçına ve bunların nasıl ölçülüp optimize edileceğine baktık.

Bu dizinin günümüz web sitelerindeki sayfa hızıyla ilgili bir sonraki makalesinde, SEO ve web geliştirmede önemli bir konu haline gelen bir konuyu ele alacağız: sayfa hızını ve sayfa oluşturmayı iyileştirmek için JavaScript varlıklarını optimize etme.

ÜCRETSİZ deneme sürümünü başlat