Largest Contentful Paint (LCP), üç Core Web Vitals metriğinden biridir. Bir web sayfasının ana içeriğinin ne kadar hızlı yüklendiğini, özellikle de kullanıcının sayfayı yüklemeye başlamasından görüntü alanı içinde en büyük resmin veya metin bloğunun oluşturulmasına kadar geçen süreyi gösterir.
İ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şturabildiğini ve bunların herhangi birindeki gecikmelerin LCP üzerinde önemli bir etkisi olan birçok faktör olabilir.
Nadiren bir sayfanın tek bir kısmına yapılan hızlı bir düzeltme, LCP'de anlamlı bir iyileşme sağlar. 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 sitelerinde bir LCP sorunu olup olmadığını ve varsa ne kadar olduğunu anlamalıdır.
LCP'yi ölçebilecek birçok araç vardır ancak bu araçların tümü LCP'yi aynı şekilde ölçmez. Gerçek kullanıcıların LCP deneyimini anlamak için yalnızca Lighthouse veya yerel test gibi laboratuvar tabanlı bir aracın gösterebileceklerini değil, gerçek kullanıcıların neler yaşadığını anlamanız gerekir. Laboratuvar tabanlı bu araçlar, LCP'yi açıklamak ve metriklerinizi iyileştirmenize yardımcı olmak için pek çok bilgi sağlayabilir ancak laboratuvar testleri, kullanıcılarınızın deneyimini tam olarak yansıtmaz.
Gerçek kullanıcıları temel alan LCP verilerini, bir sitede yüklü 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) aracılığıyla gösterebilirsiniz.
PageSpeed Insights'ta CrUX verilerini kullanma
PageSpeed Insights, Gerçek kullanıcılarınızın deneyimini keşfedin bölümündeki CrUX verilerine erişim sağlar. Daha ayrıntılı laboratuvar tabanlı verileri Performans sorunlarını teşhis edin bölümünde bulabilirsiniz. Her zaman ilk olarak CrUX verilerine odaklanın.
CrUX'in veri sunmadığı durumlarda (örneğin, sayfa düzeyinde veri almak için yeterli trafiğe sahip olmayan bir sayfa için) CrUX'i, sayfada çalışan JavaScript API'leri kullanılarak toplanan RUM verileriyle ekleyebilirsiniz. Bu ayrıca, CrUX'in herkese açık bir veri kümesi olarak ortaya koyabileceğinden çok daha fazla veri sağlayabilir. Bu kılavuzun ilerleyen bölümlerinde, bu verilerin JavaScript kullanılarak nasıl toplanacağını açıklayacağız.
LCP verileri
PageSpeed Insights, en fazla dört farklı CrUX veri kümesi 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ı, bu bölümün üst ve sağ üst kısmındaki denetimlerden değiştirebilirsiniz. Bir URL'nin URL düzeyinde gösterilmeye yetecek kadar verisi yoksa, ancak kaynak verisi varsa PageSpeed Insights her zaman kaynak verilerini gösterir.
Tüm kaynak için LCP, 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 genellikle yeni kullanıcılar tarafından ziyaret edilir ve bu nedenle çoğu zaman önbelleğe alınmış içerik olmadan yüklenirler. Bu da onları web sitesindeki en yavaş sayfalar yapar.
CrUX verilerinin dört farklı kategorisini incelemek, bir LCP sorununun bu sayfaya özel mi yoksa daha genel bir site genelinde mi kaynaklandığını anlamanıza yardımcı olabilir. Benzer şekilde, hangi cihaz türlerinde LCP sorunları olduğunu gösterebilir.
Ek metrikler
LCP'yi optimize etmek için çalışan geliştiriciler, 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 kullanabilirler.
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çilerden, kötü ağ koşullarındaki ziyaretçilerden veya sorgu parametreleri nedeniyle önbelleğe alınmış içeriğin kullanılamamasından kaynaklanabilir.
Sayfa oluşturulmaya başladığında, ilk boyama (ör. 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 ve FCP ile diğer metrikler arasındaki fark çok açıklayıcı olabilir.
TTFB ve FCP arasındaki büyük bir fark, tarayıcının oluşturma engelleyici çok sayıda öğe indirmesi gerektiğini gösterebilir. Ayrıca bu, tarayıcının anlamlı içerikleri oluşturmak için çok fazla iş tamamlaması gerektiğinin de bir göstergesi olabilir. Bu da sitenin büyük ölçüde istemci tarafında oluşturmaya dayandığını gösterir.
FCP ve LCP arasındaki büyük bir fark, LCP kaynağının öncelik vermek amacıyla tarayıcı tarafından hemen kullanılamayacağı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üleyebilmek için başka işleri tamamlaması gerektiğini gösterir.
PageSpeed Insights Lighthouse verilerini kullanma
PageSpeed Insights'ın Lighthouse bölümü, LCP'yi iyileştirmek için bazı yol gösterir, ancak önce 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, muhtemelen kullanıcı deneyiminize ilişkin daha doğru bir fikir vermesi beklenir. İş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ırsatı'nın yanı sıra, sorunun teşhis edilmesine yardımcı olmak için 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:
Bir sonraki bölümde LCP'nin alt kategorileri daha ayrıntılı olarak incelenmektedir.
LCP dökümü
Bu bölümde, LCP'yi en önemli alt kategorilerine ayıran bir metodoloji, her bir alt kategoriyi optimize etmek için özel öneriler ve en iyi uygulamalar sunulmaktadır.
Çoğu sayfa yüklemesinde genellikle birkaç ağ isteği bulunur ancak LCP'yi iyileştirme fırsatlarını belirlemek için yalnızca ilk HTML belgesi ve varsa LCP kaynağıyla başlamanızı öneririz.
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ı belirlemek amacıyla, LCP öğesini belirlemek için PageSpeed Insights, Chrome Geliştirici Araçları veya WebPageTest gibi geliştirici araçlarını kullanabilirsiniz. Buradan, öğe tarafından sayfa tarafından yüklenen tüm kaynakların bir ağ şelalesinde yüklenen URL'yi (varsa) eşleştirebilirsiniz.
Örneğin, aşağıdaki görselleştirmede bu kaynaklar tipik bir sayfa yüklemesindeki ağ şelalesi diyagramında vurgulanmış olarak gösterilmiştir. LCP öğesinin oluşturulması için resim isteği gerekir.
İ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 kategorilere bölebilirsiniz:
- İlk bayta kadar geçen süre (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 kendisini yüklemek için gereken süre. LCP öğesi oluşturmak için kaynak yükü gerektirmiyorsa 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.
LCP'yi optimize ederken bu alt kategorileri optimize etmeye çalışmak faydalıdır. Ancak, bazı optimizasyonlar LCP'yi azaltmak yerine bir bölümde kazanılan süreyi başka bir bölüme kaydırdığı için hepsinin optimize edildiğinden emin olmanız gerekir.
Örneğin, ağ şelalesi örneğinde, resmi daha fazla sıkıştırarak veya daha optimum bir biçime geçerek (AVIF ya da WebP gibi) resmin dosya boyutunu azaltmak, kaynak yükleme süresini kısaltır ancak öğe oluşturma gecikmesinin bir parçası haline geldiği için LCP'yi iyileştirmez. Bunun nedeni, LCP öğesinin, ilişkili JavaScript'inin yüklenmesi bitene kadar gizlenmesi ve yükleme tamamlandıktan sonra gösterilmesidir.
En uygun alt kategori süreleri
İyi optimize edilmiş bir sayfada LCP'nin her bir alt kategorisini optimize etmek için bu alt kategorilerin ideal dökümünün ne olduğunu anlamak önemlidir.
Gecikmeler içeren iki alt kategori mümkün olduğunca azaltılmalıdır. Diğer ikisi, doğası gereği zaman alan ve tamamen optimize edilemeyen ağ istekleriyle ilgilidir.
Aşağıda, idealleştirilmiş bir LCP dağılımı gösterilmektedir.
Bu zamanlar katı kurallar değil, rehberdir. Sayfalarınızın LCP süreleri tutarlı olarak 2, 5 saniye veya daha kısaysa dökümün nasıl göründüğü önemli değildir. Ancak gecikme kategorileriniz gereksiz şekilde uzunsa 2,5 saniye hedefine ulaşmada sorun yaşarsınız.
LCP süresi dökümünü şu şekilde değerlendirmenizi öneririz:
- LCP süresinin büyük bir kısmı HTML belgesinin ve LCP kaynağının yüklenmesi için harcanmalıdır.
- LCP öncesinde bu iki kaynaktan birinin yüklenmediği herhangi bir zaman iyileştirme fırsatıdır.
Her bir kategoriyi optimize etme
İyi optimize edilmiş bir sayfada LCP alt kategori sürelerinin nasıl göründüğünü öğrendiğinize göre artık kendi sayfalarınızı optimize etmeye başlayabilirsiniz.
Aşağıdaki bölümlerde, en büyük etkiye sahip olabilecek optimizasyonlardan başlayarak her bir kategoriyi optimize eden öneriler ve en iyi uygulamalar sunulmaktadır.
Kaynak yükleme gecikmesini ortadan kaldırın
Bu adımın amacı, LCP kaynağının mümkün olduğunca erken yüklenmeye başlamasını sağlamaktır. Bir kaynağın teorik olarak 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 olur.
Genel bir kural olarak, LCP kaynağınızın sayfanın yüklendiği ilk kaynakla aynı anda başladığından emin olun.
Genel olarak bir LCP kaynağının ne kadar hızlı yüklenebildiğ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 söz konusu kaynağın, tarayıcının ön yükleme tarayıcısı tarafından ilk HTML dokümanı yanıtında bulunabilir olması gerekir. Bulunabilir LCP kaynaklarına örnek olarak şunlar verilebilir:
srcveyasrcsetözellikleri ilk HTML işaretlemesinde bulunan bir<img>öğesi.- Söz konusu resmin HTML işaretlemesinde
<link rel="preload">tarafından önceden yüklenmiş olması (veyaLinküstbilgisi kullanılarak) CSS arka plan resmi gerektiren herhangi bir öğe. - Yazı tipi HTML işaretlemesinde
<link rel="preload">tarafından önceden yüklendiği (veyaLinküst bilgisi kullanılarak) olduğu sürece, oluşturulması için bir web yazı tipi gerektiren metin düğümü.
HTML belgesi yanıtı taranarak bulunamayan bazı LCP kaynaklarını burada bulabilirsiniz. Her durumda, tarayıcının LCP kaynağını keşfedip yüklemeye başlamadan önce bir komut dosyası çalıştırması veya bir stil sayfası uygulaması gerekir. Bunun sonucunda tarayıcı, ağ isteklerinin tamamlanmasını beklemelidir.
<img>, JavaScript kullanılarak sayfaya dinamik bir şekilde eklenir.srcveyasrcsetözelliklerini (genellikledata-srcveyadata-srcsetolarak kullanılır) gizleyen bir JavaScript kitaplığı kullanılarak geç yüklenen herhangi bir öğe.- CSS arka plan resmi gerektiren tüm öğeler.
Gereksiz kaynak yükleme gecikmesini ortadan kaldırmak için LCP kaynağınızın, HTML kaynağından bulunabilir olması gerekir. Kaynağın yalnızca harici bir CSS veya JavaScript dosyasından referans aldığı 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 ön yükleme tarayıcısındaki öncelikli buluşsal yöntemler, kaynağın önemli olduğunu algılamazsa 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 teyit edene kadar kaynağın yüklenmemesi anlamına gelir. Bu da genellikle resmin görüntü alanında olduğundan daha sonra yüklenmesine neden olur.
Tarayıcılar, geç yükleme olmadan bile yüksek öncelikli resimleri yüklemez. Bunun nedeni, bu resimlerin oluşturulmasını engelleyen kaynak olmamasıdır. Bir kaynağın yükleme önceliğini, fetchpriority özelliğini kullanarak aşağıdaki şekilde artırabilirsiniz:
<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. Bununla birlikte, bir veya ikiden fazla görüntü için yüksek öncelikli ayarlamak, öncelik ayarını LCP'nin azaltılmasına faydasız hale getirir.
Ayrıca, doküman yanıtının başlarında yer alabilecek ancak stil nedeniyle görünmeyen resimlerin (ör. başlangıçta görülmeyen 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 daha fazla ihtiyaç duyan kaynaklar için daha fazla bant genişliği sağlayabilirsiniz. Ancak bunda aşırıya kaçmamaya dikkat edin. Kaynak önceliğini daima Geliştirici Araçları'ndan kontrol edin ve değişikliklerinizi laboratuvar ve alan araçlarıyla test edin.
LCP kaynak önceliğinizi ve keşif sürenizi optimize ettikten sonra ağ şelaleniz, LCP kaynağı ilk kaynakla aynı zamanda başlayacak şekilde şöyle görünmelidir:
Önemli nokta: LCP kaynağınızın, HTML kaynağından bulunsa bile mümkün olduğunca erken yüklenmeye başlamamasının bir başka nedeni de, tarayıcının kaynağı yüklemeye başlamadan önce bağlanması gereken farklı bir kaynakta barındırılmasıdır. Mümkün olduğunda, kritik kaynakları HTML dokümanı kaynağınızla aynı kaynakta barındırmanızı öneririz. Böylece tarayıcı zaman kazanmak için mevcut bağlantıyı yeniden kullanabilir (bu konuya daha sonra değineceğiz).
Öğe oluşturma gecikmesini ortadan kaldırma
Bu adımdaki amaç, LCP öğesinin, kaynağının yüklenmesi bittikten sonra, ne zaman olursa olsun hemen oluşturulabildiğinden emin olmaktı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 JavaScript kodunun yüklenmesini beklediği için henüz DOM'a eklenmedi.
- Öğe, kullanıcının hangi deneme amaçlı gruba yerleştirileceğine henüz karar vermemiş bir A/B testi kitaplığı gibi başka bir kod tarafından gizlenmiştir.
- Ana iş parçacığı uzun görevler nedeniyle engellenir ve işin oluşturulması için bu uzun görevler tamamlanana kadar beklemesi gerekir.
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şaretleme bloğundan yüklenen stil sayfaları, bunları izleyen tüm içeriğin oluşturulmasıdır. Bu, stil sayfasının diğer öğeler yüklenmeden önce etkin olmasını sağladığı için genellikle iyi bir şeydir. Bununla birlikte, stil sayfasının yüklenmesi LCP kaynağından önemli ölçüde uzun sürecek kadar büyükse bu örnekte gösterildiği gibi, LCP öğesinin kaynağının yüklenmesi tamamlandıktan sonra bile LCP öğesinin oluşturulması engellenir:
Bu sorunu düzeltmek için:
- 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.
Stil sayfanızı satır içine almak, yalnızca stil sayfası küçükse LCP'yi azaltmada etkilidir. Bununla birlikte, stil sayfanızın yüklenmesi LCP kaynağınızdan daha uzun sürüyorsa etkili bir şekilde satır içi yapmak için muhtemelen çok büyüktür. Bu nedenle, stil sayfanızın karmaşıklığını aşağıdaki şekilde azaltmanızı öneririz:
- Kullanılmayan CSS'yi kaldırma: Kullanılmayan ve kaldırılabilecek (veya ertelenmiş) 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 kullanılacak stillere, ardından geç yüklenebilecek stillere bölün.
- CSS'yi küçültün ve sıkıştırın: Kritik öneme sahip 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
async veya defer özelliklerini kullanarak sayfalarınızdaki tüm komut dosyalarını eşzamansız hale getirmenizi öneririz. Eşzamanlı komut dosyaları kullanmak, performans açısından neredeyse her zaman kötüdür.
Bununla birlikte, sayfa yüklenirken mümkün olduğunca erken çalışması gereken JavaScript'iniz varsa tarayıcının ağ isteklerini beklerken harcadığı süreyi azaltmak için küçük komut dosyalarını satır içine alarak LCP'yi iyileştirebilirsiniz.
<head>
<script>
// Inline script contents directly in the HTML.
// IMPORTANT: only do this for very small scripts.
</script>
</head>
<head> <script src="/path/to/main.js"></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.
SSR, LCP'nin optimize edilmesine aşağıdaki şekillerde yardımcı olur:
- Kaynak yükleme gecikmesini ortadan kaldırma bölümünde açıklandığı gibi, kaynaklarınızı HTML kaynağından keşfedilebilir hale getirir.
- Sayfanızın oluşturulabilmesi için ek JavaScript isteklerine ihtiyaç duymasını önler.
SSR'nin en önemli 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 genellikle bu dengeye değer.
Ayrıca, daha iyi performans için HTML sayfalarınızı istek üzerine değil, bir oluşturma adımında oluşturmanızı öneririz. Bu uygulamaya statik site oluşturma (SSG) veya önceden oluşturma denir.
Uzun görevleri bölün
Tüm bu tavsiyelere uymanıza ve JavaScript kodunuz öğelerinizi oluşturmayı engellemese veya oluşturmaktan sorumlu olmasa bile LCP'de gecikmeye neden olabilir.
En yaygın neden, bir sayfa büyük bir JavaScript dosyası yüklediğinde, tarayıcının ana iş parçacığındaki kodu ayrıştırıp yürütmesinin zaman almasıdır. Bu, LCP kaynağı tamamen indirilmiş olsa bile alakasız bir komut dosyasının çalışması bitene kadar oluşturulması için beklemesi gerekebileceği anlamına gelir.
Tüm tarayıcılar, resimleri ana iş parçacığında oluşturur. Bu, ana iş parçacığını engelleyen herhangi bir şeyin, gereksiz öğe oluşturma gecikmesine de yol açabileceği anlamına gelir. Bu nedenle, büyük bir JavaScript dosyasını birden fazla komut dosyası dosyasına bölmenizi öneririz. Bu dosyaların her biri gerektiğinde ayrıştırılabilir.
Kaynak yükleme süresini azaltma
Bu adımın amacı, tarayıcının kaynağı ağ üzerinden kullanıcının cihazına aktarırken harcadığı süreyi azaltmaktır. Genel olarak, bunu yapmanın birkaç 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
LCP kaynakları genellikle resim veya web yazı tipleridir. Aşağıdaki kılavuzlarda her ikisinin de boyutunun nasıl küçültüleceği hakkında ayrıntılı bilgiler verilmektedir:
- İ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
Sunucularınızı coğrafi olarak kullanıcılarınıza mümkün olduğunca yakın bir konuma yerleştirerek yükleme sürelerini de azaltabilirsiniz. Bunu yapmanın en iyi yolu bir içerik yayınlama ağı (CDN) kullanmaktır.
Aslında, özellikle görsel CDN'ler hem kaynağın gitmesi gereken mesafeyi azalttığı hem de daha önce bahsedilen stratejileri uygulayarak genellikle kaynağın boyutunu küçülttüğü için faydalıdır.
Önemli nokta: Görüntü CDN'leri, kaynak yükleme sürelerini azaltmanın harika bir yoludur. Ancak görüntülerinizi barındırmak için üçüncü taraf alan kullanmanın ek bağlantı maliyeti vardır. Kalkış noktasına önceden bağlanmak bu maliyetin bir kısmını azaltabilir. Ancak en iyi seçenek, HTML belgenizle aynı kaynaktan resimler sunmaktır. Buna olanak tanımak için birçok CDN, istekleri kaynağınızdan onların kaynaklarına yönlendirmenize olanak tanır.
Ağ bant genişliği için çakışması azalt
Sayfanız aynı anda çok sayıda kaynak yüklüyorsa tek bir 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 tek seferde çok fazla kaynak yüklemek, özellikle de bu kaynakların birçoğu yüksek fetchpriority değerine sahipse LCP'yi etkileyebilir. Yüksek fetchpriority değerine sahip yalnızca en hızlı şekilde yüklenmesi gereken kaynaklar olduğundan emin olarak ağ anlaşmazlığını azaltmanızı öneririz.
Ağ süresini tamamen ortadan kaldırma
Kaynak yükleme sürelerini azaltmanın en iyi yolu, ağı işlemden tamamen kaldırmaktır. Kaynaklarınızı etkili bir önbellek denetimi politikasıyla sunarsanız bu kaynakları ikinci kez isteyen ziyaretçiler bunları önbellekten sunar. Böylece, kaynak yükleme süresi temelde sıfıra indirilir.
LCP kaynağınız bir web yazı tipiyse web yazı tipi boyutunu küçültmenin yanı sıra web yazı tipi kaynağı yükünde oluşturmayı engellemeniz gerekip gerekmediğini dikkate almanızı öneririz.
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 LCP'nin ekstra ağ isteğini beklemesi gerekmez.
Son olarak, LCP kaynağınız küçükse ek ağ isteğini ortadan kaldırmak için kaynakları bir veri URI'si olarak satır içine almak mantıklı olabilir. Bununla birlikte, veri URI'lerini kullanmanın dezavantajları vardır: Bu yöntem, kaynakların önbelleğe alınmasını engeller ve ek kod çözme maliyeti nedeniyle bazı durumlarda oluşturma gecikmelerinin daha uzun sürmesine neden olabilir.
4. İlk bayta geçiş süresini azaltma
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 listelenmiştir. Ancak aynı zamanda en önemli adımlardan biridir çünkü kendisinden sonra gelen her adımı doğrudan etkiler. 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 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 bir başka neden de önbelleğe alınan içeriğin CDN uç sunucusundan kullanılamaması ve tüm isteklerin tamamen tekrar kaynak sunucuya yönlendirilmesini gerektirmesidir. Bu durum, ziyaretçiler analiz için benzersiz URL parametreleri kullandığında, farklı sayfalarla sonuçlanmasalar bile gerçekleşebilir.
TTFB'yi azaltma konusunda özel yardım için TTFB'yi optimize etme konusuna bakın.
JavaScript'te LCP dökümünü izleme
Tüm LCP alt kategorileri için zamanlama bilgilerine, aşağıdaki performans API'lerinin bir kombinasyonu aracılığıyla JavaScript'te ulaşılabilir:
Bu zamanlama değerlerini JavaScript'te hesaplamak, hata ayıklama ve optimizasyon konusunda yardımcı olması için bunları bir analiz sağlayıcısına göndermenize veya geliştirici araçlarınıza kaydetmenize olanak tanı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ının yanında yararlıdır. Böylece, bu zaman aralıklarında sayfada başka neler olduğunu görebilirsiniz.
Sayfalarınızın önerilen yüzde dökümlerini karşılayıp karşılamadığını belirlemek amacıyla her bir alt kategorinin toplam LCP süresinin yüzde kaçını kapladığını hesaplamak için de JavaScript kullanabilirsiniz.
Bu ekran görüntüsünde, her LCP alt kategorisinin konsola toplam süresinin ve 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 time',
'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ızın LCP dökümünü daha iyi anlayabilmek amacıyla bu verileri bir analiz sağlayıcısına gönderecek şekilde değiştirebilirsiniz.
Web Verileri uzantısını kullanarak LCP dökümünü izleme
Web Verileri uzantısı, bu dökümü göstermek için konsol günlük kaydındaki LCP süresini, LCP öğesini ve dört alt kategoriyi günlüğe kaydeder.
