SEO'da Teknik Altyapının Önemi: Core Web Vitals Rehberi

Core Web Vitals; Google'ın bir sayfanın gerçek kullanıcı deneyimini ölçmek için tanımladığı üç somut metriğin ortak adıdır: yükleme hızı (LCP), etkileşim tepkiselliği (INP) ve görsel kararlılık (CLS). Bu rehber genel bir SEO anlatımı değil; her metriği tek tek ele alan, eşiklerini ve pratik iyileştirme tekniklerini gösteren teknik bir başvuru kaynağıdır. Sonunda sitenizin hangi metrikte nerede olduğunu ölçebilecek ve neyi düzelteceğinizi bileceksiniz.

Core Web Vitals Nedir?

Core Web Vitals, Google'ın "iyi bir sayfa deneyimi" tanımını mühendislik diline çeviren üç ölçülebilir metriktir. Amaç, "site hızlı hissettiriyor" gibi öznel bir yargıyı; milisaniye, saniye ve skor cinsinden karşılaştırılabilir sayılara indirgemektir. Üç metrik, kullanıcının bir sayfayla kurduğu ilişkinin üç farklı anına karşılık gelir:

• LCP (Largest Contentful Paint): Sayfa ne kadar hızlı yükleniyor hissini ölçer — ana içeriğin ekrana gelme süresi.
• INP (Interaction to Next Paint): Sayfa ne kadar hızlı tepki veriyor — kullanıcının tıklama, dokunma ve tuş girişlerine yanıt gecikmesi.
• CLS (Cumulative Layout Shift): Sayfa ne kadar kararlı — yükleme sırasında beklenmedik düzen kaymalarının toplamı.

Bu üç metriğin kritik özelliği, sentetik bir test aracının değil gerçek kullanıcıların deneyimini yansıtmasıdır. Google, bu verileri Chrome tarayıcısı üzerinden anonim olarak toplanan CrUX (Chrome User Experience Report) veri setinden okur. Yani laboratuvarda mükemmel görünen bir sayfa, sahada zayıf puan alabilir; belirleyici olan gerçek ziyaretçilerinizin cihaz ve bağlantı koşullarıdır.

Neden Bir Google Sıralama Faktörü?

Google, kullanıcıyı hızlı, akıcı ve kararlı sayfalara yönlendirmek ister; çünkü kötü bir sayfa deneyimi, kullanıcının arama motorundan da soğumasına yol açar. Bu nedenle Core Web Vitals, Google'ın Page Experience (sayfa deneyimi) sinyalinin çekirdeğini oluşturur ve organik sıralamada bir faktör olarak değerlendirilir. Sinyalin doğasını doğru anlamak önemlidir: Core Web Vitals içeriğin alaka düzeyinin yerini tutmaz. İçeriği alakasız bir sayfa, sırf hızlı diye üst sıraya çıkmaz. Ancak alaka düzeyi benzer iki sayfa arasında, sayfa deneyimi belirleyici bir eşitlik bozucu (tie-breaker) rolü oynar.

Pratik sonuç şudur: Core Web Vitals'ı iyileştirmek, sadece bir sıralama sinyalini beslemez; aynı zamanda hemen çıkma oranını düşürür ve dönüşümü artırır. Bu ikisi birbirini besler — nitekim site hızının doğrudan satışları nasıl etkilediğini ayrı bir yazıda verilerle ele almıştık. Teknik altyapı, sağlıklı bir SEO stratejisinin pazarlıksız temelidir.

LCP — Largest Contentful Paint

LCP Nedir?

LCP, sayfanın görünür alanında (viewport) çizilen en büyük içerik öğesinin render süresini ölçer. Bu öğe çoğunlukla bir hero görseli, video posteri ya da geniş bir metin bloğudur. LCP, kullanıcının "sayfa yüklendi" hissine kavuştuğu anı temsil ettiği için, algılanan yükleme hızının en iyi tek göstergesidir.

Hedef: < 2,5 sn

Google'ın eşiği, saha verisinin 75. yüzdelik diliminde (p75) LCP'nin 2,5 saniyenin altında kalmasıdır. Yani ziyaretçilerinizin en az %75'i için ana içerik 2,5 saniye içinde ekrana gelmelidir. LCP genellikle üç bileşenden oluşur: sunucu yanıt süresi (TTFB), kaynağın yüklenme gecikmesi ve öğenin render süresi. İyileştirme, bu üç bileşenin hangisinin darboğaz olduğunu tespit etmekle başlar.

LCP İyileştirme Teknikleri

• LCP öğesini önceliklendirin: En büyük görsele fetchpriority="high" verin ve gerektiğinde <link rel="preload"> ile erkenden yükleyin. Tarayıcı bu öğeyi diğer kaynaklardan önce çeksin.
• LCP görseline asla loading="lazy" koymayın: Ekranın üst kısmındaki (above the fold) ana görseli tembel yüklemek, LCP'yi doğrudan geciktirir. Lazy loading yalnızca ekran dışı görseller içindir.
• Görselleri modernleştirin: WebP/AVIF formatı, srcset ile responsive boyutlandırma ve doğru sıkıştırma; en büyük kazanımı buradan alırsınız.
• Sunucu yanıtını (TTFB) düşürün: Sayfa önbelleği, CDN ve optimize edilmiş veritabanı sorguları ile ilk baytın gelme süresini kısaltın.
• Render engelleyen kaynakları azaltın: Kritik CSS'i satır içine alın (inline), kritik olmayan CSS/JS'i erteleyin.
• Web fontlarını hızlandırın: Ana fontu preload edin ve font-display: swap ile metnin font yüklenene kadar görünür kalmasını sağlayın.

INP — Interaction to Next Paint

INP Nedir?

INP, kullanıcının sayfa ömrü boyunca yaptığı tüm etkileşimlerin (tıklama, dokunma, klavye girişi) tepki gecikmesini gözlemler ve en kötüye yakın değeri raporlar. Bir etkileşimin tam süresi üç aşamadan oluşur: giriş gecikmesi (input delay), olay işleyicilerin çalışma süresi (processing) ve bir sonraki boyamanın (next paint) hazırlanması. INP, bu zincirin toplamını ölçtüğü için sayfanın gerçek tepkiselliğini FID'den çok daha dürüst yansıtır.

FID'in Yerini Aldı (Mart 2024)

INP, Mart 2024'te FID (First Input Delay) metriğinin yerini alarak resmi bir Core Web Vitals oldu. Aradaki fark tayin edicidir: FID yalnızca ilk etkileşimin giriş gecikmesini ölçüyordu — yani en kolay geçilen, en az bilgi veren an. INP ise sayfadaki tüm etkileşimleri ve her birinin tam süresini kapsar. Bu yüzden FID'de "iyi" görünen birçok sayfa, INP ölçümünde zayıf çıkar; çünkü ilk tık sorunsuz olsa da sonraki etkileşimlerde ağır JavaScript ana iş parçacığını (main thread) kilitler.

Hedef: < 200 ms

Saha verisinin p75'inde INP'nin 200 milisaniyenin altında olması "iyi" kabul edilir. 200–500 ms arası geliştirilmeli, 500 ms üzeri kötüdür. INP sorunlarının kaynağı neredeyse her zaman aynıdır: ana iş parçacığını uzun süre meşgul eden JavaScript.

INP İyileştirme Teknikleri

• Uzun görevleri parçalayın: 50 ms'yi aşan görevler (long tasks) tarayıcıyı bloke eder. Ağır işleri küçük parçalara bölün ve aralarda ana iş parçacığını serbest bırakın (scheduler.yield() veya setTimeout ile).
• Kritik olmayan işi erteleyin: Analitik, öneriler gibi acil olmayan hesaplamaları requestIdleCallback ile tarayıcı boştayken çalıştırın.
• Üçüncü parti scriptleri kontrol edin: Chat widget'ları, takip kodları ve reklam scriptleri INP'nin en yaygın sessiz katilidir; geciktirin veya web worker'a taşıyın.
• JavaScript paketini küçültün: Kod bölme (code splitting), kullanılmayan kodu ayıklama (tree shaking) ve tembel modül yükleme ile ana iş parçacığındaki yükü azaltın.
• Görsel geri bildirimi ayırın: Kullanıcı bir butona tıkladığında görsel tepkiyi (loading göstergesi) ağır işlemden önce gösterin; algılanan gecikme düşer.

CLS — Cumulative Layout Shift

CLS Nedir?

CLS, sayfa yüklenirken meydana gelen beklenmedik düzen kaymalarının toplam skorunu ölçer. Bir yazıyı okumaya başlarken üstte geç yüklenen bir görselin metni aşağı itmesi ya da tam tıklayacakken butonun yer değiştirmesi klasik CLS problemleridir. Skor, kayan alanın büyüklüğü ile kayma mesafesinin çarpımından hesaplanır; birimsiz bir orandır.

Hedef: < 0,1

p75'te CLS skorunun 0,1'in altında olması gerekir. 0,1–0,25 arası geliştirilmeli, 0,25 üzeri kötüdür. Önemli bir ayrım: kullanıcının kendi eyleminden (bir butona tıklayıp açılan menü) hemen sonra oluşan kaymalar skora dahil edilmez; ceza yalnızca beklenmedik kaymalara işler.

CLS İyileştirme Teknikleri

• Görsel ve videolara boyut verin: Her <img> ve <video> etiketine width/height nitelikleri ya da CSS'te aspect-ratio tanımlayın; tarayıcı yer ayırır, öğe yüklenince kayma olmaz.
• Reklam ve embed alanlarını rezerve edin: Dinamik yüklenen banner, iframe ve gömülü içerikler için önceden sabit bir alan ayırın.
• Fontları erken yükleyin: Yedek font ile web fontu arasındaki boyut farkı metni kaydırır; preload ve font-display: swap yanında size-adjust ile yedek fontu eşleştirin.
• İçeriği DOM'un üstüne enjekte etmeyin: Mevcut içeriğin üzerine sonradan bildirim çubuğu, çerez banner'ı veya kampanya kutusu eklemek en sık görülen CLS hatasıdır; bunları en baştan yerleştirin ya da içeriğin üstünde kaplama (overlay) olarak gösterin.
• Animasyonu transform ile yapın: Layout tetikleyen top/left yerine transform kullanın; bu, düzeni yeniden hesaplamadan hareket sağlar.

Metrik Eşikleri Özeti

Üç metriğin resmi Google eşiklerini tek tabloda topladık. Değerler, saha verisinin 75. yüzdelik dilimi (p75) üzerinden değerlendirilir:

Laboratuvar Verisi mi, Saha Verisi mi?

Core Web Vitals ile çalışırken en çok kafa karıştıran nokta budur; ikisini ayırt etmeden doğru optimizasyon yapılamaz.

• Laboratuvar (lab) verisi: Kontrollü, sabit bir ortamda tek seferlik ölçümdür — Lighthouse'un ürettiği skor gibi. Tekrarlanabilir ve hata ayıklama için idealdir. Ancak INP ve CLS gibi gerçek kullanıcı etkileşimine bağlı metrikleri tam yansıtamaz; çünkü sentetik test bir insanın sayfayla nasıl etkileşeceğini bilemez.
• Saha (field) verisi — CrUX: Gerçek Chrome kullanıcılarından, izinli ve anonim biçimde toplanan son 28 günlük veridir. Google'ın sıralama için kullandığı veri budur. Kullanıcılarınızın gerçek cihazlarını, bağlantılarını ve davranışlarını içerdiği için nihai gerçeği yansıtır.

Doğru iş akışı şudur: Lab verisini neyi düzelteceğinizi bulmak için (sorunu izole etmek, denemek), saha verisini ise düzelttiğinizin işe yarayıp yaramadığını doğrulamak için kullanın.

Core Web Vitals'ın altın kuralı: Lighthouse'un yeşil skoru bir başlangıçtır; sıralamayı belirleyen ise gerçek kullanıcılarınızın CrUX'a yansıyan p75 değeridir. Laboratuvarda kazanılan puan, sahada doğrulanmadıkça yalnızca bir hipotezdir.

Core Web Vitals Nasıl Ölçülür?

Doğru araçlarla, hem sorunu bulmak hem de ilerlemeyi izlemek mümkündür. Her araç farklı bir soruya cevap verir:

• PageSpeed Insights: Tek bir URL için hem saha (CrUX) hem lab verisini bir arada gösterir. Başlangıç için en pratik ilk duraktır; en üstteki saha verisine, sonra iyileştirme önerilerine bakın.
• Google Search Console — Core Web Vitals raporu: Sitenizin tamamını URL grupları hâlinde, saha verisiyle değerlendirir. Hangi sayfa şablonlarının "kötü" veya "geliştirilmeli" olduğunu toplu görmenin en iyi yolu budur.
• Lighthouse: Chrome DevTools içinde çalışan lab aracıdır. Tek sayfa için ayrıntılı, tekrarlanabilir teşhis ve "fırsatlar" listesi verir.
• Chrome DevTools Performance paneli: Uzun görevleri, render engelleyen kaynakları ve düzen kaymalarını kare kare inceleyip INP ve CLS'in kök nedenini bulmak için kullanılır.
• web-vitals JS kütüphanesi: Kendi gerçek kullanıcı izleme (RUM) altyapınızı kurmak isterseniz, metrikleri tarayıcıdan doğrudan toplayıp analitiğinize gönderir.

Yaygın Hatalar

Core Web Vitals çalışmalarında tekrar tekrar gördüğümüz, skoru boşuna aşağı çeken hatalar:

1. LCP görseline loading="lazy" koymak: Ana görseli tembel yüklemek, en sık yapılan ve en pahalıya patlayan hatadır.
2. Sadece lab skoruna güvenmek: Lighthouse'ta 95 alıp sahada "kötü" görünen sayfalar sık rastlanır; sıralamayı saha verisi belirler.
3. Ortalamaya bakmak: Google p75'i (75. yüzdelik dilim) kullanır; ortalama, uçlardaki kötü deneyimleri gizler ve yanıltır.
4. Mobil ve masaüstünü karıştırmak: İki cihaz sınıfı ayrı ayrı ölçülür; mobil neredeyse her zaman daha zayıftır ve önceliklendirilmelidir.
5. 100/100 skoruna takılmak: Lighthouse performans puanı bir metrik değil, ağırlıklı bir özettir. Amaç mükemmel skor değil, üç metrikte de "iyi" eşiğini geçmektir.
6. Çerez banner'ı veya pop-up ile CLS üretmek: Sonradan enjekte edilen bildirim ve onay kutuları içeriği kaydırarak skoru bozar.
7. Bir kez optimize edip bırakmak: Yeni içerik, eklenti veya üçüncü parti script her an performansı geriletebilir; ölçüm süreklilik ister.

Sıkça Sorulan Sorular

Core Web Vitals sıralamayı ne kadar etkiler?

Core Web Vitals bir sıralama sinyalidir, ancak içeriğin alaka düzeyi kadar baskın değildir. İçeriği zayıf bir sayfa sırf hızlı diye üste çıkmaz. Etkisi, alaka düzeyi benzer sayfalar arasında bir eşitlik bozucu olarak ortaya çıkar; rekabetin yoğun olduğu aramalarda bu fark belirleyici olabilir. Ayrıca dolaylı etkisi doğrudan etkisinden büyüktür: daha iyi deneyim, daha düşük hemen çıkma ve daha yüksek dönüşüm demektir.

INP ile FID arasındaki fark nedir?

FID yalnızca ilk etkileşimin giriş gecikmesini ölçüyordu; yani en yüzeysel anı. INP ise sayfadaki tüm etkileşimleri ve her birinin tam süresini (giriş gecikmesi + işleme + boyama) kapsar. Bu nedenle INP, sayfanın gerçek tepkiselliğini çok daha dürüst yansıtır. INP, Mart 2024'te FID'in yerini resmen almıştır.

PageSpeed skorum neden sürekli dalgalanıyor?

İki farklı ölçüm tipini karıştırıyor olabilirsiniz. Lab skoru (Lighthouse) her çalıştırmada test koşullarına göre değişebilir. Saha verisi (CrUX) ise son 28 günün hareketli penceresidir; bugün yaptığınız bir iyileştirmenin bu veriye tam yansıması haftalar alır. Dalgalanma çoğu zaman lab ölçümünün doğasından kaynaklanır.

Mobil ve masaüstü ayrı mı değerlendirilir?

Evet. CrUX verisi cihaz sınıfına göre ayrışır ve Google mobil öncelikli indeksleme uygular. Trafiğinizin büyük kısmı mobilden geldiği için önceliğiniz mobil skorlar olmalıdır. Bu, güçlü bir responsive web tasarım altyapısını Core Web Vitals açısından da zorunlu kılar.

Tüm sayfalarımın "iyi" olması şart mı?

İdeal olan budur, ancak Search Console sayfaları benzer şablonlara göre URL grupları hâlinde değerlendirir. Önceliğinizi trafiği ve dönüşümü en yüksek sayfa türlerine (ana sayfa, kategori, ürün, blog) verin; bir şablonu düzeltmek, o şablonu kullanan tüm sayfaları birden iyileştirir.

İyileştirmenin sonucunu ne kadar sürede görürüm?

Lab aracında (Lighthouse) etkiyi anında görürsünüz. Ancak sıralamayı etkileyen saha verisi 28 günlük hareketli bir penceredir; değişiklik yayına alındıktan sonra CrUX'a tam yansıması genellikle birkaç haftayı bulur. Bu yüzden sabırlı olmak ve ölçümü sürdürmek gerekir.

Sağlam Teknik Altyapı İçin Web Factory

Core Web Vitals, sonradan yamayla değil; projenin mimarisi kurulurken kazanılan bir performanstır. Web Factory olarak geliştirdiğimiz her sitede LCP, INP ve CLS'i tasarım aşamasından itibaren gözetiyor; görsel optimizasyonu, kritik render yolu, JavaScript disiplini ve düzen kararlılığını standart kabul ediyoruz. Sitenizin metrikleri "geliştirilmeli" veya "kötü" seviyedeyse, sorunun kök nedenini birlikte çıkarabiliriz. Web geliştirme ve performans hizmetlerimizi inceleyin ya da siteniz için ücretsiz Core Web Vitals değerlendirmesi talep edin.