Bir sayfanın Largest Contentful Paint (LCP) değerini iyileştirmek karmaşık olabilir. Bu işlem genellikle birden fazla değişkeni ve değiş tokuşları içerir. Bu yayında, geliştiricilerin optimizasyon çalışmalarına nerelerde odaklanmaları gerektiğini belirlemek için web'deki gerçek sayfa yüklemelerinden elde edilen alan verileri inceleniyor.
Klasik LCP tavsiyesi: Resimlerinizin boyutunu küçültün.
Web'deki çoğu sayfa için LCP öğesi bir resimdir. Bu nedenle, LCP'yi iyileştirmenin en iyi yolunun LCP resminizi optimize etmek olduğunu varsaymak doğaldır.
LCP'nin kullanıma sunulmasından bu yana yaklaşık beş yıl içinde, genellikle başlıktaki tavsiye bu olmuştur. Resimlerinizin uygun boyutta ve yeterince sıkıştırıldığından emin olun. Bu sırada 21. yüzyıla uygun bir resim biçimi kullanabilirsiniz. Lighthouse'ta bu önerileri yapmak için üç farklı denetim bile vardır.
Bu tavsiyenin yaygın olmasının bir nedeni, fazla baytların ölçülmesinin ve resim sıkıştırma araçlarının önerilmesinin kolay olmasıdır. Derleme ve dağıtım ardışık düzenlerinize bağlı olarak da uygulanması kolay olabilir.
Öyleyse bunu yapın. Kullanıcılarınıza daha az bayt göndermek neredeyse her zaman avantaj sağlar. Web'de, temel sıkıştırma işlemlerinin bile çözebileceği gereksiz yere büyük resimler sunmaya devam eden birçok site var.
Ancak LCP süresinin genellikle nerede harcandığını görmek için Chrome'daki kullanıcıların alan performansı verilerine bakmaya başladığımızda, resim indirme süresinin neredeyse hiçbir zaman darboğaz olmadığını tespit ettik.
Bunun yerine, LCP'nin diğer bölümleri çok daha büyük bir sorundur.
LCP alt bölüm dökümü
LCP'yi iyileştirmek için en büyük fırsat alanlarının neler olduğunu anlamak amacıyla, LCP'yi optimize etme bölümünde açıklandığı gibi LCP alt bölümlerinden gelen verilere baktık.
Her sayfa ve her çerçeve, sayfanın LCP öğesi olacak öğeyi yükleme ve görüntüleme konusunda farklı bir yaklaşım benimseyebilir. Ancak her biri aşağıdaki alt bölümlere ayrılabilir:
Bu makaleden alıntı yaparak alt bölümleri şu şekilde sıralayabiliriz:
- İlk Bayta Erişim Süresi (TTFB)
- Kullanıcının sayfayı yüklemeye başladığı andan tarayıcının HTML dokümanı yanıtının ilk baytını aldığı ana kadar geçen süre.
- Kaynak yükleme gecikmesi
- TTFB ile tarayıcının LCP kaynağını yüklemeye başladığı zaman arasındaki süre. LCP öğesinin oluşturulması için kaynak yükleme gerekmiyorsa bu süre
0
olur. - Kaynak yükleme süresi
- LCP kaynağının kendisinin yüklenmesi için geçen süre. LCP öğesinin oluşturulması için kaynak yükleme gerekmiyorsa bu süre
0
olur. - Öğe oluşturma gecikmesi
- LCP kaynağının yüklenmesinin tamamlanması ile LCP öğesinin tamamen oluşturulması arasındaki süre.
Gerçek navigasyon performansı verileri
LCP derecelendirmesi | TTFB (ms) | Resim yükleme gecikmesi (ms) | Resim yükleme süresi (ms) | Oluşturma gecikmesi (ms) |
---|---|---|---|---|
İyi | 600 | 350 | 160 | 230 |
Gelişime açık | 1.360 | 720 | 270 | 310 |
Yetersiz | 2.270 | 1.290 | 350 | 360 |
Bu yayında, LCP alt bölümlerine göz atmak için Chrome'da alt kaynak resmi LCP'si olan sayfa gezinmelerinden elde edilen verileri kullandık. Bu tür verilere daha önce de baktık, ancak gerçek kullanıcıların bir sayfanın LCP'sini beklerken zamanlarını nerede geçirdiğini görmek için hiçbir zaman saha verilerini kullanmadık.
Core Web Vitals'ta olduğu gibi, CrUX veri kümesindeki her kaynak için her LCP alt bölümünün 75. yüzdelik dilimini (p75) aldık. Bu işlem sonucunda, p75 değerlerinin dört dağılımı (her alt bölüm için bir tane) elde edildi. Bu dağılımları özetlemek için dört LCP alt bölümünün her biri için tüm kaynaklardaki bu değerlerin medyan değerini aldık.
Son olarak, 75. yüzdelik dilimde"iyi", "iyileştirme gerektiriyor" veya "yetersiz" LCP değerine sahip olup olmadıklarına göre kaynaklarını gruplara ayırırız. Bu sayede, iyi LCP'ye sahip bir kaynağın kötü LCP'ye sahip bir kaynaktan ne açıdan farklı olduğu gösterilebilir.
LCP resminizin boyutunu küçültmek mi istiyorsunuz? Bu kez verilerle
Yükleme süresi, LCP kaynağının (bu durumda bir resim) getirilmesinin ne kadar sürdüğünü ölçer. Bu süre genellikle resimdeki bayt sayısıyla orantılıdır. Bu nedenle, tüm performans önerileri bu bayt sayısını azaltmayla ilgilidir.
Önceki grafiklerde zamanın nereye harcandığını incelediğimizde, resim yükleme süresinde çok fazla zaman harcanmadığını görüyoruz. Aslında tüm LCP gruplarındaki en kısa LCP alt bölümüdür. LCP değeri düşük kaynaklarda yükleme süresi, LCP değeri yüksek kaynaklara kıyasla daha uzundur ancak yine de zamanın büyük bir kısmı bu aşamada harcanmaz.
LCP'si düşük olan kaynakların çoğu, p75 LCP sürelerinin% 10'undan azını LCP resmini indirmek için harcar.
Evet, resimlerinizin optimize edildiğinden emin olmanız gerekir ancak bu, LCP'yi iyileştirmenin yalnızca bir parçasıdır. Bu verilerden, web'deki tipik bir kaynak için sıkıştırma şeması ne kadar karmaşık olursa olsun LCP'nin genel olarak milisaniye cinsinden potansiyel kazançlarının küçük olduğu açıkça görülüyor.
Son bir sürpriz: Yavaş yükleme süreleri eskiden genellikle mobil cihazlar ve mobil ağların kalitesinden kaynaklanıyordu. Bir zamanlar, kablolu bağlantı üzerinden masaüstü bilgisayarla aynı görüntüyü indirmek için tipik bir telefonun birkaç kat daha uzun süre almasını bekleyebilirdik. Veriler, artık böyle olmadığını gösteriyor. LCP'si düşük olan kaynaklarda, p75 medyan resim yükleme süresi mobil cihazlarda masaüstünden yalnızca% 20 daha yavaştır.
İlk Bayta Erişim Süresi (TTFB)
Ağ isteği yapan gezinmelerde TTFB her zaman biraz zaman alır. DNS araması yapmak ve bağlantı başlatmak zaman alır. Fizik kurallarına da uymanız gerekir: Bir isteğin sunucuya ulaşması için gerçek dünyada kablolar ve optik kablolar üzerinden ilerlemesi, ardından yanıtın geri dönmesi gerekir. İyi LCP'ye sahip olan ortalama kaynak bile 75. yüzdelik dilimde TTFB için yarım saniyeden fazla zaman harcıyor.
Ancak iyi ve kötü LCP kaynakları arasındaki TTFB farkı, iyileştirme fırsatı olduğunu gösteriyor. Kötü LCP'ye sahip kaynakların en az yarısında, 2.270 milisaniyelik p75 TTFB yalnızca p75 LCP'nin 2,5 saniyelik "iyi" eşiğinden daha hızlı olamayacağını neredeyse garanti eder. Bu sürenin yüzde olarak azalması bile önemli bir LCP iyileştirmesi anlamına gelir.
Fiziği yenemeyebilirsiniz ancak yapabileceğiniz şeyler vardır. Örneğin, kullanıcılarınız genellikle sunucularınızdan çok farklı bir konumdaysa CDN, içeriğinizi onlara daha yakın hale getirebilir.
Daha fazla bilgi için TTFB'yi optimize etme kılavuzuna bakın.
Yavaş LCP'nin gözden kaçan suçlusu: Kaynak yükleme gecikmesi
TTFB iyileştirilebilir ancak iyileştirmeler fizik kurallarına bağlıysa kaynak yükleme gecikmesi ortadan kaldırılabilir. Bu durum, pratikte yalnızca sunma mimarinize bağlıdır.
Bu alt bölüm, HTML yanıtının ilk baytının gelmesi (TTFB) ile tarayıcının LCP resmi için istek başlattığı zaman arasında geçen süreyi ölçer. Yıllardır LCP resimlerinin indirilmesinin ne kadar sürdüğüne odaklandık ancak tarayıcıya indirme işlemini başlatması söylenmeden önce boşa geçen süreyi genellikle göz ardı ettik.
LCP'si düşük olan ortalama bir site, LCP resmini indirmeye başlamak için beklerken bu işlemin kendisinin dört katı kadar süre harcar.Bu siteler, TTFB ile resim isteği arasında 1,3 saniye beklemektedir. Bu, tek bir alt bölümde 2,5 saniyelik LCP bütçesinin yarısından fazlasının kullanıldığı anlamına gelir.
Bağımlılık zincirleri, uzun yükleme gecikmelerinin yaygın bir nedenidir. Daha basit bir örnek olarak, tarayıcı düzeni oluşturduktan sonra LCP olacak bir arka plan resmi ayarlayan bir stil sayfası yükleyen bir sayfa verilebilir. Tüm bu adımların, tarayıcı LCP resmini indirmeye başlamadan önce gerçekleşmesi gerekir.
HTML belgesinden LCP resmine kadarki ağ isteklerinin "başlatıcı" zincirini kaydeden HTTP Archive herkese açık tarama verilerini kullanarak, istek zinciri uzunluğunun daha yavaş LCP ile net bir ilişkisi olduğunu görebilirsiniz.
Önemli olan, tarayıcıya LCP'nin ne olacağını mümkün olan en kısa sürede bildirmektir. Böylece tarayıcı, sayfanın düzeninde yer açmadan önce bile LCP'yi yüklemeye başlayabilir. Bunu yapmak için birkaç araç vardır. Örneğin, HTML'de klasik bir <img>
etiketi kullanarak önyükleme tarayıcısıyla hızlıca bulunabilir ve indirilebilir hale getirilebilir. <img>
olarak kullanılmayacak resimler için de <link rel="preload">
etiketi (veya HTTP üst bilgisi) kullanılabilir.
Tarayıcıya hangi kaynaklara öncelik vereceğini belirlemesi için yardımcı olmak da önemlidir. Bu durum, özellikle sayfanız sayfa yükleme sırasında çok sayıda istek gönderiyorsa geçerlidir. Tarayıcılar, genellikle bu kaynakların çoğu yüklenip sayfa düzeni oluşturulana kadar LCP öğesinin ne olacağını bilemez. Olası LCP öğesine fetchpriority="high"
özelliği ekleyerek (ve loading="lazy"
özelliğinden kaçındığınızdan emin olarak) tarayıcının kaynağı hemen yüklemeye başlamasını sağlayabilirsiniz.
Yükleme gecikmesini optimize etme hakkında daha fazla öneri
Oluşturma gecikmesi
Oluşturma gecikmesi, tarayıcıda LCP resminin yüklenmiş ve hazır olduğu, ancak bir nedenle ekranda gösterilmeden önce gecikme olduğu zamanı ölçer. Bazen bu, resim hazır olduğunda ana iş parçacığını engelleyen uzun bir görevdir. Diğer durumlarda, gizli bir öğeyi göstermek için kullanıcı arayüzü seçimi olabilir.
Web'deki tipik kaynak için büyük bir oluşturma gecikmesi fırsatı yok gibi görünse de optimizasyon sırasında bazen daha önce diğer alt kısımlarda harcanan zamandan oluşturma gecikmesi oluşturabilirsiniz. Örneğin, bir sayfa LCP resmini hızlıca kullanılabilir hale getirmek için önceden yüklemeye başlarsa artık uzun bir yükleme gecikmesi olmaz. Ancak sayfanın kendisi resmi göstermeye hazır değilse (ör. büyük bir oluşturma işlemini engelleyen stil sayfası veya herhangi bir şey gösterilmeden önce tüm JavaScript'ini yüklemesi gereken istemci tarafı oluşturma uygulaması) LCP yine olması gerekenden daha yavaş olur ve bekleme süresi artık oluşturma gecikmesi olarak gösterilir. Bu nedenle, sunucu tarafı oluşturma veya statik HTML, LCP söz konusu olduğunda genellikle avantajlıdır.
Kendi içeriğiniz etkileniyorsa oluşturma gecikmesini optimize etme hakkında daha fazla bilgi edinin.
Tüm bu alt parçaları kontrol edin
LCP'yi etkili bir şekilde optimize etmek için geliştiricilerin yalnızca resimleri optimize etmeye odaklanmak yerine sayfa yükleme işlemine bütünsel olarak bakmaları gerektiği açıktır. LCP'ye kadar geçen sürenin her bölümünü kontrol edin. Çünkü iyileştirme için çok daha büyük fırsatlar olabilir.
Bu verileri sahada toplamak için web-vitals kitaplığının ilişkilendirme derlemesi, LCP alt bölümlerinin zamanlamalarını içerir. Chrome Kullanıcı Deneyimi Raporu (CrUX) henüz bu verilerin tümünü içermiyor ancak TTFB ve LCP ile ilgili girişler bulunduğundan başlangıç için iyi bir kaynaktır. Bu yayında kullanılan verileri gelecekte CrUX'a dahil etmeyi umuyoruz. Bu konuyla ilgili gelişmelerden haberdar olmak için takipte kalın.
LCP alt bölümlerini yerel olarak test etmek için Core Web Vitals uzantısını veya bu makaledeki JavaScript snippet'ini deneyin. Lighthouse, "Largest Contentful Paint öğesi" denetiminde de dökümünü içerir. Yakında kullanıma sunulacak Geliştirici Araçları Performans panelinde LCP alt bölümleriyle ilgili daha fazla tavsiye bulabilirsiniz.