Core Web Vitals optimizasyonu, sayfa hızı efsanelerinden uzaklaşıp LCP, INP ve CLS metriklerini ölçülebilir ve önceliklendirilebilir işlere çevirmektir. Bu rehberde her metriği nasıl teşhis edeceğinizi, hangi sorunu önce çözeceğinizi ve laboratuvar ile saha verisini nasıl birlikte okuyacağınızı bulacaksınız.
Core Web Vitals optimizasyonu çoğu sitede “sayfa daha hızlı açılsın” cümlesine indirgenir. Oysa Google’ın izlediği üç metrik — LCP, INP ve CLS — hız efsanesi değil; yükleme, etkileşim ve görsel kararlılık için ayrı teşhis dilleri sunar. Bu rehberde üç metriği tek bir genel hız hedefine yığmadan ölçer, kök nedeni ayırır ve iş listesini önceliklendirirsiniz.
Amaç, laboratuvar skoru peşinde koşmak değil; gerçek kullanıcı deneyimini bozan en maliyetli sorunu önce bulmaktır. KepezWeb ekibinin saha çalışmalarında da en sık görülen hata, hepsini aynı anda “optimize etmeye” çalışmak ve hiçbirini bitirmemektir.
Core Web Vitals nedir, ne değildir?
Core Web Vitals, bir sayfanın kullanıcıya nasıl hissettirdiğini üç eksende özetler:
- LCP (Largest Contentful Paint): Ana içeriğin ne kadar hızlı göründüğü
- INP (Interaction to Next Paint): Tıklama, dokunma ve klavye girişine yanıtın ne kadar akıcı olduğu
- CLS (Cumulative Layout Shift): Sayfa yerleşiminin ne kadar sarsıldığı
Bunlar “site yavaş” cümlesinin yerine geçen teşhis araçlarıdır. TTFB iyi olsa da LCP kötü olabilir. Toplam JS boyutu makul görünse de ana iş parçacığı tıkalı olduğu için INP bozulabilir. Görseller sıkıştırılmış olsa da boyut rezervi verilmediği için CLS artabilir.
Önemli bir ayrım: laboratuvar verisi (Lighthouse, PageSpeed Insights’ın simüle kısmı) tekrarlanabilir teşhis içindir; saha verisi (CrUX, Search Console) gerçek kullanıcı dağılımını gösterir. Kararı saha verisi, müdahaleyi laboratuvar teşhisi yönlendirir.
Ölçüm dili: önce hangi veriyi okuyacaksınız?
Core Web Vitals optimizasyonuna “hemen kod değiştirerek” başlamak en pahalı yoldur. Önce hangi URL grubunun, hangi cihazda ve hangi metrikte bozulduğunu netleştirin.
Saha ve laboratuvarı birlikte kullanın
- Search Console’daki Core Web Vitals raporundan mobil ve masaüstü URL gruplarını ayırın.
- Kötü veya iyileştirme gereken URL örneklerini PageSpeed Insights ve Chrome DevTools ile açın.
- LCP öğesini, uzun görevleri ve layout shift kaynaklarını kaydedin.
- Aynı sorunun şablon mu (ürün listesi, blog yazısı, sepet) yoksa tek sayfa mı olduğunu işaretleyin.
Şablon sorunuysa tek sayfa düzeltmek yetmez; bileşen düzeyinde müdahale gerekir. Tek sayfa sorunuysa içerik, kampanya görseli veya üçüncü parti script gibi yerel bir neden aranır.
Önceliklendirme için basit matris
Her bulguyu üç soruyla sıralayın:
- Etkilenen trafik ne kadar geniş?
- Metrik “kötü” mü yoksa “iyileştirme gerekir” bandında mı?
- Düzeltme şablon geneline yayılabilir mi?
Geniş trafikli şablon + kötü bant + tekrar kullanılabilir düzeltme kombinasyonu her zaman listenin tepesine çıkar. Küçük bir blog yazısındaki tek seferlik görsel kayması, ürün listeleme şablonundaki LCP sorunundan sonra gelir.
LCP optimizasyonu: ana içeriği görünür kılın
LCP, ekranda en büyük anlamlı öğenin boyanma zamanıdır. Çoğu sitede bu hero görseli, ürün görseli, büyük başlık bloğu veya slider’daki ilk karedir. LCP’yi “tüm sayfayı hızlandırma” işi gibi değil, “o öğeyi engelleyen zinciri kısaltma” işi gibi ele alın.
LCP teşhis adımları
- DevTools Performance veya Lighthouse’ta LCP öğesini belirleyin.
- Öğenin sunucu yanıtı, kaynak keşfi, indirme ve render aşamalarından hangisinde takıldığını ayırın.
- Öğe görselse boyut, format, öncelik ipucu ve CSS arkasında kalma durumuna bakın.
- Öğe metinse web fontu, kritik CSS ve üstteki engelleyici script’leri kontrol edin.
Sık LCP kök nedenleri ve müdahale sırası
- Geç keşfedilen hero görseli: HTML’de erken referans, uygun fetchpriority ve gereksiz lazy-load kaldırma
- Ağır medya: modern format, doğru boyut, gereksiz 2x/3x varyantları temizleme
- Kritik render yolu: üstteki CSS/JS’i sadeleştirme, render-blocking kaynakları azaltma
- Yavaş ilk bayt: sunucu ve önbellek katmanını ayrı iş olarak ele alma; LCP’nin tamamını hosting’e yüklemeyin
Hero alanı LCP’nin sık kaynağıdır. Mesaj ve görsel hiyerarşisini sadeleştirmek hem algıyı hem ölçümü iyileştirir; bu konuda hero section tasarımı kararları da teknik optimizasyonla birlikte düşünülmelidir.
INP optimizasyonu: etkileşimi tıkayan işi azaltın
INP, kullanıcının sayfayla etkileşime girdiği andan bir sonraki boyamaya kadar geçen süreyi izler. Eski FID odaklı düşünce artık yetmez; tek bir “ilk gecikme” değil, oturum boyunca zayıf etkileşimler de skoru bozar.
INP’yi nasıl teşhis edersiniz?
Laboratuvarda Interaction veya Performance paneliyle uzun görevleri, zorunlu yeniden hesaplamaları ve ana iş parçacığını meşgul eden script’leri görün. Sahada ise yavaş etkileşimlerin hangi sayfa şablonunda ve hangi olayda (menü, filtre, sepete ekle, sekme değiştirme) yoğunlaştığına bakın.
Uygulanabilir INP iş listesi
- Büyük JS paketlerini sayfa ihtiyacına göre bölün; kullanılmayan kodu yüklemeyin.
- Tıklama işleyicilerini sadeleştirin; ağır hesaplamayı etkileşim anından sonraya kaydırın.
- Üçüncü parti etiketleri envanterleyin; aynı işi yapan pikselleri birleştirin veya erteleyin.
- Ağır DOM güncellemelerini parçalayın; bir tıklamada tüm listeyi yeniden boyamaktan kaçının.
- Mobil menü, filtre paneli ve sepet drawer gibi sık kullanılan bileşenleri ayrı profilleyin.
E-ticaret sitelerinde filtre ve sepete ekle etkileşimleri INP’nin en görünür kırılma noktalarıdır. Bu yüzden e-ticaret sitesi performansında sadece görsel sıkıştırmaya odaklanmak yetmez; arayüz olaylarının maliyeti de ölçülmelidir.
CLS optimizasyonu: yerleşimi önceden kilitleyin
CLS, beklenmedik kaymaların toplam etkisini ölçer. Kullanıcı bir düğmeye basmak üzereyken öğenin kayması hem güveni hem dönüşümü bozar. CLS çoğu zaman “ağır site” sorunu değil, “boyut bilinmeyen öğe” sorunudur.
Klasik CLS kaynakları
- width/height veya aspect-ratio verilmemiş görseller ve videolar
- Geç yüklenen web fontlarının metni yeniden akıtması
- Üstte aniden açılan çerez bandı, kupon çubuğu veya bildirim şeridi
- Reklam ve gömülü içerik alanlarının yüksekliğinin sonradan dolması
- İskelet yerine boş alan bırakıp sonra içeriği basan bileşenler
Teşhisten düzeltmeye
- Layout Shift Regions ile hangi öğenin ne zaman kaydığını izleyin.
- Kayma kullanıcı etkileşiminden sonra mı, yoksa yükleme sırasında mı oluşuyor ayırın.
- Medya ve embed alanlarına sabit alan ayırın.
- Font-display ve yedek font metriklerini yaklaştırarak metin sıçramasını azaltın.
- Sabit üst bar ve sticky öğelerin içeriği itip itmediğini mobil kırılımlarda kontrol edin.
CLS düzeltmeleri çoğu zaman küçük ama yüksek etkili işlerdir. Boyut rezervi vermek, bir kampanya banner’ını “sürpriz” olarak en üste basmamak veya reklam yuvasına min-height tanımlamak, haftalar süren altyapı projelerinden daha hızlı sonuç verebilir.
Üç metriği tek iş listesinde birleştirme
LCP, INP ve CLS aynı sprint’te “hepsi birden” ele alınırsa ekip dağılır. Daha sağlıklı akış şöyledir:
- Saha verisinde en kötü ve en geniş etkili metriği seçin.
- O metrik için şablon düzeyinde kök nedeni bulun.
- Düzeltmeyi ölçülebilir bir kabul kriteriyle yayınlayın.
- Aynı URL grubunu birkaç gün/hafta saha verisiyle izleyin.
- Sonra ikinci metriğe geçin.
Pratik bir sıra çoğu sitede şöyle ilerler: önce LCP (kullanıcı içeriği görsün), sonra CLS (yerleşim sarsılmasın), ardından INP (etkileşim akıcı olsun). Ancak sepet ve hesap paneli gibi etkileşim ağırlıklı sayfalarda INP öne alınabilir.
| Metrik | Ne sorar? | Önce bakılacak yer | Tipik ilk müdahale |
|---|---|---|---|
| LCP | Ana içerik ne zaman göründü? | Hero, ürün görseli, kritik CSS/JS | LCP öğesini erken keşfetmek ve hafifletmek |
| INP | Etkileşim ne kadar geç yanıt verdi? | Ana iş parçacığı, uzun görevler, etiketler | JS yükünü ve olay işleyicilerini sadeleştirmek |
| CLS | Yerleşim ne kadar kaydı? | Görseller, fontlar, banner/reklam alanları | Alan rezervi ve geç basılan UI’yi sabitlemek |
Core Web Vitals efsaneleri ve gerçek teşhis
Birçok ekip hâlâ genel “hız ipuçları” listesiyle ilerliyor. Aşağıdaki ayrımlar iş listesini temizler:
- Efsane: “CDN açtık, Core Web Vitals bitti.” Gerçek: CDN ağ mesafesini kısaltır; LCP öğesi lazy-load ile gecikiyorsa veya JS tıkalıysa yetmez.
- Efsane: “Lighthouse 90+ aldık, sorun yok.” Gerçek: Laboratuvar skoru teşhistir; saha dağılımı farklı cihaz ve ağlarda bozulabilir.
- Efsane: “Görselleri sıkıştırırsak INP düzelir.” Gerçek: Görsel boyutu çoğunlukla LCP ve bazen CLS’yi etkiler; INP için script ve olay maliyeti gerekir.
- Efsane: “Tema değişince her şey düzelir.” Gerçek: Yeni tema yeni LCP öğesi, yeni font ve yeni üçüncü parti yığını getirebilir.
Bu yüzden SEO hizmeti kapsamında Core Web Vitals’ı içerik ve tarama işlerinden ayrı, kendi ölçüm ve öncelik diliyle yönetmek gerekir. Tasarım tarafında da gereksiz animasyon, ağır slider ve plansız üst bar kararları metrikleri bozabilir; sade bir web tasarım yaklaşımı performans işini baştan kolaylaştırır.
Yayın sonrası kontrol listesi
Bir düzeltme canlıya alındığında iş bitmiş sayılmaz. Kısa bir doğrulama döngüsü kurun:
- Etkilenen şablonda laboratuvar ölçümünü aynı senaryoyla tekrarlayın.
- LCP öğesinin değişip değişmediğini kontrol edin; bazen düzeltme yeni bir LCP adayı yaratır.
- Mobil gerçek cihazda menü, filtre ve form etkileşimlerini elle deneyin.
- Search Console URL gruplarını izleyerek gerileme olup olmadığına bakın.
- Yeni etiket, slider veya kampanya bileşeni eklenirken aynı üç metriği “kabul kriteri” yapın.
KepezWeb olarak performans işini tek seferlik bir “hız paketi” gibi değil, yayın alışkanlığına gömülü bir kalite kapısı gibi ele almayı öneririz. Her yeni bileşenin LCP adayı, INP maliyeti ve CLS riski var mıdır sorusu, sonradan yangın söndürmekten daha ucuzdur.
Sıkça Sorulan Sorular
Core Web Vitals optimizasyonuna hangi metrikten başlamalıyım?
Saha verisinde en kötü bantta olan ve en çok URL’yi etkileyen metrikten başlayın. Trafiği yüksek şablonlarda LCP sık öne çıkar; etkileşim yoğun panellerde INP öncelik alabilir.
Lighthouse skorum iyi, Search Console neden hâlâ sorun gösteriyor?
Lighthouse kontrollü bir ortam simülasyonudur. Search Console ise gerçek kullanıcıların cihaz, ağ ve davranış dağılımını yansıtır. Karar için saha verisini, kök neden için laboratuvarı kullanın.
INP ile eski FID aynı şey midir?
Hayır. FID çoğunlukla ilk etkileşim gecikmesine bakardı. INP, sayfa yaşamı boyunca etkileşimlerin ne kadar akıcı kaldığını daha geniş ölçer; bu yüzden menü, filtre ve sepet gibi tekrarlayan olaylar daha kritik hale gelir.
CLS için yalnızca görsel boyutlandırmak yeterli mi?
Görsel boyutları temel adımdır ama yeterli değildir. Geç açılan çubuklar, font kayması, reklam yuvaları ve dinamik banner’lar da CLS üretir. Kaymanın kaynağını Layout Shift araçlarıyla tek tek doğrulayın.
Core Web Vitals düzeltmesi SEO’da ne işe yarar?
Daha iyi deneyim, sayfanın kullanılabilirliğini ve etkileşim kalitesini yükseltir. Bu, teknik SEO hijyeninin bir parçasıdır; tek başına içerik ve alaka düzeyinin yerini almaz, ancak zayıf deneyimin yarattığı sürtünmeyi azaltır.
Üç metriği ölçülebilir işlere çevirmek istiyor, şablon bazlı öncelik listesi ve uygulama planı mı arıyorsunuz? KepezWeb ile mevcut saha verinizi birlikte okuyup net bir müdahale sırası çıkarabiliriz. Projenizi anlatmak için teklif al sayfasından bize ulaşmanız yeterli.
