Bir sayfanın Largest Contentful Paint (LCP) özelliği karmaşık olabilir ve genellikle birden fazla hareketli parça ve denge içerir. Bu yayında, geliştiricilerin optimizasyon çabalarını nereye odaklamaları gerektiğini belirlemek için web genelindeki gerçek sayfa yüklemelerinden elde edilen alan verilerine bakılmaktadır.
Klasik LCP önerisi: Resimlerinizin boyutunu küçültün!
Web'deki çoğu sayfada LCP öğesi bir resimdir. Bu durumda, LCP'yi iyileştirmenin en iyi yolunun LCP resminizi optimize etmek olduğunu varsaymak doğaldır.
LCP'nin kullanıma sunulduğu yaklaşık beş yıl içinde bu, genellikle manşetteki tavsiye oldu. Resimlerinizin uygun şekilde boyutlandırıldığından ve yeterince sıkıştırıldığından emin olun. İsterseniz resimlerinizi kullanırken 21. yüzyıla ait bir resim biçimi de kullanabilirsiniz. Hatta Lighthouse'ta bu önerileri yapmak için üç farklı denetim vardır.
Bunun bu kadar yaygın bir tavsiye olmasının nedenlerinden biri, aşırı 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, uygulaması da kolay olabilir.
Varsa yapın! Kullanıcılarınıza daha az bayt göndermek neredeyse her zaman kazançlıdır. Web'de, temel sıkıştırmanın bile düzeltebileceği gereksiz büyüklüklerde resimler yayınlamaya devam eden birçok site vardır.
Bununla birlikte, LCP'ye harcanan sürenin genellikle nereye harcandığını görmek üzere Chrome'daki kullanıcıların saha performansı verilerine baktığımızda, resim indirme süresinin neredeyse hiçbir zaman performans sorunu olmadığını gördük.
Bunun yerine, LCP'nin diğer kısımları ç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 için 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 sergileyebilir. Ancak her sayfa şu alt bölümlere ayrılabilir:
Bu makaleden alıntı yapılan alt bölümler:
- İlk Bayt Zamanı (TTFB)
- Kullanıcının sayfayı yüklemeye başlamasından tarayıcıya kadar geçen süre HTML belgesi yanıtının ilk baytını alır.
- Kaynak yükleme gecikmesi
- TTFB ile tarayıcının LCP kaynağını yüklemeye başlaması arasında geçen süre. Eğer
LCP öğesinin oluşturulması için kaynak yükü gerekmez. Şu anda
0. - Kaynak yükleme süresi
- LCP kaynağının kendisini yüklemek için gereken süre. LCP
öğesinin oluşturulması için kaynak yükü gerekmez. Şu anki değer
0. - Öğe oluşturma gecikmesi
- LCP kaynağının yüklenmesi ile LCP öğesinin yüklenmesi arasındaki süre tamamen oluşturuluyor.
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 gönderide, LCP alt bölümlerini incelemek için Chrome'da alt kaynak resim LCP'sine sahip sayfa gezinmelerinden elde edilen verileri kullandık. Bu tür verileri daha önce inceledik, ancak gerçek kullanıcıların bir sayfanın LCP'sini beklerken zamanlarını nerede harcadıklarını görmek için hiçbir zaman alan verilerinden yararlanamadık.
Core Web Vitals'da 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. Böylece, p75 değerlerinin dört dağıtımı (her alt bölüm için bir tane) elde ettik. Bu dağılımları özetlemek gerekirse dört LCP alt bölümünün her biri için tüm kaynaklardaki bu değerlerin ortanca değerini aldık.
Son olarak, kaynakları "iyi", "iyileştirme gerekli" veya "kötü" durumlarına göre gruplara ayırırız 75. yüzdelik dilimde LCP. Bu şekilde, iyi LCP'ye sahip olan ve LCP'si düşük olan kaynakları ayırt eden özellikleri görebilirsiniz.
LCP resminizin boyutu azaltılsın mı? Bu sefer veri ile
Yükleme süresi, LCP kaynağının (bu örnekte bir resim) getirilmesi için geçen sürenin ölçüsüdür. Bu süre genellikle görüntüdeki bayt sayısıyla orantılıdır. Bu nedenle, tüm performans önerileri söz konusu bayt sayısını azaltmaya yöneliktir.
Önceki grafiklerde zamanın nereye gittiğine bakarken dikkat çeken bir nokta, resim yükleme süresinde çok fazla zaman harcanmadığıdır. Hatta tüm LCP paketlerinde en kısa LCP alt bölümüdür. Zayıf LCP kaynakları için yükleme süresi, iyi LCP kaynaklarıyla karşılaştırıldığında daha uzundur. Ancak bu süre yine de büyük ölçüde zaman harcanmış olan kaynaklar değildir.
Düşük LCP'ye sahip kaynakların çoğu, p75 LCP süresinin% 10'undan azını LCP görüntüsünü indirir.
Evet, resimlerinizin optimize edildiğinden emin olmalısınız. Ancak bu, LCP'yi iyileştirmenin yalnızca bir parçasıdır. Bu veriler, sıkıştırma şeması ne kadar gelişmiş olursa olsun web'deki tipik kaynaklarda genel olarak LCP'nin potansiyel milisaniye kazancının az olduğu açıkça görülüyor.
Son bir sürpriz: Yavaş yükleme süreleri eskiden mobil cihazların yanı sıra mobil ağların kalitesinden de kaynaklanmıştı. Eskiden normal bir telefonun, aynı görüntünün kablolu bağlantı üzerinden bir masaüstü makinesiyle indirilmesinin birkaç kat daha uzun süreceğini tahmin etmiştik. Veriler artık durumun böyle olmadığını gösteriyor. Düşük LCP'ye sahip kaynaklar için ortanca p75 resim yükleme süresi, mobil cihazlarda masaüstüne kıyasla yalnızca% 20 daha yavaştır.
İlk Bayt Zamanı (TTFB)
Ağ isteğinde bulunan gezinmeler için TTFB her zaman biraz zaman alır. DNS araması yapmak ve bağlantı başlatmak zaman alır. Fiziği geçemezsiniz: Bir isteğin bir sunucuya ulaşmak için kablolar ve optik kablolar üzerinden gerçek dünyada seyahat etmesi, sonra da yanıtın seyahati geri alması gerekir. İyi LCP'ye sahip ortanca kaynak bile 75. yüzde birlik dilimde TTFB'de yarım saniyeden fazla zaman geçirir.
Ancak iyi ve zayıf LCP kaynakları arasındaki TTFB uyumsuzluğu, iyileştirme fırsatına işaret eder. Düşük LCP'ye sahip kaynakların en az yarısı için yalnızca 2.270 milisaniyelik p75 TTFB, p75 LCP'nin 2,5 saniyelik "iyi"den daha hızlı olamayacağını neredeyse garanti eder sağlayabilirsiniz. Bu sürenin yüzde olarak azalması bile LCP'de önemli bir iyileşme anlamına gelir.
Fiziği geçemeyebilirsiniz ancak bu konuda yapabileceğiniz şeyler var. Örneğin, kullanıcılarınız genellikle sunucularınızdan çok farklı bir konumdaysa, bir CDN sayesinde içeriğinizi onlara daha yakın hale getirebilirsiniz.
Daha fazla bilgi için TTFB'yi optimize etme kılavuzuna bakın.
Kaynak yükleme gecikmesi, LCP'nin atlanan yavaş olmasının nedeni
TTFB iyileştirilebiliyorsa ancak herhangi bir iyileştirme fiziğe bağlıysa kaynak yükü gecikmesi potansiyel olarak ortadan kaldırılabilir. Bu da pratikte yalnızca sunum mimarinizle sınırlıdır.
Bu alt bölüm, HTML yanıtının ilk baytının (TTFB) gelmesinden tarayıcının LCP resmi için bir istek başlatmasına kadar geçen süreyi ölçer. Uzun yıllardır LCP resimlerini indirmenin ne kadar süreceğine odaklandık, ancak tarayıcıya indirmeyi başlatması bile söylenmeden önce boşa harcanan zamanı genellikle dikkate almayız.
LCP'si zayıf olan ortanca site, LCP resmini indirme işlemini başlatmak için neredeyse dört kat daha uzun süre bekler ve TTFB ile görüntü isteği arasında 1,3 saniye bekler. Bu, 2,5 saniyelik LCP bütçesinin yarısından fazlası tek bir alt bölüme ayrılır.
Bağımlılık zincirleri, uzun yükleme gecikmelerinin yaygın bir nedenidir. Daha basit olan uçta, bir stil sayfası yükleyen sayfa bulunur. Bu sayfa, tarayıcının düzenini yaptıktan sonra LCP'ye dönüşecek bir arka plan resmi ayarlar. Tarayıcı, LCP görüntüsünü indirmeye başlamayı henüz öğrenmeden bu adımların hepsinin gerçekleştirilmesi gerekir.
"Başlatan"ı kaydeden HTTP Arşivi herkese açık tarama verilerini kullanma istek zinciri uzunluğunun daha yavaş LCP ile açık ilişkisini görebilirsiniz.
Önemli olan, LCP'nin ne olacağını mümkün olan en kısa sürede bildirmektir. Böylece, LCP'nin sayfa düzeninde bir yer çıkmadan önce bile sayfayı yüklemeye başlayabilir. Bunu gerçekleştirmek için kullanılabilecek birkaç araç vardır. Örneğin, HTML'deki klasik <img> etiketi ile önceden yükleme tarayıcısının onu hızlı bir şekilde bulup indirmeye başlamasını ya da <img> ile indirilmeyecek resimler için <link rel="preload"> etiketini (veya HTTP üstbilgisini) <br class="ph-2.
Tarayıcının öncelik verilecek kaynakları belirlemesine yardımcı olmak da önemlidir. Bu durum, özellikle sayfanız sayfa yükleme sırasında çok fazla istek gönderiyorsa geçerlidir. Çünkü tarayıcı, çoğu zaman bu kaynakların çoğu yüklenene ve düzen gerçekleşene kadar LCP öğesinin ne olacağını bilemez. Olası LCP öğesine fetchpriority="high" özelliğiyle açıklama eklemek (ve loading="lazy" özelliğini kullanmadığınızdan emin olmak), tarayıcının kaynağı hemen yüklemeye başlamasını kolaylaştırır.
Yükleme süresini optimize etmeyle ilgili daha fazla öneriyi okuyun.
Oluşturma gecikmesi
Oluşturma gecikmesi, LCP resminin tarayıcıda yüklenmesi ve hazırlanmasından itibaren geçen süreyi ölçer, ancak resmin ekranda gösterilmeden önce biraz gecikme yaşanmasını sağlar. Bazen bu, resim hazır olduğunda ana iş parçacığını engelleyen uzun bir görevdir. Bazı durumlarda ise 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ı yoktur, ancak optimizasyon sırasında bazen daha önce diğer alt bölümlerde harcanan süre dışında oluşturma gecikmesi oluşturabilirsiniz. Örneğin, bir sayfa hızlı kullanılabilmesi için LCP resmini önceden yüklemeye başlarsa yükleme gecikmesi uzun sürmez. Ancak sayfanın kendisi resmi görüntülemeye hazır değilse (örneğin, oluşturma engelleyen büyük bir stil sayfasından veya herhangi bir şey gösterilmeden önce tüm JavaScript'ini yüklemesini tamamlaması gereken bir istemci taraflı oluşturma uygulamasından) LCP yine de olması gerekenden daha yavaş olur ve bekleme süresi artık daha yavaş olur ve oluşturma gecikmesi olarak görünür. Bu nedenle, LCP söz konusu olduğunda sunucu tarafı oluşturma veya statik HTML genellikle avantajlıdır.
Kendi içeriğiniz etkileniyorsa oluşturma süresini optimize etmeyle ilgili daha fazla öneriyi okuyun.
Bu alt bölümlerin her birini
LCP'yi etkili bir şekilde optimize etmek için geliştiricilerin sadece resimleri optimize etmeye odaklanmakla kalmayıp sayfa yüklemesini bir bütün olarak ele alması gerektiği açıktır. Muhtemelen çok daha büyük iyileştirme fırsatları olduğundan LCP'yi her aşamada kontrol edin.
Bu verileri alanda toplamak için web-önemlig kitaplığının ilişkilendirme yapısı LCP alt bölümlerinin zamanlamalarını içerir. Chrome Kullanıcı Deneyimi Raporu (CrUX) henüz tüm bu verileri içermese de TTFB ve LCP için girişleri olduğundan, bu bir başlangıç. Bu gönderide kullanılan verileri ileride CrUX'e eklemeyi umuyoruz. Bu konuda daha fazla haber için bizi takip etmeye devam edin.
LCP alt bölümlerini yerel olarak test etmek için Web Verileri uzantısını veya bu makaledeki JavaScript snippet'ini deneyin. Lighthouse, "Largest Contentful Paint öğesi"ne de dökümü de içerir. denetim. Çok yakında, Geliştirici Araçları Performans panelinde LCP alt bölümüyle ilgili daha fazla öneri bulabilirsiniz.