Bir hız testinde yüksek puan almak, ziyaretçilerin tamamının hızlı bir site gördüğü anlamına gelmez. Farklı cihazlar, ağlar ve kullanıcı etkileşimleri deneyimi değiştirebilir. Core Web Vitals, bu deneyimin belirli yönlerini ölçmek için kullanılır; SEO çalışmasında da teknik sorunları önceliklendirmeye yardımcı olabilir.
Bu rehberdeki metrikler ve eşikler, 10 Ekim 2026 tarihinde kontrol edilen Google ve web.dev belgelerine dayanır. Bir teknoloji blogunu örnek alacağız. Burada herhangi bir sitenin ölçülmüş hız puanı veya tamamlanmış performans testi sunulmuyor.
Güncel üç metrik neyi ölçüyor?
Web Vitals belgesi, LCP, INP ve CLS’yi temel metrikler olarak listeler. İyi deneyim için kullanılan eşikler aşağıdadır. Değerlendirmede ziyaretlerin yüzde 75’lik dilimi dikkate alınır; mobil ve masaüstü ayrı ele alınır.
| Metrik | Ölçtüğü yön | İyi eşik |
|---|---|---|
| LCP | Büyük ana içeriğin görünmesi | 2,5 saniye veya daha az |
| INP | 200 milisaniye veya daha az | |
| CLS | 0,1 veya daha az |
Bu tablo, tek bir testte bütün sayfaların aynı sonucu vermesini beklememiz gerektiği anlamına gelmez. Ölçüm koşullarını ve verinin hangi kullanıcı grubunu temsil ettiğini bilmek gerekir. Eski rehberlerde karşılaşılan FID yerine güncel temel metrik setinde INP bulunur.
SEO açısından ne beklemeli?
Google Search Central, Core Web Vitals verilerinin sıralama sistemlerinde kullanıldığını açıklar. Bununla birlikte iyi değerler, aramada üst sıraları garanti etmez. Kullanıcının sorusuna cevap vermeyen bir sayfa, yalnızca hızlı açıldığı için kapsamlı ve ilgili bir kaynağa dönüşmez.
Örnek blogumuzda bu nedenle iki çalışma hattı kurabiliriz: içeriğin faydasını geliştirmek ve kullanıcıların içeriğe erişmesini zorlaştıran teknik sorunları gidermek. Bunlardan birini diğerinin yerine geçirmek yerine, etkisi yüksek engelleri birlikte ele almak daha anlamlıdır.
Saha ve laboratuvar verisini ayırın
Saha verisi gerçek ziyaretlerdeki deneyimi yansıtır; laboratuvar testi ise belirli koşullarda sorunu yeniden üretmeye yardımcı olur. Bu iki görünümün aynı sayı olması beklenmemelidir. Yeterli veri bulunmaması da sayfanın kesinlikle iyi veya kötü olduğu anlamına gelmez.
Örnek süreçte önce kullanıcıların zorlandığı sayfa türünü seçeriz: yazı, kategori veya arama sonucu. Ardından aynı şablondan birkaç URL’yi inceleriz. Tek bir hızlı ana sayfayı, bütün sitenin iyi çalıştığının kanıtı saymayız.
LCP için ana içeriğe giden yolu inceleyin
Yazı kapağının ana içerik öğesi olduğunu varsayalım. Görselin dosyası, sayfada ne zaman keşfedildiği ve onu göstermek için gereken kaynaklar birlikte değerlendirilmelidir. Buradaki öneri, önce hangi öğenin LCP olarak ölçüldüğünü bulmaktır; rastgele bütün görselleri küçültmekle başlamayız.
Örnek blog için gereksiz büyük kapak dosyalarını, yanlış kaynak seçimini ve ilk ekrandaki görselin ertelenmesini inceleyebiliriz. Responsive görseller rehberimiz, srcset ve sizes kararlarının yerleşimle nasıl ilişkilendirileceğini anlatır.
Bu değişikliklerden sonra yalnızca dosya boyutunu değil, sayfanın ne zaman kullanılabilir göründüğünü de kontrol ederiz. Kapağı çok agresif sıkıştırıp kod ekran görüntüsünü okunmaz hâle getirmek, performans ile içerik kalitesi arasındaki dengeyi bozabilir.
INP için gerçek etkileşimi bulun
INP optimizasyon rehberi, etkileşim gecikmesini giriş beklemesi, olay işleme ve sonraki görsel güncelleme gibi parçalar üzerinden ele alır. Uzun görevler ve yoğun ana iş parçacığı çalışması, kullanıcının tıklamasına verilen yanıtı geciktirebilir.
Örnek kategorimizde filtre düğmesi ağır çalışıyorsa önce aynı işlemi yeniden üretiriz. Binlerce kartın tek seferde güncellenmesi mi, üçüncü taraf kodu mu, yoksa başka bir görev mi gecikmeye neden oluyor? Kaynağı belirlemeden bütün eklentileri kaldırmak veya rastgele önbellek seçeneklerini açmak kontrollü bir teşhis değildir.
Küçük bir iyileştirme planında önce sorunlu etkileşimi kaydeder, sonra tek bir değişiklik yaparız. Aynı görev üzerinden tekrar ölçmek, hangi düzenlemenin gerçekten yararlı olduğunu anlamamızı kolaylaştırır.
CLS için sonradan hareket eden alanlara bakın
Örnek blogda görsel yüklenince paragrafın aşağı kayması veya sonradan açılan bir bandın içeriği itmesi, okuyucunun takip ettiği satırı kaybetmesine neden olabilir. Görsel ve yerleştirilen içerik için yer ayırma kararlarını incelemek, böyle bir sorunun başlangıç noktasıdır.
Yalnızca sayfanın ilk görüntüsüne bakmayın. Yazıyı aşağı kaydırın, geç yüklenen içerikleri gözlemleyin ve farklı bağlantı hızlarında davranışı kontrol edin. Tasarımın yükleme tamamlandıktan sonraki düzgün hâli, kullanıcının o noktaya kadar yaşadığı hareketi göstermez.
Önceliklendirme nasıl yapılmalı?
Örnek iş listemizde her sorun için etkilenen şablonu, kullanıcı görevini, gözlenen belirtiyi ve planlanan değişikliği yazarız. Çok ziyaret alan yazı şablonundaki ortak sorunu çözmek, az kullanılan tek bir sayfanın puanını yükseltmekten daha geniş fayda sağlayabilir.
Düzenleme sonrasında laboratuvar kontrolü yapıp saha verisinin zaman içinde nasıl değiştiğini izleyin. Başarıyı yalnızca renkli bir puan kutusuyla değil, daha hızlı okuma, daha akıcı filtreleme ve daha az yerleşim kayması gibi gerçek davranışlarla değerlendirin.
