Google, 2021'de Core Web Vitals'ı doğrudan sıralama sinyali olarak duyurduğunda çoğu SEO uzmanı konuya "önemli ama belirleyici değil" dedi. 2024'te INP'nin CWV'ye eklenmesiyle bu yaklaşım değişmek zorunda kaldı.
Geçtiğimiz 14 ayda 23 farklı projede Core Web Vitals iyileştirmesi yaptık. Gözlemlediğimiz örüntü net: üç metriği birden "İyi" aralığına çeken sitelerde organik tıklama oranı ortalama %18-34 artıyor. Bu makalede ne yaptığımızı, ne işe yaradığını ve ne işe yaramadığını yazıyoruz.
Core Web Vitals nedir? 2025 eşik değerleri
Google'ın belirlediği üç metrik ve "İyi" sayılmak için gereken eşik değerleri şunlar:
| Metrik | Ne ölçer? | İyi (<) | Geliştirilmeli | Zayıf (>) |
|---|---|---|---|---|
| LCP | Yüklenme hızı (en büyük içerik) | 2.5 sn | 4.0 sn | 4.0 sn |
| CLS | Görsel kararlılık (kayan layout) | 0.1 | 0.25 | 0.25 |
| INP | Etkileşim yanıt süresi | 200 ms | 500 ms | 500 ms |
INP (Interaction to Next Paint), Mart 2024'te FID'in (First Input Delay) yerini aldı. FID yalnızca ilk tıklamayı ölçerken INP, sayfa boyunca tüm etkileşimleri ölçer. Bu fark kritik: iyi FID skoru alan birçok site INP'de zayıf çıkıyor.
LCP: En büyük içerik ne kadar hızlı görünüyor?
LCP'nin "en büyük içerik" tanımı şaşırtabilir. Google, aşağıdakileri değerlendirir: <img> etiketleri, background-image ile yüklenen görseller, <video> poster görseli ve büyük metin blokları.
Pratikte gördüğümüz en yaygın LCP sorunu: hero görseli lazy load ile işaretlenmiş. Browser görsel yüklemeyi ertelediği için LCP skoru 5-8 saniyeye fırlıyor. Düzeltmesi tek satır:
<!-- YANLIŞ: hero görseline lazy load -->
<img src="hero.jpg" loading="lazy" alt="...">
<!-- DOĞRU: above-the-fold görsele eager + fetchpriority -->
<img src="hero.jpg" loading="eager" fetchpriority="high" alt="...">İkinci yaygın sorun: sunucu yanıt süresi (TTFB). LCP %40'ı sunucuda geçiyor. PHP sayfalar için OPcache aktif değilse, 200ms'lik bir sayfa 800ms'ye çıkabiliyor. Laragon'da geliştirme yaparken fark etmiyorsunuz çünkü her şey local — ama production ortamında belirgin.
LCP için pratik kontrol listesi
- Hero görseline
fetchpriority="high"ekleyin - Hero görselini WebP formatına dönüştürün (ortalama %30 küçülme)
<link rel="preload">ile hero görselini önceden yükletin- Sunucuda OPcache, Redis veya en azından statik cache aktif mi? Kontrol edin.
- CDN kullanıyorsanız edge cache'in çalıştığından emin olun
CLS: Layout kaymaları neden olur ve nasıl önlenir?
CLS, kullanıcı okurken sayfanın yerinden oynamasını ölçer. Reklam alanları, geç yüklenen görseller ve web fontları başlıca suçlular.
En sık gördüğümüz hata: görsellere width ve height attribute'u verilmemiş. Browser, görsel yüklenene kadar alan açmayı bilmiyor; görsel gelince her şey kayıyor.
<!-- CLS sorunu yaratır -->
<img src="foto.jpg" alt="...">
<!-- CLS'yi sıfırlar: boyutlar önceden tanımlı -->
<img src="foto.jpg" width="1200" height="630" alt="...">Google Fonts için CLS önlemi: font-display: swap yeterli değil, aslında CLS yaratabilir. Daha iyi yaklaşım: font-display: optional ile birlikte sistem fontunu fallback olarak aynı boyuta getiren size-adjust CSS özelliğini kullanın.
@font-face {
font-family: 'Syne';
src: url('/assets/fonts/syne-800.woff2') format('woff2');
font-display: optional; /* CLS'yi sıfırlar */
font-weight: 800;
}INP: FID'den farkı neden bu kadar önemli?
FID, kullanıcının ilk tıklamasından browser'ın olayı işlemeye başlamasına kadar geçen süreyi ölçüyordu. INP ise sayfadaki tüm tıklama, dokunma ve klavye etkileşimlerinin gecikme süresini ölçüyor.
İki site arasındaki fark dramatik olabiliyor: FID 50ms (mükemmel), INP 680ms (zayıf). Bu genellikle şu anlama geliyor: sayfa açılışta hızlı, ama kullanıcı menüye veya accordion'a tıkladığında donuyor.
INP'nin kötü olduğu en yaygın senaryolar:
- Büyük JavaScript paketleri: React/Vue uygulamalarında 300KB+ JS, ana thread'i bloklıyor
- Senkron third-party script'ler: Chat widget, analytics, reklam scriptleri
- Uzun görev zincirleri: Tıklamada 50ms+ süren DOM manipülasyonları
Vanilla JS avantajı
Web Partner'da geliştirdiğimiz sitelerin çoğu sıfır JS framework, sıfır jQuery. Bu tesadüf değil — kasıtlı bir karar. Vanilla JS ile yazdığımız interaction handler'lar ortalama 12-40ms arasında tutuluyor; framework kullanan eşdeğerleri 80-250ms.
Gerçek proje verisi: 2 örnek
Örnek 1 — Hukuk bürosu web sitesi
Teslim öncesi durum: LCP 6.2sn / CLS 0.38 / INP 890ms. Tüm metrikler "Zayıf".
Yaptıklarımız: Hero görseli WebP'ye dönüştürüldü + fetchpriority="high" eklendi. Tüm <img>'lere boyut attribute'ları verildi. jQuery kaldırıldı (8 plugin vardı, 6'sı kullanılmıyordu). Google Fonts selfhost edildi.
Sonuç (6 hafta): LCP 1.8sn / CLS 0.04 / INP 140ms. Organik tıklama oranı 12 haftada %27 arttı.
Örnek 2 — E-ticaret sitesi
Teslim öncesi durum: LCP 4.8sn (ana sorun: ürün liste görselleri lazy load) / CLS 0.22 (banner alanı boyutsuz) / INP 520ms (filtre tıklamaları sync).
Sonuç (8 hafta): LCP 2.1sn / CLS 0.06 / INP 180ms. Google Search Console'da ilk 3'te görünen kelime sayısı 14'ten 89'a çıktı.
Core Web Vitals'ı nasıl ölçersiniz?
Laboratuvar verisi (Lighthouse) yeterli değil — Google, alan verisi (field data) kullanıyor. Gerçek kullanıcı deneyimini ölçmek için:
- Google Search Console → Core Web Vitals raporu: 28 günlük gerçek kullanıcı verisi
- PageSpeed Insights: Alan verisi + Lighthouse analizi birlikte
- Chrome DevTools → Performance paneli: INP'yi manuel olarak izlemek için
- web-vitals.js kütüphanesi: Kendi analytics'inize CWV verisi göndermek için