Core Web Vitals Nedir — ve Gerçekten Nasıl İyileştirilir

Core Web Vitals, Google’ın bir sayfanın kullanıcıya gerçekte nasıl hissettirdiğini anlamak için baktığı temel performans metrikleridir. Yani mesele yalnızca “site kaç saniyede açılıyor?” değildir. Sayfa ne kadar hızlı görünür oluyor, yüklenirken zıplıyor mu, kullanıcı tıkladığında hemen tepki veriyor mu? Asıl sorular bunlar.

Evet, Core Web Vitals bir sıralama sinyalidir. Ama bundan daha önemlisi, ziyaretçinin sitede kalıp kalmayacağını doğrudan etkiler. Kullanıcı sayfanın açılmasını beklerken sıkılırsa, tam bir butona basacakken sayfa kayarsa ya da menüye tıkladığında hiçbir şey olmuyormuş gibi hissederse, SEO skorunuz iyi olsa bile işiniz zorlaşır.

Bu yüzden Core Web Vitals’ı yalnızca teknik bir rapor gibi değil, kullanıcı deneyiminin ölçülebilir hali gibi düşünmek gerekir. Aşağıda üç temel metriğin ne anlama geldiğini, neden bozulduğunu ve pratikte nasıl iyileştirileceğini sade şekilde anlatıyorum.

Üç metrik

Core Web Vitals üç ana metriğe dayanır: LCP, CLS ve INP. Her biri sayfanın farklı bir yönünü ölçer. Biri ilk görünürlükle, biri görsel stabiliteyle, diğeri etkileşim hızıyla ilgilenir.

Bu metrikleri tek tek ele almak önemlidir çünkü “site yavaş” dediğimizde aslında birçok farklı problemden bahsediyor olabiliriz. Sunucu geç cevap veriyor olabilir. Görseller ağır olabilir. JavaScript ana iş parçacığını kilitliyor olabilir. Ya da sayfa hızlı açılıyor gibi görünür ama kullanıcı tıklayınca gecikme yaşanır.

Doğru teşhis olmadan yapılan performans optimizasyonu genelde boşa vakit harcatır.

LCP — Largest Contentful Paint

LCP, sayfadaki en büyük görünür içeriğin kullanıcı ekranında ne kadar sürede belirdiğini ölçer. Bu öğe çoğu zaman hero görseli, büyük bir başlık, ana görsel blok ya da üst bölümdeki büyük bir metindir. Hedef: 2.5 saniyenin altı.

Basitçe söylemek gerekirse LCP, kullanıcının “tamam, sayfa geldi” dediği ana yakındır. Bu yüzden çok kritiktir. Sayfanın arka planda başka şeyler yüklemesi önemli olabilir ama kullanıcı ilk ekranda boşluk, geç gelen görsel veya geç beliren başlık görüyorsa deneyim kötü başlar.

Kötü LCP’nin yaygın sebepleri şunlardır:

• Büyük, optimize edilmemiş hero görseli.
• İlk boyamayı geciktiren render-blocking CSS veya JavaScript.
• Yavaş sunucu yanıtı, yani yüksek TTFB.
• Metnin görünmesini engelleyen web fontu.
• İlk ekranda gereksiz büyük slider, video veya animasyon kullanımı.
• Gereğinden fazla üçüncü parti script.

LCP’yi düzeltirken önce en büyük öğenin ne olduğunu bulmak gerekir. Bazen herkes görsele odaklanır ama asıl LCP öğesi büyük bir başlık olabilir. Bazen de masaüstünde başka, mobilde başka öğe LCP olur. Bu yüzden mobil testleri ayrıca kontrol etmek gerekir.

Pratik çözümler şunlardır: Görselleri modern formatta, yani AVIF veya WebP olarak sunmak iyi bir başlangıçtır. Ama format tek başına yetmez. Görselin doğru boyutta servis edilmesi de gerekir. Mobil ekranda 3000 piksel genişliğinde bir görsel yükletiyorsanız, WebP olsa bile hâlâ gereğinden ağırdır.

Kritik CSS’i inline etmek, ilk ekranın daha hızlı boyanmasını sağlar. Sayfanın üst kısmı için gereken stiller ayrı düşünülmeli, geri kalanı mümkünse ertelenmelidir. LCP görseli gerçekten kritikse preload edilebilir. Aynı şekilde, ilk ekranda kullanılan kritik fontlar da dikkatli şekilde preload edilebilir.

Sunucu tarafı da unutulmamalı. Yavaş hosting, ağır backend işlemleri veya yanlış cache ayarları LCP’yi doğrudan bozar. Hızlı bir host, doğru cache ve mümkünse CDN kullanımı çoğu projede ciddi fark yaratır.

CLS — Cumulative Layout Shift

CLS, sayfa yüklenirken düzenin ne kadar oynadığını ölçer. Daha gündelik bir örnekle: Bir butona tıklayacakken reklam gelir, buton aşağı kayar ve yanlış yere tıklarsınız. İşte bu CLS problemidir. Hedef: 0.1’in altı.

CLS kullanıcıyı en çok rahatsız eden performans sorunlarından biridir çünkü kontrol hissini bozar. Sayfa açılmış gibi görünür ama öğeler yer değiştirir. Görsel geç yüklenir, metin aşağı iner. Banner sonradan eklenir, içerik kayar. Font değişir, satırlar yeniden akar.

Yaygın sebepler şunlardır:

• Genişlik ve yükseklik belirtilmemiş görsel veya iframe.
• Yüklemeden sonra enjekte edilen reklam, çerez bildirimi veya kampanya banner’ı.
• Metni yeniden akıtan font değişimi.
• Üst alana sonradan eklenen dinamik bileşenler.
• Skeleton veya placeholder kullanılmadan yüklenen kart yapıları.

CLS tarafında en temel kural şudur: Sayfada sonradan gelecek bir şey varsa, ona baştan yer ayırın.

Görsellerde width ve height değerlerinin belirtilmesi gerekir. Modern CSS ile responsive tasarım yapıyor olsanız bile tarayıcının görsel gelmeden önce kaplayacağı alanı bilmesi önemlidir. Aynı şey iframe, video embed ve reklam alanları için de geçerlidir.

Dinamik banner’lar için de benzer bir yaklaşım gerekir. Sayfanın üstüne sonradan bir çubuk ekleyip tüm içeriği aşağı itmek kötü bir deneyimdir. Eğer çerez bildirimi, duyuru alanı veya kampanya bandı kullanılacaksa bunun yeri tasarımda baştan düşünülmelidir.

Fontlar da CLS yaratabilir. Özel font geç yüklenir, önce sistem fontu görünür, sonra özel font devreye girer ve metnin ölçüleri değişirse sayfa oynar. Burada mantıklı bir font-display stratejisi kullanmak gerekir. Amaç, metni görünmez bırakmadan ve düzeni zıplatmadan font geçişini yönetmektir.

INP — Interaction to Next Paint

INP, kullanıcının sayfayla etkileşime girdiğinde ne kadar hızlı yanıt aldığını ölçer. Bir butona tıklamak, menüyü açmak, form alanına yazmak veya filtre kullanmak gibi etkileşimler buna dahildir. 2024’te FID’in yerini aldı. Hedef: 200ms’nin altı.

INP’nin odaklandığı şey şudur: Kullanıcı bir işlem yaptığında sayfa gerçekten hızlı tepki veriyor mu?

Bir site ilk bakışta hızlı açılabilir. LCP iyi olabilir. CLS sorunsuz olabilir. Ama kullanıcı menüye bastığında geç açılıyorsa, sepete ekle butonu birkaç yüz milisaniye sonra tepki veriyorsa veya filtreler takılarak çalışıyorsa INP kötüleşir.

Buradaki suçlu çoğu zaman aynıdır: Ana iş parçacığını bloklayan fazla JavaScript.

Tarayıcı aynı anda her şeyi yapamaz. JavaScript uzun süre çalışıyorsa, kullanıcı etkileşimleri beklemek zorunda kalır. Bu da sayfanın donmuş gibi hissedilmesine neden olur. Özellikle ağır framework kullanımı, büyük bundle dosyaları, sayfanın ihtiyacından fazla çalışan istemci tarafı kod, üçüncü parti scriptler ve karmaşık event handler’lar INP’yi bozabilir.

Çözüm “birkaç ayar yapalım, düzelsin” kadar basit olmayabilir. Öncelikle daha az JavaScript göndermek gerekir. Kullanılmayan kod temizlenmeli, büyük paketler bölünmeli, ilk yüklemede gerekmeyen işlevler ertelenmelidir.

Her bileşenin ilk anda interaktif olması gerekmeyebilir. Sayfanın üst kısmında kullanıcı için kritik olmayan bir carousel, chat widget ya da analiz scripti ana yüklemeyi yavaşlatmamalıdır. Ağır işlemler mümkünse kullanıcı etkileşiminden sonraya, boş zamana veya daha küçük parçalara bölünerek çalıştırılmalıdır.

Özellikle içerik odaklı sitelerde en iyi INP optimizasyonu, baştan daha az istemci tarafı JavaScript kullanmaktır. Çünkü hiç göndermediğiniz JavaScript’i optimize etmek zorunda kalmazsınız.

Laboratuvar vs saha — “100” neden yalan söyleyebilir

Lighthouse ve PageSpeed Insights performans analizi için çok faydalı araçlardır. Ancak bu araçların ürettiği skorları doğru okumak gerekir. Lighthouse, belirli koşullar altında sentetik bir test çalıştırır. Yani simüle edilmiş bir cihaz, simüle edilmiş bağlantı ve kontrollü bir test ortamı vardır.

Bu kötü bir şey değildir. Laboratuvar testleri problemi yakalamak, karşılaştırma yapmak ve geliştirme sırasında ilerlemeyi görmek için çok işe yarar. Ama gerçek kullanıcı deneyiminin tamamını temsil etmez.

Google sıralama tarafında saha verisine, yani CrUX verilerine bakar. Bu veriler gerçek Chrome kullanıcılarından toplanan ölçümlere dayanır. Bu nedenle laboratuvarda yeşil görünen bir sayfa, sahada kırmızı olabilir.

Bunun birkaç nedeni vardır. Gerçek kullanıcıların cihazları daha yavaş olabilir. Bağlantıları zayıf olabilir. Eski telefon kullanıyor olabilirler. Sayfayı farklı ülkelerden, farklı ağ koşullarında açıyor olabilirler. Ayrıca gerçek kullanıcılar siteyle etkileşime girer; sadece sayfanın açılmasını beklemez. Bu da özellikle INP için önemlidir.

Bu yüzden sadece Lighthouse skoruna bakıp “performans tamam” demek yanıltıcıdır. Skor 100 olsa bile Search Console’daki Core Web Vitals raporu sorun gösterebilir. Tam tersi de mümkündür: Laboratuvarda bazı uyarılar görünür ama saha verisi gayet sağlıklıdır.

En doğru yaklaşım ikisini birlikte kullanmaktır. Laboratuvar testleri teşhis içindir. Saha verisi ise gerçek durumun göstergesidir. Eğer Search Console belirli URL gruplarında sorun gösteriyorsa, önce o şablonlara odaklanmak gerekir. Blog yazıları mı sorunlu, kategori sayfaları mı, ürün detayları mı? Core Web Vitals genelde tek tek sayfalardan çok şablon bazlı düşünülmelidir.

En hızlı çözüm mimaridir

Performans optimizasyonunda küçük dokunuşlar işe yarar. Görselleri sıkıştırmak, cache ayarlamak, CSS’i düzenlemek, scriptleri ertelemek elbette önemlidir. Ama yavaş bir mimari üzerine kurulu siteyi ancak bir yere kadar hızlandırabilirsiniz.

Asıl büyük kazanç, en başta daha az şey göndermekten gelir.

Bir sayfanın hızlı olması için tarayıcıya devasa JavaScript paketleri, ağır görseller, gereksiz animasyonlar ve üçüncü parti scriptler yüklemek zorunda olmaması gerekir. Kullanıcıya mümkün olduğunca hızlı şekilde HTML sunmak, kritik içeriği erken göstermek ve sadece gerçekten gereken yerlerde etkileşim eklemek en sağlıklı yaklaşımdır.

Bu özellikle içerik siteleri, kurumsal web siteleri, bloglar, landing page’ler ve SEO odaklı projeler için geçerlidir. Bu tür sitelerde çoğu sayfanın tamamen uygulama gibi davranmasına gerek yoktur. Kullanıcı önce içeriği görmek ister. Menü düzgün çalışsın, form gönderilsin, sayfa hızlı açılsın yeterlidir.

Bu yüzden hazır HTML ve sıfıra yakın JavaScript yaklaşımı çok değerlidir. Tarayıcı daha az iş yapar. Ana iş parçacığı daha az yorulur. LCP daha kolay iyileşir. INP için risk azalır. CLS de daha kontrollü hale gelir.

İçerik sitelerini tam da bu nedenle hafif, içerik öncelikli ve neredeyse hiç JavaScript göndermeyen bir zemin üzerine kuruyorum; sayfa sunucuda hazırlanıp hazır gelir. Çünkü performansı sonradan kovalamak yerine, en baştan doğru zeminde başlamak daha mantıklı. Güçlü Core Web Vitals değerleri sihirli bir optimizasyon listesinin sonucu değil; çoğu zaman doğru mimarinin doğal sonucudur. Bu yaklaşımın detayı: hızlı web sitesi geliştirme.

Core Web Vitals tek başına SEO’nun tamamı değildir. Daha büyük teknik resmin bir parçasıdır. Tarama, indexlenme, render süreci, site mimarisi, iç linkleme, canonical kullanımı, yönlendirmeler ve schema gibi konular da aynı derecede önemlidir. Bu tarafı daha kapsamlı ele almak istersen: teknik SEO.

Özetle, Core Web Vitals’ı yalnızca “PageSpeed skoru yükseltme işi” gibi görmek eksik kalır. Burada amaç daha hızlı, daha stabil ve kullanıcıya daha güven veren bir deneyim oluşturmaktır. Skorlar kırmızıysa ve geçici yamalar yerine kalıcı olarak yeşil bir yapı istiyorsan, bana yaz.