Üç metrik, üç farklı soru
Core Web Vitals, kullanıcının bir sayfayı nasıl deneyimlediğini üç ayrı açıdan ölçer. Her metrik farklı bir soruya cevap verir ve farklı bir düzeltme gerektirir; bu yüzden "site yavaş" demek yerine hangi metriğin kötü olduğunu net olarak belirlemek ilk adımdır.
| Metrik | Ne ölçer? | "İyi" eşiği |
|---|---|---|
| LCP (Largest Contentful Paint) | Ana içeriğin ekrana ne kadar sürede geldiği | En fazla 2,5 saniye |
| INP (Interaction to Next Paint) | Tıklama ve dokunmalara sayfanın ne kadar hızlı tepki verdiği | 200 milisaniye veya altı |
| CLS (Cumulative Layout Shift) | Sayfa yüklenirken öğelerin beklenmedik şekilde kayması | 0,1 veya altı |
INP, daha önce kullanılan FID metriğinin yerini almıştır ve yalnızca ilk etkileşimi değil, ziyaret boyunca yaşanan etkileşimleri dikkate alır. Değerlendirme, gerçek kullanıcıların yüzde 75'lik dilimine göre yapılır; yani ziyaretçilerin büyük çoğunluğu iyi deneyim yaşamıyorsa sayfa geçemez. Eşikler zaman içinde güncellenebileceği için Google'ın web.dev ve Search Central belgelerini dönem dönem kontrol etmenizi öneririz.
Saha verisi ile laboratuvar verisini karıştırmayın
Webmasterların en sık yaptığı hata, PageSpeed Insights'taki performans puanını Core Web Vitals sonucu sanmaktır. Aracın üst kısmında yer alan bölüm gerçek Chrome kullanıcılarından toplanan saha verisidir; alttaki puan ise tek bir simüle edilmiş yüklemeden gelen laboratuvar verisidir.
- Saha verisi sıralama sinyali olarak değerlendirilen veridir, ancak yeterli trafiği olmayan sayfalar için oluşmaz ve değişiklikleri yansıtması birkaç hafta sürer.
- Laboratuvar verisi anında sonuç verir ve sorunun kaynağını bulmak için idealdir, fakat gerçek kullanıcıların cihaz ve bağlantı çeşitliliğini yansıtmaz.
Doğru yaklaşım şudur: Search Console'daki Core Web Vitals raporuyla hangi URL gruplarının sorunlu olduğunu saha verisinden öğrenin, ardından o gruptan örnek bir sayfayı laboratuvar araçlarında inceleyerek nedeni bulun. Search Console benzer sayfaları gruplar; bu, sorunun şablon kaynaklı olduğunun güçlü bir işaretidir. Bu raporun diğer bölümlerle birlikte nasıl okunacağını SEO denetimi planımızda ele aldık.
LCP sorunlarını kaynağında çözmek
LCP süresini dört parçaya ayırmak teşhisi kolaylaştırır: sunucunun ilk baytı göndermesi, LCP kaynağının indirilmeye başlaması, kaynağın indirilmesi ve öğenin ekrana çizilmesi. Hangi parçanın uzun olduğunu Chrome geliştirici araçlarındaki performans panelinden görebilirsiniz.
- Sunucu yanıtı yavaşsa: Sayfa önbelleği kullanın, veritabanı sorgularını azaltın, gerekiyorsa barındırma altyapınızı gözden geçirin. Dinamik sayfalarda her istekte aynı içeriği yeniden üretmek en yaygın nedendir.
- LCP görseli geç keşfediliyorsa: Ana görseli CSS arka planı veya JavaScript ile yüklemek yerine HTML içinde normal bir görsel etiketiyle verin. Bu görsele tembel yükleme (lazy load) uygulamayın; aksine yüksek öncelik ipucu vermeyi değerlendirin.
- Görsel ağırsa: Doğru boyutta servis edin, modern formatları kullanın ve farklı ekranlar için farklı boyutlar sunun.
- Çizim gecikiyorsa: Sayfanın üst kısmını engelleyen CSS ve JavaScript dosyalarını azaltın, web fontlarının metni görünmez bırakmasını önleyin.
WordPress kullanıyorsanız, önbellek ve görsel optimizasyonu eklentileri bu adımların bir kısmını otomatikleştirir; ancak eklenti eklemeden önce mevcut eklentilerin sayfaya ne kadar kod eklediğini kontrol edin. Altyapı tarafındaki sorunlarda sunucu ve hosting bilgi alışverişi bölümü faydalı olabilir.
INP: etkileşim gecikmesinin gerçek nedenleri
INP kötüyse sorun neredeyse her zaman ana iş parçacığını meşgul eden JavaScript'tir. Kullanıcı bir menüye dokunduğunda tarayıcı o sırada başka bir uzun görevi işliyorsa tepki gecikir.
- Üçüncü taraf betikleri envanterleyin: Sohbet balonları, reklam kodları, ısı haritası ve analiz araçları en sık görülen kaynaklardır. Her birinin gerçekten gerekli olup olmadığını sorgulayın.
- Uzun görevleri bölün: Tek seferde çalışan ağır işlemleri daha küçük parçalara ayırmak, tarayıcıya arada kullanıcıya cevap verme fırsatı tanır.
- Olay işleyicilerini hafifletin: Bir tıklamanın ardından yapılan ağır hesaplamaları, görsel geri bildirim verildikten sonraya erteleyin.
- DOM boyutunu küçültün: Binlerce öğeden oluşan sayfalar, her etkileşimde yeniden çizim maliyetini artırır.
INP sorunu çoğunlukla laboratuvar testinde görünmez, çünkü test sırasında etkileşim yapılmaz. Bu yüzden geliştirici araçlarında sayfayla gerçekten etkileşime girerek kayıt almanız gerekir.
CLS: kayan düzeni sabitlemek
CLS, kullanıcıyı en çok rahatsız eden ve düzeltmesi genellikle en kolay olan metriktir. Kaymaların büyük kısmı birkaç tanıdık nedenden kaynaklanır:
- Genişlik ve yükseklik belirtilmemiş görseller, videolar ve iframe'ler.
- Sayfa yüklendikten sonra içeriği aşağı iten reklam alanları veya çerez bildirimleri.
- Yedek fonttan web fontuna geçişte boyut farkı nedeniyle metnin yeniden akması.
- JavaScript ile sonradan eklenen bannerlar ve "ilgili içerik" kutuları.
Çözüm, her dinamik öğe için önceden yer ayırmaktır. Reklam alanlarına sabit minimum yükseklik verin, görsellere en-boy oranını bildirin ve bildirimleri içeriği itmek yerine üstüne binecek şekilde konumlandırın.
Kaymanın hangi öğeden kaynaklandığını bulmak için geliştirici araçlarındaki performans kaydında "layout shift" olaylarını inceleyin; her olayda yer değiştiren öğe işaretlenir. Kaymalar yalnızca sayfa açılışında değil, kaydırma sırasında da oluşabilir. Özellikle sonsuz kaydırma kullanan listelerde ve geç yüklenen reklam bloklarında sayfanın aşağı kısımlarını da test etmeyi unutmayın.
Şablon bazlı çalışma planı
Core Web Vitals çalışmasını sayfa sayfa yürütmek hem yorucu hem de verimsizdir. Sorunların büyük kısmı ortak şablonlardan kaynaklandığı için planı şablon üzerine kurun:
- Şablonları listeleyin: Ana sayfa, kategori, ürün veya yazı, arama sonuçları, iletişim gibi sayfa tiplerini çıkarın.
- Her şablon için temsilci URL seçin: En çok trafik alan bir veya iki sayfayı örnek olarak belirleyin.
- Metrik eşleştirmesi yapın: Search Console'daki sorunlu URL gruplarını bu şablonlarla eşleştirin. Hangi şablonun hangi metrikte başarısız olduğunu bir tabloya yazın.
- Kök nedeni tek yerde düzeltin: Bir şablondaki görsel boyutu veya fazla betik sorunu çözüldüğünde o şablonu kullanan bütün sayfalar birlikte iyileşir.
- Mobil önceliğiyle test edin: Saha verisinde mobil ve masaüstü ayrı değerlendirilir; sorunlar genellikle orta segment mobil cihazlarda ve yavaş bağlantılarda belirginleşir.
Sık yapılan yanlış optimizasyonlar
Hız çalışmalarında iyi niyetle yapılan bazı değişiklikler durumu kötüleştirebilir. Şu tuzaklara dikkat edin:
- Her şeye tembel yükleme uygulamak: Ekranın üst kısmındaki ana görseli de geciktirmek LCP'yi doğrudan uzatır.
- Tüm JavaScript'i ertelemek: Menü veya sepet gibi etkileşim için gereken kodun geç yüklenmesi, kullanıcının ilk dokunuşunda gecikme yaratabilir.
- Birden fazla önbellek eklentisi kullanmak: Çakışan kurallar bozuk sayfalara veya eski içeriğin gösterilmesine yol açar.
- Yalnızca puan için optimizasyon: Test aracında puanı yükseltmek için kullanıcıya görünen içeriği gizlemek veya geciktirmek gerçek deneyimi iyileştirmez.
Düzeltmeyi doğrulamak ve önceliklendirmek
Bir düzeltmeyi yayına aldıktan sonra Search Console'daki raporda "düzeltmeyi doğrula" seçeneğini kullanabilirsiniz. Saha verisi geriye dönük bir pencereyle hesaplandığı için sonucun netleşmesi birkaç hafta sürer; bu sürede başka büyük değişiklik yapmamak, neyin işe yaradığını anlamanızı kolaylaştırır.
Önceliklendirme yaparken şunu unutmayın: Core Web Vitals önemli bir kullanıcı deneyimi göstergesidir, ancak tek başına içerik kalitesinin yerini tutmaz. Arama niyetine cevap vermeyen bir sayfa ne kadar hızlı olursa olsun üst sıralara çıkmaz. Hız çalışmalarını, en çok trafik alan ve dönüşüm getiren şablonlardan başlatın. Bu şablonları belirlemek için iç linkleme stratejisi rehberimizdeki sayfa önceliklendirme yöntemini de kullanabilirsiniz.
Hız iyileştirmesi sonrasında trafik beklediğiniz gibi değişmediyse, sorunun başka bir katmanda olabileceğini düşünün. Trafik düşüşü analizi rehberimiz kaybın kaynağını ayrıştırmanıza, yapısal veri rehberimiz ise arama sonuçlarındaki görünümünüzü zenginleştirmenize yardımcı olur. Belirli bir sayfanın ölçümlerini yorumlamakta zorlanırsanız SEO bölümünde PageSpeed sonuçlarınızı paylaşarak görüş alabilirsiniz.
Forumdaki ilgili bölümler
- Arama Motoru Optimizasyonu (SEO)Hız ve sayfa deneyimi sorunlarını tartışın
- Sunucu/Hosting Bilgi AlışverişiSunucu yanıt süresi ve önbellek ayarları
- WordPressWordPress sitelerde hız optimizasyonu
Sık sorulan sorular
Core Web Vitals sıralamayı ne kadar etkiler?
Google, sayfa deneyimini sıralama sistemlerinin değerlendirdiği sinyallerden biri olarak tanımlar; ancak içerik alaka düzeyi çok daha belirleyicidir. Benzer kalitede sayfalar arasında fark yaratabilir, zayıf içeriği tek başına kurtarmaz.
PageSpeed puanım 100 değil, sorun mu?
Hayır. Laboratuvar puanı teşhis için bir yardımcıdır. Asıl bakmanız gereken, Search Console ve PageSpeed Insights üst bölümündeki gerçek kullanıcı verisinin üç metrikte de iyi eşiklerde olup olmadığıdır.
Sayfamda saha verisi görünmüyor, ne yapmalıyım?
Yeterli trafiği olmayan sayfalar için saha verisi oluşmaz. Bu durumda aynı şablonu kullanan daha popüler sayfaların verisine bakın ve laboratuvar testleriyle sorunları önceden giderin.
Düzeltmeden sonra rapor ne zaman güncellenir?
Saha verisi geriye dönük yaklaşık dört haftalık bir dönemi kapsadığı için iyileşmenin raporlara tam yansıması birkaç hafta sürebilir. Doğrulama sürecini başlattıktan sonra sabırla izleyin.