Core Web Vitals ve Site Hızı Optimizasyonu: LCP, INP ve CLS İçin Kapsamlı Rehber

Core Web Vitals nedir?

Core Web Vitals, Google'ın bir sayfanın kullanıcı deneyimini ölçmek için tanımladığı ve yayımladığı üç temel metrik grubudur. Sayfanın ne kadar hızlı yüklendiğini, kullanıcı etkileşimine ne kadar çabuk yanıt verdiğini ve yüklenirken içeriğin ne kadar kararlı kaldığını ölçerler. Google, bu metrikleri web.dev üzerinden belgeler ve Search Console'da "Core Web Vitals" raporunda siteler için raporlar.

Hız çalışmaları çoğunlukla tek bir skoru yükseltmeye değil, gerçek ziyaretçinin yaşadığı gecikmeyi azaltmaya odaklanmalıdır. Genel SEO içindeki yerini görmek için SEO rehberimizin teknik SEO bölümüne de bakabilirsiniz.

Metrikler ve eşik değerleri

INP, 2024'te FID (First Input Delay) metriğinin yerini alarak Core Web Vitals'ın bir parçası oldu. FID yalnızca ilk etkileşimin gecikmesini ölçerken INP, sayfa ömrü boyunca tüm etkileşimleri değerlendirir. Eşik değerlerin ve tanımların güncel halini her zaman web.dev belgelerinden kontrol edin; Google bunları zamanla güncelleyebilir.

Değerlendirme yöntemi önemlidir: bir sayfanın "geçtiği" söylenebilmesi için gerçek kullanıcı verisinde sayfa yüklemelerinin en az %75'inin ilgili eşik içinde kalması gerekir. Yani birkaç hızlı ölçüm yeterli değildir; kullanıcıların çoğu için tutarlı performans esastır.

Saha verisi ve laboratuvar verisi

Hız ölçümünde iki farklı veri türü vardır ve karıştırılmaları sık yapılan bir hatadır:

• Saha verisi (field data): Gerçek kullanıcıların gerçek cihaz ve ağ koşullarında yaşadığı performans. Chrome Kullanıcı Deneyimi Raporu (CrUX) bu veriyi toplar; Search Console ve PageSpeed Insights'taki "gerçek kullanıcı deneyimi" bölümü buradan beslenir. Core Web Vitals değerlendirmesi saha verisine dayanır.
• Laboratuvar verisi (lab data): Lighthouse gibi araçların kontrollü bir ortamda, sabit cihaz ve ağ simülasyonuyla ürettiği ölçüm. Hataları teşhis etmek ve değişikliği test etmek için çok değerlidir, ancak gerçek kullanıcı deneyiminin birebir yansıması değildir.

Laboratuvarda 100 puan almak, sahada sorunsuz olduğunuz anlamına gelmez; tersine, düşük laboratuvar puanı da her zaman sıralama sorunu demek değildir. Doğru yaklaşım, sahadaki sorunu tespit edip laboratuvarda nedenini bulmak ve düzeltmektir. Yeni veya az trafikli sitelerde CrUX verisi bulunmayabilir; bu durumda laboratuvar verisi ve kendi gerçek kullanıcı ölçümünüz (web-vitals kütüphanesi gibi) yol gösterir.

Hangi araçlarla ölçülür?

Ölçüm yaparken hem mobil hem masaüstü sonuçlarına bakın; Google siteleri esas olarak mobil sürümleri üzerinden dizinler ve mobil koşullar genellikle daha zorlayıcıdır. Tek bir sayfayı değil, ana sayfa, hizmet sayfası, makale ve iletişim sayfası gibi farklı şablonları ayrı ayrı değerlendirin.

LCP nasıl iyileştirilir?

LCP genellikle sayfanın ana görseli, büyük bir başlık bloğu veya hero alanıdır. Gecikmenin nedeni dört parçadan biridir: sunucu yanıt süresi, kaynağın keşfedilmesi, kaynağın indirilmesi ve görüntülenmesi (render). Pratik iyileştirmeler:

• Sunucu yanıtını (TTFB) hızlandırın: CDN kullanın, önbellek ekleyin, statik içeriği mümkün olduğunca önceden üretin.
• LCP görselini erkenden yükletin: LCP görseline loading="lazy" koymayın; fetchpriority="high" kullanın ve gerekirse preload ile bildirin.
• Görsel boyutunu küçültün: Modern format (WebP/AVIF) ve doğru boyutta dosya kullanın.
• Render'ı engelleyen kaynakları azaltın: Kritik olmayan CSS ve JavaScript'i erteleyin.
• Metinsel LCP için: Yazı tipi yüklenmesini beklemeden metin görünsün diye font-display kullanın.
• İçeriği JavaScript ile sonradan çizmeyin: Ana içerik ilk HTML'de bulunuyorsa tarayıcı çok daha erken gösterebilir.

INP nasıl iyileştirilir?

INP, kullanıcı bir şeye tıkladığında ekranın ne kadar çabuk güncellendiğini ölçer. Kötü INP'nin temel nedeni, ana iş parçacığının (main thread) uzun JavaScript görevleriyle meşgul olmasıdır. İyileştirme yolları:

• Uzun görevleri bölün: 50 ms'yi aşan görevleri parçalara ayırın; ağır işlemleri etkileşimden sonraya erteleyin.
• Gönderilen JavaScript miktarını azaltın: Kullanılmayan kodu temizleyin, gereksiz kütüphaneleri kaldırın, kodu bölün (code splitting).
• Etkileşim işleyicilerini hafif tutun: Tıklamada senkron ağır hesaplama yapmayın.
• Üçüncü taraf betikleri sınırlayın: Sohbet, takip ve reklam betikleri etkileşimi geciktirebilir.
• Büyük DOM'dan kaçının: Çok fazla öğe, düzen ve boyama maliyetini yükseltir.
• Animasyonları verimli yazın: Mümkünse düzen tetiklemeyen transform ve opacity kullanın.

CLS nasıl iyileştirilir?

CLS, kullanıcı okurken veya tıklamak üzereyken içeriğin kaymasını ölçer. Genellikle şu nedenlerle oluşur ve şu şekilde önlenir:

• Boyutsuz görseller ve videolar: Her görsele width ve height (veya aspect-ratio) verin; tarayıcı yer ayırsın.
• Sonradan yüklenen reklam, ek içerik ve çerez bannerları: Bunlar için önceden sabit alan ayırın; mevcut içeriğin üstüne ekleme yapmaktan kaçının.
• Yazı tipi değişimi: Yedek font ile asıl font ölçüleri çok farklıysa metin kayar; font-display ve uyumlu yedek font seçimi bunu azaltır.
• Dinamik olarak eklenen öğeler: Kullanıcı etkileşimi sonucu olmayan DOM eklemelerinden kaçının.
• Animasyonlar: Düzeni değiştiren animasyonlar yerine transform kullanın.

Görsel optimizasyonu

Görseller çoğu sitede toplam sayfa ağırlığının en büyük bölümünü oluşturur ve en kolay kazanım alanıdır:

• Modern formatlar: WebP veya AVIF kullanın; fotoğraflarda PNG yerine bu formatlar genellikle çok daha küçük dosya üretir. Şeffaflık gerektiren logolar için de WebP uygundur.
• Doğru boyut: Ekranda 300 piksel görünen görseli 2000 piksel genişlikte yüklemeyin. Gerektiğinde srcset ve sizes ile farklı ekranlara farklı boyut sunun.
• Sıkıştırma: Gözle fark edilmeyen kalite kaybıyla dosya boyutunu belirgin biçimde azaltın.
• Tembel yükleme: Ekranın altındaki görsellere loading="lazy" ekleyin; ancak ilk ekranda görünen (özellikle LCP) görsele eklemeyin.
• Boyut bildirimi: width ve height ile düzen kaymasını önleyin.
• Kod çözme: decoding="async" ana iş parçacığı yükünü azaltabilir.

Örneğin bu sitedeki referans logoları PNG'den WebP'ye çevirmek, toplam logo boyutunu yaklaşık 815 KB'den 234 KB'ye düşürdü. Benzer bir dönüşüm kendi sitenizde de ciddi kazanım sağlayabilir.

Yazı tipi (font) optimizasyonu

• Kullanılan ağırlık ve stil sayısını azaltın: Her ek font varyantı ek bir indirme demektir.
• Yalnızca gerekli karakter kümelerini (subset) yükleyin.
• font-display: swap (veya uygun alternatifi) kullanın: Metin, font inene kadar görünmez kalmasın.
• Kritik fontları önceden yükleyin: preload ile erkenden keşfedilmelerini sağlayın; preconnect üçüncü taraf font sunucusuna bağlantıyı hızlandırır.
• Kendi sunucunuzdan sunmayı değerlendirin: Üçüncü taraf font servisine bağımlılığı azaltabilir; lisans koşullarını kontrol edin.
• Sistem yazı tipi yığını: Performans önceliğinizse fontsuz tasarım en hızlı seçenektir.

JavaScript ve CSS

• Kritik olmayan betikleri ertelenmiş yükleyin: defer veya async ile ilk boyamayı engellemeyin. Betiğin sayfa düzenine veya ilk görünüme etkisi varsa yerleşimi test edin; ilk içeriği betikle gizleyip göstermek LCP'yi geciktirebilir.
• Kullanılmayan kodu temizleyin: Kullanılmayan kütüphaneler, eklentiler ve stil kuralları gereksiz ağırlıktır.
• Küçültme ve sıkıştırma: Minify edin; sunucuda Brotli veya gzip açın.
• Kritik CSS: İlk ekran için gereken stilleri öne alıp geri kalanı sonradan yüklemek render engelini azaltabilir.
• Hazır büyük kütüphanelerden kaçının: Küçük bir iş için büyük bir kütüphane yüklemek maliyetlidir.

Sunucu, CDN ve önbellek

• CDN kullanın: Statik dosyaları ziyaretçiye yakın sunuculardan vermek gecikmeyi azaltır.
• Önbellek başlıkları: Değişmeyen dosyalar (görseller, versiyonlu CSS/JS) için uzun Cache-Control, HTML için kısa veya doğrulamalı önbellek kullanın.
• Güncel protokoller: HTTP/2 veya HTTP/3 ve TLS 1.3 gibi modern protokoller bağlantı maliyetini düşürür; çoğu modern barındırma ve CDN bunu hazır sunar.
• Statik veya önceden üretilmiş sayfalar: Veritabanı sorgusu gerektirmeyen sayfalar çok daha hızlı yanıt verir.
• Yönlendirme zincirlerinden kaçının: Her ek yönlendirme ek bir gidiş-dönüş demektir.

Üçüncü taraf betikler

Analitik, sohbet widget'ları, reklam ve sosyal medya eklentileri, haritalar ve video gömmeleri çoğu zaman yavaşlığın asıl nedenidir. Her biri ek ağ isteği ve JavaScript çalıştırma maliyeti getirir. Şu soruları sorun:

• Bu betik gerçekten gerekli mi, kullanılıyor mu?
• Sayfa yüklendikten sonra veya kullanıcı etkileşiminde mi yüklenebilir?
• Video veya harita gibi ağır gömmeler yerine önce hafif bir önizleme gösterip tıklayınca yüklenebilir mi (facade)?
• Etiket yöneticinizde (ör. Google Tag Manager) kullanılmayan etiketler birikmiş mi?

Üçüncü taraf kullanımı KVKK ve çerez yükümlülükleriyle de kesiştiği için, gereksiz betikleri kaldırmak hem hız hem uyum açısından kazançtır.

Hız ve SEO ilişkisi

Google, sayfa deneyimi sinyallerinin sıralamada rol oynayabileceğini belirtir; ancak bunun içerik uygunluğu ve kalitesinin önüne geçen bir faktör olmadığını da açıkça ifade eder. Yani hızlı ama alakasız bir sayfa, yavaş ama arama niyetine mükemmel cevap veren bir sayfanın önüne geçmeyebilir. Buna karşın hızın dolaylı etkileri güçlüdür:

• Yavaş sayfalarda kullanıcılar daha sık ayrılır; dönüşüm düşer.
• Mobil kullanıcıda hız, memnuniyetin ve güvenin parçasıdır.
• Hızlı ve hafif sayfalar tarama kaynağını daha verimli kullanır.
• Yapay zekâ botları ve diğer tarayıcılar, basit ve hızlı yanıt veren sayfaları daha rahat işler; bunun ayrıntıları için GEO rehberimize bakabilirsiniz.

Yani hız çalışması, SEO'nun "tek başına yeterli" değil ama vazgeçilmez temel katmanıdır. Web sitesi yaptırırken hız ve teknik kalitenin teklif kapsamında olup olmadığını sorun; bu konuyu web sitesi maliyeti rehberimizde da ele aldık.

Önceliklendirilmiş iyileştirme planı

1. Ölç

• Search Console Core Web Vitals raporunda sorunlu sayfa gruplarını bulun.
• PageSpeed Insights ile tipik şablonları (ana sayfa, hizmet sayfası, makale) mobil olarak test edin.

2. En büyük darboğazı bul

• Hangi metrik zayıf: LCP, INP veya CLS?
• LCP öğesi nedir? Hangi kaynak geç yükleniyor? Hangi betik ana iş parçacığını meşgul ediyor?

3. Yüksek etkili düzeltmeleri yap

• Görselleri WebP/AVIF'e çevirin, boyut bildirin, LCP görselini öne alın.
• Fontları azaltın, font-display ve preload kullanın.
• Kullanılmayan JavaScript ve üçüncü taraf betikleri kaldırın veya erteleyin.
• Önbellek başlıklarını ve CDN'i yapılandırın.

4. Doğrula ve izle

• Değişiklikten sonra laboratuvarda yeniden test edin.
• Saha verisi (CrUX, Search Console) güncellenene kadar bekleyin; bu birkaç hafta sürebilir.
• Yeni özellik veya betik eklerken performans bütçesi belirleyin.

Sık yapılan hatalar

• Yalnızca laboratuvar skoruna bakıp sahadaki gerçek sonucu görmemek.
• Yalnızca ana sayfayı test etmek.
• LCP görseline loading="lazy" eklemek.
• Görsellere boyut bildirmeyerek düzen kaymasına yol açmak.
• Çok sayıda font ağırlığı ve üçüncü taraf betik yüklemek.
• Önbellek ve CDN'i yapılandırmadan yalnızca "eklenti kurarak" çözüm aramak.
• Skor peşinde kullanıcı deneyimini bozacak kısıtlamalar yapmak (ör. gerekli içeriği kaldırmak).

Hız kontrol listesi

Sitenizin hız ve teknik durumu için bir değerlendirme almak isterseniz bizimle iletişime geçebilirsiniz. Teknik SEO ve hız çalışmalarının genel dijital strateji içindeki yeri için pillar rehberimize bakabilirsiniz.

Sık sorulan sorular