Core Web Vitals: SEO için Kapsamlı Optimizasyon Rehberi (2026)

Core Web Vitals (CWV), Google'ın web sitenizdeki gerçek dünya kullanıcı deneyimini değerlendirmek için onaylanmış bir sıralama sinyali olarak kullandığı üç belirli sayfa performans metriğinden oluşan bir settir. 2020'de tanıtılan ve Mart 2024'te FID yerine INP ile güncellenen Core Web Vitals, sayfanızın ana içeriğini ne kadar hızlı yüklediğini (LCP), kullanıcı etkileşimlerine ne kadar hızlı yanıt verdiğini (INP) ve yükleme sırasında görsel olarak ne kadar kararlı kaldığını (CLS) ölçer. Bu üç metrik birlikte, sayfanızın kullanıcıların — ve Google'ın — beklediği türde bir deneyim sunup sunmadığını belirler.

2026'da Core Web Vitals artık isteğe bağlı değildir. Google'ın sayfa deneyimi sıralama sisteminin onaylanmış bir bileşenidir ve sayfalarınızın benzer içerik kalitesi ve otoritesine sahip rakiplerden daha üst sıralarda yer alıp almayacağını doğrudan etkiler. Daha da önemlisi, sitenizdeki her ziyaretçinin deneyimini etkiler. Yavaş yüklenen, tıklamalara ağır yanıt veren veya yükleme sırasında içeriği kaydıran bir sayfa kullanıcıları uzaklaştırır — ve Google bunu bilir, çünkü Chrome Kullanıcı Deneyimi Raporu (CrUX) aracılığıyla dünya çapındaki gerçek Chrome kullanıcılarından tam olarak bu davranışları ölçer.

Bu rehber, 2026'da Core Web Vitals hakkında bilmeniz gereken her şeyi kapsar: her metriğin neyi ölçtüğü, SEO ve yapay zeka araması için neden önemli olduğu, sorunları nasıl teşhis edeceğiniz ve tam olarak nasıl düzelteceğiniz. İster geliştirici, ister SEO uzmanı, ister site sahibi olun, gerçek kod örnekleri, önce/sonra karşılaştırmaları ve bugün uygulayabileceğiniz net bir optimizasyon iş akışı ile uygulanabilir stratejiler bulacaksınız.

Core Web Vitals Nedir?

Core Web Vitals, Google'ın sayfa deneyimi kalitesinin en önemli göstergeleri olarak belirlediği üç kullanıcı merkezli performans metriğidir. Teknik ölçümlere odaklanan geleneksel performans metriklerinin (DNS arama süresi, ilk bayt süresi) aksine, Core Web Vitals kullanıcıların gerçekte ne deneyimlediğine odaklanır: Sayfa ne kadar hızlı yükleniyor gibi görünüyor? Bir şeye tıkladığımda ne kadar hızlı yanıt veriyor? Okumaya veya etkileşimde bulunmaya çalışırken düzen etrafta sıçrıyor mu?

Google, Core Web Vitals'ı Mayıs 2020'de sayfa deneyiminin nasıl ölçüldüğünü standartlaştırmaya yönelik daha geniş bir girişimin parçası olarak tanıttı. Orijinal üç metrik LCP (Largest Contentful Paint), FID (First Input Delay) ve CLS (Cumulative Layout Shift) idi. Mart 2024'te Google, FID'yi INP (Interaction to Next Paint) ile değiştirdi çünkü INP, yalnızca ilk girdi gecikmesini değil, tam etkileşim yaşam döngüsünü yakalayan daha kapsamlı bir yanıt verme ölçüsü sağlar.

Core Web Vitals hakkında anlaşılması gereken temel şey, bunların laboratuvar simülasyonları değil, gerçek kullanıcı verileri kullanılarak ölçülmesidir. Google, Chrome Kullanıcı Deneyimi Raporu'na (CrUX) katılan milyonlarca Chrome kullanıcısından performans verileri toplar ve bir sayfanın her metriği geçip geçmediğini değerlendirmek için bu saha verilerinin 75. yüzdelik dilimini kullanır. Bu, yalnızca laboratuvar testleri için optimize ederek Core Web Vitals'ı kandıramayacağınız anlamına gelir — gerçek ziyaretçilerinizin gerçek dünya deneyimi önemlidir.

CWV Eşikleri Bir Bakışta

*TTFB bir Core Web Vital değildir ancak LCP'yi doğrudan etkileyen kritik bir teşhis metriğidir. Yavaş bir TTFB, iyi bir LCP puanı elde etmeyi neredeyse imkansız kılar.

LCP: Largest Contentful Paint

Largest Contentful Paint (LCP), görünüm alanındaki en büyük görünür içerik öğesinin render edilmesinin tamamlanma süresini ölçer. Bu genellikle bir hero görseli, büyük bir metin bloğu, bir video posteri veya bir arka plan görseli olur. LCP, kullanıcının temel sorusunu yanıtlar: "Ana içerik yüklendi mi?" İyi bir LCP 2,5 saniye veya altıdır.

LCP, tüm teslimat zincirini etkilediği için genellikle optimize edilmesi en zorlu Core Web Vital'dır: sunucu yanıt süresi (TTFB), kaynak keşfi, kaynak indirme ve render. Bu zincirin herhangi bir noktasına eklenen her milisaniye, LCP'nizi doğrudan artırır. Bu nedenle LCP optimizasyonu bütünsel bir yaklaşım gerektirir — tek bir darboğazı düzeltmek nadiren yeterlidir.

Kötü LCP'nin Yaygın Nedenleri

• Yavaş sunucu yanıt süresi (TTFB): Sunucunuzun yanıt vermesi 2 saniye sürüyorsa, LCP'niz 2,5 saniyenin altında olamaz. Sunucu tarafı render gecikmeleri, veritabanı sorguları ve eksik önbellekleme yaygın nedenlerdir.
• Render engelleyen kaynaklar: <head> içindeki CSS ve JavaScript dosyaları, tamamen indirilip ayrıştırılana kadar render'ı engeller. Büyük, küçültülmemiş CSS veya senkron JS dosyaları LCP'yi saniyeler kadar geciktirebilir.
• Optimize edilmemiş görseller: WebP/AVIF yerine PNG formatında sunulan hero görseller, görünüm alanı için düzgün boyutlandırılmamış görseller veya önceden yükleme ipuçları olmadan yüklenen görseller, tarayıcıyı yükleme sürecinde geç büyük dosyalar keşfetmeye ve indirmeye zorlar.
• İstemci tarafı render: İçeriği tamamen JavaScript'te render eden tek sayfa uygulamaları (React, Vue, Angular), herhangi bir içerik görünmeden önce tarayıcının JS'yi indirmesini, ayrıştırmasını ve çalıştırmasını gerektirir. Bu, çerçeve başlatılana kadar boş bir sayfa oluşturur.
• LCP öğesine lazy loading uygulamak: Hero görsele veya ekranın üst kısmındaki içeriğe yanlışlıkla loading="lazy" uygulamak, tarayıcı öğe görünüm alanına yaklaşana kadar getirmeyi beklediği için yüklemeyi geciktirir.

LCP'yi Optimize Etmek için 5 Strateji

1. Sunucu Yanıt Süresini Optimize Edin

Sunucu tarafı önbellekleme uygulayarak, CDN kullanarak, barındırmanızı yükselterek veya edge render edilmiş sayfalara geçerek TTFB'yi azaltın. TTFB'deki her 100ms'lik azalma doğrudan LCP'yi iyileştirir.

# Nginx — Gzip sıkıştırma ve statik önbelleklemeyi etkinleştir
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml;
gzip_min_length 256;

location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

2. LCP Görselini Önceden Yükleyin

Belge başlığında <link rel="preload"> etiketi kullanarak tarayıcıya LCP görseli hakkında erken bilgi verin. Bu, tarayıcının görseli DOM'da keşfetmeden önce indirmeye başlamasına olanak tanır.

<!-- Daha hızlı LCP için hero görselini önceden yükle -->
<link rel="preload" as="image" href="/images/hero.webp"
      type="image/webp" fetchpriority="high">

<!-- LCP görselini fetchpriority ile işaretle -->
<img src="/images/hero.webp" alt="Hero açıklaması"
     width="1200" height="630" fetchpriority="high">

3. Modern Görsel Formatları Kullanın

Görselleri WebP veya AVIF formatına dönüştürün. WebP genellikle eşdeğer kalitede JPEG'den %25-35 daha küçük dosyalar sağlar ve AVIF dosya boyutunu %50'ye kadar azaltabilir. Aşamalı geliştirme için <picture> öğesini kullanın.

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="Ürün vitrini"
       width="1200" height="630" fetchpriority="high">
</picture>

4. Render Engelleyen Kaynakları Ortadan Kaldırın

Kritik CSS'yi doğrudan <head> içine gömün ve kritik olmayan stil dosyalarını erteleyin. Ayrıştırıcıyı engellemesini önlemek için JavaScript'i defer veya async nitelikleriyle yükleyin.

<!-- Kritik ekranın üst kısmı CSS'sini göm -->
<style>
  /* Header, hero, nav için kritik stiller */
  .header { display:flex; height:60px; }
  .hero { min-height:400px; }
</style>

<!-- Kritik olmayan CSS'yi ertele -->
<link rel="preload" href="/style.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">

<!-- JavaScript'i ertele -->
<script src="/app.js" defer></script>

5. Statik Varlıklar için CDN Kullanın

Görselleri, CSS'yi, JavaScript'i ve yazı tiplerini, kullanıcılarınıza yakın edge konumları olan bir İçerik Dağıtım Ağı (CDN) üzerinden sunun. CDN, kaynak sunucunuzdan uzaktaki kullanıcılar için varlık indirme sürelerini %50-80 azaltabilir. Cloudflare, Fastly ve AWS CloudFront'un hepsi çoğu web sitesi için uygun ücretsiz veya uygun fiyatlı katmanlar sunar.

INP: Interaction to Next Paint

Interaction to Next Paint (INP), bir kullanıcı etkileşimi (tıklama, dokunma veya tuş basma) ile ekrandaki bir sonraki görsel güncelleme arasındaki gecikmeyi izleyerek sayfanızın en kötü durum yanıt verme hızını ölçer. INP, Mart 2024'te First Input Delay (FID) yerine Core Web Vital olarak geçti. İyi bir INP 200 milisaniye veya altıdır.

INP ile önceki FID arasındaki kritik fark kapsamdır. FID yalnızca tarayıcının ilk kullanıcı etkileşimini işlemeye başlamadan önceki gecikmeyi ölçüyordu. INP, sayfa yaşam döngüsü boyunca her etkileşimin tam gecikmesini ölçer ve en kötüsünü (veya neredeyse en kötüsünü, 98. yüzdelik dilimde) raporlar. Bu, ilk tıklamaya hızlı yanıt veren ancak kullanıcı bir açılır menü açtığında 800ms donduran bir sayfanın, FID'yi geçmiş olsa bile INP'yi geçemeyeceği anlamına gelir.

INP, etkileşim gecikmesinin üç farklı aşamasını yakalar:

• Girdi gecikmesi: Kullanıcının etkileşimi ile tarayıcının olay işleyicilerini çalıştırmaya başlaması arasındaki süre. Bu, ana iş parçacığının diğer görevlerle meşgul olmasından kaynaklanır (uzun görevler, yoğun JavaScript çalıştırma).
• İşleme süresi: Olay işleyicilerinin çalıştırılması için gereken süre. Senkron DOM manipülasyonu, yoğun hesaplama veya engelleyici API çağrıları gerçekleştiren karmaşık olay işleyicileri işleme süresini artırır.
• Sunum gecikmesi: Olay işleyicilerinin tamamlanması ile tarayıcının bir sonraki kareyi boyaması arasındaki süre. Bu, etkileşim tarafından tetiklenen stil yeniden hesaplaması, düzen ve boya işlemlerini içerir.

INP'yi Optimize Etme Stratejileri

1. Uzun Görevleri Parçalayın

50ms'den uzun süren JavaScript görevleri ana iş parçacığını engeller ve tarayıcının kullanıcı etkileşimlerine yanıt vermesini önler. requestIdleCallback, setTimeout veya scheduler.yield() API'sini kullanarak uzun görevleri daha küçük parçalara ayırın.

// Kötü: Tek bir uzun senkron görev (ana iş parçacığını engeller)
function processAllItems(items) {
  items.forEach(item => heavyProcessing(item)); // 500ms+
}

// İyi: scheduler.yield() ile parçalara ayır
async function processAllItems(items) {
  for (const item of items) {
    heavyProcessing(item);
    // Öğeler arasında ana iş parçacığına kontrol ver
    if (navigator.scheduler?.yield) {
      await navigator.scheduler.yield();
    } else {
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

2. JavaScript Paket Boyutunu Azaltın

Büyük JavaScript paketlerinin ayrıştırılması ve çalıştırılması daha uzun sürer, sayfa yüklemesi sırasında ve etkileşimlerden sonra ana iş parçacığını engeller. Yalnızca mevcut sayfa için gereken JavaScript'i yüklemek için kod bölme kullanın, kullanılmayan kodu tree-shake yapın ve kritik olmayan betikleri erteleyin.

3. Girdi İşleyicilerini Debounce Edin

Scroll, resize, mousemove ve input olayları için olay işleyicileri saniyede yüzlerce kez ateşlenebilir. Bu işleyicileri debounce veya throttle ederek ana iş parçacığını bunaltmalarını ve sonraki kullanıcı etkileşimleri için kötü INP'ye neden olmalarını önleyin.

4. Zorunlu Senkron Düzenleri Önleyin

DOM'u değiştirdikten hemen sonra düzen özelliklerini (offsetHeight veya getBoundingClientRect() gibi) okumak, tarayıcıyı ana iş parçacığını engelleyen senkron bir düzen hesaplaması yapmaya zorlar. Okuma ve yazma işlemlerinizi ayrı ayrı gruplayın.

CLS: Cumulative Layout Shift

Cumulative Layout Shift (CLS), sayfanızın görünür içeriğinin yaşam döngüsü boyunca ne kadar beklenmedik şekilde hareket ettiğini ölçer. Görsel kararsızlığı nicelleştirir — bir düğmeye tıklamak üzereyken üstüne bir reklam yüklendi diye aniden sıçraması veya bir web yazı tipi yüklendiği için okuduğunuz metnin aşağı kayması gibi sinir bozucu anlar. İyi bir CLS puanı 0,1 veya altıdır.

CLS, etki oranı (görünüm alanının ne kadarının kaymadan etkilendiği) ile mesafe oranı (öğelerin ne kadar hareket ettiği) çarpılarak hesaplanır. Yalnızca beklenmeyen kaymalar sayılır — bir kullanıcı etkileşiminin (açılır menüye tıklama gibi) 500ms'si içinde gerçekleşen düzen değişiklikleri CLS'den hariç tutulur. Google, CLS'yi hesaplamak için "oturum penceresi" yaklaşımı kullanır; birbirini 1 saniye içinde takip eden kaymaları gruplar (maksimum 5 saniyelik bir pencere ile) ve en büyük oturum penceresini raporlar.

Kötü CLS'nin Yaygın Nedenleri

• Boyutları olmayan görseller ve videolar: Görseller açık width ve height nitelikleri olmadan yüklendiğinde, tarayıcı onlar için yer ayıramaz. Yüklendiklerinde, altlarındaki tüm içeriği aşağı iterler.
• Ayrılmış alanı olmayan reklamlar, gömülü içerikler ve iframe'ler: Önceden tanımlanmış bir kapsayıcı olmadan kendini sayfaya dinamik olarak ekleyen üçüncü taraf içerikleri önemli düzen kaymalarına neden olur.
• Dinamik olarak eklenen içerik: İlk render'dan sonra içeriği aşağı iten banner'lar, bildirim çubukları, çerez onay modülleri veya "son dakika" şeritleri.
• FOUT'a neden olan web yazı tipleri (Stilsiz Metin Yanıp Sönmesi): Bir web yazı tipi yüklenip yedek yazı tipinin yerini aldığında, yazı tipi metriklerindeki farklılıklar (boyut, satır yüksekliği, harf aralığı) metin bloklarının kaymasına neden olur.
• Düzeni tetikleyen CSS animasyonları: transform yerine top, left, width veya height gibi özellikleri kullanan animasyonlar, kayma olarak sayılan düzen yeniden hesaplamalarına neden olur.

CLS'yi Düzeltme Stratejileri

1. Her Zaman Görsel ve Video Boyutlarını Belirleyin

<!-- Görseller için her zaman width ve height ekleyin -->
<img src="/product.webp" alt="Ürün fotoğrafı"
     width="800" height="600" loading="lazy">

<!-- Duyarlı görseller için aspect-ratio CSS kullanın -->
<style>
  .responsive-img {
    width: 100%;
    height: auto;
    aspect-ratio: 16 / 9;
    object-fit: cover;
  }
</style>

2. Reklamlar ve Gömülü İçerikler için Yer Ayırın

<!-- 300x250 reklam alanı için yer ayır -->
<div style="min-height: 250px; width: 300px;">
  <!-- Reklam betiği burada yüklenir -->
</div>

<!-- Iframe gömme için yer ayır -->
<iframe src="https://embed.example.com"
        width="560" height="315"
        loading="lazy"></iframe>

3. font-display: swap ile Boyut Ayarlı Yedekler Kullanın

/* Web yazı tiplerinden düzen kaymasını önle */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  /* Metrikleri eşleştirmek için boyut ayarlı yedek */
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

/* Alternatif: @font-face override kullan */
@font-face {
  font-family: 'Inter Fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
}

4. Animasyonlar için CSS transform Kullanın

/* Kötü: Düzen özelliklerini canlandırmak CLS'ye neden olur */
.slide-in {
  animation: slideIn 0.3s ease;
}
@keyframes slideIn {
  from { left: -100%; }
  to { left: 0; }
}

/* İyi: transform kullan (düzen kayması yok) */
.slide-in {
  animation: slideIn 0.3s ease;
}
@keyframes slideIn {
  from { transform: translateX(-100%); }
  to { transform: translateX(0); }
}

Core Web Vitals Sıralamaları Nasıl Etkiler

Google, Core Web Vitals'ı Haziran 2021'de daha geniş Sayfa Deneyimi güncellemesinin parçası olarak bir sıralama sinyali olarak doğruladı. O zamandan beri, Searchmetrics, Semrush ve bağımsız SEO araştırmacılarından yapılan birçok çalışma, CWV puanları ile sıralama pozisyonları arasındaki korelasyonu analiz etti. Konsensüs nettir: Core Web Vitals gerçek ama ılımlı bir sıralama faktörüdür. İçerik kalitesini veya backlink otoritesini geçersiz kılmaz, ancak rakip sayfalar kalite ve alaka açısından benzer olduğunda anlamlı bir belirleyici olarak hizmet eder.

Veriler tutarlı bir model göstermektedir: iyi Core Web Vitals'a sahip siteler ölçülebilir trafik artışları görme eğilimindeyken, kötü CWV'ye sahip siteler, özellikle Google'ın sayfa deneyimi sinyallerine daha fazla ağırlık verdiği mobil arama sonuçlarında sıralama dezavantajlarıyla karşılaşır.

Core Web Vitals'ın dolaylı etkileri, doğrudan sıralama etkisinden tartışmasız daha önemlidir. Hızlı yüklenen, anında yanıt veren ve görsel olarak kararlı kalan sayfalar daha düşük hemen çıkma oranlarına, daha yüksek etkileşime, daha uzun oturum sürelerine ve daha fazla dönüşüme sahiptir. Google, kullanıcı etkileşim sinyallerini (kalma süresi, pogo-sticking) sıralama algoritmalarının bir parçası olarak ölçer, bu nedenle iyi CWV'den gelen kullanıcı davranışı iyileştirmeleri, sıralamalarınızı daha da güçlendiren pozitif bir geri bildirim döngüsü oluşturur.

Core Web Vitals Optimizasyon İş Akışı

Core Web Vitals'ı optimize etmek tek seferlik bir görev değildir — iteratif bir süreçtir. CWV performansınızı sistematik olarak belirlemek, teşhis etmek, düzeltmek, doğrulamak ve zaman içinde sürdürmek için bu beş adımlı iş akışını izleyin.

Adım 1 — Ölç: Google Search Console'un Core Web Vitals raporundaki ve PageSpeed Insights'taki gerçek dünya (saha) verilerinizi kontrol ederek başlayın. CrUX'tan gelen saha verileri, son 28 günün gerçek kullanıcı deneyimlerini yansıtır. CrUX verileri için yeterli trafiğiniz yoksa, başlangıç noktası olarak Lighthouse'dan laboratuvar verilerini kullanın, ancak laboratuvar puanlarının yaklaşık değerler olduğunu, saha performansının garantisi olmadığını unutmayın.

Adım 2 — Teşhis Et: Belirli darboğazları belirlemek için Chrome DevTools Performans panelini kullanın. LCP için, LCP kaynağını neyin geciktirdiğini bulmak üzere Ağ şelalesine bakın. INP için, ana iş parçacığını engelleyen uzun görevleri bulmak üzere Performans panelinin etkileşim izlemesini kullanın. CLS için, hangi öğelerin ne zaman kaydığını tam olarak görmek üzere "Düzen Kayması Bölgeleri" kaplamasını etkinleştirin.

Adım 3 — Optimize Et: Teşhisinize dayalı hedefli düzeltmeler uygulayın. "İyi" eşiğinden en uzak olan metriğe öncelik verin. Bu rehberde her metrik için ayrıntılı olarak açıklanan spesifik optimizasyon stratejilerini kullanın.

Adım 4 — Test Et: Düzeltmeleri uyguladıktan sonra, Lighthouse ve WebPageTest kullanarak hazırlık ortamında test edin. Önceki ve sonraki puanları karşılaştırın. İyileştirmelerin farklı cihaz türleri ve ağ koşullarında geçerli olduğundan emin olun. İçeriğin daha hızlı yüklendiğini ve kaymadığını görsel olarak doğrulamak için WebPageTest'in film şeridi görünümünü kullanın.

Adım 5 — İzle: Üretime dağıtın ve Search Console'da CrUX verilerini izleyin. Saha verilerinin tam olarak güncellenmesi 28 gün sürer, bu yüzden sabırlı olun. Gerçek ziyaretçilerinizden gerçek zamanlı performans verileri almak için web-vitals JavaScript kitaplığıyla Gerçek Kullanıcı İzleme (RUM) kurun. Herhangi bir metrik kötüleşirse bilgilendirilmeniz için uyarı eşikleri belirleyin.

// Kurulum: npm install web-vitals
import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
  // Metrik verilerini analiz uç noktanıza gönderin
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement', veya 'poor'
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
  });

  // Güvenilir teslimat için sendBeacon kullanın
  navigator.sendBeacon('/api/vitals', body);
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Önce ve Sonra: Gerçek Optimizasyon Sonuçları

6 Temel Optimizasyon Tekniği

Bu altı teknik, üç Core Web Vital genelinde en etkili optimizasyonları kapsar. Altısının tümünü uygulamak, çoğu web sitesindeki CWV sorunlarının büyük çoğunluğunu çözecektir.

Metriğe Göre Optimizasyon Teknikleri

Core Web Vitals için Teşhis Araçları

Etkili CWV optimizasyonu doğru ölçüm araçlarını gerektirir. İşte 2026'da mevcut araçların güçlü yönlerine ve ideal kullanım alanlarına göre düzenlenmiş kapsamlı bir karşılaştırması.

Öneri: Araçların bir kombinasyonunu kullanın. Büyük resim için Google Search Console ile başlayın (hangi sayfalar geçiyor, hangileri geçmiyor ve trendler nasıl görünüyor). Gerçek CrUX verileriyle sayfa bazında teşhis için PageSpeed Insights kullanın. Belirli bir darboğazı izlemeniz gerektiğinde etkileşimli hata ayıklama için Chrome DevTools kullanın. Rekabet analizi ve dağıtmadan önce değişiklikleri test etmek için WebPageTest kullanın. CWV'nin 136+ diğer sıralama faktörünün yanında genel SEO resminize nasıl uyduğunu görmek için seoscore.tools kullanın.

Önceliklendirme: Hızlı Kazanımlar vs Uzun Vadeli Düzeltmeler

Core Web Vitals ve Yapay Zeka Araması

Core Web Vitals'ın yapay zeka arama görünürlüğü için önemli olup olmadığını merak edebilirsiniz — sonuçta, ChatGPT, Perplexity ve Google AI Overview gibi yapay zeka sistemleri içeriği bir tarayıcı aracılığıyla değil, programatik olarak işler. Cevap nüanslı ama önemlidir: Core Web Vitals, yapay zeka arama görünürlüğünü dolaylı ama anlamlı bir şekilde etkiler.

CWV yapay zeka aramasıyla şu şekilde bağlantılıdır:

Arama dizini etkisi: Google AI Overview, CWV'nin bir sıralama faktörü olduğu Google'ın arama dizininden kaynaklar çeker. İyi CWV'ye sahip sayfalar geleneksel aramada daha üst sıralarda yer alır, bu da AI Overview'un seçim yaptığı aday havuzunda görünme olasılıklarını artırır. Sayfanız kötü CWV nedeniyle 15. sıradaysa, aynı içeriğe sahip ancak daha iyi performans gösteren 3. sıradaki bir sayfaya kıyasla AI Overview'da alıntılanma olasılığı çok daha düşüktür.

Tarama verimliliği: Yapay zeka tarayıcılarının (Perplexity ve ChatGPT'nin göz atma modu dahil) sayfaları getirmek ve ayrıştırmak için sınırlı zaman bütçeleri vardır. Render edilmesi 6 saniye süren yavaş yüklenen bir sayfa, yapay zeka tarama işlemleri sırasında zaman aşımına uğrayabilir veya yalnızca kısmen render edilebilir. Hızlı, temiz sayfalar yapay zeka sistemleri tarafından daha güvenilir şekilde taranır ve dizine eklenir.

İçerik erişilebilirliği: Önemli düzen kaymaları veya JavaScript'e bağımlı render'a sahip sayfalar, yapay zeka tarayıcılarına insan ziyaretçilerden farklı içerik sunabilir. Ana içeriğiniz render edilmek için yoğun JavaScript çalıştırma gerektiriyorsa (INP ve LCP için kötü), yapay zeka tarayıcıları bunu tamamen kaçırabilir. İyi CWV'ye sahip sunucu tarafı render edilmiş içerik, hem geleneksel hem de yapay zeka arama sistemleri tarafından en güvenilir şekilde ayrıştırılır.

Kalite sinyali olarak kullanıcı deneyimi: Google, davranışsal sinyalleri (hemen çıkma oranı, etkileşim, kalma süresi) giderek daha fazla dolaylı sıralama faktörleri olarak kullanmıştır. Kötü CWV'ye sahip sayfalar daha kötü davranışsal sinyaller üretir, bu da sıralamaları düşürür, bu da yapay zeka alıntılama olasılığını azaltır. Kullanıcı düzeyindeki kötü performansın azaltılmış yapay zeka görünürlüğüne kaskad ettiği bir zincirleme reaksiyondur.

Yaygın Core Web Vitals Hataları

Deneyimli geliştiriciler ve SEO uzmanları bile Core Web Vitals'ı optimize ederken bu hataları yapar. Bunlardan kaçınmak size saatlerce hata ayıklama süresinden tasarruf ettirecek ve gerilemeyi önleyecektir.

• Yalnızca laboratuvar verileri için optimize etmek. 100'lük bir Lighthouse puanı iyi CrUX verileri garanti etmez. Laboratuvar testleri sabit bir cihazda sabit bir ağla çalışır; gerçek kullanıcılar son derece farklı cihazlara, bağlantılara ve tarayıcı bağlamlarına sahiptir. Laboratuvar iyileştirmelerini her zaman saha verileriyle doğrulayın. Lighthouse puanınız 95 ama CrUX INP'niz 450ms ise, laboratuvar testi sizi yanıltıyor demektir.
• LCP öğesine lazy loading uygulamak. Hero görsellere, ekranın üst kısmındaki banner'lara veya birincil içerik görsellerine loading="lazy" eklemek, en yaygın ve zararlı LCP hatalarından biridir. Lazy loading, tarayıcı öğe görünüm alanına yaklaşana kadar getirmeyi beklediği için bu kritik kaynakları geciktirir. LCP öğesi her zaman fetchpriority="high" ile hevesle yüklenmelidir.
• Üçüncü taraf betiklerini görmezden gelmek. Analiz, sohbet widget'ları, sosyal gömülü içerikler, reklam betikleri ve A/B test araçları, genellikle kendi kodunuzdan daha fazla kötü CWV'ye katkıda bulunur. Tek bir optimize edilmemiş sohbet widget'ı, ana iş parçacığını engelleyerek INP'ye 500ms+ ekleyebilir. Her üçüncü taraf betiğini denetleyin, kritik olmayanları erteleyin ve üçüncü taraf iframe'ler için Partitioned niteliğini kullanın.
• CLS'yi geliştirmede düzeltip üretimde düzeltmemek. CLS, geliştirme ortamlarında bulunmayan reklamlar, çerez onay banner'ları, A/B test varyasyonları ve kullanıcı tarafından oluşturulan içerikler nedeniyle üretimde genellikle farklı davranır. CLS'yi her zaman gerçek reklam yapılandırmaları ve gerçek kullanıcı akışlarıyla üretimde ölçün.
• Çok fazla web yazı tipi kullanmak. Google Fonts veya kendi barındırdığınız bir yazı tipi servisinden 4-6 yazı tipi ağırlığı ve stili yüklemek, LCP'ye önemli gecikme ekler ve yazı tipleri değiştiğinde CLS'ye neden olur. Kendinizi en fazla 2-3 yazı tipi dosyasıyla sınırlayın. Düzen kaymalarını önlemek için boyut ayarlı yedeklerle font-display: swap kullanın ve yalnızca en kritik yazı tipi dosyasını önceden yükleyin.
• Duyarlı görsellerde açık boyutlar ayarlamamak. HTML width ve height nitelikleri, duyarlı CSS (width: 100%; height: auto;) ile mükemmel şekilde çalışır. Tarayıcı, görsel yüklenmeden önce doğru alanı ayırmak için niteliklerden en-boy oranını kullanır. Duyarlı görseller ve açık boyutlar arasında çatışma yoktur — bunları ihmal etmek her zaman bir hatadır.
• WiFi'de hızlı bir sitenin her yerde hızlı olduğunu varsaymak. Sayfalarınızı simüle edilmiş 3G ve 4G bağlantılarında test edin ve gerçek orta sınıf Android cihazlarda test edin. Google'ın CrUX verileri, değişken bağlantılardaki mobil kullanıcılar tarafından domine edilir. Sayfanız fiber internetteki MacBook Pro'nuzda "iyi" puan alabilir ama mobil cihazlardaki gerçek kullanıcılarınızın çoğunluğu için "kötü" olabilir.
• Dağıtım sonrası izlememek. Yeni özellikler, reklamlar, üçüncü taraf betikleri ve içerikler eklendikçe performans gerilemeleri sürekli yaşanır. Sürekli izleme olmadan, optimize edilmemiş bir hero görseli veya yeni bir analiz betiği ekleyen tek bir PR, aylarca süren optimizasyon çalışmasını geri alabilir. web-vitals kütüphanesi veya bir RUM servisi kullanarak otomatik uyarılar kurun.

Sık Sorulan Sorular

Temel Çıkarımlar

1. Core Web Vitals onaylanmış bir Google sıralama faktörüdür. LCP, INP ve CLS, sayfa deneyimi sinyalinin bir parçası olarak arama sıralamalarınızı doğrudan etkiler. Üç eşiği de geçen sitelerin, özellikle mobilde ölçülebilir bir avantajı vardır.
2. INP, Mart 2024'te FID'nin yerini aldı ve geçmesi çok daha zordur. Yalnızca ilk etkileşimin girdi gecikmesini ölçen FID'den farklı olarak, INP sayfadaki her etkileşimin tam gecikmesini ölçer. FID'yi kolayca geçen birçok site INP'de başarısız olur. INP'nizi özellikle denetleyin — güvende olduğunuzu varsaymayın.
3. Gerçek kullanıcılar için optimize edin, laboratuvar puanları için değil. Google, 75. yüzdelik dilimde ölçülen Chrome Kullanıcı Deneyimi Raporu'ndan (CrUX) saha verilerini kullanır. Mükemmel bir Lighthouse puanı, gerçek cihazlardaki gerçek kullanıcılarınız kötü deneyimler yaşıyorsa hiçbir şey ifade etmez. Her zaman CrUX saha verileriyle doğrulayın.
4. Hızlı kazanımlar mevcuttur ve önce yapılmalıdır. Görsel sıkıştırma, LCP öğesini önceden yükleme, açık görsel boyutları ayarlama ve önbelleklemeyi etkinleştirme, minimum çabayla CWV'yi dramatik şekilde iyileştirebilir. Karmaşık mimari değişikliklere yatırım yapmadan önce oradan başlayın.
5. CWV yapay zeka aramasını dolaylı ama önemli ölçüde etkiler. Daha hızlı, daha kararlı sayfalar geleneksel aramada (yapay zeka sistemlerinin yararlandığı) daha üst sıralarda yer alır, yapay zeka tarayıcıları tarafından daha güvenilir şekilde taranır ve daha iyi kullanıcı etkileşim sinyalleri üretir. CWV'yi optimize etmek, hem geleneksel hem de yapay zeka destekli aramada görünürlüğü artırır.
6. Sürekli izleme vazgeçilmezdir. Yeni özellikler, reklamlar ve üçüncü taraf betiklerinden kaynaklanan performans gerilemeleri süreklidir. Gerçek kullanıcı metriklerini izlemek için web-vitals kütüphanesini kullanın ve gerilemelerin anında yakalanması için uyarılar kurun. CWV'nizin genel SEO sağlığınıza nasıl uyduğunu görmek için seoscore.tools'u düzenli olarak kontrol edin.