Core Web Vitals: LCP, INP ve CLS Nasıl Düzeltilir?

Core Web Vitals, bir sayfanın kullanıcıya ne kadar iyi hizmet ettiğini üç ölçüyle özetler: içerik ne zaman görünüyor, tıklamaya ne kadar hızlı cevap veriyor ve sayfa yerleşimi ne kadar kararlı. Üçünün de sebepleri ayrıdır; bu yüzden "siteyi hızlandıralım" gibi genel bir yaklaşım nadiren sonuç verir.

Core Web Vitals tam olarak neyi ölçer?

Üç metrik ve geçerli eşik değerleri şöyledir. Değerlendirme, gerçek kullanıcı ölçümlerinde 75. yüzdelik dilim üzerinden yapılır; yani ziyaretlerinizin dörtte üçü eşiğin altında kalmalıdır.

INP, 2024 Mart ayında FID metriğinin yerini aldı. FID yalnızca ilk etkileşimin gecikmesini ölçüyordu; INP ise sayfadaki tüm etkileşimleri değerlendirdiği için gerçek kullanım hissine çok daha yakındır ve geçmek daha zordur.

Laboratuvar verisi ile saha verisi neden farklı çıkar?

Lighthouse ve PageSpeed Insights sayfanın üst kısmında laboratuvar (lab) sonucu gösterir: belirlenmiş bir cihaz ve bağlantı profiliyle yapılan tek bir ölçüm. Aynı sayfanın üstünde bir de saha (field) verisi vardır; bu, gerçek kullanıcıların tarayıcılarından toplanan CrUX verisidir ve son 28 günü kapsar.

Sıralamayı ve Search Console raporunu belirleyen saha verisidir. Laboratuvar sonucu yeşil olduğu hâlde saha verisi kırmızı olabilir; bunun tipik sebebi kullanıcıların daha yavaş cihaz ve bağlantılarla, farklı sayfa varyantlarıyla ve önbelleksiz olarak gelmesidir. Düzeltmeden sonra saha verisinin toparlanması 28 günlük pencere nedeniyle haftalar alır; hemen sonuç göremediğinizde paniğe kapılmayın.

LCP neden yavaş, nasıl düzeltilir?

LCP genellikle görünen alandaki büyük bir görselden, arka plan görselinden ya da başlık metninden kaynaklanır. Süre dört parçaya ayrılır ve hangisinin baskın olduğunu bilmeden yapılan iyileştirme çoğu zaman boşa gider.

• Sunucu yanıt süresi (TTFB): Hedef 800 ms altıdır. Yavaşsa sebep genellikle veritabanı sorguları, önbelleksiz sayfa üretimi veya uzak bir sunucudur. Sayfa önbelleği, sorgu optimizasyonu ve CDN kullanımı en hızlı kazanımı burada verir.
• Kaynak yükleme gecikmesi: LCP görseli geç keşfediliyorsa gecikir. Görsel CSS arka planıysa, JavaScript ile ekleniyorsa veya tembel yükleme (lazy load) uygulanmışsa tarayıcı onu geç görür. Görünen alandaki görselde lazy load kullanılmaz; aksine fetchpriority yüksek verilir ve gerekiyorsa önceden yüklenir.
• Kaynak yükleme süresi: Görselin kendisi büyükse süre uzar. WebP veya AVIF formatı, doğru boyutlandırma ve duyarlı görsel tanımları burada belirleyicidir. Kapak görselinin 1,5 MB olduğu siteler hâlâ yaygındır.
• Öğe render gecikmesi: Görsel indiği hâlde ekranda çizilmiyorsa sebep genellikle render engelleyici CSS veya web fontlarıdır. Kritik CSS satır içine alınır, geri kalanı ertelenir; fontlarda font-display: swap kullanılır.

INP yüksekse sorun nerededir?

INP, kullanıcının tıklaması ile ekranda bir değişiklik görmesi arasındaki süreyi ölçer. Neredeyse her zaman tek bir sebebi vardır: ana iş parçacığı meşguldür. Tarayıcı JavaScript çalıştırırken kullanıcı etkileşimine cevap veremez.

Yapılacaklar sırasıyla şunlardır:

1. Uzun görevleri bölün. 50 ms üzerindeki her görev uzun görev sayılır. Büyük bir döngüyü parçalara ayırmak, aralarda tarayıcıya nefes aldırmak INP üzerinde doğrudan etki yapar.
2. Gereksiz JavaScript kaldırın. Kullanılmayan eklentiler, çift yüklenen kütüphaneler, tek bir animasyon için eklenen ağır paketler. Kullanılmayan kodu ölçmek için tarayıcının kapsam (coverage) aracı yeterlidir.
3. Üçüncü taraf betikleri denetleyin. Sohbet widget'ları, ısı haritası araçları, çoklu reklam ve piksel kodları INP'yi bozan en yaygın kalemdir. Her birinin gerçekten gerekli olup olmadığını sorgulayın, gerekli olanları etkileşim sonrasına erteleyin.
4. Etiket yöneticisini temizleyin. Yıllar içinde biriken ve artık kimsenin bakmadığı etiketler, her sayfa görüntülemesinde çalışmaya devam eder.
5. Görsel geri bildirimi öne alın. Tıklamadan sonra ağır işi yapmadan önce arayüzde küçük bir değişiklik gösterin. Kullanıcı yanıt aldığını görür, ölçüm de bunu kaydeder.

CLS neden oluşur, nasıl sıfıra yaklaşır?

CLS, sayfa yüklenirken içeriğin yer değiştirmesidir. Kullanıcı bir bağlantıya tıklamak üzereyken düğmenin kayması bu metriğin ölçtüğü şeydir. Sebepleri sınırlıdır ve hepsi çözülebilir:

• Boyutu belirtilmemiş görseller. Her img etiketine genişlik ve yükseklik değeri verin; tarayıcı yeri baştan ayırır. Video ve iframe için de aynısı geçerlidir.
• Web fontları. Yedek font ile asıl font arasındaki ölçü farkı metni oynatır. Yerel yedek fontun ölçülerini asıl fonta yaklaştıran ayarlar bu kaymayı büyük ölçüde giderir.
• Sonradan eklenen bloklar. Çerez bildirimi, duyuru şeridi, reklam alanı ve öneri kutuları içeriğin üstüne geldiğinde her şeyi aşağı iter. Bu alanlar için yer baştan ayrılmalı ya da bloklar mevcut içeriğin üstünde katman olarak açılmalıdır.
• Geç yüklenen CSS. Stil dosyası geç geldiğinde sayfa önce biçimsiz görünür, sonra yerleşir. Kritik stiller ilk yanıtta gelmelidir.

CLS düzeltmesi, üç metrik içinde genellikle en ucuz ve en kesin sonuç verenidir. Çoğu sitede birkaç günlük çalışmayla 0,1 eşiğinin altına inilebilir.

Hangi araçla ölçmeli?

Her aracın işlevi farklıdır; birini diğerinin yerine kullanmak yanlış sonuca götürür.

• Search Console Core Web Vitals raporu: Sitenizin tamamı için saha verisini URL grupları hâlinde gösterir. Nereden başlayacağınızı burası söyler.
• PageSpeed Insights: Tek bir URL için hem saha hem laboratuvar verisi verir.
• Lighthouse ve tarayıcı geliştirici araçları: Düzeltme sırasında kullanılır; performans kaydı, uzun görevleri ve kayma yaratan öğeleri tek tek gösterir.
• Kendi ölçümünüz (RUM): Gerçek kullanıcılardan metrik toplayan küçük bir kod, 28 günlük gecikme olmadan sonuç verir. Trafiği yüksek siteler için en değerli kaynaktır.

Core Web Vitals sıralamayı ne kadar etkiler?

Bu metrikler sıralama sinyalidir, ancak içerik uygunluğunun yerine geçmez. Konusuyla ilgisiz hızlı bir sayfa, ilgili ve yavaş bir sayfayı geçmez. Etkisi, benzer kalitedeki sayfalar arasında ayrıştırıcı olmaktır.

Buna karşılık dolaylı etkisi doğrudan etkisinden büyüktür. Yavaş açılan sayfa terk edilir, terk edilen sayfa dönüşüm üretmez ve sayfada geçirilen süre düşer. Yani bu çalışmayı yalnızca arama motoru için değil, ziyaretçinin gerçekten sayfada kalması için yaparsınız.

Mobil ve masaüstü neden ayrı değerlendirilir?

Core Web Vitals ölçümleri mobil ve masaüstü için ayrı tutulur ve iki taraf çoğu zaman çok farklı sonuç verir. Sebep basittir: mobil cihazların işlemci gücü daha düşük, bağlantı kalitesi daha değişkendir. Masaüstünde sorunsuz çalışan bir JavaScript paketi, orta seviye bir telefonda ana iş parçacığını saniyelerce meşgul edebilir.

Bu yüzden düzeltmeleri mobil öncelikli yapmak gerekir. Ölçüm sırasında tarayıcının işlemci kısıtlama ayarını kullanmak, geliştirme makinenizde hiç göremeyeceğiniz sorunları ortaya çıkarır. Kendi telefonunuzda test etmek de yeterli değildir; kullanıcılarınızın cihaz dağılımına analitikten bakıp ortalamanın altındaki bir cihazı referans almak daha doğru bir yöntemdir.

Sık yapılan üç yanlış nedir?

• Lighthouse puanını hedef almak. Puan, birden çok göstergenin ağırlıklı özetidir ve Core Web Vitals ile birebir aynı şey değildir. Puanı yükseltmek için yapılan bazı düzenlemeler gerçek kullanıcı deneyimine katkı sağlamaz.
• Her şeyi ertelemek. Tüm betikleri ertelemek INP tarafında iyileşme gösterebilir ama etkileşimin ilk saniyelerde hiç çalışmamasına yol açabilir. Erteleme kararı, öğenin görünen alanda olup olmadığına ve kullanıcının onunla ne zaman etkileşeceğine göre verilir.
• Önbelleği tek çözüm sanmak. Önbellek sunucu yanıt süresini düşürür, tarayıcının yapacağı işi azaltmaz. INP sorunları önbellekle çözülmez; JavaScript miktarını azaltmakla çözülür.

Nereden başlamalı?

Sırayla ilerlemek işi hem hızlandırır hem de yapılan işin etkisini ölçülebilir kılar:

1. Search Console raporundan en çok trafik alan ve eşiği geçemeyen URL grubunu seçin.
2. Bu grubun temsilcisi bir sayfayı PageSpeed Insights ile ölçün, saha ve laboratuvar farkını not edin.
3. Önce CLS'yi kapatın; en düşük maliyetli kazanç oradadır.
4. LCP için sunucu yanıt süresini ve kapak görselini ele alın.
5. INP için üçüncü taraf betikleri gözden geçirin, gereksizleri kaldırın.
6. Değişiklikleri yayına aldıktan sonra dört hafta bekleyip saha verisini yeniden okuyun.

Bir noktayı baştan kabul etmek gerekir: performans tek seferlik bir proje değildir. Her yeni eklenti, her yeni takip kodu ve her yeni kampanya bölümü metrikleri geri götürebilir. Bu yüzden yayına alma sürecine küçük bir performans bütçesi koymak, altı ayda bir baştan optimizasyon yapmaktan çok daha ucuzdur.