Core Web Vitals Nedir ve Nasıl İyileştirilir?

Core Web Vitals, Google'ın bir sayfanın gerçek kullanıcılar için ne kadar iyi çalıştığını ölçmek üzere belirlediği üç ölçüttür: ana içeriğin ne kadar hızlı göründüğü (LCP), sayfanın etkileşimlere ne kadar çabuk tepki verdiği (INP) ve sayfa düzeninin yüklenirken ne kadar sabit kaldığı (CLS). Değerlendirme, gerçek ziyaretlerden toplanan verinin 75. yüzdelik dilimine göre, mobil ve masaüstü için ayrı ayrı yapılır. Yani bir sayfanın “iyi” sayılması için ziyaretlerin en az dörtte üçünde her ölçütün iyi eşiğini karşılaması gerekir.

Bu ölçütler Google'ın sayfa deneyimi sinyalleri arasındadır, ancak sıralamada içeriğin konuyla ilgisinin yerini tutmaz. Asıl etkileri kullanıcı üzerindedir: Geç açılan, dokunulduğunda donan ya da okunurken kayan bir sayfa, hem ziyaretçi kaybettirir hem de reklam bütçesinin bir kısmını boşa harcatır. Aşağıda her ölçütün ne olduğunu, nasıl iyileştirildiğini, hangi araçlarla ölçüldüğünü ve işe nereden başlanacağını anlatıyoruz.

LCP

Largest Contentful Paint (LCP), sayfa açılmaya başladıktan sonra ekrandaki en büyük görselin ya da metin bloğunun görüntülendiği ana kadar geçen süredir. 2,5 saniye ve altı iyi, 2,5 ile 4 saniye arası iyileştirilmeli, 4 saniyenin üzeri zayıf kabul edilir. LCP dört parçaya ayrılarak incelenir: sunucunun ilk yanıtı (TTFB), LCP kaynağının istenmeye başlamasındaki gecikme, kaynağın indirilme süresi ve öğenin ekrana çizilmesindeki gecikme. Hangi parçanın uzun olduğu, çözümün nerede aranacağını gösterir.

Sık görülen bir senaryo, ana sayfadaki büyük tanıtım görselinin JavaScript ile çalışan bir kaydırıcı (slider) içinde, tembel yükleme ayarıyla sunulmasıdır; tarayıcı görseli ancak betikler çalıştıktan sonra fark eder. Çözüm, LCP görselini HTML'de doğrudan yer alacak biçimde sunmak, tembel yüklemeden çıkarmak, fetchpriority="high" ile önceliklendirmek, doğru boyut ve modern biçimde hazırlamaktır. Sunucu tarafında önbellek ve CDN kullanımı, işlemeyi engelleyen CSS ve JavaScript dosyalarının azaltılması ve yazı tiplerinin verimli yüklenmesi de LCP'yi doğrudan iyileştirir.

INP

Interaction to Next Paint (INP), ziyaretçinin sayfadaki tıklama, dokunma ve klavye etkileşimlerinden sonra sayfanın bir sonraki görsel güncellemeyi ne kadar sürede ekrana yansıttığını ölçer. Ziyaret boyunca gözlenen en yavaş etkileşim esas alınır; çok sayıda etkileşim olan sayfalarda aşırı uç değerler hesaba katılmaz. 200 milisaniye ve altı iyi, 200 ile 500 milisaniye arası iyileştirilmeli, 500 milisaniyenin üzeri zayıftır. INP, Mart 2024'te First Input Delay (FID) ölçütünün yerini aldı; FID yalnızca ilk etkileşimin bekleme süresini ölçerken INP tüm etkileşimleri ve tepkinin ekrana yansıma süresini hesaba katar.

Kötü INP'nin başlıca nedeni, tarayıcının ana iş parçacığını uzun süre meşgul eden JavaScript görevleridir. Örneğin bir ürün listesinde filtreye tıklandığında tüm listenin tek seferde yeniden hesaplanması sayfayı kısa süreliğine dondurur. İyileştirme için uzun görevler küçük parçalara bölünür, kritik olmayan betikler ertelenir, üçüncü taraf etiketleri gözden geçirilir ve tıklamaya önce hızlı bir görsel geri bildirim verilip ağır işlem arkadan yapılır. Hangi etkileşimin yavaş olduğunu görmek için gerçek kullanıcı verisini etkileşim ayrıntısıyla toplamak gerekir.

CLS

Cumulative Layout Shift (CLS), sayfa öğelerinin beklenmedik biçimde yer değiştirmesini ölçer. Her kayma, etkilediği alanın büyüklüğü ve kayma mesafesiyle puanlanır; en yoğun kayma dönemindeki puanların toplamı CLS değeri olarak raporlanır. 0,1 ve altı iyi, 0,1 ile 0,25 arası iyileştirilmeli, 0,25'in üzeri zayıftır. Kullanıcının kendi tıklamasından hemen sonra gerçekleşen, beklenen kaymalar hesaba katılmaz.

En yaygın nedenler, boyutu belirtilmemiş görseller ve gömülü içerikler, yeri önceden ayrılmamış reklam alanları, içeriği aşağı iten çerez bildirimleri ya da duyuru şeritleri ve geç yüklenen yazı tiplerinin metni yeniden dizmesidir. Okuduğu paragraf aniden aşağı kayan ya da bu kayma yüzünden yanlış düğmeye basan bir ziyaretçi, bu ölçütün neden önemli olduğunu gösterir. Çözüm için görsellere genişlik ve yükseklik ya da en-boy oranı verilir, reklam ve gömülü alanlar için yer ayrılır, bildirimler içeriğin üzerine yerleşecek biçimde tasarlanır ve animasyonlarda konum yerine transform özelliği kullanılır.

Ölçüm araçları

İki tür veri vardır. Saha (alan) verisi, gerçek kullanıcıların tarayıcılarından toplanır; Google'ın değerlendirmede kullandığı Chrome Kullanıcı Deneyimi Raporu (CrUX) son 28 günün verisini gösterir ve yalnızca yeterli trafiği olan sayfalar ve siteler için oluşur. Laboratuvar verisi ise Lighthouse ya da Chrome geliştirici araçları gibi araçlarla, belirli bir cihaz ve bağlantı hızı taklit edilerek tek seferlik testle üretilir. Laboratuvar testi sorunu bulmak ve düzeltmeyi denemek için, saha verisi ise sonucu değerlendirmek için kullanılır.

PageSpeed Insights iki veriyi aynı ekranda gösterir: Üst bölüm CrUX saha verisi, alt bölüm Lighthouse laboratuvar testidir. Search Console'daki Core Web Vitals raporu, benzer sayfaları gruplayarak sorunlu URL gruplarını listeler. Standart bir Lighthouse sayfa testi INP'yi ölçemez, çünkü testte gerçek bir kullanıcı etkileşimi yoktur; laboratuvardaki en yakın gösterge Toplam Engelleme Süresi (TBT) değeridir. Kendi ziyaretçilerinizden ayrıntılı veri toplamak için web-vitals JavaScript kütüphanesiyle ölçüm yapıp sonuçları analiz aracınıza gönderebilirsiniz.

Teknik önceliklendirme

İyileştirme listesi uzun olabilir; önceliği üç soru belirler. Sorun bir şablondan mı kaynaklanıyor? Ürün, kategori ya da blog şablonundaki tek bir düzeltme yüzlerce sayfayı aynı anda iyileştirir. Sorunlu sayfalar ne kadar trafik ve gelir taşıyor? Reklam trafiğinin indiği açılış sayfaları ve en çok ziyaret alan organik sayfalar önce ele alınır. Düzeltmenin maliyeti ne? Görsellere boyut vermek gibi hızlı kazanımlar, altyapı değişikliği gerektiren işlerden önce yapılır.

Önerilen çalışma sırası şudur: Search Console'da zayıf URL gruplarını bulmak, sorunu laboratuvar testinde yeniden üretmek, ölçütün hangi parçasının bozulduğunu teşhis etmek, düzeltmeyi yayına almak ve raporda doğrulamayı başlatmak. Saha verisi 28 günlük bir pencereye dayandığı için sonucun görünmesi birkaç hafta sürer. Yeni pazarlama etiketleri ve eklentiler eklendikçe sorunlar geri dönebileceğinden, yayın sürecine otomatik bir performans kontrolü eklemek, sorunları erkenden yakalamayı sağlar.

Uygulamada sık yapılan hatalar

• Hızlı bağlantılı bir masaüstü bilgisayarda yapılan tek bir testi sitenin gerçek durumu saymak.
• Sayfanın en büyük görselini tembel yüklemeye bırakmak ya da bir kaydırıcının içine gömmek.
• Görsellere, reklam alanlarına ve çerez bildirimine yer ayırmadan sayfayı tasarlamak.
• Her yeni pazarlama etiketini ve sohbet eklentisini performans etkisini ölçmeden eklemek.
• Düzeltmeden birkaç gün sonra Search Console raporunun değişmesini beklemek.

Çamlıca yaklaşımı

Çamlıca Reklam Ajansı olarak Core Web Vitals çalışmasını tek seferlik bir hız optimizasyonu değil, şablon düzeyinde bir mühendislik işi olarak ele alıyoruz: Saha verisiyle önceliklendiriyor, laboratuvarda teşhis ediyor, düzeltmeyi yine saha verisiyle doğruluyoruz. Web projelerinin kapsamını web tasarım ve yazılım sayfamızda, tüm uzmanlık alanlarımızı hizmetler sayfamızda bulabilirsiniz.

Sayfa hızı, arama görünürlüğünü, reklam maliyetini ve dönüşümü birlikte etkiler. Bu yüzden çalışmayı gerektiğinde SEO, AEO ve GEO; dijital reklam ve performans pazarlaması; yapay zekâ, CRM ve otomasyon ekiplerimizle birlikte yürütüyoruz. Arama görünürlüğünün yapay zekâ yanıtlarına uzanan boyutu için SEO, AEO ve GEO arasındaki farkı, hızlanan sayfalardan gelen taleplerin takibi için CRM'in ne olduğunu anlatan yazılarımıza göz atabilirsiniz.