Core Web Vitals: Web Sitesi Hız Optimizasyonu Rehberi

Core Web Vitals optimizasyonu, tek bir hız puanını yükseltmekten daha somut bir iştir: sayfanın ana içeriği ne zaman görünür, kullanıcı etkileşimine ne kadar hızlı cevap verir ve ekran ne kadar sabit kalır? Önce bu soruların hangi sayfa ve cihazlarda sorun olduğunu belirleyin, sonra değişiklik yapın.

LCP, INP ve CLS için farklı teşhis soruları kurun

9 Ekim 2026 tarihinde kontrol edilen web.dev Web Vitals açıklamasında iyi deneyim hedefleri LCP için en fazla 2,5 saniye, INP için en fazla 200 milisaniye, CLS için en fazla 0,1 olarak verilir. Değerlendirme, mobil ve masaüstü ayrı olmak üzere sayfa yüklemelerinin 75. yüzdelik diliminde yapılır.

LCP ana içerik görünürlüğü, INP etkileşim yanıtı, CLS görsel kararlılıkla ilgilidir. Eski FID metriğini güncel INP yerine raporlamayın. Bu eşikler yerel bir testte sitenizin geçtiği veya aramada sıralamasının artacağı anlamına gelmez.

İyi eşik ile ölçülen sonuç aynı şey değildir

Resmî eşikler değerlendirme çerçevesidir; sitenin o eşikleri sağladığına dair kanıt değildir. Raporda metrik adı, sayfa türü, cihaz sınıfı, veri kaynağı ve dönem bulunmalıdır. Bir masaüstü laboratuvar koşusunun iyi sonucu bütün mobil ziyaretçilere genellenmez. Aynı şekilde saha verisi olmayan bir sayfa otomatik başarısız veya başarılı sayılmamalıdır.

Bir sayfanın ana içeriği kapak görseli olabilir; başka sayfada büyük başlık metni LCP adayı olabilir. Ekran genişliği ve içerik değiştiğinde aday da değişebilir. Bu nedenle “görselleri küçülttük, hız düzeldi” demeden gerçek öğeyi ve bekleme nedenini ölçün. Üç metriği tek bir puanda toplamak hangi işin önce yapılacağını gizleyebilir.

Saha ve laboratuvar ölçümünü aynı raporda ayrı tutun

Laboratuvar testi kontrollü cihaz ve ağ koşulunda tekrar edilebilir teşhis sağlar. Saha verisi gerçek ziyaretçilerin deneyimine dayanır. Yerel masaüstü tarayıcıdaki hızlı yükleme, yavaş mobil cihazların aynı sonucu aldığına dair kanıt değildir.

PageSpeed Insights veya Search Console’da saha verisi bulunmadığında bunu “veri yok” olarak kaydedin; başarısız veya başarılı sonuç uydurmayın. Kullanıcı ölçümü kurulacaksa veri kapsamı, örnekleme ve izin gereksinimini değerlendirin. Birden fazla ölçüm aracı aynı kaydı gönderiyorsa sahipliği netleştirin.

Karşılaştırma dosyasında tarayıcı sürümü, ekran boyutu, cihaz ölçeği, ağ/CPU yavaşlatması, önbellek durumu ve dış istek politikası yazılır. Önce ölçüm yavaş cihaz taklidiyle, sonra hızlı yerel bağlantıyla yapıldıysa fark doğrudan iyileştirme başarısı değildir. Birden fazla tekrarın medyanı ve aralığı tek en iyi değerden daha açıklayıcı olabilir; tekrarlar aynı koşulda yapılmalıdır.

Yerel sunucunun iş yükünü kontrol edin

Build veya geniş tarayıcı testleri çalışırken alınan ölçüm, boşta sunucuyla aynı koşulu taşımayabilir. Bu etki kesin neden olarak varsayılmaz; tekrar ölçümle araştırılır. Performance kaydı, sunucu yanıtı ve kaynak zamanları birlikte incelenir. Gerçek saha verisi olmadan yerel sonucu “mobil kullanıcıların tamamı hızlandı” şeklinde sunmayın.

LCP'yi dört zaman parçasına ayırın

Testte en büyük içerik öğesini belirleyin. Sorun sunucu yanıtı, görselin geç keşfedilmesi, dosya büyüklüğü veya render beklemesi olabilir. Her durumda bütün görselleri aynı anda yüklemek çözüm değildir; kritik öğeyle ekran dışı görsellerin ihtiyacı farklıdır.

Görselin boyutunu kullanım alanına uygun hazırlayın. Kritik içeriği gereksiz client çalışmasına bağlamayın. Font, stil ve üçüncü taraf isteklerin ana içeriğin görünmesine etkisini inceleyin. Değişikliği önce ilgili şablonda, sonra diğer sayfa türlerinde test edin.

Font ve görsel müdahalesi gerçek öğeye göre yapılmalı

Metin LCP'sinde fontun görünürlüğe etkisi, görsel LCP'sinde kaynağın keşfi ve çizilmesi ayrı incelenir. Bütün fontları veya bütün görselleri preload etmek gereksiz yarış yaratabilir. Ekran dışı içerik için gecikmeli yükleme uygun olabilirken kritik kapakta aynı tercih sorun oluşturabilir. Değişikliği yalnız ölçülen darboğazın bulunduğu bileşende sınırlı tutun.

web.dev LCP optimizasyon rehberi bu zaman parçalarını incelemek için resmî başvurudur. Kaynak süresi azalsa bile render gecikmesi baskınsa toplam sonuç beklenen kadar değişmeyebilir. Önce ve sonra aynı öğe, koşul ve zaman parçaları karşılaştırılır. Ölçülen farkın hangi müdahaleyle ilişkili olduğu açıklanamadığında kesin nedensel başarı iddiası yapılmaz.

INP için gerçek etkileşimin başlangıcını ve çizimini izleyin

Menü açma, filtre seçme, varyant değiştirme ve form doğrulama gibi görevler için tarayıcı performans kaydı alın. Uzun JavaScript işleri, çok sayıda DOM güncellemesi veya pahalı hesaplama yanıtı geciktirebilir. Yalnız ilk yükleme testi etkileşim sorununun tamamını göstermez.

İş yükünü azaltmak veya bölmek gerektiğinde işlevi koruyan bir çözüm seçin. Kullanıcıya doğru geri bildirim vermek önemlidir; butonu çalışmaz hâle getirerek iyi metrik elde etmeye çalışmayın. Düşük güçlü cihazda aynı görevi tekrar sınayın.

Filtreyi açma veya ürün seçme görevinde kullanıcı girdisinden sonraki görsel yanıta kadar olan süreci inceleyin. Uzun işlerin yeri, olay işleyicisinin maliyeti ve render güncellemeleri ayrı nedenler olabilir. İşlevi geciktiren hesaplamayı azaltmak, gereksiz render'ı önlemek veya işi uygun şekilde bölmek değerlendirilir. Yanıtı ölçmek için butonu devre dışı bırakmak kullanıcı görevini bozuyorsa geçerli çözüm değildir.

Etkileşim olmayan koşuda INP sonucu uydurmayın

İlk yükleme testi gerçek kullanıcı etkileşimi içermiyorsa INP'yi sıfır diye başarı olarak kaydetmeyin. Veri yokluğu ile iyi ölçüm farklıdır. Laboratuvar görevi seçildiyse hangi tıklama ve girişlerin uygulandığı belirtilir. Saha değerlendirmesinde gerçek ziyaretçi dağılımı ve veri kapsamı gerekir; tek sentetik görev bütün site deneyimini temsil etmez.

CLS kaynağını görsel kayıt ve boyutlarla doğrulayın

Temsili LCP incelemesi: Kapak dosyası hızlı gelmesine rağmen uzun bir istemci işi bittikten sonra görünüyorsa yalnız WebP kalitesini azaltmak asıl beklemeyi çözmeyebilir. Kaynak yüklemesi ile öğenin çizilmesi arasındaki süre araştırılır. Tersine görsel geç keşfediliyorsa dosya küçültme kadar yüklemenin ne zaman başladığı da önemlidir. Bu örnek ölçülmüş müşteri sonucu değildir; farklı nedenlerin farklı müdahale gerektirdiğini gösterir.

Performans değişikliğinden sonra görselin doğru kırpıldığını, alternatif metnin korunduğunu ve mobil metnin okunabildiğini kontrol edin. Daha küçük dosya yüzünden teknik şema okunamaz hâle geldiyse metrik hedefi içerik kalitesini bozmuş olabilir. Aynı şekilde font değişikliği başlıkları taşırıyor veya butonları kaydırıyorsa responsive kabul gerekir. Performans işi kullanıcı görevini koruyarak tamamlanır.

Görsel ölçülerini, reklam alanlarını, geç gelen banner’ları ve font değişimini inceleyin. Yer ayırmak sıçramayı azaltabilir; ancak gerçek reklam davranışı yalnız mock boş alanla doğrulanamaz. Kullanıcı etkileşiminden sonra açılan öğenin konumunu da değerlendirin.

Değişiklik kaydında önceki sorun, örnek URL, cihaz, test koşulu ve sonraki sonuç bulunmalıdır. Web sitesi performans çalışması kapsamına işlev regresyonunu dahil edin. Öncelik planı için teknik SEO kontrol listesi kullanılabilir. Bu projedeki responsive kontroller, gerçek ziyaretçi Core Web Vitals ölçümü olarak raporlanmaz.

Görselin genişlik ve yüksekliğini belirtmek yer ayrılmasına yardımcı olabilir; fakat geç gelen reklam, bildirim veya font değişimi ayrıca kayma yaratabilir. Sadece ilk ekranın sabit görünmesi yeterli değildir. İçerik aşağı kaydırıldığında ve etkileşim sonrası beklenen alanlar açıldığında davranışı da inceleyin. Gerçek reklam sunumu doğrulanmadıysa boş mock alanın sabitliğiyle reklam deneyiminin tamamını onaylamayın.

Son raporda önceki sorun, gerçek öğe, kaynak zamanları, müdahale kapsamı ve aynı koşuldaki tekrar sonuçları yer alır. İşlev ve responsive regresyonu da kontrol edilir. Teknik puan artışı arama sıralaması veya satış artışı garantisi değildir. Başarı, ölçülen sorunun hangi sınırlar içinde iyileştiğinin açık biçimde gösterilmesidir.