LCP'nin nasıl ayrıştırılacağı ve iyileştirilmesi gereken temel alanların nasıl belirleneceğiyle ilgili adım adım açıklamalı kılavuz.
Yayınlanma tarihi: 30 Nisan 2020
Largest Contentful Paint (LCP), üç Core Web Vitals metriğinden biridir ve bir web sayfasının ana içeriğinin ne kadar hızlı yüklendiğini gösterir. Daha açık belirtmek gerekirse LCP, kullanıcının sayfayı yüklemeye başlamasından görüntü alanında en büyük resim veya metin bloğunun oluşturulmasına kadar geçen süreyi ölçer.
İyi bir kullanıcı deneyimi sağlamak için sitelerin, sayfa ziyaretlerinin en az% 75'inde 2,5 saniye veya daha kısa bir LCP'ye sahip olması gerekir.
Tarayıcının bir web sayfasını ne kadar hızlı yükleyip oluşturabileceğini bir dizi faktör etkileyebilir ve bunların herhangi birindeki gecikmelerin LCP üzerinde önemli bir etkisi olabilir.
Sayfanın tek bir kısmında yapılan hızlı bir düzeltmenin LCP'de anlamlı bir iyileşme sağlaması nadirdir. LCP'yi iyileştirmek için yükleme sürecinin tamamını incelemeniz ve yoldaki her adımın optimize edildiğinden emin olmanız gerekir.
LCP metriğinizi anlama
Geliştiriciler, LCP'yi optimize etmeden önce LCP sorunu olup olmadığını ve bu tür bir sorunun kapsamını anlamaya çalışmalıdır.
LCP, çeşitli araçlarda ölçülebilir. Bu araçların tümü LCP'yi aynı şekilde ölçmez. Gerçek kullanıcıların LCP'sini anlamak için, Lighthouse gibi laboratuvar tabanlı bir aracın veya yerel testlerin gösterdiği deneyimler yerine gerçek kullanıcıların deneyimlerine bakmalıyız. Bu laboratuvar tabanlı araçlar, LCP'yi açıklamak ve iyileştirmenize yardımcı olmak için bol miktarda bilgi sağlayabilir, ancak laboratuvar testlerinin tek başına gerçek kullanıcılarınızın deneyimini tam olarak yansıtmayabileceğini unutmayın.
Gerçek kullanıcılara dayalı LCP verileri, bir siteye yüklü olan Gerçek Kullanıcı İzleme (RUM) araçlarından veya milyonlarca web sitesinin gerçek Chrome kullanıcılarından anonim veriler toplayan Chrome Kullanıcı Deneyimi Raporu (CrUX) kullanılarak gösterilebilir.
Chrome Geliştirici Araçları CrUX LCP verilerini kullanma
Chrome Geliştirici Araçları'nın Performans panelinde, canlı metrik görünümünde sayfanın veya kaynağın CrUX LCP'sinin yanında yerel LCP deneyiminiz gösterilir.
Alan verilerini Performans paneline ekleyerek bir sayfanın gerçek kullanıcı LCP sorunları olup olmadığını değerlendirebilir ve yerel ortam ayarlarınızı bu sorunları daha iyi yeniden oluşturacak ve hata ayıklama yapacak şekilde uyarlayabilirsiniz.
PageSpeed Insights CrUX LCP verilerini kullanma
PageSpeed Insights, Gerçek kullanıcılarınızın neler yaşadığını keşfedin etiketli üst bölümde CrUX verilerine erişim sağlar. Laboratuvar verilerine dayalı daha ayrıntılı verileri Performans sorunlarını teşhis etme başlıklı alt bölümde bulabilirsiniz. Web siteniz için CrUX verileri kullanılabiliyorsa önce her zaman gerçek kullanıcı verilerine odaklanın.
PageSpeed Insights, en fazla dört farklı CrUX verisi gösterir:
- Bu URL için mobil veri
- Bu URL için Masaüstü verileri
- Kaynak'ın tamamı için Mobil veriler
- Kaynak'ın tamamı için Masaüstü verileri
Bu ayarları, bu bölümün üst ve sağ üst tarafındaki kontrollerden değiştirebilirsiniz. Bir URL, URL düzeyinde gösterilmeye yeterli veriye sahip değilse ancak kaynak için veri içeriyorsa PageSpeed Insights her zaman kaynak verileri gösterir.
Kaynağın tamamının LCP'si, LCP'nin ilgili kaynaktaki diğer sayfalara kıyasla o sayfada nasıl yüklendiğine bağlı olarak tek bir sayfanın LCP'sinden çok farklı olabilir. Ayrıca, ziyaretçilerin bu sayfalara nasıl gittiği de bu metriği etkileyebilir. Ana sayfalar genellikle yeni kullanıcılar tarafından ziyaret edildiğinden, genellikle önbelleğe alınmış içerik olmadan "soğuk" olarak yüklenebilir. Bu nedenle, web sitesindeki en yavaş sayfalar genellikle ana sayfalardır.
Dört farklı CrUX veri kategorisini incelemek, LCP sorununun bu sayfaya özel mi yoksa site genelinde daha genel bir sorun mu olduğunu anlamanıza yardımcı olabilir. Benzer şekilde, hangi cihaz türlerinde LCP sorunları olduğunu da gösterebilir.
PageSpeed Insights CrUX ek metriklerini kullanma
LCP'yi optimize etmek isteyenler, LCP hakkında değerli bilgiler sağlayabilecek iyi teşhis metrikleri olan ilk zengin içerikli boyama (FCP) ve ilk bayta kadar geçen süre (TTFB) zamanlamaları da kullanmalıdır.
TTFB, ziyaretçinin bir sayfaya gitmeye başladığı andan (ör. bir bağlantıyı tıkladığında) HTML belgesinin ilk baytlarının alındığı ana kadar geçen süredir. Yüksek bir TTFB, 2,5 saniyelik LCP değerine ulaşmayı zor, hatta imkansız hale getirebilir.
Yüksek TTFB'nin nedeni birden çok sunucu yönlendirmesi, en yakın site sunucusundan uzakta bulunan ziyaretçiler, kötü ağ koşullarında bulunan ziyaretçiler veya sorgu parametreleri nedeniyle önbelleğe alınmış içeriği kullanamama olabilir.
Bir sayfa oluşturulmaya başladığında ilk boyama (ör. arka plan rengi) ve ardından bazı içerikler (ör. site başlığı) gösterilebilir. İlk içeriğin görünümü FCP ile ölçülür. FCP ile diğer metrikler arasındaki fark çok anlamlı olabilir.
TTFB ve FCP arasındaki büyük bir delta, tarayıcının çok sayıda oluşturmayı engelleyen öğe indirmesi gerektiğini gösterebilir. Ayrıca, anlamlı bir içerik oluşturmak için çok fazla çalışma yapması gerektiğine dair bir işaret de olabilir. Bu, büyük ölçüde istemci tarafı oluşturmaya dayanan bir sitenin klasik bir işaretidir.
FCP ile LCP arasındaki büyük bir fark, LCP kaynağının tarayıcı tarafından önceliklendirilmek üzere hemen kullanılamadığını (örneğin, ilk HTML'de mevcut olmak yerine JavaScript tarafından yönetilen metin veya resimler) veya tarayıcının LCP içeriğini görüntüleyemeden önce başka bir işi tamamladığını gösterir.
PageSpeed Insights Lighthouse verilerini kullanma
PageSpeed Insights'ın Lighthouse bölümü, LCP'yi iyileştirmeye yönelik bazı bilgiler sunar, ancak önce, verilen LCP'nin, CrUX tarafından sağlanan gerçek kullanıcı verileriyle genel olarak uyumlu olup olmadığını kontrol etmeniz gerekir. Lighthouse ve CrUX'un sonuçları birbirinden farklıysa CrUX, kullanıcı deneyiminizin daha doğru bir resmini sunuyordur. İşlem yapmadan önce CrUX verilerinizin tam kaynak değil, sayfanız için olduğundan emin olun.
Hem Lighthouse hem de CrUX, iyileştirme gerektiren LCP değerleri gösteriyorsa Lighthouse bölümü, LCP'yi iyileştirme yöntemleri hakkında değerli bilgiler sağlayabilir. Aşağıdaki şekilde yalnızca LCP ile alakalı denetimleri göstermek için LCP filtresini kullanın:
İyileştirmeye yönelik Fırsatlar'ın yanı sıra, sorunu teşhis etmeye yardımcı olacak daha fazla bilgi sağlayabilecek Teşhis bilgileri de vardır. Largest Contentful Paint öğesi raporu, LCP'yi oluşturan çeşitli zamanlamaların faydalı bir dökümünü gösterir:
Ardından bu alt bölümleri ayrıntılı olarak inceleyeceğiz.
LCP dökümü
PageSpeed Insights bu metriğin nasıl iyileştirileceğine dair yanıt vermediğinde LCP için optimizasyon yapmak daha karmaşık bir iş olabilir. Karmaşık görevleri genellikle daha küçük ve daha yönetilebilir görevlere ayırıp her birini ayrı ayrı ele almak daha iyidir.
Bu bölümde, LCP'nin en önemli alt bölümlerine nasıl ayrılacağıyla ilgili bir metodoloji sunulmakta, ardından her bir bölümün optimize edilmesi için spesifik öneriler ve en iyi uygulamalar sunulmaktadır.
Çoğu sayfa yüklemesi genellikle birkaç ağ isteği içerir ancak LCP'yi iyileştirme fırsatlarını belirlemek için yalnızca ikisine bakarak başlamanız gerekir:
- İlk HTML belgesi
- LCP kaynağı (varsa)
Sayfadaki diğer istekler LCP'yi etkileyebilir ancak bu iki istek, özellikle de LCP kaynağının başlangıç ve bitiş zamanları gibi, sayfanızın LCP için optimize edilip edilmediğini gösterir.
LCP kaynağını belirlemek için geliştirici araçlarını (ör. daha önce bahsedilen PageSpeed Insights, Chrome Geliştirici Araçları veya WebPageTest) kullanarak LCP öğesini belirleyebilirsiniz. Buradan, sayfa tarafından yüklenen tüm kaynakların ağ şelalesine öğe tarafından yüklenen URL'yi (varsa) eşleştirebilirsiniz.
Örneğin, aşağıdaki görselleştirmede bu kaynaklar, LCP öğesinin oluşturulması için resim isteği gerektirdiği tipik bir sayfa yüklemesinde bir ağ şelale diyagramında vurgulanmıştır.
İyi optimize edilmiş bir sayfada, LCP kaynak isteğinizin mümkün olduğunca erken yüklenmeye başlamasını ve LCP kaynağının yüklenmesi tamamlandıktan sonra LCP öğesinin mümkün olduğunca hızlı oluşturulmasını istersiniz. Belirli bir sayfanın bu ilkeye uyup uymadığını görselleştirmek için toplam LCP süresini aşağıdaki alt bölümlere ayırabilirsiniz:
- İlk Bayta Erişim Süresi (TTFB)
- Kullanıcının sayfayı yüklemeye başlamasından tarayıcının HTML belge yanıtının ilk baytını almasına 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 (örneğin, öğe bir sistem yazı tipiyle oluşturulan bir metin düğümüyse) bu süre 0 olur.
- 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ü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.
Her sayfanın LCP'si şu dört alt kategoriden oluşur. Bunlar arasında boşluk veya çakışma yoktur ve bunlar LCP süresinin tamamını oluşturur.
Her sayfanın LCP değeri bu dört alt bölüme ayrılabilir. Bu iki öğe arasında çakışma veya boşluk yoktur. Bu ayarlar toplu olarak tam LCP süresine eklenir.
LCP'yi optimize ederken bu alt parçaları tek tek optimize etmeyi denemek faydalı olabilir. Ancak, bunların tümünü optimize etmeniz gerektiğini de unutmamak gerekir. Bazı durumlarda, bir bölüme uygulanan optimizasyon LCP'yi iyileştirmez, yalnızca tasarruf edilen süreyi başka bir bölüme kaydırır.
Örneğin, önceki ağ şelalesinde resmimizi daha fazla sıkıştırarak veya daha uygun bir biçime (AVIF veya WebP gibi) geçerek dosya boyutunu küçültseniz kaynak yükleme süresi azalır ancak zaman sadece öğe oluşturma gecikmesi alt bölümüne kayacağı için LCP aslında iyileşmez:
Bunun nedeni, bu sayfada LCP öğesinin JavaScript kodu yüklendikten sonra gizlenmesi ve ardından her şeyin bir anda gösterilmesidir.
Bu örnek, en iyi LCP sonuçlarını elde etmek için bu alt parçaların tümünü optimize etmeniz gerektiği fikrini açıklamaya yardımcı olur.
En uygun alt bölüm süreleri
LCP'nin her alt bölümünü optimize etmek için iyi optimize edilmiş bir sayfada bu alt bölümlerin ideal dökümünün ne olduğunu anlamanız önemlidir.
Dört alt bölümden ikisinin adında "gecikme" kelimesi bulunmaktadır. Bu, bu sürelerin olabildiğince sıfıra yakın olmasını istediğinize dair bir ipucudur. Diğer iki bölüm, doğası gereği zaman alan ağ isteklerini içerir.
Bu zaman dökümlerinin katı kurallar değil, kurallara yol gösterici öneriler olduğunu unutmayın. Sayfalarınızdaki LCP süreleri tutarlı bir şekilde 2, 5 saniye içindeyse göreli oranların ne olduğu önemli değildir. Ancak "gecikme" bölümlerinden birinde çok fazla zaman harcarsanız 2, 5 saniyelik hedefi sürekli olarak tutmanız çok zor olur.
LCP süresinin dökümünü düşünmenin iyi bir yolu şudur:
- LCP süresinin çoğunluğu HTML dokümanı ve LCP kaynağının yüklenmesi için harcanmalıdır.
- LCP'den önce bu iki kaynaktan birinin yüklenmediği her durum iyileştirme fırsatı olarak değerlendirilir.
Her bölüm nasıl optimize edilir?
İyi optimize edilmiş bir sayfada LCP alt bölüm sürelerinin her birinin nasıl bölünmesi gerektiğini anladığınıza göre kendi sayfalarınızı optimize etmeye başlayabilirsiniz.
Sonraki dört bölümde, her bir bölümün nasıl optimize edileceğine ilişkin öneriler ve en iyi uygulamalar sunulur. En büyük etkiye sahip olması muhtemel optimizasyonlardan başlayarak sıralı olarak sunulur.
1. Kaynak yükleme gecikmesini ortadan kaldırın
Bu adımdaki amaç, LCP kaynağının olabildiğince erken yüklenmeye başlamasını sağlamaktır. Teorik olarak bir kaynağın yüklenmeye başlaması için en erken zaman TTFB'den hemen sonradır ancak pratikte tarayıcıların kaynakları yüklemeye başlaması her zaman biraz gecikir.
LCP kaynağınızın, ilgili sayfa tarafından yüklenen ilk kaynakla aynı anda yüklenmeye başlaması iyi bir kuraldır. Başka bir deyişle, LCP kaynağı ilk kaynaktan daha geç yüklenmeye başlıyorsa iyileştirme fırsatı vardır.
Genel olarak, bir LCP kaynağının ne kadar hızlı yüklenebileceğini etkileyen iki faktör vardır:
- Kaynak keşfedildiğinde.
- Kaynağa verilen öncelik.
Kaynak keşfedildiğinde optimizasyon yapın
LCP kaynağınızın mümkün olduğunca erken yüklenmeye başlaması için kaynağın, tarayıcı önceden yükleme tarayıcısıyla ilk HTML dokümanı yanıtında bulunabilir olması önemlidir. Örneğin, tarayıcı aşağıdaki durumlarda HTML dokümanı yanıtını tarayarak LCP kaynağını keşfedebilir:
- LCP öğesi bir
<img>öğesidir vesrcveyasrcsetözellikleri ilk HTML işaretlemesinde bulunur. - LCP öğesi için bir CSS arka plan resmi gerekir. Ancak bu resim, HTML işaretlemesinde
<link rel="preload">kullanılarak (veya birLinküst bilgisi kullanılarak) önceden yüklenir. - LCP öğesi, oluşturulması için bir web yazı tipi gerektiren bir metin düğümüdür ve yazı tipi, HTML işaretlemesinde
<link rel="preload">kullanılarak (veyaLinkbaşlığı kullanılarak) yüklenir.
HTML dokümanı yanıtının taranmasından LCP kaynağının bulunamadığı bazı örnekler aşağıda verilmiştir:
- LCP öğesi, JavaScript kullanılarak sayfaya dinamik olarak eklenen bir
<img>öğesidir. - LCP öğesi,
srcveyasrcsetözelliklerini (genellikledata-srcveyadata-srcsetolarak) gizleyen bir JavaScript kitaplığıyla yavaşça yüklenir. - LCP öğesi için CSS arka plan resmi gerekir.
Bu durumların her birinde, tarayıcının LCP kaynağını bulup yüklemeye başlamadan önce komut dosyasını çalıştırması veya stil sayfasını uygulaması (genellikle ağ isteklerinin tamamlanmasını beklemeyi içerir) gerekir. Bu durum hiçbir zaman optimal değildir.
Gereksiz kaynak yükleme gecikmesini ortadan kaldırmak için LCP kaynağınız HTML kaynağından bulunabilir olmalıdır. Kaynağa yalnızca harici bir CSS veya JavaScript dosyasından başvurulduğu durumlarda LCP kaynağı yüksek bir getirme önceliğiyle önceden yüklenmelidir. Örneğin:
<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">
<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">
Kaynağa verilen önceliği optimize etme
LCP kaynağı HTML işaretlemesinden bulunabilir olsa bile yine de ilk kaynak kadar erken yüklenmeye başlamayabilir. Bu durum, tarayıcı ön yükleme tarayıcısının öncelikli keşif kuralları kaynağın önemli olduğunu tanımıyorsa veya diğer kaynakların daha önemli olduğunu belirlerse ortaya çıkabilir.
Örneğin, <img> öğeniz üzerinde loading="lazy" ayarını yaparsanız LCP resminizi HTML kullanarak geciktirebilirsiniz. Yavaş yükleme kullanıldığında, kaynak, düzenin resmin görüntü alanında olduğunu onaylayana kadar yüklenmez. Bu nedenle, yükleme normalden daha geç başlayabilir.
Geç yükleme olmasa bile resimler, oluşturmayı engelleyen kaynak olmadıkları için başlangıçta tarayıcılar tarafından en yüksek öncelikle yüklenmez. Daha yüksek bir öncelikten yararlanabilecek kaynaklar için fetchpriority özelliğini kullanarak tarayıcıya en önemli kaynakların hangileri olduğuna dair ipucu verebilirsiniz:
<img fetchpriority="high" src="/path/to/hero-image.webp">
Sayfanızın LCP öğesi olma olasılığı yüksek bir <img> öğesinde fetchpriority="high" ayarlamak iyi bir fikirdir. Ancak bir veya ikiden fazla resim için yüksek öncelik ayarlamak, öncelik ayarının LCP'yi azaltmada faydalı olmasını engeller.
Ayrıca, belge yanıtının başlarında yer alabilecek ancak stil nedeniyle görünmeyen resimlerin (ör. başlangıçta görünmeyen bant slaytlarındaki resimler) önceliğini düşürebilirsiniz:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
Belirli kaynakların önceliğini düşürmek, daha çok ihtiyaç duyan kaynaklara daha fazla bant genişliği sağlayabilir ancak dikkatli olun. Geliştirici Araçları'nda her zaman kaynak önceliğini kontrol edin, ardından laboratuvar ve alan araçlarıyla değişiklikleri test edin.
LCP kaynak önceliğinizi ve keşif zamanınızı optimize ettikten sonra ağ şelaleniz şu şekilde görünmelidir (LCP kaynağı, ilk kaynakla aynı anda başlar):
2. Öğe oluşturma gecikmesini ortadan kaldırın
Bu adımdaki amaç, LCP öğesinin kaynağının ne zaman yükleneceği fark etmeksizin, kaynağın yüklenmesi tamamlandıktan sonra hemen oluşturulmasını sağlamaktır.
LCP öğesinin kaynağının yüklenmesi tamamlandıktan hemen sonra oluşturulamamasının birincil nedeni, oluşturmanın başka bir nedenle engellenmesidir:
<head>içindeki hâlâ yüklenmekte olan stil sayfaları veya senkronize komut dosyaları nedeniyle sayfanın tamamının oluşturulması engelleniyor.- LCP kaynağının yüklenmesi tamamlandı, ancak LCP öğesi henüz DOM'ye eklenmedi (bazı JavaScript kodlarının yüklenmesini bekliyor).
- Öğe, kullanıcının hangi denemeye dahil edileceğini hâlâ belirleyen bir A/B testi kitaplığı gibi başka bir kod tarafından gizleniyordur.
- Ana iş parçacığı uzun görevler nedeniyle engellendi ve oluşturma işleminin bu uzun görevler tamamlanana kadar beklemesi gerekiyor.
Aşağıdaki bölümlerde, gereksiz öğe oluşturma gecikmesinin en yaygın nedenlerinin nasıl ele alınacağı açıklanmaktadır.
Oluşturmayı engelleyen stil sayfalarını azaltma veya satır içi hale getirme
HTML işaretçisinden yüklenen stil sayfaları, bunları izleyen tüm içeriğin oluşturulmasını engeller. Genellikle stili olmayan HTML'yi oluşturmak istemediğiniz için bu durum iyidir. Ancak stil sayfası, LCP kaynağından çok daha uzun sürede yüklenecek kadar büyükse bu sayfa, kaynağının yüklenmesi tamamlandıktan sonra bile LCP öğesinin oluşturulmasını engeller. Bu örnekte gösterildiği gibi:
Bu sorunu düzeltmek için aşağıdaki seçeneklerden birini kullanabilirsiniz:
- ek ağ isteğinden kaçınmak için stil sayfasını HTML'de satır içi olarak kullanma veya
- stil sayfasının boyutunu azaltın.
Genel olarak stil sayfanızı satır içine almanız, yalnızca stil sayfanız küçükse önerilir. Çünkü HTML'deki satır içi içerik, sonraki sayfa yüklemelerinde önbelleğe alma özelliğinden yararlanamaz. Stil sayfası, yüklenmesi LCP kaynağından daha uzun sürecek kadar büyükse satır içine almak için iyi bir aday olma olasılığı düşüktür.
Çoğu durumda, stil sayfasının LCP öğesinin oluşturulmasını engellemediğinden emin olmanın en iyi yolu, boyutunu LCP kaynağından daha küçük olacak şekilde azaltmaktır. Bu sayede, çoğu ziyaret için darboğaz oluşturmaz.
Stil sayfasının boyutunu küçültmek için bazı öneriler:
- Kullanılmayan CSS'yi kaldırın: Kullanılmayan veya kaldırılabilecek (veya ertelenebilecek) CSS kurallarını bulmak için Chrome Geliştirici Araçları'nı kullanın.
- Kritik olmayan CSS'yi erteleyin: Stil sayfanızı ilk sayfa yükleme için gerekli olan stillere ve daha sonra geç yüklenebilen stillere ayırın.
- CSS'yi küçültün ve sıkıştırın: Kritik olan stiller için aktarım boyutunu mümkün olduğunca küçülttüğünüzden emin olun.
Oluşturma engelleyici JavaScript'i erteleme veya satır içi olarak yerleştirme
Sayfalarınızın <head> özelliğine senkron komut dosyaları (async veya defer özellikleri olmayan komut dosyaları) eklemek neredeyse hiçbir zaman gerekli değildir ve bunu yapmak neredeyse her zaman performansı olumsuz etkiler.
JavaScript kodunun sayfa yükleme sırasında mümkün olduğunca erken çalışmasının gerektiği durumlarda, oluşturmanın en iyisi satır içi yapmaktır. Böylece, oluşturma işlemi başka bir ağ isteğini beklerken gecikir. Ancak stil sayfalarında olduğu gibi, yalnızca çok küçük komut dosyalarını satır içi olarak eklemeniz gerekir.
<head> <script src="/path/to/main.js"></script> </head>
<head>
<script>
// Inline script contents directly in the HTML.
// IMPORTANT: only do this for very small scripts.
</script>
</head>Sunucu tarafı oluşturma özelliğini kullanma
Sunucu tarafı oluşturma (SSR), istemci tarafı uygulama mantığınızı sunucuda çalıştırma ve HTML dokümanı isteklerine tam HTML işaretlemesiyle yanıt verme işlemidir.
LCP'yi optimize etme açısından SSR'nin iki temel avantajı vardır:
- Resim kaynaklarınız, HTML kaynağından bulunabilir (daha önce 1. adımda açıklandığı gibi).
- Sayfa içeriğinizin oluşturulması için ek JavaScript istekleri gerekmez.
SSR'nin en büyük dezavantajı, ek sunucu işleme süresi gerektirmesidir. Bu da TTFB'nizi yavaşlatabilir. Ancak sunucu işleme süreleri sizin kontrolünüzdeyken kullanıcılarınızın ağ ve cihaz özellikleri sizin kontrolünüzde olmadığından bu değişim genellikle buna değer.
SSR'ye benzer bir seçenek, statik site oluşturma (SSG) veya ön oluşturma olarak adlandırılır. Bu, HTML sayfalarınızı isteğe bağlı olarak değil, bir derleme adımında oluşturma işlemidir. Mimarinizde önceden işleme kullanılabiliyorsa bu genellikle performans için daha iyi bir seçenektir.
Uzun görevleri bölün
Daha önceki tavsiyeyi uygulamış olsanız ve JavaScript kodunuz oluşturmayı engellemese ya da öğelerinizi oluşturmaktan sorumlu olmasa da LCP'yi geciktirebilir.
Bu durumun en yaygın nedeni, sayfaların tarayıcı ana iş parçacığında ayrıştırılması ve yürütülmesi gereken büyük JavaScript dosyaları yüklemesidir. Bu, resim kaynağınız tamamen indirilmiş olsa bile alakasız bir komut dosyasının yürütülebilmesi için yürütülmesini beklemesi gerekebileceği anlamına gelir.
Günümüzde tüm tarayıcılar resimleri ana mesaj dizisinde oluşturur. Bu, ana mesaj dizisini engelleyen her şeyin gereksiz öğe oluşturma gecikmesine de neden olabileceği anlamına gelir.
3. Kaynak yükleme süresini azaltma
Bu adımın amacı, kaynağın baytlarını ağ üzerinden kullanıcının cihazına aktarırken harcanan süreyi azaltmaktır. Genel olarak bunu yapmanın dört yolu vardır:
- Kaynağın boyutunu küçültün.
- Kaynağın kat etmesi gereken mesafeyi azaltın.
- Ağ bant genişliği için çekişmeyi azaltın.
- Ağ süresini tamamen ortadan kaldırın.
Kaynağın boyutunu azaltın
Bir sayfanın LCP kaynağı (varsa) resim veya web yazı tipi olur. Aşağıdaki kılavuzlarda, her ikisinin de boyutunun nasıl küçültüleceği ayrıntılı olarak açıklanmaktadır:
- Optimum resim boyutunu sunma
- Modern resim biçimlerini kullanın
- Resimleri sıkıştırın
- Web yazı tipi boyutunu küçültme
Kaynağın gitmesi gereken mesafeyi azaltın
Bir kaynağın boyutunu küçültmeye ek olarak sunucularınızı coğrafi olarak kullanıcılarınızın olabildiğince yakınına getirerek yükleme sürelerini de azaltabilirsiniz. Bunu yapmanın en iyi yolu bir içerik yayınlama ağı (CDN) kullanmaktır.
Özellikle resim CDN'leri, yalnızca kaynağın seyahat etmesi gereken mesafeyi azaltmakla kalmayıp aynı zamanda genellikle kaynağın boyutunu da azaltarak daha önceki tüm boyut azaltma önerilerini sizin için otomatik olarak uyguladığı için özellikle yararlıdır.
Ağ bant genişliği için çekişmeyi azaltma
Kaynağınızın boyutunu ve kat etmesi gereken mesafeyi azaltmış olsanız bile, aynı anda başka birçok kaynak yüklüyorsanız kaynağın yüklenmesi uzun sürebilir. Bu soruna ağ çekişmesi denir.
LCP kaynağınıza yüksek bir fetchpriority verdiyseniz ve en kısa sürede yüklemeye başladıysanız tarayıcı, düşük öncelikli kaynakların onunla rekabet etmesini önlemek için elinden geleni yapar. Ancak, yüksek fetchpriority değerine sahip çok sayıda kaynak yüklüyorsanız veya genel olarak çok sayıda kaynak yüklüyorsanız LCP kaynağının ne kadar hızlı yüklendiğini etkileyebilir.
Ağ zamanını tamamen ortadan kaldırma
Kaynak yükleme süresini azaltmanın en iyi yolu, ağı işlemden tamamen kaldırmaktır. Kaynaklarınızı verimli bir önbellek kontrol politikasıyla sunarsanız bu kaynakları ikinci kez isteyen ziyaretçilere önbellekten sunulur. Böylece kaynak yükleme süresi neredeyse sıfıra iner.
LCP kaynağınız bir web yazı tipiyse web yazı tipi boyutunu azaltmanın yanı sıra web yazı tipi kaynağı yüklenirken oluşturmayı engellemeniz gerekip gerekmediğini de değerlendirmeniz gerekir. font-display değerini auto veya block dışında bir değer olarak ayarlarsanız metin yükleme sırasında her zaman görünür ve ek bir ağ isteğinde LCP engellenmez.
Son olarak, LCP kaynağınız küçükse kaynakları veri URL'si olarak satır içi olarak eklemek mantıklı olabilir. Bu işlem, ek ağ isteğini de ortadan kaldırır. Ancak veri URL'lerinin kullanılması ihtiyat gerektirir. Çünkü bu durumda kaynaklar önbelleğe alınamaz ve bazı durumlarda ek kod çözme maliyeti nedeniyle daha uzun oluşturma gecikmeleri yaşanabilir.
4. İlk bayta geçiş süresini azaltma
Bu adımın amacı, ilk HTML'yi mümkün olduğunca hızlı bir şekilde yayınlamaktır. Bu adım en sonuncu adımdır çünkü genellikle geliştiricilerin üzerinde en az kontrole sahip olan adımdır. Ancak, kendisinden sonraki her adımı doğrudan etkilediği için en önemli adımlardan biridir. Arka uç, içeriğin ilk baytını yayınlayana kadar ön uçta hiçbir şey olamaz. Bu nedenle, TTFB'nizi hızlandırmak için yapabileceğiniz her şey diğer tüm yükleme metriklerini de iyileştirir.
Normalde hızlı bir sitede TTFB'nin yavaş olmasının yaygın bir nedeni, reklamlar veya kısaltılmış bağlantılar gibi birden çok yönlendirme üzerinden gelen ziyaretçilerdir. Ziyaretçilerin beklemesi gereken yönlendirme sayısını her zaman en aza indirin.
Sık karşılaşılan bir diğer neden de, önbelleğe alınan içeriğin bir CDN uç sunucusundan kullanılamamasıdır. Bu durumda tüm istekler kaynak sunucuya yönlendirilmelidir. Bu durum, benzersiz URL parametreleri ziyaretçiler tarafından analizler için kullanılıyorsa (farklı sayfalara yönlendirmeseler bile) ortaya çıkabilir.
TTFB'yi optimize etmeyle ilgili özel bilgi için TTFB'yi optimize etme kılavuzuna bakın.
JavaScript'te LCP dökümünü izleme
Daha önce bahsedilen LCP alt bölümlerinin tümünün zamanlama bilgileri, aşağıdaki performans API'lerinin bir kombinasyonu aracılığıyla JavaScript'te kullanılabilir:
JavaScript'te bu zamanlama değerlerini hesaplamanın avantajı, bunları bir analiz sağlayıcısına göndermenize veya hata ayıklama ve optimizasyon konusunda yardımcı olması için geliştirici araçlarınıza kaydetmenize olanak tanımasıdır.
Örneğin, aşağıdaki ekran görüntüsünde Chrome Geliştirici Araçları Performans panelindeki Zamanlamalar kanalına çubuk eklemek için User Timing API'deki performance.measure() yöntemi kullanılmaktadır.
Zamanlamalar kanalındaki görselleştirmeler özellikle Ağ ve Ana iş parçacığı kanallarına bakıldığında faydalıdır. Bunun nedeni, bu zaman aralıklarında sayfada başka neler olduğunu bir bakışta görmenizi sağlar.
Zaman çizelgesi parçasındaki LCP alt parçalarını görselleştirmenin yanı sıra, her bir alt parçanın toplam LCP süresinin yüzdesini hesaplamak için JavaScript'i de kullanabilirsiniz. Bu bilgilerle, sayfalarınızın daha önce açıklanan önerilen yüzde dökümlerini karşılayıp karşılamadığını belirleyebilirsiniz.
Bu ekran görüntüsünde, her LCP alt bölümünün toplam süresinin ve konsola giden toplam LCP süresi yüzdesinin günlüğe kaydedildiği bir örnek gösterilmektedir.
Bu görselleştirmelerin her ikisi de aşağıdaki kodla oluşturulmuştur:
const LCP_SUB_PARTS = [
'Time to first byte',
'Resource load delay',
'Resource load duration',
'Element render delay',
];
new PerformanceObserver((list) => {
const lcpEntry = list.getEntries().at(-1);
const navEntry = performance.getEntriesByType('navigation')[0];
const lcpResEntry = performance
.getEntriesByType('resource')
.filter((e) => e.name === lcpEntry.url)[0];
// Ignore LCP entries that aren't images to reduce DevTools noise.
// Comment this line out if you want to include text entries.
if (!lcpEntry.url) return;
// Compute the start and end times of each LCP sub-part.
// WARNING! If your LCP resource is loaded cross-origin, make sure to add
// the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
const ttfb = navEntry.responseStart;
const lcpRequestStart = Math.max(
ttfb,
// Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
);
const lcpResponseEnd = Math.max(
lcpRequestStart,
lcpResEntry ? lcpResEntry.responseEnd : 0
);
const lcpRenderTime = Math.max(
lcpResponseEnd,
// Use LCP startTime (the final LCP time) because there are sometimes
// slight differences between loadTime/renderTime and startTime
// due to rounding precision.
lcpEntry ? lcpEntry.startTime : 0
);
// Clear previous measures before making new ones.
// Note: due to a bug, this doesn't work in Chrome DevTools.
LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));
// Create measures for each LCP sub-part for easier
// visualization in the Chrome DevTools Performance panel.
const lcpSubPartMeasures = [
performance.measure(LCP_SUB_PARTS[0], {
start: 0,
end: ttfb,
}),
performance.measure(LCP_SUB_PARTS[1], {
start: ttfb,
end: lcpRequestStart,
}),
performance.measure(LCP_SUB_PARTS[2], {
start: lcpRequestStart,
end: lcpResponseEnd,
}),
performance.measure(LCP_SUB_PARTS[3], {
start: lcpResponseEnd,
end: lcpRenderTime,
}),
];
// Log helpful debug information to the console.
console.log('LCP value: ', lcpRenderTime);
console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
console.table(
lcpSubPartMeasures.map((measure) => ({
'LCP sub-part': measure.name,
'Time (ms)': measure.duration,
'% of LCP': `${
Math.round((1000 * measure.duration) / lcpRenderTime) / 10
}%`,
}))
);
}).observe({type: 'largest-contentful-paint', buffered: true});
Bu kodu yerel hata ayıklama için olduğu gibi kullanabilir veya gerçek kullanıcılar için sayfalarınızda LCP dökümünün ne olduğunu daha iyi anlamak amacıyla bu verileri bir analiz sağlayıcısına gönderecek şekilde değiştirebilirsiniz.
Özet
LCP karmaşık bir konudur ve zamanlaması çeşitli faktörlerden etkilenebilir. Ancak LCP'yi optimize etmenin öncelikle LCP kaynağının yükünü optimize etmekle ilgili olduğunu düşünürseniz bu, işleri önemli ölçüde basitleştirebilir.
Genel olarak, LCP'yi optimize etme işlemi dört adımda özetlenebilir:
- LCP kaynağının mümkün olduğunca erken yüklenmeye başladığından emin olun.
- LCP öğesinin, kaynağının yüklenmesi tamamlanır tamamlanmaz oluşturulabileceğinden emin olun.
- Kaliteden ödün vermeden LCP kaynağının yüklenme süresini mümkün olduğunca azaltın.
- İlk HTML dokümanlarını mümkün olduğunca hızlı bir şekilde yayınlayın.
Sayfalarınızda bu adımları uygulayabiliyorsanız kullanıcılarınıza en iyi yükleme deneyimini sunduğunuzdan emin olabilirsiniz. Bu durum, gerçek LCP puanlarınıza da yansır.