Ücretsiz Araç · Sayfa hızı
Core Web Vitals Testi
Sayfanızın gerçek kullanıcılardaki LCP, INP ve CLS değerlerini (Chrome kullanıcı deneyimi raporu, son 28 gün) ve Lighthouse laboratuvar ölçümünü tek ekranda görün; hangi iyileştirmenin ne kadar kazandıracağını öğrenin.
Metrikler ve eşikler
Google, bir sayfanın deneyimini ziyaretlerin 75. yüzdelik değerine (p75) göre değerlendirir: ziyaretlerin en az %75’i “iyi” eşiğindeyse metrik iyidir. Eşikler Google’ın web.dev belgelerindeki değerlerdir.
| Kısaltma | Metrik | Neyi ölçer? | İyi | İyileştirilmeli | Zayıf | Örnek |
|---|---|---|---|---|---|---|
| LCP | Largest Contentful Paint | Sayfanın ana içeriğinin (en büyük görsel ya da metin bloğu) ne zaman göründüğü. | ≤ 2,5 sn | 2,5–4 sn | > 4 sn | Nasıl düzeltilir? ↓ |
| INP | Interaction to Next Paint | Tıklama, dokunma ve tuş basımlarına sayfanın ne kadar hızlı görsel yanıt verdiği (Mart 2024’te FID’nin yerini aldı). | ≤ 200 ms | 200–500 ms | > 500 ms | Nasıl düzeltilir? ↓ |
| CLS | Cumulative Layout Shift | Sayfa yüklenirken ve kullanılırken içeriğin beklenmedik biçimde ne kadar kaydığı. | ≤ 0,1 | 0,1–0,25 | > 0,25 | Nasıl düzeltilir? ↓ |
| FCP | First Contentful Paint | İlk metin ya da görselin ekrana çizildiği an (Core Web Vitals’a dahil değil, teşhis içindir). | ≤ 1,8 sn | 1,8–3 sn | > 3 sn | Nasıl düzeltilir? ↓ |
| TTFB | Time to First Byte | Sunucunun ilk baytı gönderme süresi (teşhis metriği). | ≤ 0,8 sn | 0,8–1,8 sn | > 1,8 sn | Nasıl düzeltilir? ↓ |
LCP, INP ve CLS sorunları nasıl düzeltilir? Örnek senaryolar
Her metrik için önce kısa cevabı, ardından sorunun ziyaretçiye nasıl göründüğünü (solda) ve düzeltilmiş hâlini (sağda) görüyorsunuz; önizlemelerin altındaki ince çizgi geçen süreyi gösterir. Ölçüm sonucunda sorunlu çıkan her metrik ve bulgu için aynı açıklamalar sonuçların içinde de yer alır.
- LCP nasıl düzeltilir?
- INP nasıl düzeltilir?
- CLS nasıl düzeltilir?
- FCP nasıl düzeltilir?
- TTFB nasıl düzeltilir?
LCP nasıl düzeltilir?
Belirti: Ana içerik geç görünüyor
LCP (Largest Contentful Paint), sayfadaki en büyük görselin ya da metin bloğunun ekrana gelme süresidir. Gerçek ziyaretlerin %75’inde 2,5 saniye veya altındaysa iyi, 4 saniyenin üzerindeyse zayıf sayılır. LCP’yi düzeltmek için ana görseli küçültüp öncelikli yükleyin, sunucu yanıtını hızlandırın ve çizimi engelleyen CSS/JavaScript dosyalarını azaltın.
LCP yüksekse ziyaretçi ne yaşar?
Ziyaretçi sayfayı açıyor; menü ve başlık geliyor ama sayfanın asıl görseli ya da büyük başlığı bir süre boş kutu olarak bekliyor. 4 saniyeyi geçen bekleme, sayfanın “yavaş” bulunmasına ve geri dönülmesine yol açar.
LCP neden yüksek olur?
Çoğunlukla büyük ve sıkıştırılmamış ana görsel, yavaş sunucu yanıtı, ana görselin geç keşfedilmesi (tembel yükleme, CSS arka planı) ve sayfanın başındaki engelleyen CSS/JavaScript dosyaları.
Adım adım çözüm
- Ana görseli küçültün ve WebP ya da AVIF formatına çevirin; ekranda göründüğü boyuttan büyük göndermeyin.
- Ana görsele
fetchpriority="high"ekleyin, onaloading="lazy"vermeyin. - Görseli HTML’de doğrudan
<img>etiketiyle verin; CSS arka planı ya da JavaScript ile sonradan eklemeyin. - Sunucu yanıtını hızlandırın (sayfa önbelleği, CDN) ve sayfanın başındaki engelleyen CSS/JavaScript’i azaltın.
INP nasıl düzeltilir?
Belirti: Dokunuşlara geç yanıt veriliyor
INP (Interaction to Next Paint), ziyaretçinin tıklama, dokunma ve tuş basımlarına sayfanın görsel olarak ne kadar sürede yanıt verdiğini ölçer; Mart 2024’te FID’nin yerini almıştır. 200 milisaniye veya altı iyi, 500 milisaniyenin üzeri zayıftır. INP’yi düzeltmek için uzun JavaScript görevlerini bölün, gereksiz üçüncü taraf kodlarını kaldırın ve tıklamada önce görsel yanıt verin.
INP yüksekse ziyaretçi ne yaşar?
Ziyaretçi “Sepete ekle”ye dokunuyor ama ekran yarım saniye boyunca donuk kalıyor. Dokunuşun algılanıp algılanmadığını anlamıyor; tekrar dokunuyor ya da vazgeçiyor.
INP neden yüksek olur?
Çoğunlukla telefonun işlemcisini meşgul eden ağır JavaScript, reklam ve analitik gibi üçüncü taraf kodları, tek seferde çok iş yapan tıklama işleyicileri ve çok kalabalık bir sayfa yapısı (DOM).
Adım adım çözüm
- Tıklamada önce görsel bir yanıt verin (buton rengi, yükleniyor işareti); ağır işi bunun ardından yapın.
- Uzun süren JavaScript görevlerini küçük parçalara bölün; tarayıcı aralarda dokunuşlara yanıt verebilsin.
- Kullanılmayan scriptleri ve gereksiz üçüncü taraf kodlarını kaldırın, kalanları sayfa yüklendikten sonra başlatın.
- Sayfadaki öğe sayısını azaltın: uzun listeleri sayfalayın, gizli menülerin içeriğini gerektiğinde oluşturun.
CLS nasıl düzeltilir?
Belirti: İçerik yerinden kayıyor
CLS (Cumulative Layout Shift), sayfa yüklenirken ve kullanılırken içeriğin beklenmedik biçimde ne kadar kaydığını gösteren bir puandır. 0,1 veya altı iyi, 0,25’in üzeri zayıftır. CLS’yi düzeltmek için görsellere genişlik ve yükseklik verin, reklam ve banner alanlarını baştan ayırın, içeriği sonradan iten öğeler eklemeyin.
CLS yüksekse ziyaretçi ne yaşar?
Ziyaretçi bir butona dokunmak üzereyken üstte bir reklam ya da görsel yükleniyor; içerik aşağı kayıyor ve parmağı başka bir şeye, çoğu zaman reklama basıyor. Okunan metnin kayması da aynı rahatsızlığı yaratır.
CLS neden yüksek olur?
Çoğunlukla genişliği ve yüksekliği belirtilmemiş görseller, sonradan eklenen reklam, banner ya da çerez uyarıları ve geç inen web fontlarının metni yeniden dizmesi.
Adım adım çözüm
- Her görsel ve videoya
widthveheightyazın ya da CSS’teaspect-ratioverin. - Reklam, banner ve gömülü içerikler için alanı baştan ayırın: içerik geldiğinde dolacak, sabit yükseklikte bir kutu.
- Çerez uyarısı, duyuru şeridi gibi öğeleri içeriği iterek değil, ekranın altına sabitlenmiş olarak gösterin.
- Web fontlarında ölçüleri uyumlu bir yedek font kullanın; animasyonlarda
top/leftyerinetransformkullanın.
FCP nasıl düzeltilir?
Belirti: Ekran uzun süre boş kalıyor
FCP (First Contentful Paint), sayfayı açan ziyaretçinin ekranda ilk metni ya da görseli gördüğü andır. 1,8 saniye veya altı iyi, 3 saniyenin üzeri zayıftır; Core Web Vitals’a dahil değildir ama yavaş bir LCP’nin ilk işaretidir. FCP’yi düzeltmek için sunucu yanıtını hızlandırın ve sayfanın başındaki engelleyen CSS/JavaScript dosyalarını azaltın.
FCP yüksekse ziyaretçi ne yaşar?
Ziyaretçi adresi açıyor ve birkaç saniye boyunca beyaz bir ekrana bakıyor; sayfanın açılıp açılmadığından emin olamıyor. Bu süre uzadıkça sayfayı terk edenler artar.
FCP neden yüksek olur?
Çoğunlukla yavaş sunucu yanıtı, sayfanın başında yüklenen ve çizimi engelleyen CSS/JavaScript dosyaları, metni gizleyen web fontları.
Adım adım çözüm
- Sunucu yanıt süresini kısaltın (sayfa önbelleği, CDN).
- İlk ekran için gereken küçük CSS’i HTML’in içine koyun, geri kalanını sonradan yükleyin.
- JavaScript dosyalarına
deferekleyin; kullanılmayan eklenti ve kütüphaneleri kaldırın. - Web fontlarında
font-display: swapkullanın: metin, font inmeden de görünsün.
TTFB nasıl düzeltilir?
Belirti: Sunucu geç yanıt veriyor
TTFB (Time to First Byte), tarayıcının sayfayı istemesiyle sunucudan ilk baytın gelmesi arasında geçen süredir. 0,8 saniye veya altı iyi, 1,8 saniyenin üzeri zayıftır; bu bekleme FCP ve LCP’ye doğrudan eklenir. TTFB’yi düzeltmek için sayfa önbelleği ve CDN kullanın, yavaş veritabanı sorgularını ve yönlendirme zincirlerini azaltın.
TTFB yüksekse ziyaretçi ne yaşar?
Tarayıcı sayfayı istiyor ama sunucu yanıtın ilk baytını göndermeden önce uzun süre “düşünüyor”. Bu bekleme ekranda hiçbir şey olmadan geçer ve LCP ile FCP’nin hepsine eklenir.
TTFB neden yüksek olur?
Çoğunlukla her ziyarette yeniden üretilen (önbelleksiz) sayfalar, yavaş veritabanı sorguları, ağır eklentiler, ziyaretçiye uzak sunucular ve yönlendirme zincirleri.
Adım adım çözüm
- Sayfa önbelleği kullanın: sayfa her ziyarette yeniden üretilmesin (WordPress’te bir önbellek eklentisi yeterlidir).
- Yavaş veritabanı sorgularını ve gereksiz eklentileri azaltın; barındırma paketiniz yetersizse yükseltin.
- Ziyaretçilerinize yakın sunuculardan yayın yapan bir CDN kullanın.
- Yönlendirme zincirlerini kaldırın: linkler doğrudan son adrese gitsin (http → https → www yerine tek adım).
Saha verisi ve laboratuvar verisi
Saha verisi (Chrome UX Report) gerçek ziyaretçilerin son 28 gündeki deneyimidir ve Google’ın kullandığı veridir; yeterli trafik yoksa oluşmaz. Laboratuvar verisi (Lighthouse) tek bir simüle yüklemedir: sorunun nerede olduğunu gösterir ve düzeltmeyi hemen denemenizi sağlar, ama INP gibi etkileşim metriklerini ölçemez (yerine Total Blocking Time kullanılır).
Sık sorulan sorular
Saha verisi ile laboratuvar verisi neden farklı?
Saha verisi (CrUX), sayfanızı gerçekten açan Chrome kullanıcılarının son 28 gündeki deneyimidir: farklı cihazlar, bağlantılar ve etkileşimler içerir; Google’ın sayfa deneyimi değerlendirmesinde kullandığı veri budur. Laboratuvar verisi ise tek bir simüle cihaz ve bağlantıyla (mobilde yavaş 4G, orta seviye telefon) yapılan tek bir yüklemedir; sorunları bulmak ve düzeltmeyi hemen denemek içindir.
Core Web Vitals sıralamayı ne kadar etkiler?
Sayfa deneyimi Google’ın kullandığı sinyallerden biridir, ama alaka ve içerik kalitesinin önüne geçmez: yavaş ama çok iyi bir yanıt, hızlı ama zayıf bir yanıttan önde olabilir. Yine de iyi Core Web Vitals kullanıcı deneyimini ve dönüşümü doğrudan iyileştirir; benzer kalitedeki sayfalar arasında fark yaratabilir.
Neden bazı sayfalarda gerçek kullanıcı verisi yok?
Chrome kullanıcı deneyimi raporu yalnızca yeterince ziyaret alan, herkese açık sayfalar için veri yayınlar. Adres düzeyinde veri yoksa site geneli (köken) verisi gösterilir; o da yoksa yalnızca laboratuvar ölçümü kullanılabilir.
Değerlendirme “Başarılı” olması için ne gerekir?
LCP, INP ve CLS’nin 75. yüzdelik değerlerinin üçünün de “iyi” eşiğinde olması gerekir; yani ziyaretlerin en az %75’i iyi deneyim yaşamalıdır. Verisi olmayan metrik değerlendirmeye katılmaz.
Ölçüm neden 20–60 saniye sürüyor?
Google’ın sunucuları sayfanızı gerçek bir Chrome ile açıp Lighthouse denetimini çalıştırır. Aynı adresin sonucu 10 dakika boyunca önbellekten verilir; değişikliği yayınladıktan sonra yeni ölçüm için bu süreyi bekleyin.
Sayfanın HTML ağırlığı için HTML Boyut Analizi’ni, görsellerin boyut ve formatı için Görsel SEO Analizi’ni kullanabilirsiniz.
Son güncelleme: