Largest Contentful Paint'i Optimize Edin

LCP'nin nasıl ayrıntılandırılacağı ve iyileştirilebilecek önemli alanları nasıl belirleyeceğinizle ilgili adım adım açıklamalı bir 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. LCP özellikle, 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 LCP değerine 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ı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 sorunun kapsamını anlamaya çalışmalıdır.

LCP çeşitli araçlarla ölçülebilir ve bunların hepsi 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.

PageSpeed Insights CrUX LCP verilerini kullanma

PageSpeed Insights, en üstteki Gerçek kullanıcılarınızın neler yaşadığını keşfedin etiketli bölümdeki 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.

ziyaret edin.

PageSpeed Insights 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 veri
• 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.

Dört farklı CrUX veri kategorisine bakmak, bir LCP sorununun bu sayfaya özgü mü 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ığı (örneğin, bir bağlantıyı tıklayarak) HTML belgesinin ilk baytı alıncaya kadar geçen zamandır. 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 biraz içerik (örneğin, site başlığı) gösterilebilir. İlk içeriğin görünümü FCP ile ölçülür. FCP ve diğer metrikler arasındaki delta nettir.

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 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 delta, LCP kaynağının tarayıcı için hemen kullanılamayacağını (örneğin, ilk HTML'de yer almak yerine JavaScript tarafından yönetilen metin veya resimler) ya da 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ş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 aynı fikirde değilse CrUX, muhtemelen kullanıcı deneyiminizle ilgili daha doğru bilgiler sunar. İş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 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örevlerde, bunları daha küçük ve daha yönetilebilir görevlere ayırmak ve her birini ayrı ayrı ele almak genellikle 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ükleme işlemi genellikle bir dizi ağ isteğini içerir. Ancak LCP'yi iyileştirme fırsatlarını belirlemek için öncelikle ikisine bakarak başlamalısınız:

1. İlk HTML belgesi
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 tartışılan PageSpeed Insights, Chrome DevTools 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 resim isteği gerektirdiği tipik bir sayfa yüklemesinde bir ağ şelale diyagramı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ı 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 kendisini yüklemek için gereken süre. LCP öğesinin oluşturulması için kaynak yükü gerekmez. Bu süre 0'dır.

Öğe oluşturma gecikmesi

LCP kaynağının yüklenmesi ile LCP öğesinin yüklenmesi arasındaki süre tamamen oluşturuluyor.

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 bir 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 bölümleri ayrı ayrı optimize etmeyi denemek faydalı olur. 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, resmimizin dosya boyutunu daha fazla sıkıştırarak veya daha optimum bir biçime (AVIF ya da WebP gibi) geçerek küçültürseniz kaynak yükleme süresi kısalabilir, ancak süre sadece öğe oluşturma gecikmesi alt bölümüne kayacağı için LCP'yi iyileştirmez:

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ü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, yönergeler 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 herhangi bir "gecikme" sorunundan herhangi birinde bir şekilde devam ediyorsa 2, 5 saniyelik hedefe ulaşmak sürekli olarak zor olacaktır.

LCP süresinin dökümünü düşünmenin iyi bir yolu şudur:

• LCP süresinin büyük çoğunluğu HTML belgesi ve LCP kaynağını yüklemeye 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 ilişkin öneriler ve en iyi uygulamalar sunulur. 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 hedef, 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 sonra olsa da pratikte tarayıcılar kaynakları gerçekten yüklemeye başlamadan önce her zaman bir gecikme yaşanır.

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

Kaynak keşfedildiğinde optimizasyon yapın

LCP kaynağınızın mümkün olduğunca erken yüklenmeye başlamasını sağlamak için kaynağın, tarayıcının önceden yükleme tarayıcısı tarafından 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ı 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 geç 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 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ğ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> öğenizde loading="lazy" değerini ayarlarsanız HTML kullanarak LCP resminizi geciktirebilirsiniz. Geç yüklemenin kullanılması, düzenin, resmin görüntü alanında bulunduğu doğrulanana kadar kaynağın yüklenmeyeceği ve dolayısıyla, normalde olduğundan daha geç yüklenmeye başlanabileceği anlamına gelir.

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 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 <img> öğesinde fetchpriority="high" ayarlamak iyi bir fikirdir. Bununla birlikte, bir veya ikiden fazla resim için yüksek bir öncelik ayarlamak, öncelik ayarının LCP'yi azaltmaya yardımcı olmaz.

Ayrıca, doküman yanıtının başlarında yer alabilecek ancak stil özellikleri nedeniyle görünmeyen resimlerin (örneğin, 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 fazla ihtiyaç duyan kaynaklara daha fazla bant genişliği kazandırabilir. 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):

ziyaret edin.

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

Bu adımdaki hedef, ne zaman olursa olsun kaynağının yüklenmesi tamamlandıktan sonra LCP öğesinin 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 katılması gerektiğ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 nedenlerini nasıl ele alacağınız açıklanmaktadır.

Oluşturmayı engelleyen stil sayfalarını azaltma veya satır içi hale getirme

HTML işaretlemesinden yüklenen stil sayfaları, bunları izleyen tüm içeriğin oluşturulmasını engeller. Bu iyi bir durumdur çünkü genellikle stilsiz HTML oluşturmak istemezsiniz. Bununla birlikte, stil sayfası, yüklenmesi LCP kaynağından çok daha uzun sürecek kadar büyükse aşağıdaki örnekte gösterildiği gibi, kaynağın yüklenmesi tamamlandıktan sonra bile LCP öğesinin oluşturulması engellenir:

Bunu düzeltmek için şunları yapabilirsiniz:

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

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. 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 ziyarette sorun yaşanmayacaktır.

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 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şturmayı engelleyen JavaScript'i erteleme veya satır içi oluşturma

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:

• 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 ana dezavantajı, ek sunucu işleme süresi gerektirmesidir ve 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 de statik site oluşturma (SSG) veya önceden işleme olarak adlandırılır. Bu, HTML sayfalarınızı isteğe bağlı değil, bir derleme adımında oluşturma işlemidir. Önceden işleme mimarinizde kullanılabiliyorsa bu genellikle performans için daha iyi bir seçenektir.

Uzun görevleri bölme

Daha önceki tavsiyeyi uygulamış olsanız ve JavaScript kodunuz oluşturmayı engellemese ya da öğelerinizi oluşturmaktan sorumlu olmasa da LCP'yi geciktirebilir.

Bunun en yaygın nedeni, sayfaların, tarayıcının 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 azaltın

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 üç yolu vardır:

• Kaynağın boyutunu küçültün.
• Kaynağın gitmesi 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 yayınlama
• Modern resim biçimlerini kullanın
• Resimleri sıkıştırma
• Web yazı tipi boyutunu küçültme

Kaynağın gitmesi gereken mesafeyi azaltın

Bir kaynağın boyutunu küçültmenin yanı sıra sunucularınızı kullanıcılarınıza coğrafi olarak olabildiğince yakın bir yere yerleştirerek yükleme sürelerini de kısaltabilirsiniz. Bunu yapmanın en iyi yolu da 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 çakışmayı azaltma

Aynı anda birçok kaynak yüklüyorsanız kaynağınızın boyutunu ve katetmesi gereken mesafeyi azaltmış olsanız bile bir kaynağın yüklenmesi uzun sürebilir. Bu soruna ağ çekişmesi denir.

LCP kaynağınıza yüksek bir fetchpriority verdiyseniz ve kaynağı mümkün olan 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. Bununla birlikte, 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 ne kadar hızlı yüklendiğini etkileyebilir.

Ağ süresini tamamen ortadan kaldırın

Kaynak yükü süresini azaltmanın en iyi yolu, ağı işlemden tamamen kaldırmaktır. Kaynaklarınızı etkili bir önbellek kontrolü politikasıyla birlikte sunuyorsanız bu kaynakları ikinci kez isteyen ziyaretçiler önbellekten sunulur. Böylece kaynak yükleme süresi neredeyse sıfıra indirilir.

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 giden süreyi kısaltın

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ı gönderene kadar ön uçta hiçbir şey olmaz. Bu nedenle, TTFB'nizi hızlandırmak için yapabileceğiniz her şey, diğer tüm yükleme metriklerini de iyileştirecektir.

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çilerin beklemesi gereken yönlendirme sayısını her zaman en aza indirin.

Bunun diğer bir yaygın nedeni, önbelleğe alınan içeriğin CDN uç sunucusundan kullanılamaması ve tüm isteklerin, kaynak sunucuya tamamen geri yönlendirilmesinin gerekmesidir. Bu durum, benzersiz URL parametreleri ziyaretçiler tarafından analizler için kullanılıyorsa (farklı sayfalara yol açmasa 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 açıklanan LCP alt bölümlerinin tümü için zamanlama bilgilerini aşağıdaki performans API'lerinin bir kombinasyonu aracılığıyla JavaScript'te bulabilirsiniz:

• 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.

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 bilgileri kullanarak 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üresine kıyasla 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.

Chrome Geliştirici Araçları'nı kullanarak LCP dökümlerini izleme

Chrome Geliştirici Araçları, bu dökümü görebilmeniz için LCP süresini, LCP öğesini ve bu dört alt bölümü gerçek zamanlı olarak günlüğe kaydeder.

Özet

LCP karmaşık bir konudur ve zamanlaması çeşitli faktörlerden etkilenebilir. Ancak LCP'yi optimize etmenin esas olarak LCP kaynağının yükünü optimize etmek olduğunu düşünüyorsanız bunu önemli ölçüde basitleştirebilirsiniz.

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. Kaliteden ödün vermeden LCP kaynağının yüklenme süresini mümkün olduğunca azaltı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.