Geçen ay bir müşterimiz gururla Lighthouse ekran görüntüsü gönderdi: 96 puan, yeşil daireler, bayram havası. Aynı hafta o sitenin gerçek kullanıcı verisine baktık: mobilde LCP 4,1 saniye, INP kırmızıda. İkisi de doğruydu — çünkü ikisi farklı şeyleri ölçüyordu. Web performansı konusunda sahada gördüğüm en büyük kafa karışıklığı bu: metriklerin ne dediğini tam bilmeden puan kovalamak. Bu yazıda Google'ın Core Web Vitals üçlüsünü — LCP, INP, CLS — pazarlama diline kaçmadan, kendi projelerimizden örneklerle anlatmak istiyorum.
Kısa bir güncelleme notu: INP'nin FID'in yerini almasıyla üçlü artık son halini aldı. FID sadece ilk etkileşimin gecikmesine bakıyordu ve fazlasıyla iyimserdi; INP çok daha acımasız, dolayısıyla çok daha dürüst bir metrik. Eski FID raporlarınızla övünmeyi bırakma vakti.
LCP: kullanıcı "site açıldı" dediği an
LCP (Largest Contentful Paint), görünür alandaki en büyük içerik parçasının — çoğunlukla kapak görseli veya ana başlık — ekrana geldiği anı ölçer. Hedef 2,5 saniyenin altı. Kullanıcının kafasındaki "açıldı/açılmadı" yargısıyla en iyi örtüşen metrik bu; o yüzden üçlünün en kıymetlisi bence.
Klasik katiller hep aynı: optimizasyonsuz dev görsel (4 MB'lık banner fotoğrafını mobile göndermek hâlâ inanılmaz yaygın), render'ı bloklayan CSS ve JavaScript, bir de yavaş sunucu yanıtı. TTFB kötüyse — yani HTML'in ilk baytı geç geliyorsa — sonrasında ne yaparsanız yapın geç kalmışsınız demektir.
TTFB tarafında ilaç bellidir: HTML çıktısını önbellekleyin (anonim kullanıcı için tam sayfa cache çoğu sitede mümkündür), sayfa başına çalışan sorgu sayısını tek haneye indirin, içeriği kullanıcıya coğrafi olarak yaklaştırın. Bir müşterimizde tek bir değişiklik — kategori sayfalarının 5 dakikalık cache'e alınması — TTFB'yi 900 milisaniyeden 120'ye indirdi. Bazen kahramanlık değil, tembellik iyidir: hazır cevabı saklayıp tekrar tekrar vermek gibi.
Reçetemiz şöyle işliyor: kritik görseli WebP veya AVIF'e çevirip fetchpriority="high" ile öne alıyoruz, ekran dışında kalan her şeyi lazy yüklüyoruz, HTML'i mümkünse CDN kenarından servis ediyoruz. Bir e-ticaret müşterimizde sadece görsel diyeti ve öncelik ayarıyla LCP 3,8'den 1,9 saniyeye indi; başka hiçbir şeye dokunmadık.
INP: tıklamadan sonra geçen o sinir bozucu boşluk
INP (Interaction to Next Paint), sayfanın ömrü boyunca gerçekleşen bütün etkileşimlerin gecikmesine bakar ve kötü olanları saklamanıza izin vermez. Hedef 200 milisaniyenin altı. Kullanıcı şikâyeti olarak şöyle duyarsınız: "Sayfa açıldı ama menüye bastım, hiçbir şey olmadı." Bu cümle bire bir INP problemidir.
Suçlu neredeyse her zaman aynı yerde saklanır: ana thread'i kilitleyen uzun JavaScript görevleri. Ağır hydration, sayfaya doluşmuş analitik ve pazarlama betikleri, her tıklamada koca bir listeyi yeniden hesaplayan event handler'lar... Tarayıcı o sırada meşgul olduğu için kullanıcının tıklaması kuyrukta bekler, ekran donmuş gibi görünür.
Çözüm de o yüzden JavaScript tarafındadır: uzun görevleri küçük parçalara bölmek, üçüncü parti betikleri ertelemek veya tamamen sorgulamak (o dört ayrı analytics aracının dördü de gerçekten gerekli mi?), kalabalık listelerde event delegation kullanmak. Bir müşterimizde INP'yi düzelten şey tek satırlık bir şey değildi; on beş küçük kararın toplamıydı. Bu metrik maalesef böyle — bıçakla değil törpüyle iyileşiyor.
Teşhis için Chrome geliştirici araçlarındaki uzun görev (long task) işaretleri yol gösterir: ana thread'de 50 milisaniyeden uzun süren her blok, bir etkileşimi geciktirme adayıdır. Gerçek kullanıcı tarafında ise web-vitals kütüphanesiyle INP değerlerini kendi analitiğinize akıtın; hangi sayfada, hangi elemanda takılma yaşandığını görmeden yapılan her optimizasyon, karanlıkta atış talimidir.
CLS: sayfa zıplayınca kaybolan güven
Hepimiz yaşadık: tam "Satın Al" düğmesine basacakken üstten bir banner yüklenir, sayfa kayar, "İptal Et"e basarsınız. CLS (Cumulative Layout Shift) tam bu zıplamayı ölçer; hedef 0,1'in altı.
Sebepler bellidir: boyutu belirtilmemiş görseller, sonradan yüklenip yer kapan reklam ve banner alanları, bir de web fontu yüklendiğinde metnin yeniden akması. Çare de sebepler kadar nettir: her görsele width ve height verin (tarayıcı yerini önceden ayırsın), dinamik içerik alanlarına min-height ile rezervasyon yapın, fontlarda font-display: swap kullanıp fallback fontu boyutça asıl fonta yakın seçin. CLS üç metrik içinde düzeltmesi en ucuz olanıdır; genellikle birkaç günlük iştir ve etkisi kalıcıdır.
Sahadan bir örnek: bir haber sitesi müşterimizde CLS'nin ana kaynağı, başlıklarda kullanılan özel fontun geç yüklenip metni yeniden akıtmasıydı. Fallback fontu, harf genişliği asıl fonta yakın bir alternatifle değiştirmek — evet, sadece bu — CLS'yi 0,24'ten 0,05'e indirdi. Bazen çözüm bir satırlık CSS'tir; pahalı olan, sorunu doğru teşhis etmektir.
Lighthouse'un söylediği ile Google'ın baktığı aynı şey değil
Baştaki hikâyenin düğümü burada çözülüyor. Lighthouse bir laboratuvar aracıdır: sizin makinenizde, belirli bir simülasyonla, tek bir çalıştırmanın fotoğrafını çeker. Google ise sıralama sinyali olarak gerçek kullanıcı verisine bakar — CrUX, yani Chrome kullanıcılarından toplanan saha verisi. Sizin fiber bağlantılı geliştirici makinenizde 96 puan alan site, Anadolu'da orta segment bir Android telefonda ve 4G'de bambaşka bir hikâye anlatır.
Doğru kullanım ikisini birlikte okumaktır: laboratuvar teşhis koyar (neyi düzelteceğinizi söyler), saha verisi doğrular (düzelttiğinizin gerçek kullanıcıya yansıyıp yansımadığını gösterir). Search Console'daki Core Web Vitals raporu ve PageSpeed Insights'ın üst kısmındaki saha bölümü, bakmanız gereken asıl yerlerdir. Lighthouse puanını KPI yapan ekipler, aynaya bakıp kilo verdiğini sanan adama benzer.
Bir şey daha: bu üç metrik, dönüşümle korelasyonu defalarca kanıtlanmış nadir teknik metriklerdendir. Yani buradaki iyileştirme "teknik borç ödeme" değil, doğrudan ciroya konuşan bir yatırımdır. Yöneticinize bütçe anlatırken bu cümleyi kullanabilirsiniz, bizden hediye olsun.
Pratik bir rutin önerisiyle kapatayım: ayda bir Search Console'un Core Web Vitals raporunu açın, kötüleşen URL gruplarını not edin, o sayfaların hem saha hem laboratuvar verisine bakıp düzeltmeyi yapın ve yaklaşık bir ay sonra (CrUX verisi 28 günlük pencereyle döner, sabır gerekir) sonucu doğrulayın. Bu döngüyü işleten ekipler metrik krizini hiç yaşamıyor; çünkü kötüleşme daha trend halindeyken yakalanıyor, manşet olmadan.
Baştaki müşterimizin hikâyesi de tatlıya bağlandı bu arada: saha verisine odaklanıp üç aylık bir iyileştirme planı çıkardık; LCP hedefin altına indi, mobil dönüşüm oranı ölçülebilir şekilde kıpırdadı. Lighthouse puanı mı? 96'dan 94'e düştü, kimsenin umurunda değil. Kendi sitenizin saha verisini birlikte okumak isterseniz bir analiz randevusu alın; ilk bakış bizden.