LCP ve CLS, kullanıcıların sayfayı hızlı ve stabil hissedip hissetmediğini gösteren iki kritik Core Web Vitals metriğidir. Biri ana içeriğin ne kadar hızlı göründüğünü, diğeri ise sayfanın yüklenirken ne kadar kaydığını ölçer.
Bir site hızlı açılıyor gibi görünebilir ama kullanıcı ana içeriği geç görüyorsa ya da tam bir butona basacakken sayfa kayıyorsa, deneyim yine zayıf olur. LCP ve CLS tam olarak bu iki sorunu görünür hale getirir. LCP, sayfadaki en büyük ana içeriğin ne kadar sürede göründüğünü; CLS ise yükleme sırasında oluşan beklenmedik kaymaları ölçer. Google ve web.dev rehberlerine göre iyi bir kullanıcı deneyimi için LCP’nin 2,5 saniye veya altında, CLS’nin ise 0,1 veya altında olması hedeflenmelidir.
Bu iki metriği birlikte düşünmek gerekir. Çünkü LCP daha çok “sayfa ne kadar geç hissediliyor?” sorusuna, CLS ise “sayfa ne kadar dengesiz hissediliyor?” sorusuna cevap verir. Örneğin ana görsel geç geliyorsa LCP bozulur; görselin yeri baştan ayrılmadıysa ve içerik aşağı itiliyorsa bu kez CLS de bozulur. Yani bazen tek bir problem iki metriği birden etkileyebilir.
LCP nedir?
LCP yani Largest Contentful Paint, kullanıcının ekranda gördüğü en büyük içerik öğesinin ne zaman görünür hale geldiğini ölçer. Bu öğe çoğu zaman bir hero görseli, büyük bir başlık bloğu ya da büyük bir afiş alanı olabilir. LCP’nin amacı, kullanıcının “sayfanın asıl içeriği geldi” hissini ne kadar sürede yaşadığını anlamaktır.
Örneğin bir hizmet sayfası düşünelim. İlk ekranda büyük bir başlık, altında kısa bir açıklama ve sağ tarafta büyük bir görsel var. Eğer o büyük görsel veya metin bloğu geç geliyorsa kullanıcı sayfa açılmış olsa bile içeriğin tamamlandığını hissetmez. İşte burada LCP değeri yükselir.
CLS nedir?
CLS yani Cumulative Layout Shift, sayfa yüklenirken ya da kullanılırken görünen alanın beklenmedik biçimde ne kadar yer değiştirdiğini ölçer. Bu metrik zaman bazlı değildir; görsel istikrarsızlığı ölçer. web.dev’e göre ani kaymaların en yaygın nedenleri boyutu belirtilmemiş görseller, alanı ayrılmamış reklam ve embed alanları, dinamik eklenen içerikler ve web fontlarıdır.
Mesela bir e-ticaret ürün sayfasında kullanıcı “Sepete Ekle” butonuna yaklaşırken, üst tarafta geç yüklenen kampanya bandı yüzünden tüm sayfa aşağı kayarsa, bu CLS problemidir. Aynı şey haber sitelerinde sonradan açılan reklam bloklarında ya da boyutsuz iframe alanlarında da çok görülür.
Önce doğru ölçüm yapın
LCP ve CLS iyileştirmeye başlamadan önce, sorunun laboratuvar verisinde mi yoksa gerçek kullanıcı tarafında mı olduğunu ayırmak gerekir. Search Console ve CrUX verileri saha verisini gösterir; Lighthouse, PageSpeed Insights ve Chrome DevTools ise laboratuvar teşhisi için kullanılır. Google ve web.dev, Core Web Vitals değerlendirmesinde 75. persentilin esas alındığını ve saha verisiyle laboratuvar verisinin birlikte yorumlanması gerektiğini vurgular.
Pratikte en iyi sıra şudur: önce Search Console veya PageSpeed Insights ile problemli sayfa grubunu bulun. Sonra Chrome DevTools ve Lighthouse ile asıl nedeni teşhis edin. Mesela CLS sadece gerçek kullanıcıda kötüyse, muhtemelen dinamik reklam alanı, cookie bildirimi veya etkileşim sonrası açılan bir bileşen problemi vardır. Eğer hem laboratuvar hem saha verisinde kötüyse, yükleme sırasında oluşan temel layout problemi daha olasıdır.
LCP nasıl iyileştirilir?
LCP iyileştirmede ilk hedef, ana içeriğin daha erken gelmesini sağlamaktır. web.dev’in LCP rehberi bunu birkaç ana başlığa ayırır: sunucu yanıt süresini düşürmek, render-blocking kaynakları azaltmak, kritik kaynağı erken yüklemek ve LCP öğesinin geç keşfedilmesini önlemek.
1. LCP öğesini bulun
Önce sayfadaki LCP öğesinin ne olduğunu bilmelisiniz. Bazen bu bir hero görselidir, bazen büyük bir H1 metin bloğudur, bazen de üstteki büyük slider alanıdır. LCP öğesini bilmeden yapılan optimizasyon çoğu zaman tahmine dayanır. PageSpeed Insights ve DevTools bu öğeyi gösterebilir.
Örneğin ana sayfanızda kocaman bir banner görseli varsa ve LCP öğesi bu görselse, çözüm “tüm JS’yi küçültmek” olmayabilir. Asıl çözüm, o görseli daha hızlı getirmek, doğru boyutta servis etmek ve gerekirse önceliklendirmektir.
2. Hero görseli geciktirmeyin
LCP çoğu zaman görseldir. Bu nedenle ilk ekrandaki büyük görsel lazy-load yapılmamalıdır. web.dev, LCP görselini geç yüklemek yerine mümkün olduğunda hızlı keşfedilir hale getirmeyi ve gerekirse fetchpriority="high" gibi yaklaşımlarla öncelik vermeyi önerir.
Mesela bir kurumsal site düşünelim. İlk ekranda 250 KB’lık bir hero görseli var. Bu görsel loading="lazy" ile sunuluyorsa kullanıcı sayfayı açsa bile görselin gelmesi gecikir. Bunun yerine ilk ekrandaki görseli normal yükleyip, sayfa aşağısındaki görselleri lazy-load yapmak çok daha doğru olur.
3. Görsel boyutunu ve formatını optimize edin
Büyük ve yanlış boyutlandırılmış görseller LCP’yi doğrudan kötüleştirir. web.dev, görsellerin sayfaların en ağır kaynakları arasında olduğunu ve uygun sıkıştırma ile modern format kullanımının yükleme süresini düşürdüğünü vurgular.
Örneğin mobilde 390 piksel alanda gösterilen bir hero görselini 2400 piksel genişlikte yüklerseniz, kullanıcıya gereksiz veri taşımış olursunuz. Aynı görseli uygun boyutta, modern formatta ve responsive yapı ile sunmak LCP’de ciddi iyileşme sağlayabilir. Bu, özellikle WordPress sitelerde çok yaygın bir kazanım alanıdır.
4. Render-blocking CSS ve JS yükünü azaltın
Kullanıcı ana içeriği görmeden önce tarayıcı çok fazla CSS ve JavaScript bekliyorsa LCP gecikir. web.dev’in LCP rehberi ve Core Web Vitals iyileştirme rehberi, ilk ekrana katkı sağlamayan ağır kaynakların yükleme önceliğinin düşürülmesini önerir.
Örneğin sayfanın üst kısmında sadece basit bir metin ve görsel gösteriyorsunuz ama tema tüm slider, galeri, popup ve form scriptlerini ilk anda yüklüyor. Bu durumda kullanıcı açısından önemsiz dosyalar, önemli içeriğin önüne geçmiş olur. İlk ekranda gerçekten gereken stilleri ve scriptleri öne almak LCP’yi hızla iyileştirebilir.
5. Sunucu ve cache tarafını gözden geçirin
LCP sadece ön yüzden etkilenmez. Sayfanın ilk HTML’i geç geliyorsa, LCP öğesi de geç keşfedilir. Bu yüzden TTFB yüksekse sunucu yanıt süresi, cache katmanı ve CDN kullanımı da incelenmelidir. web.dev’in LCP rehberi, sunucu yanıt süresinin ilk aşamada önemli bileşenlerden biri olduğunu açıkça anlatır.
Mesela aynı sayfa bir cache katmanı olmadan her kullanıcı için yeniden oluşturuluyorsa, içerik geç gelmeye başlar. Buna karşılık tam sayfa cache veya etkili bir CDN ile ilk HTML ve statik dosyalar daha hızlı ulaşır. Sonuçta kullanıcı ana içeriği daha erken görür.
CLS nasıl iyileştirilir?
CLS iyileştirmede temel mantık şudur: sonradan gelecek her öğe için yerini önceden ayırın. web.dev’e göre CLS’yi düzeltmenin ana yolu, yükleme sonrası içeriğin iteceği alanları baştan rezerve etmektir. En yaygın problemler de boyutu tanımlanmamış görseller, reklamlar, embed alanları ve font değişimleridir.
1. Görsellere mutlaka boyut verin
CLS düzeltmenin en temel adımı budur. web.dev, görseller için width ve height öznitelikleri veya eşdeğer CSS boyutlarının verilmesini açıkça önerir. Çünkü tarayıcı alanı baştan hesaplayamazsa görsel geldiğinde sayfayı aşağı iter.
Örneğin blog yazınızda öne çıkan görsel var ama HTML’de boyutu belirtilmemiş. Sayfa önce metni gösteriyor, sonra görsel gelince metin aşağı kayıyor. Kullanıcı tam bir başlığa tıklayacakken içerik yer değiştiriyor. Bu klasik bir CLS sorunudur. Basitçe görsel ölçülerini belirtmek bile çoğu zaman büyük fark yaratır.
2. Reklam, embed ve iframe alanları için yer ayırın
Reklam blokları, YouTube embed’leri, haritalar ve üçüncü taraf widget’lar CLS’nin en sık nedenlerindendir. Çünkü bu alanlar çoğu zaman sayfa yüklendikten sonra boyut kazanır. web.dev, bu tip içeriklerin yüklenmeden önce yerinin ayrılmasını özellikle önerir. aspect-ratio özelliği de bu tür alanlarda kullanışlıdır.
Mesela ürün sayfasında yorumlardan önce bir Instagram embed alanı düşünün. Eğer bu alanın yüksekliği baştan tanımlanmamışsa, içerik önce yukarıda görünür, embed sonradan gelince her şeyi aşağı iter. Bu da kullanıcıyı rahatsız eder. Çözüm, iframe veya embed kapsayıcısının alanını baştan ayırmaktır.
3. Sonradan gelen içerikleri üst tarafa enjekte etmeyin
Sayfa açıldıktan sonra üst alana yeni içerik eklemek CLS’yi hızla bozar. Özellikle cookie banner’ları, kampanya duyuruları, stok uyarıları ve “uygulamayı indir” bar’ları burada sorun çıkarır. web.dev, dinamik eklenen içeriklerin yer değiştirme yaratmaması için dikkatli tasarlanması gerektiğini vurgular.
Örneğin kullanıcı ürün sayfasını inceliyor, birkaç saniye sonra üstte kampanya barı açılıyor ve tüm içerik aşağı kayıyor. Bu tür eklemeler kullanıcıya “siteyi kontrol edemiyorum” hissi verir. Daha doğru yaklaşım, bu tip bileşenler için önceden alan ayırmak veya kullanıcı etkileşimiyle açılan sabit katmanlar kullanmaktır.
4. Font yükleme stratejisini düzeltin
Web fontları da CLS’ye katkı sağlayabilir. Çünkü geç gelen font, metnin ölçüsünü ve satır kırılımını değiştirebilir. web.dev, font yükleme ve yedek font eşleştirmesinin layout shift’i azaltmada önemli olduğunu belirtir.
Mesela başlıklarınız özel bir fontla geliyor ama ilk anda sistem fontu kullanılıyor, sonra asıl font gelince satır yapısı değişiyor. Bu, özellikle dar mobil ekranlarda başlıkların ve butonların yerini kaydırabilir. Font ağırlıklarını azaltmak, doğru font-display yaklaşımı ve benzer fallback font seçimi burada yardımcı olur.
LCP ve CLS birlikte nasıl ele alınmalı?
Bu iki metriği ayrı ayrı optimize etmek gerekir ama bazı kararlar ikisini aynı anda etkiler. Örneğin ilk ekrandaki büyük görsel hem LCP öğesi olabilir hem de boyutu verilmediyse CLS sorunu yaratabilir. Bu durumda aynı anda hem hızlı yüklenmesi hem de alanının baştan ayrılması gerekir.
Pratik bir örnek verelim. Bir ana sayfada büyük bir slider var. Görseller ağır, lazy-load yanlış kurgulanmış, ayrıca yüklenmeden önce yükseklik tanımlanmamış. Sonuçta kullanıcı hem görselleri geç görüyor hem de sayfa yüklenirken içerik oynuyor. Bu durumda slider’ı sadeleştirmek, ilk görseli önceliklendirmek ve slider alanının yüksekliğini sabitlemek aynı anda hem LCP hem CLS’yi iyileştirir.
En sık yapılan hatalar
En sık görülen hata, sadece Lighthouse puanına odaklanmaktır. Oysa saha verisi ve kullanıcı deneyimi daha önemlidir. Başka bir yaygın hata, ilk ekrandaki LCP görseline lazy-load uygulamak ya da görsellerin boyutunu belirtmeden bırakmaktır. CLS tarafında ise sonradan yüklenen banner’lar, alanı ayrılmamış reklam blokları ve font değişimleri en yaygın sorunlardır.
Örneğin biri “sayfam hızlı çünkü puanım 90” diyebilir. Ama gerçek kullanıcı verisinde özellikle mobilde LCP 4 saniyeyse, bu puan tek başına güvenli değildir. Ya da “tasarım çok hareketli” diye her şeyi sonradan yüklemek estetik görünebilir ama kullanıcı deneyimini bozabilir. Google da tek başına mükemmel skorun üst sıralama garantisi vermediğini, asıl amacın kullanıcı için iyi deneyim sunmak olduğunu açıkça söylüyor.
Nereden başlamalısınız?
Önce en çok trafik alan ve en önemli dönüşüm sayfalarını seçin. Sonra PageSpeed Insights ve Search Console ile bu sayfalarda LCP mi, CLS mi daha baskın problem görün onu belirleyin. Ardından ilk ekrandaki büyük öğeyi bulun, görsellerin boyutlandırmasını kontrol edin, sonradan gelen içerikleri inceleyin ve DevTools ile layout shift kaynaklarını tek tek görün. Google da Search Console Core Web Vitals raporunu ve Chrome araçlarını başlangıç noktası olarak önerir.
Küçük bir başlangıç planı şöyle olabilir: önce LCP öğesini tespit edin, ilk ekrandaki büyük görseli optimize edin, kritik olmayan JS’yi erteleyin, görsel ve embed alanlarına sabit ölçü verin, sonradan gelen duyuru bloklarını yeniden tasarlayın. Çoğu sitede en hızlı kazanım bu beş adımdan gelir.
LCP ve CLS
LCP ve CLS iyileştirmek, sadece teknik raporu güzelleştirmek için yapılmaz. Amaç, kullanıcıya sayfanın hızlı ve güvenilir hissettirmesidir. LCP size ana içeriğin ne kadar geç geldiğini, CLS ise sayfanın ne kadar oynadığını söyler. Bu iki metriği düzenli takip edip gerçek kullanıcı deneyimine göre iyileştirdiğinizde, hem SEO hem dönüşüm tarafında daha güçlü bir zemin kurarsınız. Google da iyi Core Web Vitals değerlerine ulaşmayı Search başarısı ve genel kullanıcı deneyimi için güçlü biçimde öneriyor.
