Largest Contentful Paint'i Optimize Edin

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.

Philip Walton

Barry Pollard

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 etkileyen çeşitli faktörler vardır ve bu faktörlerden herhangi birinde yaşanan gecikmeler LCP'yi önemli ölçüde etkileyebilir.

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ına bakmanız ve bu süreçteki 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 testin gösterdiği değerler yerine gerçek kullanıcıların ne yaşadığına bakmamız gerekir. Laboratuvar tabanlı bu araçlar, LCP'yi açıklamak ve iyileştirmenize yardımcı olmak için çok sayıda 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üklenen Gerçek Kullanıcı İzleme (RUM) araçlarından veya milyonlarca web sitesi için 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 mevcutsa her zaman önce gerçek kullanıcı verilerine odaklanın.

PageSpeed Insights, en fazla dört farklı CrUX verisi gösterir:

• Bu URL için Mobil verileri
• 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'nin URL düzeyinde gösterilecek yeterli verisi yoksa ancak kaynakla ilgili verileri varsa PageSpeed Insights her zaman kaynak verilerini gösterir.

Kaynaktaki tüm sayfaların LCP'si, LCP'nin ilgili kaynaktaki diğer sayfalara kıyasla söz konusu sayfaya nasıl yükleneceğ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.

LCP sorununun bu sayfaya özgü mü yoksa site genelinde daha genel bir sorun mu olduğunu anlamak için dört farklı CrUX veri kategorisine bakabilirsiniz. Benzer şekilde, hangi cihaz türlerinde LCP sorunu 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ını 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 TTFB, 2,5 saniyelik LCP'ye ulaşmayı zorlaştırabilir hatta imkansız hale getirebilir.

Yüksek TTFB, birden fazla sunucu yönlendirmesi, en yakın site sunucusundan uzakta bulunan ziyaretçiler, kötü ağ koşullarına sahip ziyaretçiler veya sorgu parametreleri nedeniyle önbelleğe alınmış içeriğin kullanılamaması nedeniyle 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 ile FCP arasında büyük bir fark olması, tarayıcının oluşturmayı engelleyen çok sayıda öğ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ünde, LCP'yi iyileştirmeyle ilgili bazı bilgiler sunulur. 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. Bu verileri işleme almadan önce CrUX verilerinizin tam kaynağın değil, sayfanızı kapsadığından 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. Yalnızca LCP ile alakalı denetimleri göstermek için LCP filtresini aşağıdaki gibi 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 teşhisi, LCP'yi oluşturan çeşitli zamanlamaların yararlı 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ğı ve ardından her bir bölümün nasıl optimize edileceğine dair belirli öneriler ve en iyi uygulamalar sunulmaktadır.

Çoğu sayfa yüklemesi genellikle bir dizi ağ isteği içerir ancak LCP'yi iyileştirme fırsatlarını belirlemek için yalnızca ikisine bakarak başlamanız gerekir:

1. İlk HTML dokümanı
2. LCP kaynağı (varsa)

Sayfadaki diğer istekler LCP'yi etkileyebilir ancak bu iki istek (özellikle LCP kaynağının başladığı ve bittiği zamanlar) 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ğ şelalesinde öğ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 bir resim isteği gerektirdiği tipik bir sayfa yükleme işleminden alınan bir ağ şelalesi şemasında vurgulanmıştır.

İyi optimize edilmiş bir sayfa için 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ı bir şekilde 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ş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 (ö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 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.

Her sayfanın LCP'si bu 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. Bunlar birlikte toplam LCP süresini oluşturur.

LCP'yi optimize ederken bu alt parçaları tek tek optimize etmeyi denemek faydalı olabilir. Ancak bunların hepsini optimize etmeniz gerektiğini de unutmayın. 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 var. Bu, bu süreleri sıfıra olabildiğince yakın bir seviyeye çekmeniz gerektiğine 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 saniyenin altındaysa göreceli 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 bir bölümü optimize etme

İ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 dair öneriler ve en iyi uygulamalar sunulmaktadır. En büyük etkiye sahip olabilecek optimizasyonlardan başlayarak sırayla 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şlarsa 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 bulunduğunda.
• Kaynağa verilen öncelik.

Kaynak keşfedildiğinde optimizasyon yapma

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 ve src veya srcset özellikleri ilk HTML işaretlemesinde bulunur.
• LCP öğesi için bir CSS arka plan resmi gerekir ancak bu resim, HTML işaretlemede <link rel="preload"> kullanılarak (veya Link başlığı 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 (veya Link baş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, src veya srcset özelliklerini (genellikle data-src veya data-srcset olarak) 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 referans verildiği durumlarda LCP kaynağı, yüksek bir getirme önceliği ile önceden yüklenmiş olmalıdır. Ö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> öğenize loading="lazy" ayarını uygularsanı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, kaynak normalden daha geç yüklenmeye başlayabilir.

Resimler, gecikmeli yükleme olmadan bile oluşturmayı engelleyen kaynaklar olmadığından tarayıcılar tarafından başlangıçta en yüksek önceliğe sahip olarak yüklenmez. Daha yüksek bir öncelikten yararlanabilecek kaynaklar için fetchpriority özelliğini kullanarak tarayıcıya hangi kaynakların en önemli olduğu konusunda 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 kaynak önceliğini her zaman kontrol edin ve değişiklikleri laboratuvar ve saha araçlarıyla test edin.

LCP kaynağı önceliğinizi ve keşif zamanınızı optimize ettikten sonra ağ şelaleniz şöyle 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'a 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ğini önlemek için stil sayfasını HTML'ye satır içi olarak ekleyin veya
• stil sayfasının boyutunu azaltın.

HTML'deki satır içi içerikler sonraki sayfa yüklemelerinde önbelleğe alma özelliğinden yararlanamadığından, stil sayfanızı satır içi olarak eklemeniz genellikle yalnızca stil sayfanız küçükse önerilir. Bir stil sayfası, LCP kaynağından daha uzun sürede yüklenecek kadar büyükse satır içi olarak yerleştirilmek için iyi bir aday olmayabilir.

Ç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 ve kaldırılabilecek (veya ertelenebilir) 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üklemesi için gereken stiller ve ardından yavaşça yüklenebilecek stiller olarak bölün.
• CSS'yi sadeleştirin ve sıkıştırın: Kritik olan stillerin aktarılma boyutunu mümkün olduğunca azalttığınızdan emin olun.

Oluşturma engelleyici JavaScript'i erteleme veya satır içi olarak yerleştirme

Sayfalarınızın <head> bölümüne senkronize 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üklenirken mümkün olduğunca erken çalışması gerektiği durumlarda, oluşturma işleminin başka bir ağ isteği beklerken gecikmemesi için kodu satır içi olarak eklemek en iyisidir. 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şaretlemeyle yanıt verme işlemidir.

LCP'yi optimize etme açısından SSR'nin iki temel avantajı vardır:

• Görsel kaynaklarınız HTML kaynağından bulunabilir (daha önceki 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. Mimarinizle ön oluşturma mümkünse genellikle performans açısından daha iyi bir seçimdir.

Uzun görevleri bölme

Daha önce verilen tavsiyeleri uygulamış olsanız ve JavaScript kodunuz oluşturmayı engellemiyor ya da öğelerinizi oluşturmaktan sorumlu olmasa bile 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 oluşturma işlemini başlatabilmek için alakasız bir komut dosyasının yürütülmesinin tamamlanmasını 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ğ zamanını 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ırma
• Web yazı tipi boyutunu küçültme

Kaynağın kat etmesi gereken mesafeyi azaltın

Bir kaynağın boyutunu azaltmanın yanı sıra sunucularınızı kullanıcılarınıza coğrafi olarak mümkün olduğunca yakın bir yere yerleştirerek 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, kaynağın kat etmesi gereken mesafeyi azaltmanın yanı sıra genellikle kaynağın boyutunu da azalttığı için özellikle yararlıdır. Bu CDN'ler, daha önceden verilen tüm boyut azaltma önerilerini sizin için otomatik olarak uygular.

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. auto veya block dışında bir font-display değeri ayarlarsanız metin yükleme sırasında her zaman görünür olur 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 olabildiğince hızlı bir şekilde yayınlamaktır. Bu adım, genellikle geliştiricilerin en az kontrole sahip olduğu adım olduğundan en son sırada listelenir. 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ı olan bir sitede TTFB'nin yavaş olmasının yaygın bir nedeni, ziyaretçilerin reklamlar veya kısaltılmış bağlantılar gibi birden fazla yönlendirme üzerinden gelmesidir. Ziyaretçinin 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:

• Largest Contentful Paint API
• Navigation Timing API
• Resource Timing API

Bu zamanlama değerlerini JavaScript'te hesaplamanın avantajı, hata ayıklama ve optimizasyona yardımcı olmak için bunları bir analiz sağlayıcıya göndermenize veya 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.

Zaman çizelgeleri kanalındaki görselleştirmeler, özellikle Ağ ve Ana mesaj dizisi kanallarıyla birlikte incelendiğinde faydalıdır. Bu zaman aralıklarında sayfada başka neler olduğunu bir bakışta görebilirsiniz.

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 yanı sıra konsoldaki toplam LCP süresinin yüzdesini günlüğe kaydeden 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ızdaki LCP dökümünü daha iyi anlayabilmek amacıyla bu verileri bir analiz sağlayıcıya 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.

LCP'yi optimize etme işlemi, ana hatlarıyla dört adımda özetlenebilir:

1. LCP kaynağının mümkün olduğunca erken yüklenmeye başladığından emin olun.
2. LCP öğesinin, kaynağının yüklenmesi tamamlanır tamamlanmaz oluşturulabileceğinden emin olun.
3. LCP kaynağının yükleme süresini, kaliteden ödün vermeden mümkün olduğunca kısaltın.
4. İ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.