Core Web Vitals Nasıl İyileştirilir? LCP, INP ve CLS (2026)

Core Web Vitals’ta üç metrik var ve üçünün de net eşiği: LCP 2,5 saniyenin, INP 200 milisaniyenin, CLS 0,1’in altında olmalı. Google puana değil eşiği geçip geçmediğine bakıyor, yani 95 ile 99 arasındaki fark sıralamaya yansımıyor; 2,4 saniye ile 2,6 saniye arasındaki fark yansıyor. İyileştirmeye ölçümden başlanır, tahminden değil. Bu yazıda üç metriği tek tek, en sık karşılaşılan darboğazlar ve çözümleriyle anlatıyoruz.

Üç metrik neyi ölçüyor?

LCP “ne zaman bir şey gördüm”, INP “dokunduğumda ne zaman tepki verdi”, CLS “okurken altımdan kaydı mı” sorusuna cevap veriyor.

Önce ölçümü doğru yap

İyileştirmeye başlamadan önce en sık yapılan üç hata:

Masaüstünde ölçmek. Ziyaretçilerin çoğu mobilde ve mobil ölçüm yavaş CPU ile yapılıyor. Masaüstünde 100 alan bir sayfa mobilde 70’te kalabiliyor.

Tek ölçüme güvenmek. Lighthouse çalıştığı makinenin o anki yüküne duyarlı. Arka planda derleme, tarayıcı sekmeleri veya başka bir iş varken alınan sonuç kayıyor. Doğrusu birkaç tur alıp ortancayı kullanmak.

Laboratuvar ile sahayı karıştırmak. Lighthouse laboratuvar ölçümü; sıralamaya giren ise saha verisi (gerçek ziyaretçilerden toplanan). İkisi farklı sorulara cevap veriyor — laboratuvar teşhis için, saha gerçeği görmek için.

Bu üçü, “sitemiz hızlı” sanılan sayfaların çoğunda yanılgının kaynağı.

LCP nasıl düşürülür?

LCP genelde sayfanın en büyük görseli veya manşet metni oluyor. Önce hangi öğe olduğunu öğren — Lighthouse raporu bunu söylüyor.

Sonra sıklık sırasıyla:

Görsel çok büyük. Ekranda 600 piksel görünen bir görseli 2400 piksel genişlikte göndermek en yaygın hata. Modern biçimler (AVIF, WebP) ve doğru boyutlandırma çoğu zaman tek başına eşiği geçiriyor.

Sunucu yanıtı yavaş. İlk bayt süresi yüksekse geri kalan her şey onun üstüne biniyor. Statik üretim veya önbellekleme burada belirleyici.

Render engelleyen kaynaklar. <head> içinde duran senkron script ve stil dosyaları, boyamayı geciktiriyor.

LCP öğesi geç keşfediliyor. Manşet görseli JavaScript ile ekleniyorsa tarayıcı onu geç buluyor. HTML’de doğrudan durması gerekiyor.

INP neden FID’den zor?

FID yalnızca ilk etkileşimin başlama gecikmesini ölçüyordu; çoğu sayfada yapay olarak iyi çıkıyordu. INP ise sayfa boyunca yaşanan tüm etkileşimlere bakıp en kötülerinden birini raporluyor.

Pratikte INP’yi bozan şey neredeyse her zaman aynı: ana iş parçacığını meşgul eden JavaScript.

• Üçüncü taraf script’leri (sohbet widget’ı, ısı haritası, reklam etiketleri)
• Büyük ve bölünmemiş JavaScript paketleri
• Her kare çalışan kaydırma ve yeniden boyutlandırma dinleyicileri
• Gereğinden sık yeniden render eden bileşenler

Çözüm sırası: önce gerçekten gerekli olmayan üçüncü taraf kodunu kaldır, sonra kalanı geciktir, en son kendi kodunu böl. Bir sohbet widget’ını kaldırmak, haftalarca süren kod optimizasyonundan daha çok kazandırıyor.

CLS nasıl sıfırlanır?

CLS’i bozan üç şey var ve üçünün çözümü aynı: alanı önceden ayır.

Boyutsuz görseller. width ve height nitelikleri veya aspect-ratio olmadan görsel yüklenince altındaki her şey kayıyor.

Sonradan gelen yazı tipi. Yedek font ile asıl font farklı genişlikteyse metin yerinden oynuyor. font-display: swap ve ölçüleri yakın bir yedek stack bunu küçültüyor.

Dinamik eklenen bloklar. Çerez bandı, duyuru şeridi, reklam alanı — sayfanın üstüne sonradan eklenirse altındaki her şeyi aşağı itiyor. Çözüm, o alanı baştan rezerve etmek ya da içeriği itmeyen bir konumda göstermek.

CLS, üç metrik içinde en kolay sıfırlanabilen olanı. Bir kez düzeltildiğinde kalıcı oluyor.

Ekran altındaki içerik neden önemli?

Az bilinen ama etkisi büyük bir kalem: tarayıcı, ekranda görünmeyen bölümlerin düzenini de ilk boyamada hesaplıyor. Uzun bir anasayfada bu, ana iş parçacığının en büyük kalemi hâline gelebiliyor.

Çözüm, ekran altındaki bölümlere content-visibility: auto vermek. Tarayıcı o alt ağaçların düzenini görüş alanına yaklaşana kadar atlıyor. İçerik DOM’da aynen kalıyor — HTML kaynağında görünür, arama motoru ve yapay zekâ tarayıcıları okur, Ctrl+F bulur. Yani SEO açısından kaybedilen bir şey yok.

Bir şart var: contain-intrinsic-size ile tahmini bir yükseklik vermek. Verilmezse kaydırma çubuğu zıplıyor.

Bu sitede anasayfanın mobil performansı 85’ten 95’e bu yöntemle çıktı; ana iş parçacığındaki “Style & Layout” kalemi belirgin biçimde düştü.

Ölçümü sürekli nasıl tutarsın?

Hız bir kerelik iş değil. Her yeni bileşen, her yeni üçüncü taraf script’i, her büyük görsel biraz geri götürüyor.

Sürdürülebilir yaklaşım:

• Ağırlık ekleyen her değişiklikten sonra ölçüp önceki tabanla karşılaştırmak
• Search Console’daki Core Web Vitals raporunu aylık kontrol etmek (saha verisi orada)
• Yeni bir üçüncü taraf script’i eklemeden önce “bu olmadan olur mu” diye sormak

Sitenin bütününe dair maddeleri kurumsal web sitesi nasıl olmalı yazısında topladık; reklamdan gelen trafiğin indiği sayfa için açılış sayfası nasıl olmalı yazısına bakabilirsin.

Sık sorulan sorular

Lighthouse puanı 100 olmalı mı?

Olmasına gerek yok. Google sıralama sinyali olarak puana değil, üç metriğin eşiği geçip geçmediğine bakıyor. LCP 2,4 saniye ile 2,6 saniye arasındaki fark önemli; 95 puan ile 99 puan arasındaki fark değil. Eşikleri geçtikten sonra kalan efor başka yere harcanabilir.

Laboratuvar ölçümü ile saha verisi neden farklı çıkıyor?

Lighthouse tek bir cihazda, sabit koşullarda ölçüyor; saha verisi (CrUX) ise gerçek ziyaretçilerin gerçek cihazlarında toplanıyor. İkisi farklı sorulara cevap veriyor: laboratuvar “bu sayfada ne yavaş”, saha “ziyaretçilerim ne yaşıyor”. Sıralamaya giren saha verisi, teşhis için ise laboratuvar daha kullanışlı.

INP, FID’in yerine mi geçti?

Evet. FID yalnızca ilk etkileşimin başlama gecikmesini ölçüyordu ve çoğu sayfada yapay şekilde iyi çıkıyordu. INP ise sayfa boyunca yaşanan tüm etkileşimlere bakıp en kötülerinden birini raporluyor, yani gerçek kullanım hissine çok daha yakın. Eşik 200 milisaniye.

CLS’i en çok ne bozuyor?

Boyutu belirtilmemiş görseller, sonradan yüklenen yazı tipleri, dinamik olarak eklenen banner ve reklam blokları. Üçünün ortak noktası aynı: tarayıcı yer ayırmadan içerik ekliyor ve altındaki her şey kayıyor. Çözüm de aynı: alanı önceden ayırmak.

Hız iyileştirmesi dönüşümü gerçekten artırır mı?

Artırıyor ama bunu tek başına bir sihir sayma. Reklamdan gelen ziyaretçi sabırsız olduğu için açılış sayfalarında etkisi en net görülüyor. Yine de yavaş bir sayfayı hızlandırmak zayıf bir teklifi kurtarmıyor; hız bir engeli kaldırıyor, talebi yaratmıyor. Web tasarım hizmetimizde hızı teslimatın ölçülen bir parçası sayıyoruz.

Nereden başlamalısın?

Lighthouse’u mobil ayarında, sakin bir makinede, üç tur çalıştır ve ortancayı al. Sonra tek bir soruya cevap ver: hangi metrik eşiği geçmiyor?

Üçü de geçiyorsa hız sorunun yok — eforu başka yere ayır. Geçmeyen varsa bu yazıdaki ilgili bölümden başla; çoğu sitede tek bir darboğaz üçünü birden bozuyor.

Ücretsiz Strateji Görüşmesi için bize yaz — sayfalarını ölçer, hangi darboğazın hangi metriği bozduğunu çıkarırız.