Sitemiz neden yavaş? Core Web Vitals, INP ve gerçek kullanıcı verisi

Site hızı tartışması çoğu zaman yanlış sayının etrafında dönüyor. Google'ın baktığı şey Lighthouse'un verdiği 0-100 puanı değil, sitenizi gerçekten ziyaret etmiş Chrome kullanıcılarından toplanan alan verisi. Üç metrik var: yükleme için LCP, tepkisellik için INP, görsel kararlılık için CLS. İyi kabul edilen eşikler sırasıyla 2,5 saniye, 200 milisaniye ve 0,1. Ölçüm ortalamayla değil 75. yüzdelikle yapılıyor, yani kullanıcılarınızın dörtte üçünün bu değerlerin altında kalması, üstelik üç metrikte birden kalması gerekiyor. Kendi makinenizde çıkan 95 puanın bununla ilgisi sınırlı.

Laboratuvar verisi ile alan verisi aynı şeyi ölçmüyor

Lighthouse bir laboratuvar testidir: tek cihaz, kısıtlanmış tek bağlantı, tek konum, tek yükleme. Kontrollü olması teşhis için değerli, temsil gücü için değil. Gerçek kullanıcılarınız arasında beş yıllık Android telefonlar da var, ofis fiberi de, metroda çeken üç çubuk da.

Alan verisi Chrome Kullanıcı Deneyimi Raporu'ndan (CrUX) geliyor. Veri seti günlük güncelleniyor ama her ölçüm son 28 günün kayan penceresi üzerinden hesaplanıyor, bu da tek günlük dalgalanmaların tabloyu bozmasını engelliyor. Yeterli trafiği olan sayfalar için URL düzeyinde veri var; olmayanlarda araç sessizce köken (origin) geneline düşüyor. PageSpeed Insights'ta "bu URL için yeterli gerçek kullanıcı verisi yok" uyarısını görüyorsanız, o ekranda okuduğunuz sayı o sayfanın değil, sitenin tamamının ortalamasıdır.

Aradaki fark metrik bazında da somut. INP laboratuvarda hiç ölçülemiyor, çünkü kullanıcının sayfayla ne zaman ve nasıl etkileşeceğini bir senaryo taklit edemez; Lighthouse onun yerine Toplam Engellenme Süresi'ni (TBT) vekil olarak gösterir. CLS'te de laboratuvar sadece açılış anındaki kaymaları görür, oysa alan verisi kullanıcı aşağı kaydırırken tembel yüklenen içeriğin yarattığı kaymaları da sayar. Kısacası laboratuvar aracı size nedeni söyler, kararı alan verisi verir.

Üç metrik, altı eşik

LCP 2,5 saniyenin altındaysa iyi, 4 saniyenin üstündeyse kötü. INP 200 milisaniyenin altındaysa iyi, 500'ün üstündeyse kötü. CLS 0,1'in altındaysa iyi, 0,25'in üstündeyse kötü. Aradaki bölge "geliştirilmeli" olarak işaretlenir ve geçmiş sayılmaz. Değerlendirme mobil ve masaüstü için ayrı ayrı yapılır.

INP, Mart 2024'te FID'in yerini aldı ve bu değişim çoğu sitenin karnesini sertleştirdi. FID yalnızca ilk etkileşimde tarayıcının olay işleyicisini çalıştırmaya başlamasına kadar geçen gecikmeyi ölçüyordu, yani işin en kolay kısmını. INP ise ziyaret boyunca gerçekleşen etkileşimlere bakıyor ve tıklamadan ekranda sonucun göründüğü kareye kadar geçen sürenin tamamını sayıyor. Kodunuzun etkileşime verdiği yanıtı gerçekten ölçen ilk metrik bu.

Takılınan yer neredeyse her zaman LCP

HTTP Archive'ın 2025 Web Almanac'ında Temmuz 2025 verisiyle çıkarılan tablo net: mobilde kökenlerin %48'i, masaüstünde %56'sı üç metrikten birden geçiyor. Tek tek bakınca mobilde CLS'i geçenler %81, INP'yi geçenler %77, LCP'yi geçenler ise %62. Yani başarısızlığın belirleyicisi büyük ölçüde tek bir metrik.

Bu, öncelik sorusunu sizin yerinize cevaplıyor. Sitenizin karnesi kırıksa ilk bakılacak yer yükleme tarafıdır, ve oradaki iyileştirme diğer ikisine dokunmadan da sizi geçer nota taşıyabilir.

LCP'yi dört parçaya bölmeden düzeltmeye çalışmayın

LCP tek bir olay değil, dört alt parçanın toplamı: ilk bayta kadar geçen süre (TTFB), LCP kaynağının yüklenmeye başlamasına kadar geçen gecikme, kaynağın kendisinin inme süresi, ve kaynak indikten sonra ekrana çizilene kadar geçen gecikme. Sağlıklı bir dağılımda TTFB ve kaynağın inme süresi toplamın yaklaşık %40'ar payını alır, aradaki iki gecikme ise %10'un altında kalır. Yani süre HTML'i ve asıl görseli indirmeye gitmeli, beklemeye değil.

Ölçtüğünüzde gecikmelerin şiştiğini görürseniz sebepler bellidir. Mobil sayfaların %76'sında, masaüstünde %85,3'ünde LCP öğesi bir görsel; dolayısıyla o görselin HTML'in ilk hâlinde keşfedilebilir olması gerekir. JavaScript'in sonradan enjekte ettiği ya da CSS arka planı olarak tanımlanan bir hero görseli tarayıcının önden yükleme tarayıcısından kaçar. Daha kötüsü de var: Almanac'a göre sayfaların yaklaşık %16-17'si LCP görselini tembel yüklüyor, yani ekranda ilk görünmesi gereken şeyi bilerek geciktiriyor. fetchpriority="high" kullanımı ise LCP görseli olan mobil sayfaların %17'sinde, 2024'teki %15'ten yukarı ama hâlâ düşük.

Sıra şu: önce LCP kaynağını keşfedilebilir yapın ve tembel yüklemeyi kaldırın, sonra çizimi engelleyen CSS ve JavaScript'i temizleyin, sonra görselin kendisini küçültün (modern format, doğru boyut, CDN), en son TTFB'ye girin. Sunucu tarafını ilk gün optimize etmek genelde en pahalı ve en az getirili adımdır.

INP'nin sorunu bağlantı değil, ana iş parçacığı

Bir etkileşim üç aşamadan oluşur: giriş gecikmesi (kullanıcı tıkladı ama ana iş parçacığı başka bir işle meşgul), işleme süresi (sizin olay işleyicileriniz çalışıyor), ve sunum gecikmesi (tarayıcı yeni kareyi çizene kadar geçen süre). Üçünün toplamı 200 milisaniyeyi aşıyorsa kullanıcı arayüzü takılmış hissettirir.

Suçlular tekrar eder. Sayfa açılışında değerlendirilen büyük JavaScript paketleri uzun görevler yaratır ve o sırada gelen her tıklama kuyrukta bekler. Stil okuyup hemen ardından yazan kod tarayıcıyı zorla senkron yerleşim hesabına sokar. Şişmiş DOM her karede yapılan işi büyütür. Çözümler de aynı ölçüde bilinen: olay işleyicisindeki işi parçalara bölüp ana iş parçacığına söz hakkı verin, kritik olmayan güncellemeyi ilk çizimden sonraya erteleyin, DOM okuma ve yazmalarını gruplayın, ekran dışı bölümler için content-visibility kullanın.

Bunun bir donanım tarafı da var. INP ağ hızıyla değil işlemci gücüyle sınırlanır, o yüzden geliştirici dizüstünde hiç görünmeyen bir sorun orta segment bir Android telefonda anında ortaya çıkar. Test cihazınızı ekibin en iyi telefonuna göre seçmeyin.

CLS en ucuz kazanç ama en çok ihmal edilen

Kayma kaynakları neredeyse hep aynı listeden çıkıyor: boyutu belirtilmemiş görseller, yer ayrılmamış reklam ve gömülü içerik alanları, sonradan enjekte edilen bileşenler, ve yazı tipi değişiminde metnin yeniden akması. Almanac'ın verisi ihmalin boyutunu gösteriyor: mobil sayfaların %62'sinde en az bir görselde açık boyut tanımı yok, %87'si web fontu kullanıyor, %40'ında düzeni tetikleyen ve derlenmemiş animasyonlar var.

Düzeltmeler birkaç saatlik iş. Görsellere width ve height verin ya da CSS'te aspect-ratio tanımlayın. Reklam ve iframe alanlarına min-height ile önceden yer ayırın. Yazı tiplerini önden yükleyin ve font-display davranışını bilinçli seçin. Animasyonda top ve left yerine transform kullanın, çünkü ikincisi yerleşimi tetiklemez.

Aynı başlık altında sık atlanan bir kazanç daha var: geri/ileri önbelleği (bfcache). Sayfanız uygunsa tarayıcı geri tuşunda onu bellekten anında geri yükler ve o gezinme pratikte ölçümsüz hızlanır. Engelleyicileri kontrol edin. Almanac'a göre unload işleyicisi hâlâ masaüstü sayfalarının %11'inde, mobilde %10'unda duruyor; Cache-Control: no-store kullanımı ise 2024'teki %21'den %23'e çıkmış. İkisi de çoğu sitede alışkanlıktan kalma, ihtiyaçtan değil.

Sıralamadaki yerini abartmayın

Google'ın kendi dokümantasyonu iki cümleyi yan yana koyuyor: "Tek bir sinyal yoktur, çekirdek sıralama sistemlerimiz genel sayfa deneyimiyle uyumlu çeşitli sinyallere bakar" ve "Core Web Vitals sıralama sistemlerimiz tarafından kullanılır". Aynı sayfa şunu da açıkça yazıyor: sayfa deneyimi zayıf olsa bile Google en alakalı içeriği göstermeyi hedefler.

Buradan çıkan pratik okuma şu. Alaka düzeyi zayıf bir sayfayı hızlandırmak onu ilk sayfaya taşımaz. Ama rekabetin dengeli olduğu bir sorguda, iki sayfanın içerik kalitesi birbirine yakınken performans farkı sıralamayı belirleyebilir. Performansı içeriğin yerine değil, içeriğin üstüne koyun.

İş tarafındaki karşılığı ölçülmüş durumda

Rakuten 24 tek bir açılış sayfasını Core Web Vitals için optimize edip bir ay boyunca trafiği yarı yarıya bölerek A/B testine soktu. İki sürüm arasındaki tek fark performanstı. Sonuç: ziyaretçi başına gelirde %53,37, dönüşüm oranında %33,13 artış. Vodafone İtalya bir açılış sayfasında LCP'yi %31 iyileştirdi ve toplam satışta %8 artış bildirdi. iCook CLS'i %15 iyileştirince reklam gelirinde %10 artış gördü.

Bu sayıları teklife koyarken dikkatli olun. Hepsi belirli bir sayfada, belirli bir sektörde, belirli bir başlangıç noktasından ölçüldü. Zaten hızlı bir sitede aynı oranları göremezsiniz. Doğru kullanım şekli, "hız satış getirir" genellemesi yerine kendi sitenizde aynı yöntemi kurmak: tek sayfa, tek değişiklik, bölünmüş trafik, ölçülen sonuç.

Ölçümü dağıtım hattının içine yerleştirin

Üç katmanı birlikte kurmak gerekiyor. Gerçek kullanıcı ölçümü için Google'ın web-vitals kütüphanesini siteye ekleyip metrikleri kendi analitiğinize gönderin; böylece CrUX'un 28 günlük penceresini beklemeden kendi p75 değerinizi görürsünüz. Regresyona karşı hatta Lighthouse çalıştırın ve paket boyutu için bir bütçe tanımlayın, eşik aşılınca yapı başarısız olsun. Uzun vadeli takip içinse Search Console'un Core Web Vitals raporu yeterli, çünkü Google'ın gördüğü veriyi gösterir.

Buradaki gecikmeyi baştan bilin. Bir düzeltmeyi yayına aldığınızda kendi ölçümünüz birkaç gün içinde değişir, CrUX tabanlı raporlar ise kayan pencere dolana kadar tam yansıtmaz. İki hafta sonra Search Console hâlâ kırmızı diye düzeltmeyi geri almayın. Bu tür kontrolleri elle değil hattın içinde çalıştırmanın nasıl kurulduğunu küçük ekipler için CI/CD yazımızda anlattık.

Bu haftaya sığan ilk adım

Dört iş yeterli. Bir: en çok trafik alan beş sayfanızı PageSpeed Insights'a girin ve yalnızca üstteki alan verisi bölümünü okuyun, laboratuvar puanını görmezden gelin. İki: her sayfada LCP öğesinin ne olduğunu tespit edin, tembel yüklenmediğinden ve HTML'de keşfedilebilir olduğundan emin olun. Üç: ekranın üst kısmındaki tüm görsellere açık boyut ya da en boy oranı verin. Dört: web-vitals kütüphanesini ekleyin ki bir sonraki tartışma tahminle değil kendi verinizle yapılsın.

Performans sorunlarının bir kısmı tek tek düzeltmelerle kapanmıyor, çünkü kaynağı mimaride ya da birikmiş yükte oluyor. O eşiğe geldiyseniz karar başka bir yere kayar; ölçmeyi ve önceliklendirmeyi teknik borç yazımızda, sıfırdan yazma ile kademeli yenileme arasındaki seçimi ise eski yazılımı yenilemek mi, sıfırdan yazmak mı yazımızda ele aldık.