Core Web Vitals Rehberi: LCP, CLS ve INP Optimizasyonu

Google yıllardır "hızlı site" diyordu ama bunu ölçülebilir bir tanıma bağlamamıştı. Core Web Vitals bu boşluğu doldurdu: artık ortada üç metrik, üç eşik değer ve herkesin görebildiği bir karne var. Sorun şu ki bu karneyi doğru okumak sanıldığı kadar kolay değil — çoğu site sahibi yanlış aracın verisine bakarak yanlış sorunu çözmeye çalışıyor.

Core Web Vitals nedir?

Core Web Vitals, Google'ın sayfa deneyimini ölçmek için kullandığı üç metrikten oluşan settir: LCP (en büyük içeriğin yüklenme süresi), CLS (görsel kayma miktarı) ve INP (etkileşime yanıt süresi).

Üçü birlikte üç ayrı soruyu cevaplar: İçerik ne zaman göründü? Görünürken zıpladı mı? Dokunduğumda tepki verdi mi? Bu üç soru, bir kullanıcının "bu site iyi çalışıyor" hissini büyük ölçüde belirler.

Önemli bir ayrıntı: Google bu değerleri ortalama üzerinden değil, ziyaretlerin %75'lik diliminden hesaplar. Yani kullanıcılarınızın dörtte üçü eşiği geçmelidir. Ortalamanın iyi görünmesi yetmez; yavaş cihazlardaki uzun kuyruk sizi geçersiz kılabilir.

LCP: İçerik Ne Zaman Göründü?

LCP, görünür alandaki en büyük öğenin ekrana çizildiği andır. Bu öğe genelde hero görseli, büyük bir başlık bloğu veya video posteridir. Kullanıcı için anlamı basittir: "sayfa yüklendi" hissinin oluştuğu an.

LCP'yi tek bir sayı olarak görmek yerine dört parçaya ayırmak, sorunu bulmayı kolaylaştırır:

• Sunucu yanıt süresi (TTFB). İlk baytın gelmesi. Yavaşsa hosting, veritabanı sorguları veya önbelleksiz sunum suçludur. Diğer üç parçayı ne kadar optimize ederseniz edin, buradaki gecikme tabana eklenir.
• Kaynak keşif gecikmesi. Tarayıcının LCP öğesini fark etmesi ne kadar sürdü? Görsel CSS içinde background-image olarak tanımlıysa ya da JavaScript ile sonradan ekleniyorsa tarayıcı onu geç görür.
• Kaynak indirme süresi. Görselin boyutu ve formatı. 2 MB'lık bir JPEG ile 180 KB'lık bir WebP arasındaki fark doğrudan buraya yansır.
• Render gecikmesi. Dosya indi ama çizilmedi — genelde render engelleyen CSS veya senkron JavaScript yüzünden.

Pratik müdahaleler: LCP görseline fetchpriority="high" verin, o görsele asla loading="lazy" koymayın (çok yaygın bir hata), modern format kullanın, kritik CSS'i satır içine alın ve kalanını ertelenmiş yükleyin.

CLS: Sayfa Okurken Zıplıyor mu?

CLS, kullanıcının beklemediği anda içeriğin yer değiştirmesini ölçer. Herkesin yaşadığı senaryodur: yazıyı okumaya başlarsınız, üstte bir reklam yüklenir, metin aşağı kayar, satırı kaybedersiniz. Ya da "İptal" butonuna basmak üzereyken düğmeler kayar ve "Onayla"ya basarsınız.

Hesaplama iki çarpanın çarpımıdır: etkilenen ekran alanının oranı × kayma mesafesinin oranı. Küçük bir öğenin çok kayması ile büyük bir bloğun az kayması benzer sonuç üretebilir.

En sık dört sebep ve çözümleri:

• Boyutsuz görseller. <img> etiketine width ve height öznitelikleri verin. Modern tarayıcılar bu iki sayıdan en-boy oranını hesaplayıp yer ayırır. Tek başına bu düzeltme çoğu sitede CLS sorununun büyük kısmını çözer.
• Yazı tipi değişimi. Özel font yüklenene kadar yedek font gösterilir, sonra metin yeniden akar. font-display: swap ve font dosyasının erken yüklenmesi etkiyi azaltır.
• Sonradan enjekte edilen içerik. Reklam, çerez bildirimi, duyuru çubuğu. Bunlar için sabit yükseklikli bir alan ayırın; içerik gelmezse boş kalsın ama düzen kaymasın.
• Animasyonlarda yanlış özellik. top, left, height gibi özellikleri animasyona sokmak düzeni yeniden hesaplatır. Bunun yerine transform kullanın — CLS'ye sayılmaz ve daha akıcıdır.

INP: Dokunduğumda Tepki Verdi mi?

INP, 2024 Mart'ında FID metriğinin yerini aldı ve ölçümü ciddi biçimde sertleştirdi. FID yalnızca ilk etkileşimin başlama gecikmesine bakıyordu; INP ise sayfadaki tüm etkileşimleri ölçer ve girdi ile görsel geri bildirim arasındaki tam süreyi dikkate alır.

Ölçülen üç aşama: girdi gecikmesi (tarayıcı meşgul olduğu için olayın işlenememesi), işlem süresi (olay işleyicinizin çalışması) ve sunum gecikmesi (sonucun ekrana çizilmesi).

INP sorunlarının kaynağı neredeyse her zaman aynıdır: ana iş parçacığını uzun süre meşgul eden JavaScript. 50 milisaniyeyi aşan her görev "uzun görev" sayılır ve bu süre boyunca tarayıcı kullanıcıya cevap veremez.

Somut bir örnek: bir arka plan animasyonu 140 parçacığı her karede birbiriyle karşılaştırıyorsa, kare başına yaklaşık on bin hesap yapılır. Saniyede 60 kare ile bu yüz binlerce işlem eder ve ana iş parçacığı sürekli doludur. Aynı animasyon uzamsal ızgara ile yeniden yazıldığında hesap sayısı otuz kata kadar düşebilir ve INP normale döner. Ders şudur: INP'yi bozan şey genelde tek bir "ağır özellik" değil, sürekli çalışan küçük bir döngüdür.

Pratik yaklaşımlar: kullanılmayan JavaScript'i kaldırın, uzun görevleri parçalara bölün, üçüncü taraf betiklerini ertelenmiş yükleyin ve mobilde gerekmeyen dekoratif işleri tamamen kapatın. Mobil cihazlar masaüstünden çok daha yavaştır ve INP puanınızın kaderini onlar belirler.

Alan Verisi ile Laboratuvar Verisi: En Sık Yapılan Karışıklık

Bu ayrım anlaşılmadan Core Web Vitals doğru yönetilemez.

İki pratik sonuç. Birincisi: karar verirken alan verisine bakın. Lighthouse'un 100 üzerinden verdiği puan bir teşhis aracıdır, karne değildir. İkincisi: düzeltme yaptıktan sonra sabırlı olun. Alan verisi 28 günlük kayan pencere kullandığı için iyileşme Search Console'a yansıyana kadar haftalar geçer. Bir hafta sonra bakıp "işe yaramadı" demek erken karardır.

Ayrıca yeni veya düşük trafikli sitelerde alan verisi hiç görünmeyebilir; CrUX yeterli örneklem toplayamaz. Bu durumda laboratuvar verisi tek rehberinizdir, ama sınırlarını bilerek kullanın.

Search Console'daki Core Web Vitals Raporu

Rapor sayfaları URL bazında değil, benzer sayfaları gruplayarak gösterir. Bu yüzden "12.000 URL zayıf" gibi bir uyarı gördüğünüzde panik yapmayın — genelde tek bir şablon hatası binlerce sayfayı aynı anda etkiliyordur. Ürün sayfası şablonundaki boyutsuz bir görsel, tüm katalogda CLS problemi olarak görünür.

Doğru okuma sırası: önce gruplara bakın, her grubun örnek URL'sini açın, sorunu şablon düzeyinde çözün, sonra "Düzeltmeyi doğrula" düğmesine basın. Google yeniden değerlendirmeyi başlatır ve alan verisi biriktikçe grup yeşile döner. Bu sürecin bütününü Search Console rehberimizde anlattık.

Sıralama Faktörü mü? Dürüst Cevap

Evet, ama abartılmamalı. Core Web Vitals bir sıralama sinyalidir; ancak içerik kalitesinin ve alaka düzeyinin önüne geçmez. Zayıf CWV puanına sahip ama soruyu en iyi cevaplayan sayfa, hızlı ama yüzeysel bir sayfanın önünde kalmaya devam eder.

Asıl etkisi iki yerde ortaya çıkar. Birincisi eşit rekabette: benzer kalitede iki sayfa arasında hız ayırt edici olur. İkincisi kullanıcı davranışında: yavaş sayfa terk oranını yükseltir, dönüşümü düşürür ve bu davranışlar zamanla dolaylı olarak sıralamaya yansır. Yani asıl kazanç sıralamadan çok gelirdedir.

Öncelik Sırası: Neyi Önce Düzeltmeli?

• Önce en çok trafik alan şablonu. Tek bir ürün sayfası değil, ürün sayfası şablonu.
• Önce mobili. Puanınızı mobil cihazlar belirler; masaüstünde iyi görünen sayfa mobilde zayıf olabilir.
• Önce ucuz kazanımları. Görsellere boyut vermek, format değiştirmek ve font-display eklemek saatler alır; JavaScript mimarisini yeniden kurmak haftalar.
• Önce "zayıf" grubu. Zayıftan geliştirilmeliye çıkmak, geliştirilmeliden iyiye çıkmaktan daha çok kullanıcı etkiler.

Uygulama tarafındaki yöntemlerin tamamı için site hızı optimizasyonu rehberimize, denetimin bütünü için teknik SEO kontrol listemize bakabilirsiniz.

Sık Yapılan Dört Hata

Lighthouse puanını hedef sanmak. 100 puan almak amaç değildir. Alan verisinde üç metriğin de eşiği geçmesi amaçtır.

LCP görseline lazy loading eklemek. "Tüm görsellere lazy ekleyelim" yaklaşımı LCP'yi doğrudan bozar. Ekranın üstündeki görsellere asla eklenmez.

Tek sayfayı test edip genellemek. Ana sayfa hızlı olabilir ama trafiğin çoğu blog veya ürün sayfalarına geliyordur. Şablon bazında test edin.

Üçüncü taraf betikleri hesaba katmamak. Sohbet widget'ı, ısı haritası aracı, reklam ağı ve sosyal medya gömüleri INP'nin en sık görülen sebebidir. Her birinin bedelini ölçün; bazıları taşıdığı değerin çok üstünde maliyet çıkarır.

Sonuç

Core Web Vitals'ı yönetmenin özeti şudur: alan verisine bakın, şablon düzeyinde düşünün, mobili önceliklendirin ve ucuz kazanımlarla başlayın. Üç metriğin her biri farklı bir sorun ailesine işaret eder — LCP genelde kaynak ve sunucu, CLS düzen ve boyut, INP ise JavaScript sorunudur.

Sitenizin Core Web Vitals karnesini çıkarmak ve öncelik sıralı bir düzeltme planı almak isterseniz SEO danışmanlığımızdan ücretsiz teknik ön analiz talep edebilirsiniz.

Sık Sorulan Sorular