Largest Contentful Paint'i Optimize Edin

LCP'nin dökümünü alma ve iyileştirilmesi gereken temel alanları belirlemeyle ilgili adım adım açıklamalı kılavuz.

Philip Walton

Barry Pollard

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. Özellikle LCP, kullanıcının sayfayı yüklemeye başlamasından görüntü alanı içindeki en büyük resmin 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 olması gerekir.

Tarayıcının bir web sayfasını ne kadar hızlı yükleyip oluşturabileceğini birçok faktör etkileyebilir ve bunların herhangi birindeki gecikmeler LCP üzerinde önemli bir etkiye sahip olabilir.

Bir sayfanın tek bir kısmına yapılan hızlı bir düzeltmenin LCP'de anlamlı bir iyileşme sağlaması nadir görülen bir durumdur. 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 bir LCP sorunu olup olmadığını ve bu tür bir sorunun kapsamını anlamaya çalışmalıdır.

LCP birkaç araçla ölçülebilir ve bunların tümü LCP'yi aynı şekilde ölçmez. Gerçek kullanıcıların LCP'sini anlamak için Lighthouse veya yerel test gibi laboratuvar tabanlı bir aracın gösterdiklerinden ziyade gerçek kullanıcıların ne yaşadıklarına bakmalıyız. Bu laboratuvar tabanlı araçlar, LCP'yi açıklamak ve iyileştirmenize yardımcı olmak için pek çok bilgi sağlayabilir, ancak laboratuvar testlerinin tek başına gerçek kullanıcı deneyiminizi tam olarak temsil etmeyebileceğ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 sunulabilir.

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 tabanlı daha ayrıntılı veriler, en alttaki Performans sorunlarını teşhis başlıklı bölümde bulabilirsiniz. Web siteniz için CrUX verileri kullanılabiliyorsa, her zaman ilk olarak gerçek kullanıcı verilerine odaklanın.

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

• Bu URL için mobil veriler
• Bu URL için masaüstü verileri
• Origin'in tamamı için mobil veri
• Origin'in tamamı için Masaüstü verileri

Bunları, bölümün üst ve sağ üst kısmındaki denetimlerden değiştirebilirsiniz. Bir URL, URL düzeyinde gösterilecek yeterli veriye sahip değilse, ancak kaynakla ilgili verilere sahipse PageSpeed Insights her zaman kaynak verilerini gösterir.

Kaynağın tamamının LCP'si, LCP'nin söz konusu 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 ulaşma şeklinden de etkilenebilir. Ana sayfalar yeni kullanıcılar tarafından ziyaret edilme eğilimindedir. Bu nedenle, önbelleğe alınmış içerik olmadan "soğuk" olarak yüklenebilen ana sayfalar çoğu zaman web sitesindeki en yavaş sayfalardır.

CrUX verilerinin dört farklı kategorisini incelemek, bir LCP sorununun bu sayfaya özel mi, yoksa daha genel bir site genelinde mi olduğunu anlamanıza yardımcı olabilir. Benzer şekilde, hangi cihaz türlerinde LCP sorunları olduğunu 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 First Contentful Paint (FCP) ve Time to First Bayte (TTFB) zamanlamalarını da kullanmalıdır.

TTFB, ziyaretçinin bir sayfaya gitmeye başlamasından (örneğin, bir bağlantıyı tıklama) HTML belgesinin ilk baytları alınıncaya kadar geçen süredir. Yüksek bir TTFB, 2,5 saniyelik LCP elde etmeyi zorlaştırabilir, hatta imkansız hale getirebilir.

Yüksek bir TTFB, birden fazla sunucu yönlendirmesinden, en yakın site sunucusundan uzakta bulunan ziyaretçilerin, kötü ağ koşullarındaki ziyaretçilerin veya sorgu parametreleri nedeniyle önbelleğe alınmış içeriğin kullanılamamasından kaynaklanabilir.

Sayfa oluşturulmaya başladığında, ilk boyama (örneğin, arka plan rengi) ve ardından bazı içerikler (ör. site başlığı) görünebilir. İlk içeriğin görünümü FCP tarafından ölçülür. FCP ile diğer metrikler arasındaki fark çok önemli olabilir.

TTFB ile FCP arasındaki büyük bir fark, tarayıcının oluşturma engelleyici çok sayıda öğe indirmesi gerektiğini gösterebilir. Bu, anlamlı bir içeriği oluşturmak için çok fazla çalışması gerektiğinin de bir işareti olabilir. Bu, büyük ölçüde istemci tarafında oluşturmaya dayanan bir sitenin klasik göstergesidir.

FCP ve LCP arasında büyük bir delta olması, LCP kaynağının öncelik vermek amacıyla tarayıcı için hemen kullanılabilir olmadığını (örneğin, ilk HTML'de kullanılabilir olmak yerine JavaScript tarafından yönetilen metin veya resimler) veya tarayıcının LCP içeriğini görüntülemeden ö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ştirmek için bir miktar yol gösterir, ancak öncelikle verilen LCP'nin CrUX tarafından sağlanan gerçek kullanıcı verileriyle geniş bir şekilde uyumlu olup olmadığını kontrol etmeniz gerekir. Lighthouse ve CrUX uyuşmuyorsa, CrUX'in kullanıcı deneyiminizle ilgili daha doğru bir fikir edinme olasılığı yüksektir. İşlem yapmadan önce CrUX verilerinizin tam kaynağa değil, sayfanıza ait olduğundan emin olun.

Hem Lighthouse hem de CrUX, iyileştirilmesi gereken LCP değerleri gösteriyorsa Lighthouse bölümü, LCP'yi iyileştirme yolları hakkında değerli bilgiler sağlayabilir. Yalnızca LCP ile alakalı denetimleri aşağıdaki şekilde göstermek için LCP filtresini kullanın:

İyileştirme fırsatlarının yanı sıra, sorunun teşhis edilmesine 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:

İleride bu alt bölümlerin ayrıntılarına gireceğiz.

LCP dökümü

PageSpeed Insights bu metriği nasıl iyileştireceğiniz konusunda size yanıt vermediğinde LCP için optimizasyon yapmak daha karmaşık bir iş olabilir. Karmaşık görevler söz konusu olduğunda bunları daha küçük, daha yönetilebilir görevlere ayırmak ve her birini ayrı ayrı ele almak genellikle daha iyidir.

Bu bölümde, LCP'yi en kritik alt bölümlerine ayırmayla ilgili metodoloji ve ardından her bölümü optimize etmeye yönelik özel öneriler ve en iyi uygulamalar sunulmaktadır.

Çoğu sayfa yüklemesi genellikle çok sayıda ağ isteği içerir, ancak LCP'yi iyileştirmeye yönelik fırsatları belirlemek için yalnızca ikisine bakarak başlamalısınız:

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

Sayfadaki diğer istekler LCP'yi etkileyebilir ancak bu iki istek, özellikle de LCP kaynağının başladığı ve bittiği zamanlar, sayfanızın LCP için optimize edilip edilmediğini ortaya çıkarır.

LCP kaynağını tanımlamak için, geliştirici araçlarını (yukarıda açıklanan PageSpeed Insights gibi, Chrome Geliştirici Araçları veya WebPageTest) kullanarak LCP öğesini belirleyebilirsiniz. Burada, sayfa tarafından yüklenen tüm kaynakların bir ağ şelalesinde öğe tarafından yüklenen URL'yi (varsa) eşleştirebilirsiniz.

Örneğin, aşağıdaki görselleştirmede bu kaynaklar tipik bir sayfa yüklemesinden alınan ağ şelale diyagramında vurgulanmış olarak gösterilmiştir. Bu örnekte LCP öğesinin oluşturulması için resim isteği gereklidir.

İ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 bittikten sonra öğenin 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 bölebilirsiniz:

İlk Bayt Zamanı (TTFB)

Kullanıcının sayfayı yüklemeyi başlatmasından tarayıcının HTML belgesi 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şlaması arasındaki süre. LCP öğesi oluşturulması için bir kaynak yüklemesi gerektirmiyorsa (örneğin, öğe 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üredir. LCP öğesinin oluşturulması için kaynak yükü 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. Aralarında boşluk veya çakışma olmaz. Toplam LCP süresine denk gelir.

Her sayfanın LCP değeri bu dört alt bölüme ayrılabilir. Aralarında çakışma veya boşluk olmamalıdır. Bunların toplamı, LCP süresinin tamamını oluşturur.

LCP'yi optimize ederken bu alt bölümleri ayrı ayrı optimize etmeye çalışmak faydalıdır. Ancak bunların tümünü optimize etmeniz gerektiğini de unutmayın. Bazı durumlarda, bir bölüme uygulanan optimizasyon LCP'yi iyileştirmez, sadece tasarruf edilen zamanı başka bir bölüme kaydırır.

Örneğin, önceki ağ şelalesinde resmimizi daha fazla sıkıştırarak veya daha optimum bir biçime (AVIF ya da WebP gibi) geçerek dosya boyutunu küçültürseniz bu, kaynak yükleme süresini kısaltır ancak zaman yalnızca öğe oluşturma gecikmesi alt bölümüne kayacağı için LCP'yi iyileştirmez:

Bunun nedeni, bu sayfada LCP öğesinin, JavaScript kodunun yüklenmesi bitene kadar gizlenmesi ve ardından her şeyin aynı anda ortaya çıkmasıdır.

Bu örnek, en iyi LCP sonuçlarına ulaşmak için tüm bu alt parçaları optimize etmeniz gereken noktayı göstermeye yardımcı olur.

En uygun alt bölüm zamanları

LCP'nin her bir 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 anlamak önemlidir.

Dört alt bölümden ikisinin adında "gecikme" kelimesi bulunmaktadır. Bu, bu zamanların mümkün olduğunca sıfıra yaklaşmasını istediğinize dair bir ipucudur. Diğer iki bölüm, doğası gereği zaman alan ağ istekleriyle ilgilidir.

Bu zaman dökümlerinin katı kurallar değil, yol gösterici kurallar 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 herhangi birinde çok fazla gereksiz zaman harcıyorsanız sürekli olarak 2, 5 saniyelik hedefe ulaşmak çok zor olacaktır.

LCP süresinin dökümünü almanın iyi bir yolu aşağıdakilerden hangisidir?

• LCP süresinin büyük çoğunluğu HTML dokümanı ve LCP kaynağının yüklenmesi için harcanmalıdır.
• LCP öncesinde bu iki kaynaktan birinin yüklenmediği her zaman iyileştirme fırsatıdır.

Her bir bölümü optimize etme

Artık iyi optimize edilmiş bir sayfada LCP alt bölüm sürelerinin her birinin nasıl bölümlere ayrılması 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ü nasıl optimize edeceğinize dair öneriler ve en iyi uygulamalar sunulmaktadır. Bunlar, en büyük etkiye sahip olma olasılığı yüksek optimizasyonlardan başlayarak sırayla sunulur.

1. Kaynak yükleme gecikmesini ortadan kaldırın

Bu adımdaki amaç, LCP kaynağının mümkün olduğunca erken yüklenmeye başlamasını sağlamaktır. Teoride bir kaynağın yüklenmeye başlayabileceği en erken tarih TTFB'den hemen sonradır, pratikte ise tarayıcılar kaynakları gerçekten yüklemeye başlamadan önce her zaman bir miktar gecikme olur.

LCP kaynağınızın, söz konusu sayfa tarafından yüklenen ilk kaynakla aynı anda yüklenmeye başlaması gerektiğini unutmayın. Başka bir deyişle, LCP kaynağı ilk kaynaktan daha sonra yüklenmeye başlarsa iyileştirme yapılabilir.

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 ne kadar öncelik verildiği.

Kaynağın ne zaman keşfedileceğini optimize edin

LCP kaynağınızın mümkün olduğunca erken yüklenmeye başlaması için kaynağın, tarayıcının önceden yükleme tarayıcısı tarafından verilen ilk HTML dokümanı yanıtında bulunabilir olması çok önemlidir. Örneğin, aşağıdaki durumlarda tarayıcı, HTML dokümanı yanıtını tarayarak LCP kaynağını bulabilir:

• LCP öğesi bir <img> öğesidir ve src veya srcset özellikleri ilk HTML işaretlemesinde mevcuttur.
• LCP öğesi için CSS arka plan resmi gerekir ancak bu resim, HTML işaretlemesinde <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.

LCP kaynağının HTML dokümanı yanıtı taranarak bulunamadığı durumlarla ilgili bazı örnekleri burada bulabilirsiniz:

• LCP öğesi, JavaScript kullanılarak sayfaya dinamik bir şekilde eklenen bir <img>'dir.
• LCP öğesi, src veya srcset özelliklerini (genellikle data-src ya da data-srcset olarak) gizleyen bir JavaScript kitaplığı ile geç yüklenir.
• LCP öğesi için CSS arka plan resmi gerekir.

Bu durumların her birinde, tarayıcının LCP kaynağını keşfedip yüklemeye başlayabilmesi için komut dosyasını çalıştırması veya stil sayfasını uygulaması (genellikle ağ isteklerinin bitmesi beklenir) gerekir. Bu, hiçbir zaman optimum değildir.

Gereksiz kaynak yükleme gecikmesini ortadan kaldırmak için LCP kaynağınız, HTML kaynağından bulunabilir olmalıdır. Kaynağın yalnızca harici bir CSS veya JavaScript dosyasından referans verildiği 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 ilk kaynak olduğu kadar erken yüklenmeye başlamayabilir. Tarayıcının önceden yükleme yöntemi, kaynağın önemli olduğunu anlamazsa veya diğer kaynakların daha önemli olduğunu belirlerse bu durum meydana gelebilir.

Örneğin, <img> öğenizde loading="lazy" değerini ayarlarsanız HTML kullanarak LCP resminizi geciktirebilirsiniz. Geç yüklemeyi kullanmak, düzenin resmin görüntü alanında olduğunu onaylayana kadar kaynağın yüklenmeyeceği ve bu nedenle, normalden daha geç yüklenmeye başlayabileceği anlamına gelir.

Geç yükleme olmasa bile, resimler oluşturmayı engelleyen kaynaklar olmadığından başlangıçta tarayıcılar tarafından en yüksek öncelikli 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 olabileceğini düşünüyorsanız bir <img> öğesinde fetchpriority="high" ayarlamak iyi bir fikirdir. Ancak, bir veya ikiden fazla resimde yüksek bir öncelik belirlemek, öncelik ayarını LCP'nin azaltılmasına yardımcı olmaz.

Ayrıca, doküman yanıtının başlarında yer alabilecek ancak stil nedeniyle görünür olmayan resimlerin (ör. başlangıçta görünür olmayan atlı karınca slaytlarındaki resimler) önceliğini de düşürebilirsiniz:

<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">

Belirli kaynakların öncelik düzeyini düşürerek bu kaynaklara daha çok ihtiyaç duyan kaynaklar için daha fazla bant genişliği sağlayabilirsiniz ancak bunu yaparken dikkatli olun. Her zaman Geliştirici Araçları'nda kaynak önceliğini kontrol edin ve değişiklikleri laboratuvar ve alan araçlarıyla test edin.

LCP kaynağınızın önceliğini ve keşif zamanını optimize ettikten sonra ağ şelaleniz şu şekilde görünmelidir (LCP kaynağı ilk kaynakla aynı zamanda başlayacak şekilde):

2. Öğe oluşturma gecikmesini ortadan kaldırın

Bu adımdaki amaç, LCP öğesinin, kaynağının yüklenmesi bittikten sonra, ne zaman olursa olsun hemen oluşturulabilmesini sağlamaktır.

LCP öğesinin, kaynağının yüklenmesi bittikten hemen sonra oluşturulamamasının birincil nedeni oluşturma işleminin başka bir nedenle engellenmesi olabilir:

• Tüm sayfanın oluşturulması, <head> içindeki stil sayfaları veya eşzamanlı komut dosyaları yüklenmeye devam ettiği için engellendi.
• LCP kaynağının yüklenmesi tamamlandı, ancak LCP öğesi henüz DOM'ye eklenmemiş (bazı JavaScript kodlarının yüklenmesini bekliyor).
• Öğe, kullanıcının hangi denemeye dahil olması gerektiğini hâlâ belirleyen 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örevlerin tamamlanmasını 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ı küçültme veya satır içi

HTML işaretlemesinden yüklenen stil sayfaları, kendilerinden sonra gelen tüm içeriğin oluşturulmasını engeller. Stilsiz HTML oluşturmak genellikle istemediğinizden bu iyi bir şeydir. Bununla birlikte, stil sayfasının yüklenmesi LCP kaynağından önemli ölçüde uzun sürecek kadar büyükse aşağıdaki örnekte gösterildiği gibi, LCP öğesinin oluşturulması engellenir. Bu, kaynağının yüklenmesi tamamlandıktan sonra bile olur:

Bunu düzeltmek için aşağıdakilerden birini yapabilirsiniz:

• Ek ağ isteğinden kaçınmak için stil sayfasını HTML'ye satır içi olarak ekleme veya
• stil sayfasının boyutunu küçültün.

Genel olarak, HTML'deki satır içi içerik sonraki sayfa yüklemelerinde önbelleğe alma özelliğinden yararlanamaz. Bu nedenle, stil sayfanızı satır içine almanız yalnızca stil sayfanız küçükse önerilir. 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 ihtimali düşüktür.

Çoğu durumda, stil sayfasının LCP öğesinin oluşturulmasını engellememesini sağlamanın en iyi yolu, boyutunu LCP kaynağından daha küçük olacak şekilde küçültmektir. Bu, trafiğin çoğu ziyaret için bir tıkanıklık oluşturmamasını sağlayacaktır.

Stil sayfasının boyutunu küçültmeye yönelik bazı öneriler:

• Kullanılmayan CSS'yi kaldırma: Kullanılmayan ve kaldırılabilecek (veya ertelenebilecek) CSS kurallarını bulmak için Chrome Geliştirici Araçları'nı kullanın.
• Kritik olmayan CSS'yi ertele: Stil sayfanızı ilk sayfa yüklemesi için gerekli olan stillere, ardından geç yüklenebilecek 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üçültdüğünüzden emin olun.

Oluşturmayı engelleyen JavaScript'i erteleme veya satır içi olarak kullanma

Eşzamanlı komut dosyalarını (async veya defer özellikleri olmayan komut dosyaları) sayfalarınızın <head> öğelerine eklemek neredeyse hiçbir zaman gerekmez ve bunu yapmanın performans üzerinde her zaman olumsuz bir etkisi olacaktır.

JavaScript kodunun sayfa yüklenirken mümkün olduğunca erken çalıştırılması gereken durumlarda, kodun satır içine alınması en iyisidir. Böylece, oluşturma işlemi başka bir ağ isteğini beklerken gecikmez. Ancak, stil sayfalarında olduğu gibi, komut dosyalarını yalnızca çok küçük olmaları durumunda satır içi olarak kullanmanız 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şturmayı kullan

Sunucu tarafı oluşturma (SSR), istemci taraflı uygulama mantığınızı sunucuda çalıştırma ve HTML belgesi 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, önceki 1. adımda açıklandığı gibi HTML kaynağından bulunabilir.
• Sayfa içeriğinizin oluşturulabilmesi için ek JavaScript isteklerinin tamamlanması gerekmez.

SSR'nin ana dezavantajı, ek sunucu işleme süresi gerektirmesidir, bu da TTFB'nizi yavaşlatabilir. Ancak sunucu işleme süreleri sizin kontrolünüzde olduğundan, kullanıcılarınızın ağ ve cihaz özellikleri sizin kontrolünüzde olduğu için bu dengeye genellikle değebilirsiniz.

SSR'ye benzer bir seçenek, statik site oluşturma (SSG) veya önceden oluşturma olarak adlandırılır. Bu, HTML sayfalarınızı istek üzerine değil, bir oluşturma adımında oluşturma sürecidir. Mimarinizle önceden işleme mümkünse performans için genellikle daha iyi bir seçimdir.

Uzun görevleri bölün

Önceki önerileri uygulamanıza rağmen JavaScript kodunuz oluşturmayı engellemiyor veya öğelerinizi oluşturmaktan sorumlu değilse bile LCP'de gecikmeye neden olabilir.

Bunun en yaygın nedeni, sayfaların büyük JavaScript dosyaları yüklemesidir. Bu dosyaların, tarayıcının ana iş parçacığında ayrıştırılıp yürütülmesi gerekir. Bu, resim kaynağınız tamamen indirilmiş olsa bile, alakasız bir komut dosyasının oluşturulabilmesi için yürütülmesini beklemesi gerekebileceği anlamına gelir.

Günümüzde tüm tarayıcılar, resimleri ana iş parçacığında oluşturmaktadır. Bu da ana iş parçacığını engelleyen herhangi bir öğe, gereksiz öğe oluşturma gecikmesine neden olabilmektedir.

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. Genellikle bunu yapmanın üç yolu vardır:

• Kaynağın boyutunu küçültün.
• Kaynağın kat etmesi gereken mesafeyi azaltın.
• Ağ bant genişliği için çakışmayı azaltın.
• Ağ süresini tamamen ortadan kaldırarak.

Kaynağın boyutunu küçültün

Bir sayfanın LCP kaynağı (varsa) bir resim veya web yazı tipi olur. Aşağıdaki kılavuzlarda, her ikisinin de boyutunun nasıl küçültüleceği oldukça ayrıntılı bir şekilde açıklanmaktadır:

• İdeal resim boyutunu sunma
• Modern resim biçimlerini kullanma
• Resimleri sıkıştırma
• Web yazı tipi boyutunu küçültme

Kaynağın kat etmesi gereken mesafeyi azaltma

Bir kaynağın boyutunu küçültmeye ek olarak, sunucularınızı kullanıcılarınıza coğrafi olarak mümkün olduğunca yaklaştırarak yükleme sürelerini de azaltabilirsiniz. Bunu yapmanın en iyi yolu ise bir içerik yayınlama ağı (CDN) kullanmaktır.

Özellikle resim CDN'leri, yalnızca kaynağın hareket etmesi gereken mesafeyi azaltmakla kalmayıp aynı zamanda kaynağın boyutunu da azaltarak daha önceki tüm boyut küçültme önerilerini sizin için otomatik olarak uyguladığı için özellikle faydalıdır.

Ağ bant genişliği için çakışması azalt

Kaynağınızın boyutunu ve kat etmesi gereken mesafeyi azaltmış olsanız bile, aynı anda başka kaynaklar yüklüyorsanız kaynağın yüklenmesi uzun sürebilir. Bu sorun ağ anlaşmazlığı olarak bilinir.

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 fazla kaynak yüklüyorsanız bu durum LCP kaynağının yüklenme hızını etkileyebilir.

Ağ süresini tamamen ortadan kaldırma

Kaynak yükleme süresini azaltmanın en iyi yolu, ağı sürecin dışında tutmaktır. Kaynaklarınızı etkili bir önbellek denetimi politikasıyla sunuyorsanız bu kaynakları ikinci kez isteyen ziyaretçiler bunları önbellekten sunar. Böylece kaynak yükleme süresi neredeyse sıfıra iner.

LCP kaynağınız bir web yazı tipiyse web yazı tipi boyutunu küçültmenin yanı sıra web yazı tipi kaynak yükünde oluşturmayı engellemeniz gerekip gerekmediğini de göz önünde bulundurmanız gerekir. auto veya block dışında bir değer için font-display değeri ayarlarsanız metin, yükleme sırasında her zaman görünür ve ek ağ isteğinde LCP engellenmez.

Son olarak, LCP kaynağınız küçükse kaynakları bir veri URL'si olarak satır içine almak mantıklı olabilir, bu da ek ağ isteğini ortadan kaldırır. Ancak veri URL'lerinin kullanılması uyarıları beraberinde getirir. Bunun nedeni, kaynakların önbelleğe alınamaması ve bazı durumlarda, ek kod çözme maliyeti nedeniyle daha uzun süreli oluşturma gecikmelerine yol açabilmesidir.

4. İlk bayta geçiş süresini azaltın

Bu adımın amacı, başlangıç HTML'sini mümkün olduğunca hızlı bir şekilde yayınlamaktır. Bu adım, genellikle geliştiricilerin en az kontrole sahip olduğu adım olduğu için son olarak listelenir. Ancak, kendisinden sonra gelen her adımı doğrudan etkilediği için bu aynı zamanda en önemli adımlardan biridir. Arka uç, içeriğin ilk baytını gönderene 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ük metriklerini de iyileştirir.

Normalde hızlı bir site için yavaş bir TTFB'nin yaygın bir nedeni, ziyaretçilerin reklamlar veya kısaltılmış bağlantılar gibi birden çok yönlendirme üzerinden gelmesidir. Bir ziyaretçinin beklemesi gereken yönlendirme sayısını her zaman en aza indirin.

Yaygın olarak karşılaşılan diğer bir neden de önbelleğe alınan içeriğin CDN uç sunucusundan kullanılamaması ve tüm isteklerin, tamamıyla tekrar kaynak sunucuya yönlendirilmesi gerektiğidir. Bu durum, farklı sayfalarla sonuçlanmasalar bile ziyaretçiler tarafından analiz için benzersiz URL parametreleri kullanıldığında ortaya çıkabilir.

TTFB'yi optimize etme konusunda özel rehberlik için TTFB kılavuzuna bakın.

JavaScript'te LCP dökümünü izleme

Daha önce açıklanan tüm LCP alt bölümlerinin zamanlama bilgilerine, aşağıdaki performans API'lerinin bir kombinasyonu aracılığıyla JavaScript'te ulaşabilirsiniz:

• Largest Contentful Paint API
• Gezinme Zamanlaması API'si
• Resource Timing API

Bu zamanlama değerlerini JavaScript'te hesaplamanın avantajı, hata ayıklama ve optimizasyon konusunda yardımcı olması için bunları bir analiz sağlayıcısına gönderebilmenizi veya geliştirici araçlarınıza kaydedebilmenizi sağlamaktı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ıyla birlikte incelendiğinde yararlıdır. Çünkü bu zaman aralıklarında sayfada başka neler olduğunu bir bakışta görebilirsiniz.

Zamanlamalar kanalında LCP alt bölümlerini görselleştirmenin yanı sıra, her bir alt bölümün toplam LCP süresindeki yüzdesini hesaplamak için JavaScript'i de kullanabilirsiniz. Bu bilgiler sayesinde, 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 bir LCP alt bölümünün toplam süresinin ve konsola toplam LCP süresindeki yüzdesinin 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ı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.

Web Verileri uzantısını kullanarak LCP dökümlerini izleme

Web Verileri uzantısı, bu dökümü kolayca görebilmeniz için LCP süresini, LCP öğesini ve bu dört alt bölümü konsolda günlüğe kaydeder.

Özet

LCP karmaşıktır ve zamanlaması bir dizi faktörden etkilenebilir. Ancak LCP'yi optimize etmenin birincil olarak LCP kaynağının yükünü optimize etmekle ilgili olduğunu düşünürseniz işleri önemli ölçüde basitleştirebilir.

LCP'yi optimize etme, 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 biter bitmez oluşturulabildiğinden emin olun.
3. Kaliteden ödün vermeden LCP kaynağının yüklenme süresini mümkün olduğunca azaltın.
4. İlk HTML belgesini mümkün olduğunca hızlı gönderin.

Sayfalarınızda bu adımları uygulayabiliyorsanız kullanıcılarınıza optimum yükleme deneyimi sunduğunuzdan emin olmalı ve bu durumun gerçek dünyadaki LCP puanlarınıza yansıtıldığını görmeniz gerekir.