Core Web Vitals Nedir? LCP, INP ve CLS Nasıl İyileştirilir?

Core Web Vitals nedir sorusunun yanıtı: Google’ın bir sayfadaki gerçek kullanıcı deneyimini ölçmek için seçtiği üç metrikten oluşan settir. LCP ana içeriğin ne kadar çabuk göründüğünü, INP sayfanın tıklama ve dokunmalara ne kadar hızlı tepki verdiğini, CLS ise içeriğin yüklenirken ne kadar kaydığını ölçer. Üçü birlikte “sayfa hızlı mı, kullanışlı mı, kararlı mı?” sorularına sayısal yanıt verir.

Bu metriklerden ikisi büyük ölçüde ön yüz kodunda çözülür; LCP’nin ilk halkası ise sunucudur. Yavaş yanıt veren bir altyapıda görselleri ne kadar sıkıştırırsanız sıkıştırın LCP iyi bölgeye zor girer; bu yüzden LIONFIN web hosting paketlerini seçerken de ölçüme TTFB ile başlamanızı öneririz. Genel hız yöntemlerinin tam listesi web sitesi hızlandırma rehberinde; aşağıda metriklerin kendisine, nasıl ölçüldüklerine ve her birinin hangi düzeltmeye yanıt verdiğine odaklanıyoruz.

Core Web Vitals nedir, hangi metriklerden oluşur?

Core Web Vitals üç metrikten oluşur ve Google her biri için üç bant tanımlar: iyi, iyileştirme gerekli ve zayıf.

Değerlendirme her metriğin 75. yüzdelik dilimine göre yapılır: ziyaretlerin en az %75’i eşiğin altında kalıyorsa sayfa o metrikte “iyi”dir. Mobil ve masaüstü ayrı değerlendirilir; masaüstünde yeşil görünen bir sayfa mobilde kırmızı olabilir.

Eski metrik FID (First Input Delay) yalnızca ilk etkileşimin başlama gecikmesini ölçüyordu; 12 Mart 2024’te yerini sayfadaki tüm etkileşimleri hesaba katan INP aldı. TTFB (Time to First Byte, ilk bayta kadar geçen süre) ve FCP (First Contentful Paint) Core Web Vitals’a dahil değildir, ama LCP’yi doğrudan beslediği için teşhiste kullanılır.

Saha verisi ile laboratuvar verisi arasındaki fark nedir?

Saha verisi gerçek ziyaretçilerin tarayıcılarından toplanır ve Google’ın değerlendirmesi buna dayanır; laboratuvar verisi ise tek bir test cihazında yapılan simüle ölçümdür ve sorunu bulmak için kullanılır. İkisinin farklı sonuç vermesi normaldir.

• CrUX (Chrome User Experience Report): Chrome kullanıcılarından toplanan, son 28 günü kapsayan kayan bir veri setidir. Trafiği az olan sayfalar için yeterli veri oluşmayabilir; bu durumda araçlar “veri yok” der.
• PageSpeed Insights: Üst bölümde CrUX’ten gelen saha verisini, alt bölümde Lighthouse ile üretilen laboratuvar sonucunu ve öneri listesini gösterir. Performans puanı laboratuvar ölçümüdür; Core Web Vitals değerlendirmesinin geçip geçmediğini üstteki bölüm söyler.
• Search Console → Core Web Vitals raporu: Saha verisini sitenin tamamı için toplar, benzer sorunlu URL’leri gruplar ve mobil ile masaüstünü ayrı gösterir. Düzeltmeden sonra Düzeltmeyi doğrula ile 28 günlük izleme başlatılır.
• Chrome DevTools: Performance paneli LCP, INP ve CLS değerlerini sayfayı kullanırken canlı gösterir; hangi etkileşimin yavaş olduğunu bulmanın en hızlı yoludur.

Laboratuvar testi kullanıcı etkileşimi içermediği için INP’yi ölçemez; Lighthouse bunun yerine ana iş parçacığının ne kadar bloke kaldığını gösteren TBT (Total Blocking Time) değerini verir. Kendi sitenizden saha verisi toplamak isterseniz Google’ın açık kaynak web-vitals JavaScript kütüphanesini analitik aracınıza bağlayabilirsiniz.

Hosting Core Web Vitals’ı nasıl etkiler?

Hosting en çok LCP’yi etkiler, çünkü LCP süresinin ilk parçası sunucunun ilk baytı göndermesine kadar geçen süredir (TTFB). LCP dört alt parçaya ayrılır: TTFB, LCP kaynağının istenmeye başlamasına kadar geçen gecikme, kaynağın inme süresi ve öğenin ekrana çizilme gecikmesi. Sunucu tek başına 1,5 saniye harcıyorsa 2,5 saniyelik bütçenin büyük kısmı daha HTML gelmeden tükenmiştir.

Google’ın web.dev rehberleri TTFB için 0,8 saniyenin altını iyi bir hedef olarak gösterir. Sunucu yanıtını komut satırından şöyle ölçebilirsiniz:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer} sn\n" https://ornek.com/

Yüksek TTFB’nin tipik nedenleri sayfa önbelleğinin olmaması, yavaş PHP ya da veritabanı sorguları, aşırı yüklenmiş paylaşımlı sunucu, ziyaretçiye uzak bir sunucu konumu ve HTTP/2 desteğinin eksik olmasıdır. Statik dosyaları ziyaretçiye yakın noktalardan sunmak için CDN kullanmak, uzak konumun etkisini azaltır.

INP ve CLS ise neredeyse tamamen tarayıcıda oluşur: sunucunuz ne kadar güçlü olursa olsun ağır bir JavaScript paketi INP’yi, boyutu belirtilmemiş bir reklam alanı CLS’yi bozar. Trafiği yüksek ve dinamik bir sitede paylaşımlı kaynak yetmiyorsa VPS sunucu ile önbellek katmanını kendiniz kurmak bir sonraki adımdır.

LCP nasıl iyileştirilir?

LCP’yi iyileştirmenin yolu, önce LCP öğesini bulmak, sonra o öğeye giden yoldaki her gecikmeyi tek tek kısaltmaktır:

1. Öğeyi belirleyin: PageSpeed Insights’ta Largest Contentful Paint öğesi tanılaması hangi görselin ya da başlığın ölçüldüğünü gösterir; çoğu zaman kapak görseli ya da slayttır.
2. TTFB’yi düşürün: Tam sayfa önbelleği, PHP OPcache ve yavaş sorguların düzeltilmesi ilk baytı öne çeker.
3. Kapak görselini tembel yüklemeyin: loading="lazy" yalnızca ekranın altındaki görsellere verilir; LCP görseline fetchpriority="high" ekleyin.
4. Görseli küçültün: WebP ya da AVIF biçimi ve srcset ile cihaza uygun boyut, inme süresini kısaltır.
5. Engelleyici kaynakları azaltın: Kritik CSS’i satır içine alın, gerekmeyen JavaScript’i defer ile erteleyin.
6. Metin LCP ise fontu öne alın: Kullanılan web fontunu preload ile erken isteyin.

<img src="/img/kapak.webp" width="1200" height="600"
     fetchpriority="high" alt="Kampanya kapak görseli">

LCP görseli CSS arka planı olarak tanımlanmışsa tarayıcı onu stil dosyasını işledikten sonra keşfeder; mümkünse <img> etiketine taşıyın.

INP nasıl iyileştirilir?

INP, ana iş parçacığını uzun süre meşgul eden JavaScript görevleri kısaltılarak iyileştirilir; kullanıcı tıkladığında tarayıcı o an çalışan görev bitmeden ekranı güncelleyemez. 50 milisaniyeyi aşan her görev “uzun görev” sayılır ve etkileşimi bekletme potansiyeli taşır.

• Üçüncü taraf betikleri gözden geçirin: Canlı destek pencereleri, etiket yöneticileri, reklam ve ısı haritası betikleri en sık suçludur. Kullanılmayanları kaldırın, gerekenleri sayfa etkileşime hazır olduktan sonra yükleyin.
• Uzun görevleri bölün: Büyük bir işi parçalara ayırıp aralarda tarayıcıya söz hakkı verin (setTimeout ya da destekleyen tarayıcılarda scheduler.yield()).
• Önce geri bildirim, sonra iş: Tıklamadan hemen sonra düğmeyi “yükleniyor” durumuna geçirin, ağır hesaplamayı bir sonraki kareye bırakın.
• DOM’u küçük tutun: Binlerce düğümlü sayfalarda her güncelleme stil ve düzen hesabını pahalılaştırır.
• Giriş olaylarını seyreltin: Arama kutusu gibi her tuşta çalışan işleyicilerde debounce kullanın.

Yavaş etkileşimi bulmak için DevTools Performance panelinde kayıt alıp sorunlu düğmeye tıklayın; uzun görevler kırmızı üçgenle işaretlenir. WordPress sitelerinde bunun çoğu eklenti kaynaklıdır; eklenti bazlı teşhis WordPress hızlandırma yazısında anlatılır.

CLS nasıl düşürülür?

CLS, her öğenin yerini sayfa yüklenmeden önce ayırarak düşürülür; kaymaların neredeyse tamamı boyutu sonradan belli olan içerikten doğar.

• Görsel, video ve iframe’lere boyut verin: width ve height nitelikleri ya da CSS aspect-ratio, tarayıcının yeri önceden ayırmasını sağlar.
• Reklam ve gömülü içerik için alan ayırın: Reklam gelmese bile kutunun en küçük yüksekliğini tanımlayın.
• Çerez ve kampanya bantlarını içeriği itmeyecek biçimde gösterin: Sayfanın üstüne eklenen bir bant tüm içeriği aşağı kaydırır; sabit konumlu (overlay) gösterim kaymaya yol açmaz.
• Font değişimini yumuşatın: Web fontu yüklenince satırlar yer değiştiriyorsa yedek fonta size-adjust verin ya da font-display: optional kullanın.
• Animasyonları transform ile yapın: top, left ya da height değiştiren animasyonlar düzeni yeniden hesaplatır.

.reklam-alani { min-height: 250px; }
img, video { max-width: 100%; height: auto; }

Kullanıcı etkileşiminden sonraki yarım saniye içinde olan kaymalar (ör. “daha fazla göster” düğmesi) puana eklenmez; sorun, kullanıcı hiçbir şey yapmazken oynayan içeriktir.

Core Web Vitals sıralamayı ne kadar etkiler?

Core Web Vitals, Google’ın sayfa deneyimi sinyallerinin bir parçasıdır ve sıralamada yer alır, ancak içeriğin aranan soruya uygunluğunun önüne geçmez. İçerik kalitesi birbirine yakın sayfalar arasında deneyim fark yaratabilir; zayıf içerikli bir sayfayı yalnızca hızlı olduğu için üst sıraya taşımaz.

Asıl kazanç çoğu zaman kullanıcı tarafındadır: geç görünen ürün görseli, tıklamaya geç tepki veren sepet düğmesi ya da yanlış bağlantıya tıklatan bir kayma doğrudan dönüşüm kaybıdır. Bu yüzden hedefi Lighthouse’ta 100 puan değil, saha verisinde üç metriğin de yeşil olması olarak koyun. HTTPS de sayfa deneyiminin parçasıdır; sertifika ile arama görünürlüğü arasındaki ilişki SSL ve SEO ilişkisi yazısında ele alınır.