Core Web Vitals Nedir? Google'ın Sayfa Deneyimi Ölçütleri ve İyileştirme Yolları

Core Web Vitals, Google'ın gerçek kullanıcı deneyimini ölçmek için seçtiği üç metrikten oluşan bir settir: yüklenme hızı için LCP, etkileşime yanıt için INP ve görsel kararlılık için CLS. 2012'den beri müşteri sitelerinde bu metriklerle uğraşıyorum. Bu yazıda her metriğin tanımını, eşiklerini ve somut iyileştirme yollarını anlatıyorum.

Genel site hızının SEO etkisini site hızı SEO'yu nasıl etkiler yazısında, Lighthouse ile test adımlarını ise Lighthouse performans testi rehberinde ele aldım. Burada odak tamamen üç metriğin kendisi ve her birini nasıl düzelteceğiniz.

Core Web Vitals nedir ve neden önemlidir?

Core Web Vitals, bir sayfanın ne kadar hızlı yüklendiğini, kullanıcı tıkladığında ne kadar çabuk yanıt verdiğini ve içerik yüklenirken ne kadar sabit durduğunu ölçen üç Google metriğidir. Bu metrikler gerçek Chrome kullanıcılarından toplanır ve Google arama sıralama sistemlerinde sayfa deneyimi sinyallerinin bir parçası olarak yer alır.

Önemli olmasının iki nedeni var. İlki arama tarafı: Google, Search Central dokümantasyonunda Core Web Vitals verisini sıralama sistemlerinde kullandığını açıkça yazıyor. İkincisi ise kullanıcı tarafı. Yavaş açılan, tıklamaya geç yanıt veren ya da butonu parmağınızın altından kaydıran bir sayfa, ziyaretçiyi sessizce kaybettirir. Dolayısıyla bu metrikler sadece bir SEO puanı değil; aynı zamanda satış hunisinin ilk basamağındaki sürtünmenin ölçüsüdür.

Benim sahada gördüğüm en yaygın yanılgı şu: işletmeler Core Web Vitals'ı bir kez düzeltilip unutulan bir teknik görev sanıyor. Oysa her yeni eklenti, her kampanya banner'ı ve her takip kodu bu değerleri yeniden bozabilir. Bu yüzden konuya bir proje değil, düzenli izlenen bir sağlık göstergesi gibi yaklaşmanızı öneririm.

Core Web Vitals hangi üç metrikten oluşur?

Güncel sette üç metrik var ve her biri kullanıcı deneyiminin farklı bir yüzünü ölçüyor. web.dev üzerindeki resmi tanımlara göre eşikler şöyle:

Burada kritik nokta şu: bir sayfanın "iyi" sayılması için üç metriğin de iyi eşikte olması gerekir. Örneğin LCP ve CLS mükemmel olsa bile INP zayıfsa, Search Console o URL grubunu zayıf olarak işaretler. Ayrıca bu eşikler ortalamaya göre değil, 75. yüzdelik dilime göre değerlendirmeye girer. Bu konuya aşağıda ayrıca değineceğim, çünkü birçok ekip ortalama değere bakıp yanlış sonuca varıyor.

Setin sabit olmadığını da bilmelisiniz. Google metrikleri zaman içinde güncelliyor; nitekim INP, Mart 2024'te FID'in yerini aldı. Kısacası bugün geçerli olan eşikleri takip etmek için kaynağınız her zaman web.dev olmalı.

LCP nedir ve iyi bir LCP değeri kaç saniyedir?

LCP, yani Largest Contentful Paint, sayfa açılmaya başladıktan sonra görünür alandaki en büyük içerik öğesinin ekrana çizildiği andır. web.dev LCP rehberine göre iyi bir değer 2,5 saniye ve altıdır; 4 saniyenin üzeri ise zayıf kabul görür.

LCP öğesi genellikle şunlardan biri olur:

• Ana görsel ya da hero alanındaki büyük fotoğraf.
• CSS ile arka plana yerleştirdiğiniz büyük bir görsel.
• Bir videonun kapak (poster) görseli.
• Görsel olmayan sayfalarda büyük bir başlık ya da metin bloğu.

Bu metriği sevmemin nedeni, kullanıcının algısına çok yakın olması. Ziyaretçi "sayfa açıldı" hissini tam olarak ana içeriği gördüğü anda yaşar. Öte yandan LCP her cihazda farklı çıkar. Masaüstünde fiber bağlantıyla 1,2 saniye ölçtüğünüz bir sayfa, orta segment bir Android telefonda mobil veriyle 4 saniyeyi rahatça geçebilir.

Bu yüzden LCP'ye bakarken her zaman mobil ve masaüstü verisini ayrı okuyun. Google da raporlarını bu iki cihaz grubuna göre ayırıyor. Üstelik Türkiye'deki trafiğin büyük bölümü mobil olduğundan, benim önceliğim neredeyse her projede mobil LCP oluyor.

LCP neden yavaş kalır?

LCP'yi düzeltmeden önce süreyi nereye harcadığınızı bilmeniz gerekir. web.dev, LCP süresini dört alt parçaya bölüyor ve bu ayrım teşhisi çok kolaylaştırıyor:

1. İlk bayta kadar geçen süre (TTFB): Sunucunun ilk yanıtı ne kadar geç gönderdiği.
2. Kaynak yükleme gecikmesi: Tarayıcının LCP görselini keşfedip indirmeye başlaması için geçen bekleme.
3. Kaynak yükleme süresi: Görselin kendisinin inmesi için geçen zaman.
4. Çizim gecikmesi: Görsel indikten sonra ekrana basılana kadar geçen süre.

Sahada en sık gördüğüm sorun ikinci maddede çıkıyor. Örneğin hero görseli JavaScript ile yükleyen bir slider kullanıyorsanız, tarayıcı bu görseli HTML'i okurken göremez. Script inip çalışana kadar bekler; yani değerli saniyeler boşa gider. Benzer şekilde LCP görseline yanlışlıkla tembel yükleme (lazy load) eklemek de keşfi geciktirir.

Birinci madde ise genellikle ucuz paylaşımlı hosting ya da önbelleksiz dinamik sayfalarda patlar. Sunucu her istekte veritabanına gidip sayfayı sıfırdan üretiyorsa, TTFB tek başına bir saniyeyi yiyebilir. Dolayısıyla LCP sorununu çözmeye görsel sıkıştırmayla değil, önce bu dört parçanın hangisinin baskın olduğunu bularak başlayın.

LCP'yi nasıl iyileştirirsiniz?

Teşhisi koyduktan sonra müdahaleler oldukça net. Benim en sık uyguladığım adımlar şunlar:

• LCP görselini HTML içinde doğrudan bir img etiketiyle verin; JavaScript ile sonradan eklemeyin.
• Bu görsele fetchpriority="high" ekleyin ve lazy loading özelliğini kaldırın.
• Görseli modern formatta (WebP veya AVIF) ve gerçek gösterim boyutunda sunun.
• Sunucu tarafında sayfa önbelleği ve bir CDN kullanarak TTFB'yi düşürün.
• Oluşturmayı engelleyen büyük CSS ve senkron script dosyalarını azaltın.
• Web fontlarını önceden yükleyin ki metin tabanlı LCP gecikmesin.

Görsel boyutu için basit bir kontrol önerisi vereyim: 1920 piksel genişliğinde bir fotoğrafı 400 piksellik mobil alanda gösteriyorsanız, gereksiz yere birkaç kat büyük dosya indiriyorsunuz. Bu durumda resim küçültme aracı ile doğru ölçüde bir sürüm hazırlayıp srcset ile farklı ekranlara farklı dosya verebilirsiniz.

Öte yandan her şeyi aynı anda yapmaya çalışmayın. Tek bir değişikliği yayına alın, birkaç hafta saha verisini izleyin, ardından bir sonrakine geçin. Böylece hangi adımın gerçekten işe yaradığını görürsünüz.

INP nedir ve FID'in yerini neden aldı?

INP, yani Interaction to Next Paint, kullanıcının sayfadaki tıklama, dokunma ve klavye etkileşimlerinden sonra ekranın bir sonraki güncellemeyi ne kadar sürede gösterdiğini ölçer. web.dev INP rehberine göre 200 milisaniye ve altı iyi, 500 milisaniyenin üzeri zayıf sayılır.

INP, 12 Mart 2024'te FID'in (First Input Delay) yerine Core Web Vitals setine girdi. Değişimin mantığı basit: FID yalnızca ilk etkileşimin başlama gecikmesine bakıyordu. Yani kullanıcı ilk kez tıkladığında tarayıcının işe ne kadar geç başladığını ölçüyor, işin ne kadar sürdüğünü ve sonraki etkileşimleri hiç hesaba katmıyordu.

INP ise sayfa ömrü boyunca gerçekleşen etkileşimleri izler ve genellikle en yavaş olanlardan birini raporlar. Bu nedenle çok daha dürüst bir metrik. Pratikte şunu gördüm: FID döneminde neredeyse her site "iyi" görünüyordu, INP geldikten sonra ise ağır JavaScript kullanan birçok e-ticaret sitesi bir anda sarı ve kırmızı bölgeye düştü.

Kısacası INP, sitenizin sadece açılışta değil, kullanıcı gezinirken, filtre seçerken ya da sepete ürün eklerken ne kadar akıcı olduğunu gösteriyor. Dönüşüm açısından en çok önemsediğim metrik de bu oldu.

INP değerini hangi etkileşimler bozar?

INP'yi bozan etkileşimler neredeyse her zaman ana iş parçacığını (main thread) meşgul eden işlerden kaynaklanır. Tarayıcı tek bir ana iş parçacığında hem JavaScript çalıştırır hem de ekranı çizer. Dolayısıyla uzun bir script çalışırken kullanıcı tıklarsa, tıklama sırada bekler.

Sahada en çok karşılaştığım sorunlu senaryolar şunlar:

• E-ticaret kategori sayfalarında filtreye tıklayınca tüm ürün listesinin yeniden hesaplanması.
• Menü açma butonunun arkasında ağır bir animasyon kütüphanesi çalışması.
• Sepete ekle butonunun aynı anda birden fazla takip kodunu tetiklemesi.
• Form alanlarına her harf girişinde doğrulama ve öneri scriptlerinin çalışması.
• Sohbet widget'ı, pop-up ve çerez bannerı gibi üçüncü taraf scriptlerin arka planda yüklenmesi.

Burada dikkat etmeniz gereken nokta şu: laboratuvar testlerinde kimse sayfaya tıklamadığı için bu sorunlar çoğu zaman görünmez. Lighthouse, INP yerine Total Blocking Time (TBT) adlı bir vekil metrik gösterir. TBT yüksekse INP de muhtemelen sorunludur; ancak TBT düşük diye INP'nin iyi olduğunu varsaymayın. Gerçek tabloyu yalnızca saha verisi gösterir.

INP'yi nasıl iyileştirirsiniz?

web.dev, bir etkileşimin süresini üç parçaya ayırıyor: girdi gecikmesi, işleme süresi ve sunum gecikmesi. İyileştirme stratejiniz hangi parçanın uzun olduğuna göre değişir.

Girdi gecikmesi uzunsa, kullanıcı tıkladığında ana iş parçacığı başka bir işle meşguldür. Bu durumda sayfa yüklenirken çalışan uzun görevleri bölmeniz ve gereksiz üçüncü taraf scriptleri geciktirmeniz gerekir. İşleme süresi uzunsa, olay dinleyicisinin kendisi fazla iş yapıyordur. Örneğin tıklamadan hemen sonra yalnızca görsel geri bildirimi verip ağır hesaplamayı bir sonraki kareye ertelemek büyük fark yaratır.

Sunum gecikmesi ise genellikle DOM çok büyük olduğunda ortaya çıkar. Binlerce öğe içeren bir sayfada tek bir sınıf değişikliği bile tarayıcıya ciddi bir yeniden hesaplama yükü bindirir. Bu yüzden sonsuz listelerde sanallaştırma ya da sayfalama kullanmanızı öneririm.

JavaScript tarafındaki derin optimizasyon başlı başına ayrı bir konu; bu yazıda ana hatlarıyla kalıyorum. Pratikte benim ilk adımım her zaman şu oluyor: sitede yüklü olan tüm üçüncü taraf scriptleri listelemek ve her birinin gerçekten kullanılıp kullanılmadığını sormak. Çoğu projede yarısını kaldırmak mümkün oluyor ve INP bir anda rahatlıyor.

CLS nedir ve nasıl hesaplanır?

CLS, yani Cumulative Layout Shift, sayfa açıkken içeriğin beklenmedik şekilde yer değiştirmesini ölçer. web.dev CLS rehberine göre 0,1 ve altı iyi, 0,25 üzeri zayıftır. Bu metrik saniye cinsinden değil, birimsiz bir skordur.

Her bir kayma için tarayıcı iki şeyi çarpar: kayan öğelerin ekranda kapladığı alan oranı ve bu öğelerin ne kadar uzağa gittiği. Ardından birbirine yakın zamanda gerçekleşen kaymaları "oturum penceresi" adı verilen gruplar halinde toplar. Bir pencere en fazla 5 saniye sürer ve kaymalar arasında 1 saniyeden uzun boşluk olursa yeni pencere başlar. CLS değeri, sayfa ömrü boyunca en yüksek skora sahip pencereden gelir.

Önemli bir ayrıntı daha var: kullanıcının kendi etkileşiminden sonraki 500 milisaniye içinde gerçekleşen kaymalar hesaba katılmaz. Yani "daha fazla göster" butonuna bastığında içeriğin açılması sorun değildir. Sorun, kullanıcı hiçbir şey yapmadan içeriğin yerinden oynamasıdır.

Hepimizin yaşadığı klasik örnek şu: bir haber sitesinde bir linke tıklamak üzereyken üstte reklam yüklenir, içerik aşağı kayar ve yanlış yere tıklarsınız. CLS tam olarak bu sinir bozucu deneyimi sayısal hale getiriyor.

CLS değerini nasıl düşürürsünüz?

CLS, üç metrik arasında düzeltmesi genellikle en kolay olanıdır, çünkü nedenleri oldukça tanıdıktır. Benim kontrol listem şöyle:

• Tüm görsel ve videolara width ve height değerleri verin ya da CSS aspect-ratio ile alan ayırın.
• Reklam, gömülü içerik ve iframe alanları için önceden sabit yükseklikte bir yer tutucu bırakın.
• Çerez bannerını içeriği iten bir blok olarak değil, sayfanın üzerine binen bir katman olarak gösterin.
• Web fontlarında font-display ayarını ve yedek font ölçülerini düzenleyerek metin kaymasını azaltın.
• Mevcut içeriğin üstüne sonradan içerik eklemekten kaçının; bildirim çubuklarını sabit alanda gösterin.

Bir de gözden kaçan bir nokta var: animasyonlar. top veya margin gibi özellikleri değiştiren animasyonlar düzen kaymasına yol açabilir. Bunun yerine transform kullanan animasyonlar kayma üretmez. Ayrıca geri ve ileri gezinmede sayfayı anında gösteren tarayıcı önbelleği (bfcache) de kaymaları azaltır.

Bu adımlar tasarımla doğrudan ilgili olduğu için, yeni bir site ya da yenileme sürecindeyseniz CLS'yi baştan hesaba katmak çok daha ucuzdur. Web tasarım projelerimde görsel alanlarını ve banner yerlerini tasarım aşamasında sabitliyorum; böylece sonradan yamaya gerek kalmıyor.

Saha verisi ile laboratuvar verisi arasındaki fark nedir?

Core Web Vitals konusunda en çok kafa karıştıran nokta bu. Saha verisi (field data), sitenize gerçekten giren Chrome kullanıcılarından toplanan ölçümlerdir. Laboratuvar verisi (lab data) ise tek bir cihazda, belirli bir ağ hızında yapılan yapay bir testin sonucudur.

Google'ın sıralamada dikkate aldığı veri saha verisidir. Dolayısıyla Lighthouse'ta 95 puan almanız, Search Console'da yeşil göründüğünüz anlamına gelmez. Tersi de mümkündür: yavaş bir test cihazında düşük puan alırsınız ama gerçek kullanıcılarınızın çoğu hızlı cihazlar kullandığı için saha verisi iyi çıkar.

Benim kuralım basit: durumu saha verisiyle ölçün, nedeni laboratuvar verisiyle bulun. İki veriyi birbirinin yerine koymayın.

75. yüzdelik dilim neden kullanılır?

Google, Core Web Vitals eşiklerini ortalamaya değil, 75. yüzdelik dilime göre değerlendirir. Yani bir sayfanın LCP değerinin "iyi" sayılması için ziyaretlerin en az yüzde 75'inde LCP'nin 2,5 saniye veya altında kalması gerekir.

Bu tercih bilinçli. Ortalama, uç değerleri gizler. Örnek hesap yapalım: ziyaretçilerinizin yarısı 1 saniyede, diğer yarısı 4 saniyede sayfayı görüyorsa ortalama 2,5 saniye çıkar ve her şey yolunda görünür. Oysa kullanıcıların yarısı kötü bir deneyim yaşıyordur. 75. yüzdelik dilim ise bu yavaş grubu doğrudan görünür kılar.

Pratikte bunun anlamı şu: optimizasyon yaparken en hızlı cihazlarınızı değil, orta ve alt segment cihazlarınızı düşünmelisiniz. Özellikle eski telefonlar ve zayıf mobil bağlantılar 75. yüzdelik dilimi belirleyen asıl gruptur. Bu nedenle test yaparken DevTools'ta CPU yavaşlatma ve ağ kısıtlama ayarlarını açmayı alışkanlık haline getirin.

Ayrıca değerlendirme mobil ve masaüstü için ayrı yapılır. Masaüstünüz yeşil, mobiliniz kırmızıysa, mobil aramalarda bu durum sizin için geçerli olan tablodur.

Core Web Vitals verisini hangi araçlarla takip edersiniz?

Core Web Vitals takibi için kullandığım araçları amaçlarına göre ayırıyorum:

• Google Search Console: Tüm sitenin URL grupları bazında saha durumunu gösterir. Genel sağlık kontrolü için başlangıç noktasıdır.
• PageSpeed Insights: Tek bir URL için hem CrUX saha verisini hem de Lighthouse laboratuvar sonucunu aynı ekranda verir.
• CrUX Vis ve CrUX API: Kaynak ya da sayfa bazında geçmiş eğilimleri görmenizi sağlar.
• Chrome DevTools Performance paneli: Yerelde, kendi etkileşimlerinizle LCP, INP ve CLS değerlerini canlı gösterir.
• web-vitals JavaScript kütüphanesi: Kendi kullanıcılarınızdan gerçek zamanlı veri toplayıp analitik aracınıza göndermenizi sağlar.

Son madde bence en az kullanılan ama en değerli seçenek. CrUX verisi 28 günlük bir pencereden geldiği için bir düzeltmenin etkisini görmek haftalar sürer. Kendi ölçümünüzü kurduğunuzda ise sonucu birkaç gün içinde görürsünüz; üstelik hangi sayfa şablonunun ya da hangi etkileşimin sorunlu olduğunu da ayırt edebilirsiniz.

Düşük trafikli sayfalarda CrUX verisi hiç görünmeyebilir. Bu durumda Google yeterli örneğe sahip değildir; dolayısıyla kendi ölçümünüz tek güvenilir kaynak haline gelir.

Search Console'daki Core Web Vitals raporunu nasıl okursunuz?

Search Console'daki rapor, URL'leri tek tek değil, benzer sayfaları gruplayarak gösterir. Google'ın rapor yardım sayfası da bu gruplama mantığını açıklıyor. Örneğin tüm ürün sayfalarınız aynı şablonu kullandığı için tek bir grupta toplanabilir.

Raporu okurken şu sırayı izliyorum. İlk olarak mobil sekmesine bakıyorum, çünkü trafiğin büyük kısmı oradan geliyor. Ardından "Zayıf" ve "İyileştirme gerekli" gruplarını açıp hangi metriğin sorun yarattığına bakıyorum. Bir grubun durumu, o grupta en kötü performansı gösteren metriğe göre belirlenir.

Sonra gruptaki örnek URL'lerden birini PageSpeed Insights'ta açıp laboratuvar teşhisine geçiyorum. Düzeltmeyi yayına aldıktan sonra raporda "Düzeltmeyi doğrula" butonunu kullanabilirsiniz. Ancak doğrulama 28 günlük bir izleme süreci başlatır; yani sonucu hemen görmeyi beklemeyin.

Search Console'un genel kullanımını, diğer raporlarla birlikte Google Search Console rehberinde anlattım. Core Web Vitals raporu o araç setinin yalnızca bir parçası.

Core Web Vitals sıralamayı ne kadar etkiler?

Dürüst cevap: etkisi var, ama içerik kalitesinin önüne geçmez. Google, sayfa deneyimi dokümantasyonunda Core Web Vitals'ı sıralama sistemlerinde kullandığını belirtiyor. Aynı zamanda iyi sayfa deneyiminin tek başına üst sıraları garanti etmediğini ve alaka düzeyinin öncelikli olduğunu da vurguluyor.

Benim saha yorumum şu: Core Web Vitals, benzer kalitede içeriğe sahip sayfalar arasında bir ayırıcı rolü oynuyor. Aramaya en iyi yanıtı veren sayfa biraz yavaş olsa bile sıralamada kalabilir. Fakat sizinle rakibiniz içerik açısından başa baş ise, deneyim farkı devreye girer.

Öte yandan sıralama etkisinden bağımsız olarak dolaylı etki çok daha büyük. Yavaş ve kaygan bir sayfada kullanıcı daha çabuk ayrılır, daha az sayfa gezer ve daha az dönüşüm yapar. Bu konuyu hemen çıkma oranını düşürme yazısında detaylandırdım.

Kısacası Core Web Vitals'a "sıralama hilesi" olarak değil, hem arama hem kullanıcı için temel bir hijyen işi olarak bakmanızı öneririm. Sayfa deneyiminin diğer boyutlarını ise SEO ve UX uyumu yazısında bulabilirsiniz.

İyileştirme çalışmasını hangi sırayla planlamalısınız?

Birçok ekip en görünür sayfadan, yani ana sayfadan başlıyor. Oysa trafiğin ve gelirin büyük kısmı genellikle kategori, ürün ya da hizmet şablonlarından geliyor. Benim önerdiğim sıra şöyle:

1. Search Console'da mobil raporu açın ve zayıf durumdaki URL gruplarını listeleyin.
2. Bu grupları trafik ve gelir katkısına göre sıralayın.
3. En değerli grubun şablonunda hangi metriğin kırmızı olduğunu belirleyin.
4. PageSpeed Insights ve DevTools ile bu metriğin alt parçalarını teşhis edin.
5. Tek seferde tek bir düzeltme yapın ve yayına alın.
6. Kendi ölçümünüzle birkaç gün, CrUX ile birkaç hafta sonucu izleyin.
7. Sonucu doğruladıktan sonra bir sonraki gruba geçin.

Bu sıranın avantajı, şablon bazlı düşünmesi. Bir ürün şablonundaki hero görsel sorununu çözdüğünüzde binlerce sayfayı aynı anda düzeltmiş olursunuz. Ayrıca iş etkisi en yüksek yerden başladığınız için yönetime sonucu anlatmak da kolaylaşıyor.

Bu tür teknik önceliklendirmeyi daha geniş bir SEO planının içine yerleştirmek istiyorsanız, teknik SEO ipuçları yazısı iyi bir çerçeve sunar.

Hangi hatalar Core Web Vitals çalışmasını boşa çıkarır?

Yıllar içinde aynı hataları farklı projelerde tekrar tekrar gördüm. En yaygın olanları şunlar:

• Lighthouse puanını hedef haline getirmek ve saha verisini hiç kontrol etmemek.
• Hız eklentisi kurup tüm görsellere, LCP görseli dahil, tembel yükleme uygulamak.
• Yalnızca masaüstünde test edip mobil kullanıcıları gözden kaçırmak.
• Düzeltmeyi yayına aldıktan bir gün sonra Search Console'da değişim beklemek.
• Pazarlama ekibinin sonradan eklediği takip kodlarını ve pop-up'ları hesaba katmamak.

Bunların arasında en pahalısı son madde. Teknik ekip aylarca uğraşıp değerleri yeşile çeker, ardından yeni bir kampanya için üç ayrı script ve bir tam ekran pop-up eklenir ve her şey başa döner. Bu yüzden Core Web Vitals'ı yalnızca geliştiricinin değil, pazarlama ekibinin de sorumluluğu haline getirmek gerekiyor.

Bir diğer yaygın hata da hız eklentilerine körü körüne güvenmek. Bu eklentiler bazen işe yarar, ancak ayarları yanlışsa CSS'i geç yükleyip CLS'yi artırabilir ya da scriptleri erteleyip etkileşimi bozabilir. Her ayar değişikliğinden sonra mutlaka ölçüm yapın.

Mobil cihazlarda Core Web Vitals neden daha zor?

Mobil cihazlarda işlemci gücü, bellek ve ağ koşulları masaüstüne göre çok daha değişkendir. Aynı JavaScript paketi güçlü bir dizüstü bilgisayarda birkaç yüz milisaniyede çalışırken, orta segment bir telefonda birkaç kat daha uzun sürebilir. Bu fark özellikle INP'ye doğrudan yansır.

Ağ tarafında da benzer bir durum var. Mobil bağlantılarda gecikme (latency) daha yüksektir; dolayısıyla her ekstra istek, her yönlendirme ve her üçüncü taraf alan adı LCP'ye ciddi süre ekler. Örneğin ana sayfadan önce bir dil yönlendirmesi yapıyorsanız, mobil kullanıcı için bu tek adım bile fark edilir bir gecikme yaratabilir.

Bu nedenle mobil tasarımı küçük ekrana sığdırılmış bir masaüstü sayfası gibi düşünmemelisiniz. Mobilde gerçekten gerekli olmayan slider'ları, ağır animasyonları ve büyük görselleri sadeleştirmek genellikle üç metriği birden iyileştirir. Mobil uyumluluğun genel kontrolü için mobil uyumluluk testi rehberine göz atabilirsiniz.

Core Web Vitals sonuçlarını nasıl kalıcı hale getirirsiniz?

Değerleri bir kez yeşile çekmek işin kolay kısmı; zor olan onları yeşilde tutmak. Bunun için birkaç kalıcı alışkanlık öneriyorum.

İlk olarak bir performans bütçesi belirleyin. Örneğin ana sayfa için toplam JavaScript boyutuna ve LCP görselinin dosya boyutuna bir üst sınır koyun. Yeni bir özellik bu bütçeyi aşıyorsa, ekip eklemeden önce neyi çıkaracağını tartışsın. Böylece performans, tasarım ve pazarlama kararlarının doğal bir parçası olur.

İkinci olarak ölçümü otomatikleştirin. web-vitals kütüphanesiyle topladığınız veriyi analitik aracınıza gönderin ve haftalık bir kontrol rutini oluşturun. Ayrıca yayın sürecine Lighthouse CI gibi bir kontrol eklerseniz, bir değişiklik canlıya çıkmadan önce gerilemeyi yakalarsınız.

Üçüncü olarak, üçüncü taraf script ekleme yetkisini sınırlayın. Tag Manager'a erişimi olan herkes siteye kod ekleyebiliyorsa, performans kontrolünüz de yok demektir.

Bu süreci kendi başınıza yürütmek yerine düzenli bir teknik denetim istiyorsanız, SEO danışmanlığı kapsamında Core Web Vitals izlemesini aylık rutinin içine alıyorum.

Sonuç: Core Web Vitals'a nereden başlamalısınız?

Özetle Core Web Vitals, kullanıcının sayfanızda yaşadığı üç temel deneyimi ölçüyor: ana içeriği ne kadar hızlı gördüğünü, tıkladığında ne kadar hızlı yanıt aldığını ve sayfanın ne kadar sabit durduğunu. Eşikler net: LCP için 2,5 saniye, INP için 200 milisaniye, CLS için 0,1.

Bugün yapabileceğiniz en faydalı adım, Search Console'da mobil raporu açıp en değerli şablonunuzda hangi metriğin sorunlu olduğunu bulmak. Ardından o metriğin alt parçalarını teşhis edin ve tek bir düzeltmeyle başlayın. Mükemmel puan peşinde koşmak yerine, gerçek kullanıcılarınızın yüzde 75'inin iyi bir deneyim yaşamasını hedefleyin. Sonuçta bu, hem Google'ın hem de müşterinizin ödüllendirdiği şeydir.