Core Web Vitals İçin Pratik Performans Rehberi

Önce ölçme kültürü, sonra optimizasyon

Performans işlerinde en pahalı hata, ölçmeden iyileştirmeye başlamaktır. Ekipler haftalarca bir şeyleri optimize eder, sonuçta puan yerinde sayar; çünkü düzeltilen şey kullanıcının gerçekten yaşadığı sorun değildir.

Bu yazı bilinçli olarak teknoloji bağımsız. Hangi çatıyı kullanırsan kullan geçerli olan kısmı anlatıyorum: üç metriğin gerçekte neyi ölçtüğü, eşiklerin nasıl okunduğu, verinin nereden geldiği ve neyi önce düzeltmen gerektiği. Uygulama tarafındaki somut kod çözümlerini ayrı bir yazıda topladım: Next.js'te Core Web Vitals'ı yeşile çekmek.

Üç metrik, üç farklı kullanıcı şikâyeti

Core Web Vitals üç metrikten oluşur ve her biri farklı bir insan şikâyetinin sayısal karşılığıdır. Metrikleri şikâyetle eşleştirmek, hangisiyle uğraşacağını seçmenin en hızlı yoludur.

LCP — "Sayfa geç açılıyor"

LCP (Largest Contentful Paint), görünür alandaki en büyük içerik parçasının ne zaman boyandığını ölçer. Bu genelde hero görseli, büyük bir başlık ya da kapak videosunun poster karesidir. Kullanıcının "açıldı" dediği andır.

LCP kötüyse kullanıcı boş bir ekrana bakıyordur. Terk oranını en doğrudan etkileyen metrik budur, çünkü henüz hiçbir şey görmemiş biri sabretmez.

INP — "Tıklıyorum, tepki vermiyor"

INP (Interaction to Next Paint), sayfanın tıklama, dokunma ve klavye girdilerine ne kadar hızlı görsel tepki verdiğini ölçer. FID'in yerini aldı ve ondan çok daha zorlu bir metrik; çünkü ilk etkileşimi değil, ziyaret boyunca yaşanan etkileşimlerin en kötülerine yakın bir değeri raporlar.

INP kötüyse kullanıcı butona iki kez basıyor, menü geç açılıyor, yazdığı harfler ekranda gecikmeli beliriyordur. "Site bozuk" algısı çoğu zaman buradan doğar.

CLS — "Tam basacakken yer değiştirdi"

CLS (Cumulative Layout Shift), sayfa yüklenirken içeriğin beklenmedik biçimde kaymasını ölçer. Geç yüklenen bir görsel, sonradan gelen bir font, tepede beliren bir duyuru çubuğu içeriği aşağı iter.

CLS kötüyse kullanıcı yanlış bağlantıya tıklar, okuduğu satırı kaybeder, formda yanlış alana yazar. Öfke üreten ama nadiren doğru teşhis edilen metrik budur.

Eşikler ve çoğunlukla atlanan 75. yüzdelik kuralı

Google'ın "iyi" kabul ettiği eşikler şunlar:

• LCP: 2,5 saniye ve altı iyi, 4 saniyeye kadar iyileştirme gerekli, üstü kötü.
• INP: 200 milisaniye ve altı iyi, 500 milisaniyeye kadar iyileştirme gerekli, üstü kötü.
• CLS: 0,1 ve altı iyi, 0,25'e kadar iyileştirme gerekli, üstü kötü.

Kritik ayrıntı şu: bu eşikler ortalamaya değil, 75. yüzdeliğe uygulanır. Yani kullanıcılarının dörtte üçü eşiğin altında bir deneyim yaşamalı. Ortalamaya bakmak, en kötü deneyimi yaşayan çeyreği görünmez kılar — ki genelde mobil kullanıcıların ve zayıf bağlantıların bulunduğu yer tam olarak orasıdır.

Bir sayfanın "geçer" sayılması için üç metriğin de aynı anda iyi olması gerekir. İkisi mükemmel, biri kötüyse sonuç kötüdür.

Saha verisi ile lab verisi aynı şey değil

Bu ayrımı anlamadan hiçbir Core Web Vitals raporu doğru okunamaz.

Saha verisi (RUM / CrUX): Gerçek kullanıcıların gerçek cihaz ve bağlantılarından toplanan veridir. Google'ın sıralama sinyali olarak kullandığı veri budur. Yaklaşık 28 günlük hareketli bir pencereyi temsil eder; yani bugün yaptığın iyileştirme raporda hemen görünmez, haftalar içinde sızar.

Lab verisi (Lighthouse, sentetik testler): Sabit bir cihaz profili ve ağ simülasyonuyla, kontrollü ortamda üretilir. Tekrarlanabilirdir, bu yüzden regresyon yakalamak ve karşılaştırma yapmak için mükemmeldir. Ama tek bir yapay ziyareti temsil eder.

Bu farkın doğurduğu iki klasik durum:

• Lab yeşil, saha kırmızı: Genelde gerçek cihaz çeşitliliği, üçüncü taraf betikler, çerez banner'ı, oturum açmış kullanıcı deneyimi ya da coğrafi gecikme yüzünden. Laboratuvarda çalışan bir sayfa, üç yaşındaki bir Android telefonda başka davranır.
• Lab kırmızı, saha yeşil: Genelde test edilen URL gerçek trafiğin geldiği sayfa değildir ya da ölçüm sırasında geçici bir yavaşlık yaşanmıştır.

Ayrıca lab ortamı INP'i doğrudan ölçemez; çünkü INP gerçek etkileşim ister. Lighthouse sana bunun yerine ana iş parçacığı yükü ve toplam engelleme süresi gibi vekil sinyaller verir. INP hakkında gerçek karar vermek için sahaya bakman gerekir.

Nereden ölçeceksin: dört katman

PageSpeed Insights

Tek bir URL için hem saha hem lab verisini yan yana gösterir. Başlangıç noktası olarak en pratik araç. Üst bölümdeki saha verisi gerçeği, alt bölümdeki lab önerileri ise ipucunu verir. Öneri listesini "yapılacaklar listesi" gibi değil, hipotez listesi gibi oku.

Search Console — Core Web Vitals raporu

Tek URL yerine URL grupları üzerinden bakar. Asıl gücü budur: hangi sayfa şablonunun (blog detay, ürün listesi, ana sayfa) sorunlu olduğunu gösterir. Site genelinde önceliklendirme yapmanın en doğru yeri burasıdır, çünkü tek tek URL kovalamak yerine kalıbı düzeltirsin.

Tarayıcı geliştirici araçları

Performance panelinde bir etkileşimi kaydedip hangi görevin ana iş parçacığını kilitlediğini adım adım görebilirsin. INP teşhisi için pratikte en verimli yer burasıdır. CLS için de kayan öğeyi işaretleyip suçluyu bulabilirsin. Lighthouse raporu ise dört kategoriyi birden özetler.

Kendi saha ölçümün (RUM)

En değerli katman bu. Kendi kullanıcılarından metrik toplarsan, üçüncü taraf raporların 28 günlük gecikmesine mahkûm kalmazsın ve veriyi kendi boyutlarınla kesebilirsin.

// Framework bağımsız: web-vitals kütüphanesi ile saha ölçümü
import { onLCP, onINP, onCLS } from "web-vitals";

function raporla(metric) {
  const govde = JSON.stringify({
    ad: metric.name,
    deger: metric.value,
    durum: metric.rating,
    yol: location.pathname,
  });
  // Kişisel veri gönderme; yalnızca metrik ve sayfa yolu yeterli
  navigator.sendBeacon("/api/vitals", govde);
}

onLCP(raporla);
onINP(raporla);
onCLS(raporla);

Topladığın veriyi en az üç boyutta kesebilmelisin: cihaz tipi (mobil/masaüstü), sayfa şablonu ve ilk ziyaret mi tekrar ziyaret mi. Bu üç kesit, sorunun nerede olduğunu genelde ilk bakışta söyler.

Ölçüm kurgusunu doğru yapmak

Ölçümün kendisi de yanlış yapılabilir. Sık gördüğüm hatalar:

• Yalnızca ana sayfaya bakmak. Organik trafiğin çoğu iç sayfalara gelir. Ana sayfa genelde en çok özenilen ve en az temsil eden sayfadır.
• Yalnızca masaüstünden ölçmek. Sıralamada belirleyici olan mobil deneyimdir; iki profil arasındaki fark çoğu sitede uçurumdur.
• Önbelleği ısıtılmış tarayıcıda test etmek. İlk ziyaretçi deneyimini görmek istiyorsan temiz profil kullan.
• Tek ölçüme güvenmek. Lab verisi doğası gereği gürültülüdür; birkaç ölçümün medyanına bak.
• Çerez banner'ını hesaba katmamak. Ekranın büyük kısmını kaplayan bir banner, hem LCP adayını hem CLS'i doğrudan değiştirir.
• Yalnızca yayın öncesi ölçmek. Performans tek seferlik bir iş değil; her yeni özellik geri çekebilir. Ölçümü sürekli hâle getir.

Önceliklendirme: neyi önce düzelteceksin

Elinde uzun bir öneri listesi olduğunda sıralamayı şu mantıkla kurmanı öneririm:

1. Kırmızı olan metrikle başla. Sarıyı yeşile çekmek tatmin edicidir ama kırmızı olan, kullanıcıyı fiilen kaybettiğin yerdir.
2. En çok trafik alan şablonu seç. Tek bir sayfayı mükemmelleştirmek yerine, yüzlerce sayfayı besleyen kalıbı düzelt.
3. Mobili öne al. Hem eşiklerin zorlandığı hem trafiğin yoğun olduğu yer orası.
4. Emek/etki oranına bak. Görsel formatı ve boyutu düzeltmek genelde saatlik bir iştir ve LCP'de büyük fark yaratır; mimari değişiklik ise haftalar sürer.
5. Üçüncü taraf betikleri sorgula. Çoğu sitede en büyük tek kazanç, gerçekten gerekli olmayan bir betiği kaldırmaktır. Her betik için "bu olmasa ne kaybederiz?" sorusunu sor.
6. Regresyonu kilitle. İyileştirmeyi yaptıktan sonra bir performans bütçesi tanımla ve otomatik kontrolle bozulmayı erken yakala.

Bu sıralama, sınırlı zamanı en çok kullanıcıya dokunan işe harcamanı sağlar.

Şikâyetten metriğe hızlı eşleme

Müşteriden gelen cümleyi doğru metriğe çevirmek, teşhisin yarısıdır:

• "Site geç açılıyor" → LCP. Görsel ağırlığı, sunucu yanıt süresi, render engelleyen kaynaklar.
• "Yazı geç geliyor, önce boş duruyor" → LCP ve font yükleme davranışı.
• "Tıklayınca donuyor" → INP. Ana iş parçacığını kilitleyen betikler, ağır bileşenler.
• "Menü geç açılıyor" → INP.
• "Yanlış yere tıklıyorum" → CLS. Boyutu tanımlanmamış görseller, sonradan gelen banner'lar.
• "Mobilde çok kötü, bilgisayarda iyi" → cihaz kesitinde ölçüm eksikliği; büyük ihtimalle JavaScript yükü.

Özet kontrol listesi

• Üç metriğin hangi kullanıcı şikâyetine karşılık geldiğini bil; teşhisi cümleden başlat.
• Eşiklere ortalamayla değil, 75. yüzdelikle bak; üçünün aynı anda iyi olması gerekir.
• Saha verisini karar için, lab verisini teşhis ve regresyon için kullan.
• Search Console'da URL grubuna, PageSpeed Insights'ta tek URL'e bak; ikisini karıştırma.
• Kendi RUM ölçümünü kur; cihaz, şablon ve ziyaret tipine göre kes.
• Önceliği kırmızı metrik, yüksek trafikli şablon ve düşük emek/yüksek etki üzerinden belirle.
• İyileştirmeden sonra bütçe koy; ölçümü sürekli hâle getir.

Ölçmeyi doğru kurduğunda geri kalan kısım teknik ayrıntıya iner ve çözülebilir hâle gelir. Uygulama tarafını merak ediyorsan Next.js'te Core Web Vitals'ı yeşile çekmek yazısında somut adımları bulacaksın; sitenin mevcut durumunu birlikte ölçmek istersen SEO ve performans hizmetime göz atabilir ya da doğrudan bana yazabilirsin.