Core Web Vitals: Üretimde LCP, INP ve CLS'yi İyileştirmek

Core Web Vitals, Google'ın bir web sayfasındaki kullanıcı deneyimini üç ölçüyle özetlediği metrik setidir: sayfanın ana içeriğinin ne kadar hızlı göründüğü, etkileşimlere ne kadar çabuk yanıt verildiği ve yerleşimin ne kadar sabit kaldığı. Google bu metrikleri arama sıralamasında kullandığı sayfa deneyimi sinyallerinin bir parçası olarak tanımlıyor; ancak içeriğin alakası her zaman önce gelir. Asıl kazanç, sayfanın kullanıcı için gerçekten daha hızlı ve kararlı hâle gelmesidir. Bu yazıda her metriğin neyi ölçtüğünü, nasıl ölçüleceğini ve üretimde hangi müdahalelerin işe yaradığını ele alıyoruz.

Üç Metrik ve Eşikleri

• LCP (Largest Contentful Paint): Görünür alandaki en büyük görselin ya da metin bloğunun ekrana çizildiği an. İyi eşik: 2,5 saniye ve altı.
• INP (Interaction to Next Paint): Sayfa ömrü boyunca tıklama, dokunma ve tuş basma etkileşimlerinden sonra bir sonraki karenin çizilmesine kadar geçen süre. Mart 2024'te FID'nin yerini aldı. İyi eşik: 200 milisaniye ve altı.
• CLS (Cumulative Layout Shift): Beklenmeyen yerleşim kaymalarının toplam skoru. İyi eşik: 0,1 ve altı.

Bu eşikler, sayfayı ziyaret eden kullanıcıların 75. yüzdelik dilimine göre değerlendirilir. Yani ortalama değil, yavaş cihaz ve bağlantılardaki kullanıcıları da kapsayan bir değer esas alınır.

Önce Doğru Ölçün: Saha ve Laboratuvar Verisi

İki tür veri vardır ve ikisi farklı sorulara cevap verir:

• Saha verisi (RUM): Gerçek kullanıcıların tarayıcılarından toplanan ölçümler. Google'ın değerlendirmesi Chrome kullanıcılarından derlenen CrUX verisine dayanır; PageSpeed Insights ve Search Console'daki Core Web Vitals raporu bu veriyi gösterir. Kendi RUM verinizi toplamak için web-vitals kütüphanesi kullanılabilir.
• Laboratuvar verisi: Lighthouse veya Chrome DevTools ile kontrollü ortamda yapılan ölçümler. Sorunun nedenini bulmak ve değişiklikleri karşılaştırmak için idealdir; ancak tek bir cihaz ve ağ profilini temsil eder. Standart bir sayfa yükleme testinde kullanıcı etkileşimi olmadığından INP ölçülmez; bu testlerde Total Blocking Time (TBT) yaklaşık bir gösterge olarak kullanılır.

import { onLCP, onINP, onCLS } from "web-vitals";

function gonder(metrik) {
  navigator.sendBeacon("/api/vitals", JSON.stringify({
    ad: metrik.name,
    deger: metrik.value,
    sayfa: location.pathname,
  }));
}

onLCP(gonder);
onINP(gonder);
onCLS(gonder);

Saha verisi "sorun var mı ve kimde?" sorusunu, laboratuvar verisi "neden ve düzeldi mi?" sorusunu yanıtlar. İkisini birlikte kullanmak gerekir.

LCP'yi İyileştirmek

LCP süresi dört alt parçaya ayrılabilir: sunucunun ilk baytı gönderme süresi (TTFB), LCP kaynağının yüklenmeye başlamadan önce beklediği süre, kaynağın indirilme süresi ve indirildikten sonra ekrana çizilene kadar geçen süre. Hangi parçanın uzun olduğunu bilmeden yapılan iyileştirme çoğu zaman yanlış yere harcanır. Chrome DevTools'un Performance panelinde bu dağılım ayrıca gösterilir.

Sunucu yanıtı

Yüksek TTFB'nin yaygın nedenleri; her istekte yeniden hesaplanan sayfalar, yavaş veritabanı sorguları ve kullanıcıdan uzak sunuculardır. Statik üretilebilen sayfaları önceden üretmek, değişmeyen içeriği CDN'de önbelleğe almak ve sayfanın ilk bölümünü yavaş veriyi beklemeden göndermek (streaming) bu süreyi kısaltır.

LCP kaynağını erken ve öncelikli yüklemek

LCP öğesi çoğu sayfada bir kahraman görseli ya da büyük bir başlıktır. Görselse:

<img src="/hero.avif" alt="..." width="1200" height="600"
     fetchpriority="high">

• LCP görseline asla loading="lazy" vermeyin; tarayıcı yüklemeyi geciktirir.
• Görsel HTML'de doğrudan yer almıyorsa (örneğin CSS arka planı ya da JavaScript ile ekleniyorsa) <link rel="preload" as="image"> ile tarayıcıya önceden bildirin.
• fetchpriority="high" ile tarayıcıya bu kaynağın öncelikli olduğunu söyleyin.
• Görseli doğru boyutta ve AVIF ya da WebP gibi modern formatlarda sunun; srcset ile mobil cihazlara küçük sürümü gönderin.

Render'ı engelleyen kaynaklar

Büyük CSS dosyaları ve head içindeki senkron script'ler, kaynak inmiş olsa bile çizimi geciktirir. Kritik olmayan script'leri defer veya async ile yükleyin. LCP öğesi bir metinse, web fontu beklenirken metnin görünmez kalmaması için font-display: swap ya da optional kullanın.

INP'yi İyileştirmek

INP kötüyse sorun neredeyse her zaman ana iş parçacığının (main thread) meşgul olmasıdır. Kullanıcı tıkladığında tarayıcı o sırada çalışan uzun bir görevi bitirmeden yanıt veremez. Bir etkileşimin süresi üç bölümden oluşur: girdi gecikmesi, olay işleyicinin çalışma süresi ve sonrasındaki çizim süresi.

• Uzun görevleri bölün. Uzun bir döngü veya hesaplama, aralarda ana iş parçacığına söz hakkı verilerek parçalara ayrılabilir. Destekleyen tarayıcılarda scheduler.yield(), diğerlerinde setTimeout ile bu yapılabilir.
• Görsel geri bildirimi önce verin. Olay işleyicide önce arayüzü güncelleyin, ağır işi sonraki bir göreve erteleyin.
• React'te acil olmayan güncellemeleri işaretleyin. React 18 ile gelen useTransition ve useDeferredValue, örneğin büyük bir listenin filtrelenmesini düşük öncelikli yaparak yazma alanının akıcı kalmasını sağlar.
• Üçüncü parti script'leri denetleyin. Analitik, sohbet ve reklam script'leri ana iş parçacığını sizden habersiz meşgul edebilir.
• DOM boyutunu küçük tutun. Çok büyük DOM ağaçları her güncellemede stil ve yerleşim hesaplamasını pahalı hâle getirir; uzun listelerde sanallaştırma kullanın.

Uzun görev, ana iş parçacığını 50 milisaniyeden uzun süre meşgul eden görev olarak tanımlanır. Aşağıdaki desen, büyük bir listeyi işlerken bu sınıra yaklaşıldığında tarayıcıya söz hakkı verir:

function anaIsParcaciginaVer() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function satirlariIsle(satirlar) {
  let baslangic = performance.now();
  for (const satir of satirlar) {
    isle(satir);
    if (performance.now() - baslangic > 50) {
      await anaIsParcaciginaVer();
      baslangic = performance.now();
    }
  }
}

CLS'yi İyileştirmek

• Görsel ve videolara boyut verin. width ve height nitelikleri ya da CSS aspect-ratio ile tarayıcı yeri önceden ayırır.
• Sonradan gelen içerik için alan ayırın. Reklamlar, gömülü içerikler ve çerez bildirimleri mevcut içeriği aşağı itmemeli; ya sabit yükseklikte bir kapta ya da içeriğin üzerinde gösterilmeli.
• Font değişiminden doğan kaymayı azaltın. Yedek fontun ölçülerini size-adjust gibi tanımlayıcılarla web fontuna yaklaştırmak, font yüklendiğinde metnin zıplamasını engeller.
• Animasyonlarda transform kullanın. top veya height gibi yerleşimi değiştiren özellikleri canlandırmak kaymaya sayılabilir.

Kazanımları Kalıcı Hâle Getirmek

Tek seferlik bir iyileştirme, birkaç ay içinde yeni özellikler ve eklenen script'lerle geri kaybolabilir. Bunu önlemenin yolu performansı sürecin parçası yapmaktır:

• Performans bütçesi belirleyin: JavaScript paket boyutu, LCP ve TBT için kabul edilebilir üst sınırlar.
• CI'da kontrol edin: Lighthouse CI, her PR'da belirlediğiniz bütçeleri doğrulayan kurallar (assertions) çalıştırabilir.
• Sahada izleyin: Laboratuvar testleri geçse de gerçek kullanıcı verisini takip edin; bazı sorunlar yalnız belirli cihazlarda veya sayfalarda ortaya çıkar.

Core Web Vitals'ı bir SEO maddesi olarak değil, kullanıcıların sayfanızı nasıl deneyimlediğinin bir ölçüsü olarak görmek, hangi iyileştirmenin öncelikli olduğuna karar vermeyi de kolaylaştırır.