Core Web Vitals: Google'ın hız karnesi nasıl okunur?

Core Web Vitals, Google'ın sitenize kestiği hız karnesidir — ve çoğu site sahibi bu karneyi ya hiç görmemiştir ya da görüp anlamamıştır. Suç onlarda değil: "LCP 2.5 saniyenin altında olmalı, CLS 0.1'i geçmemeli" gibi cümleler, çeviri yapılmadan kimseye bir şey söylemez. Bu yazı o çeviriyi yapıyor: üç metriğin her biri gerçekte neyi ölçer, karneyi nereden okursunuz, hangi notlar gerçekten önemlidir ve kötü notlar nasıl düzelir.

Core Web Vitals neden umurunuzda olmalı?

İki nedenle. Birincisi Google: Core Web Vitals, sıralama sinyallerinden biridir. Tek başına sizi birinci sayfaya taşımaz — içerik ve otorite daha ağır basar — ama başa baş rekabette yavaş site geride kalır. Google'ın hız sinyalini abartan da yanılır, yok sayan da.

İkinci neden daha somut: Bu metrikler zaten ziyaretçinizin yaşadığı deneyimi ölçüyor. Sayfa geç açılıyorsa, butona basınca tepki gelmiyorsa, tam tıklayacakken içerik zıplıyorsa — ziyaretçi bunu sizden önce fark ediyor ve bir kısmı geri dönüyor. Karne aslında Google için değil, sizin için tutuluyor.

Üç metrik, üç soru

Core Web Vitals üç metrikten oluşur ve her biri ziyaretçinin sorduğu bir soruya karşılık gelir.

LCP — "Sayfa ne zaman geldi?"

Largest Contentful Paint, sayfadaki en büyük görsel öğenin — çoğunlukla kapak görseli veya ana başlık — ekranda görünmesine kadar geçen süredir. Ziyaretçinin "site açıldı" hissiyle örtüşen metrik budur. Google'ın eşiği: 2.5 saniyenin altı iyi, 4 saniyenin üstü zayıf.

LCP'yi bozan tipik şüpheliler: sıkıştırılmamış dev görseller, yavaş sunucu yanıtı, sayfayı bloke eden script yığını, ve görselin geç yüklenmeye (lazy load) alınması gibi iyi niyetli ama yanlış yerde kullanılmış optimizasyonlar. Evet — ekranın en üstündeki görsele lazy load koymak, hızlandırayım derken yavaşlatmanın klasik örneğidir.

INP — "Bastım, tepki verdi mi?"

Interaction to Next Paint, ziyaretçi bir şeye tıkladığında veya yazdığında ekranın tepki vermesine kadar geçen süreyi ölçer. 2024'te eski metrik FID'in yerini aldı ve ondan çok daha zorlu bir ölçüttür; çünkü yalnızca ilk etkileşimi değil, sayfa boyundaki tüm etkileşimleri hesaba katar. Eşik: 200 milisaniyenin altı iyi.

INP'nin baş düşmanı, tarayıcıyı meşgul eden JavaScript'tir: analitik kodları, pazarlama pikselleri, ağır menü animasyonları, üçüncü taraf sohbet balonları. Sayfa "açılmış" görünür ama tıklayınca donar — ziyaretçinin en çok güven kaybettiği an budur.

CLS — "Zemin ayağımın altından kaydı mı?"

Cumulative Layout Shift, sayfa yüklenirken içeriğin ne kadar zıpladığını ölçer. Yazıyı okurken metnin aşağı kayması, tam "Onayla"ya basarken araya reklam girip "İptal"e basmış olmanız — hepsi CLS'dir. Eşik: 0.1'in altı iyi.

Nedeni neredeyse her zaman aynıdır: boyutu önceden bildirilmemiş öğeler. Genişliği-yüksekliği belirtilmemiş görseller, sonradan yüklenen reklam ve banner alanları, geç gelen yazı tipleri. Çözümü de mimari bir devrim değil, disiplindir: her öğeye yer ayır, sonra yükle.

Karne nereden okunur?

İki farklı kaynak var ve ikisini karıştırmak en yaygın hatadır.

Alan verisi (field data): Chrome kullanıcılarının sitenizde gerçekten yaşadığı deneyimin toplandığı veridir (CrUX). Google sıralamada bunu dikkate alır. PageSpeed Insights'ın üst bölümünde ve Search Console'un Core Web Vitals raporunda görürsünüz. Not: Trafiği düşük sitelerde bu veri hiç oluşmayabilir; bu bir hata değil, örneklem yetersizliğidir.

Laboratuvar verisi (lab data): Lighthouse gibi araçların, standart bir cihaz simülasyonunda yaptığı tek seferlik ölçümdür. Sorun ayıklamak için birebirdir, ama Google'ın gördüğü karne bu değildir. "Lighthouse'ta 95 aldım" cümlesi keyif verir; sıralamayı etkileyen ise gerçek kullanıcıların yaşadığıdır.

Bir incelik daha: Değerlendirme, kullanıcıların yüzde 75'lik dilimine göre yapılır. Yani ofisteki fiber bağlantınızla site hızlı açılıyor diye karne iyi çıkmaz; metroda telefonuyla bağlanan ziyaretçinin deneyimi de karneye dahildir.

Kötü karne nasıl düzelir? Öncelik sırasıyla

Tipik bir sitede kazancın büyükten küçüğe sırası şöyledir:

Görselleri ehlileştirin. Modern format (WebP/AVIF), gerçek boyutunda servis, ekran üstü görsellere öncelik. Çoğu sitede tek başına en büyük LCP kazancı budur.
Üçüncü taraf scriptleri sorgulayın. Her pazarlama pikseli, her sohbet balonu INP'den yer. Soru basit: Bu script geçen ay ne kazandırdı? Cevap yoksa script de olmasın.
Sunucu yanıtını hızlandırın. Sayfa daha gelmeden geçen her yüz milisaniye, LCP'ye peşin yazılır. Önbellekleme, daha iyi hosting veya CDN burada devreye girer.
Yer ayırın. Görsellere boyut, reklam alanlarına sabit yükseklik, yazı tiplerine geçiş stratejisi. CLS büyük oranda bu üç alışkanlıkla çözülür.

Eklenti ile mi, mimari ile mi?

Dürüst olalım: WordPress sitenize bir önbellek eklentisi kurup görselleri sıkıştırarak karneyi kırmızıdan turuncuya, bazen yeşile çekebilirsiniz. Bu meşru ve çoğu zaman yeterli bir yoldur; site zaten iyi kurulmuşsa mimari değiştirmeye gerek olmayabilir.

Ama bir eşik var: Optimizasyon eklentileri üst üste binmeye, birbirini bozmaya ve her tema güncellemesinde yeniden ayar istemeye başladıysa, artık hızı "satın almaya çalışıyorsunuz" demektir. Statik üretilmiş sitelerde bu kavga baştan yoktur: sayfalar hazır dosya olarak CDN'den gelir, LCP doğal olarak düşük, CLS disiplinle sıfıra yakın, INP hafif JavaScript sayesinde rahat eşiğin altındadır. Hız, sonradan eklenen bir özellik değil mimarinin çıktısı olur.

Karnede olmayan ama karneyi etkileyen şey: ölçüm alışkanlığı

Core Web Vitals'ı bir kez ölçüp bırakmak, tartıya yılda bir çıkmak gibidir. Skorlar yaşayan şeylerdir: yeni eklenen bir pazarlama scripti, değişen bir kapak görseli, güncellenen bir tema INP'yi veya LCP'yi bir gecede bozabilir. Pratik öneri: Search Console'un Core Web Vitals raporuna ayda bir bakmayı takvime yazın ve siteye üçüncü taraf bir kod eklendiğinde "skora etkisi ölçüldü mü" sorusunu rutin hâline getirin. Bozulmayı bir hafta içinde yakalamak küçük bir düzeltmedir; bir yıl sonra fark etmek ise arkeolojidir.

Gerçekçi beklenti: karne kaç günde düzelir?

Teknik düzeltmeler yayına girdikten sonra bile alan verisi anında değişmez; CrUX 28 günlük hareketli pencereyle çalışır. Yani bugün yaptığınız iyileştirmenin karneye tam yansıması haftalar alır. Bu, "yaptık ama işe yaramadı" panikleri için en sık görülen açıklamadır: yaramış olabilir, karne henüz güncellenmemiştir. Search Console'daki grafiği izleyin; yönü yukarıysa doğru yoldasınız.

Karnenizi hiç görmediyseniz, beş dakikanızı ayırıp sitenizi PageSpeed Insights'a yazın — okuduklarınızdan sonra rapor artık yabancı dil gibi gelmeyecek. Sonuç kırmızıysa ve eklenti yamalarıyla düzelmiyorsa, sorun büyük ihtimalle makyajlık değil mimariktir. Böyle bir durumu konuşmak isterseniz Vucod'a yazın; her başvuruya 48 saat içinde net bir cevapla dönüyoruz: vucod.com