Bir web sitesinin Google’da iyi sıralanması için içeriğin kaliteli olması artık tek başına yetmiyor; sitenin hızlı ve kararlı açılması da gerekiyor. İşte tam bu noktada Core Web Vitals devreye giriyor. 10 yılı aşkın süredir SEO ve dijital pazarlama tarafında çalışıyorum; son yıllarda “içeriğim iyi ama neden yükselmiyorum?” diyen pek çok site sahibinin asıl sorununun teknik tarafta, yani core web vitals ve site hızı metriklerinde gizli olduğunu gördüm. Bu rehberde bu metrikleri sade bir dille açıklayacak, her birini nasıl ölçüp nasıl iyileştireceğinizi adım adım göstereceğim.
Üstelik bunu teorik olarak değil, kendi sitemde bizzat uyguladığım deneyimlerle anlatacağım. Yazının sonunda, sitenizin hangi metriklerde zayıf olduğunu nasıl tespit edeceğinizi ve önceliği nereye vereceğinizi net olarak bileceksiniz.
Core Web Vitals Nedir ve Neden Önemli?
Core Web Vitals, Google’ın bir sayfanın kullanıcı deneyimi kalitesini ölçmek için tanımladığı üç temel metrikten oluşan bir settir. Amaç basit: Sayfa ne kadar hızlı görünür hale geliyor, kullanıcı etkileşimlerine ne kadar çabuk yanıt veriyor ve ekranda beklenmedik kaymalar yaşanıyor mu? Google bu metrikleri “sayfa deneyimi” sinyallerinin bir parçası olarak sıralama algoritmasında kullanıyor.
Burada dürüst bir çerçeve çizeyim: Core Web Vitals tek başına sizi birinci sıraya taşıyan sihirli bir kaldıraç değildir. İçerik kalitesi ve alaka düzeyi hâlâ baskın faktörlerdir. Ancak iki sitenin içeriği benzer güçteyse, hızlı ve kararlı olan öne geçer. Bir de işin doğrudan ticari tarafı var: Yavaş açılan sayfalar ziyaretçiyi kaçırır. Deneyimime göre, açılışı saniyelerce geciken bir sayfada kullanıcı daha içeriği görmeden geri tuşuna basar; yani core web vitals site hızı meselesi aynı anda hem SEO hem dönüşüm meselesidir.
Üç Temel Metrik: LCP, CLS ve INP
Önce önemli bir güncellemeyle başlayayım, çünkü bu konuda internette hâlâ eski bilgi dolaşıyor: Uzun süre üçüncü metrik olarak kullanılan FID (First Input Delay), 12 Mart 2024 itibarıyla kaldırıldı ve yerini INP (Interaction to Next Paint) aldı. INP, etkileşim hızını çok daha kapsamlı ölçtüğü için bu doğru bir değişiklikti. Yani 2026 itibarıyla üç temel metrik şunlar: LCP, CLS ve INP.
LCP — Largest Contentful Paint (En Büyük İçeriğin Yüklenmesi)
LCP, sayfadaki en büyük görünür öğenin (genellikle hero görseli, büyük bir başlık ya da kapak resmi) ekranda render edilme süresini ölçer. Kullanıcı açısından bu, “sayfa yüklendi, içeriği görüyorum” anının ne zaman geldiğidir. Deneyimime göre site sahiplerinin en çok zorlandığı metrik budur; çünkü doğrudan sunucu hızı, görsel boyutları ve render engelleyen kaynaklarla ilişkilidir.
CLS — Cumulative Layout Shift (Kümülatif Düzen Kayması)
CLS, sayfa yüklenirken öğelerin beklenmedik şekilde yer değiştirmesini ölçer. Hepimiz yaşamışızdır: Bir yazıyı okumaya başlarsınız, üstte geç yüklenen bir reklam ya da görsel araya girer ve içerik aşağı kayar; tam tıklayacakken buton yer değiştirir. Bu hem sinir bozucudur hem de yanlış tıklamalara yol açar. İyi haber şu ki CLS, genellikle en kolay düzeltilebilen metriktir.
INP — Interaction to Next Paint (Etkileşime Yanıt Süresi)
INP, kullanıcının bir tıklama, dokunma veya tuşa basma gibi etkileşiminden sonra sayfanın görsel olarak yanıt vermesinin ne kadar sürdüğünü ölçer. Sayfa açıldıktan sonra “donuk” hissi veriyorsa, butona bastığınızda bir şey olması gecikiyorsa sorun INP’dedir. Genellikle ağır JavaScript yükünden kaynaklanır.
İyi Bir Skor İçin Hedef Eşikler
Google her metrik için üç bant tanımlar: “İyi”, “İyileştirme gerekli” ve “Kötü”. Çok önemli bir nokta var: Bu değerlendirme, ziyaretçilerinizin %75’inin (p75) aldığı sonuca göre yapılır. Yani birkaç hızlı cihazda iyi skor almanız yetmez; kullanıcılarınızın dörtte üçü eşiğin altında kalmalıdır. Aşağıdaki tablo güncel hedefleri özetliyor.
| Metrik | İyi | İyileştirme Gerekli | Kötü |
|---|---|---|---|
| LCP | 2,5 saniye ve altı | 2,5 – 4,0 saniye | 4,0 saniyeden fazla |
| CLS | 0,1 ve altı | 0,1 – 0,25 | 0,25’ten fazla |
| INP | 200 ms ve altı | 200 – 500 ms | 500 ms’den fazla |
Saha Verisi mi, Laboratuvar Verisi mi?
Ölçüm yaparken karşınıza iki tür veri çıkar ve ikisini karıştırmak en sık yapılan hatadır:
- Saha verisi (field data): Gerçek ziyaretçilerinizin gerçek cihaz ve bağlantılarında yaşadığı deneyimdir. Google bunu CrUX (Chrome User Experience Report) üzerinden toplar ve genellikle son 28 günün kayan ortalamasıdır. Google sıralamada esas olarak bu veriyi dikkate alır. Dezavantajı: Yeni yaptığınız bir iyileştirme rapora hemen yansımaz, birikmesi zaman alır.
- Laboratuvar verisi (lab data): Lighthouse gibi araçların kontrollü, simüle edilmiş bir ortamda yaptığı tek seferlik ölçümdür. Anında sonuç verir, hata ayıklamak için idealdir; ama tek bir cihaz/bağlantı senaryosunu yansıttığı için gerçek kullanıcı deneyiminin tamamını temsil etmez.
Pratik kuralım şu: Sorunu teşhis etmek ve düzeltmeyi test etmek için laboratuvar verisini, gerçek durumu ve sıralama etkisini görmek için saha verisini kullanırım. Bir düzeltme yaptıktan sonra Search Console’daki saha raporunun güncellenmesini sabırla beklemek gerekir.
Core Web Vitals Nasıl Ölçülür?
Düzenli olarak kullandığım ve size de önerdiğim üç ücretsiz araç var:
- PageSpeed Insights: Tek bir URL’yi yazıp hem saha hem laboratuvar verisini bir arada görmenin en hızlı yolu. Mobil ve masaüstü skorlarını ayrı ayrı verir; mutlaka mobile öncelik verin.
- Search Console — Core Web Vitals raporu: Sitenizin tamamını saha verisiyle, “iyi / iyileştirme gerekli / kötü” gruplarına ayırarak gösterir. Hangi URL gruplarının sorunlu olduğunu toplu görmek için en değerli kaynak budur.
- Lighthouse (Chrome DevTools): Tarayıcının içinde, geliştirme sırasında anlık laboratuvar ölçümü ve somut iyileştirme önerileri için kullanırım.
Core Web Vitals’ı daha geniş bir teknik resmin parçası olarak değerlendirmek isterseniz, hazırladığım teknik SEO denetimi kontrol listesini de bu rehberle birlikte okumanızı öneririm; site hızı, o listenin önemli bir maddesidir.
Her Metriği İyileştirmenin Yolları
LCP’yi İyileştirmek
- Hero görselini ve en büyük öğeyi optimize edin: doğru boyutta sunun, modern formatlar (WebP/AVIF) kullanın, gereksiz büyük dosyalardan kaçının.
- Render engelleyen CSS ve JavaScript’i azaltın; kritik CSS’i öne çıkarın, gerisini erteleyin.
- Sunucu yanıt süresini (TTFB) düşürün: iyi bir hosting, önbellekleme (cache) ve gerekiyorsa CDN kullanın.
- Ekranın üst kısmındaki (above the fold) kritik görseli “lazy load” yapmayın; aksine önceliklendirin.
CLS’yi İyileştirmek
- Tüm görsel ve video öğelerine genişlik ve yükseklik (ya da en-boy oranı) tanımlayın ki tarayıcı yer ayırsın.
- Reklam, gömülü içerik ve iframe’ler için önceden alan rezerve edin.
- Yazı tiplerini doğru yükleyin; geç gelen fontun metni “zıplatmasını” önleyin.
- Yeni içeriği mevcut içeriğin üstüne, kullanıcı bir etkileşim beklemiyorken enjekte etmekten kaçının.
INP’yi İyileştirmek
- Ağır JavaScript yükünü azaltın; kullanılmayan script ve eklentileri temizleyin.
- Uzun süren işlemleri küçük parçalara bölün ki ana iş parçacığı (main thread) kilitlenmesin.
- Üçüncü taraf scriptlerini (sohbet widget’ı, ısı haritası, fazladan izleme kodları) gözden geçirin; çoğu sitede en büyük gecikme bunlardan gelir.
- Etkileşime kadar gerekmeyen scriptleri geciktirin (defer/delay).
Kendi Deneyimim: Bir Sitenin Hızını Toparlamak
Teoriyi bir kenara bırakıp size sahadan konuşayım. Kendi sitemde bir dönem LCP ve genel yüklenme süresi beni hiç memnun etmiyordu; ağır bir tema, çok sayıda eklenti ve birikmiş script yükü işi yavaşlatıyordu. Sunucu tarafında LiteSpeed önbellekleme ile QUIC.cloud üzerinden ürettiğim kritik CSS (critical CSS) yaklaşımını devreye aldığımda, özellikle ana iş parçacığını bloke eden süre (TBT) ve LCP tarafında ciddi, gözle görülür bir iyileşme elde ettim. Burada size sahte bir rakam vermeyeceğim; ama söyleyebileceğim şu: doğru önbellekleme ve render optimizasyonu, çoğu sitede en yüksek getirili tek hamledir.
Bu deneyimden çıkardığım en önemli ders şu oldu: Critical CSS gibi optimizasyonlar genellikle gerçek trafikle birkaç gün içinde “olgunlaşır”; yani değişikliği yaptığınız an değil, biraz sabredince tam etkisini gösterir. Bu yüzden bir iyileştirme sonrası paniğe kapılıp geri almak yerine, saha verisinin oturmasını beklemek gerekir.
Sık Yapılan Hatalar
- Sadece masaüstüne bakmak: Çoğu trafik mobilden gelir ve mobil skorlar genellikle daha düşüktür. Her zaman mobile öncelik verin.
- Laboratuvar skoruna takılıp saha verisini görmezden gelmek: Sıralamayı etkileyen saha verisidir; Lighthouse’ta 100 almak tek başına yetmez.
- Tek bir yüksek skoru genelleştirmek: Değerlendirme p75 üzerinden yapılır; “benim bilgisayarımda hızlı açılıyor” bir kanıt değildir.
- Eklenti enflasyonu: Her yeni eklenti biraz daha script ve yük demektir. Kullanmadığınız eklentileri temizlemek çoğu zaman en hızlı kazançtır.
- FID’yi hâlâ optimize etmeye çalışmak: FID kalktı; odağınız artık INP olmalı.
Bütün bunlar kulağa teknik geliyorsa endişelenmeyin; doğru önceliklendirmeyle çoğu site belirgin bir iyileşme yakalayabilir. Eğer sitenizin Core Web Vitals tarafını profesyonel olarak ele almamı ve bir hız optimizasyonu planına dönüştürmemi isterseniz, sunduğum SEO hizmeti kapsamında teknik performans iyileştirmesi standart bir adımdır. Daha bütünsel bir SEO bakışı için 2026 SEO rehberimi de inceleyebilir, aklınızdaki projeyi konuşmak için iletişim sayfası üzerinden bana ulaşabilirsiniz.
Sıkça Sorulan Sorular
Core Web Vitals bir sıralama faktörü mü?
Evet, Google’ın sayfa deneyimi sinyallerinin bir parçası olarak sıralamada dikkate alınır. Ancak baskın faktör değildir; içerik kalitesi ve alaka düzeyi hâlâ daha ağır basar. En doğru bakış açısı şudur: Benzer güçte iki içerik arasında, hızlı ve kararlı olan öne geçer. Yani Core Web Vitals’ı bir “tie-breaker” (eşitlik bozucu) ve kullanıcı deneyimi yatırımı olarak görmek gerekir.
FID ile INP arasındaki fark nedir?
FID (First Input Delay) yalnızca kullanıcının ilk etkileşimindeki gecikmeyi ölçüyordu ve dar bir metrikti. 12 Mart 2024’te kaldırıldı. Yerine gelen INP (Interaction to Next Paint) ise sayfa boyunca yapılan tüm etkileşimlerin yanıt süresini değerlendirir ve görsel yanıtın tamamlanmasına kadar geçen süreyi ölçer. Yani INP, etkileşim hızını çok daha gerçekçi ve kapsamlı yansıtır.
İyileştirme yaptım ama skor değişmedi, neden?
Büyük olasılıkla saha verisine bakıyorsunuz. Search Console ve PageSpeed Insights’ın saha verisi genellikle son 28 günün kayan ortalamasıdır; bu yüzden yeni bir düzeltme rapora anında yansımaz, birikmesi gerekir. Değişikliğin etkisini hemen görmek için laboratuvar (Lighthouse) ölçümünü kullanın, gerçek etki için saha verisinin oturmasını birkaç gün bekleyin.
Mobil mi yoksa masaüstü skoru mu daha önemli?
Çoğu sektörde trafiğin büyük kısmı mobilden geldiği ve Google mobil öncelikli (mobile-first) değerlendirdiği için mobil skorlar önceliklidir. Mobil cihazlar genellikle daha sınırlı işlemci ve bağlantıya sahip olduğundan skorlar da daha düşük çıkar. Bu yüzden optimizasyonu her zaman önce mobil tarafında yapın.
WordPress sitesinde Core Web Vitals nasıl iyileştirilir?
Pratikte en çok işe yarayan adımlar: iyi bir önbellekleme çözümü (örneğin LiteSpeed), kritik CSS üretimi, görsellerin modern formatta ve doğru boyutta sunulması, kullanılmayan eklentilerin temizlenmesi ve gereksiz scriptlerin ertelenmesidir. Deneyimime göre önbellekleme ve render optimizasyonu, WordPress’te en yüksek getirili ilk hamledir; ağır tema ve eklenti yükü ise en sık görülen kök sorundur.
