Önemli Web Verileri 101 ve Geliştirme Kılavuzu

Neler Oluyor ve Değişiyor?

Mayıs 2021'de Google, sayfa hızı ve kullanıcı deneyimiyle ilgili olduğundan sayfa sıralaması/sıralamaları için sinyallere ek bir faktör ekleyen bir temel algoritma güncellemesinin kullanıma sunulmasını başlattı. Çekirdek güncelleme sunumu, Haziran 2021'e kadar uzandı ve bunu tarihteki en büyük temel değişikliklerden biri haline getirdi. Önemli Web Verileri, genel sayfa deneyimi sıralama faktöründe arama sinyalleri olarak HTTPS güvenli site, mobil kullanım kolaylığı ve araya girmeyen ara reklamlar gibi eski sıralama sinyallerine katılacak.

Önemli Web Verileri'nin üç bileşeni aşağıdakileri içerir:

• En Büyük İçerikli Boyama (LCP) : algılanan yükleme hızını ölçer ve sayfanın ana içeriğinin muhtemelen yüklendiği noktayı sayfa yükleme zaman çizelgesinde işaretler. İyi bir kullanıcı deneyimi sağlamak için siteler , sayfa yüklenmeye başladıktan sonraki ilk 2,5 saniye içinde LCP'nin gerçekleşmesini sağlamalıdır.
• İlk Giriş Gecikmesi (FID) : yanıt verebilirliği ölçer ve kullanıcıların sayfayla ilk etkileşimde bulunmaya çalışırken hissettikleri deneyimi sayısallaştırır. İyi bir kullanıcı deneyimi sağlamak için siteler, 100 milisaniyeden daha kısa bir FID'ye sahip olmaya çalışmalıdır .
• Kümülatif Düzen Kayması (CLS) : görsel kararlılığı ölçer ve görünür sayfa içeriğindeki beklenmeyen düzen kaymasının miktarını belirler. İyi bir kullanıcı deneyimi sağlamak için siteler, 0,1'den düşük bir CLS puanına sahip olmaya çalışmalıdır .

Google'ın bu algoritma güncellemesiyle ilgili resmi yayın bildirimi: https://developers.google.com/search/blog/2020/11/timing-for-page-experience

Ayrıca Google, kullanıma sunma sırasında performansı izlemeye devam ederken CLS değişikliği hakkında daha fazla bilgi yayınladı. Sonuç olarak, birçok site son değişiklikler nedeniyle daha olumlu bir puan aldı ve site düzenlerini ayarlamak için birçok geliştirme çalışmasından kaçındı. Her zaman olduğu gibi, bu değişiklikler değişebilir, bu nedenle CWV'leri haftalık veya aylık bir kontrol listesinin parçası olarak izlemenizi öneririz.

Sıralama Güncellemesi Hakkında Ne Biliyoruz?

Çoğu Google algoritma güncellemesinde olduğu gibi, mevcut arama ortamını nasıl etkileyeceği konusunda bilinmeyen çok şey var. Bunun sayfa sıralamalarında bir faktör olacağını biliyoruz. Ancak, bir faktörün yüzde kaçının veya algoritma içinde ne kadar etkili olacağını bilmiyoruz. Bilinmeyen diğer bir faktör, doğrudan rakiplerin yeni faktörlere uymak için sitelerini güncellemek için uyum sağlamaları veya harekete geçmeleri olacaktır. Rakip davranışına bağlı olarak, bunun sitenizin sıralamasında benzerlerine kıyasla olumlu veya olumsuz bir etkisi olabilir. Bildiğimiz şey, Google'ın kullanıcılar için değerli veya alakalı olarak gördüğü içeriği sıralamaya, içeriği zayıf olan daha hızlı web siteleri yerine öncelik vermeye devam edeceğidir.

Aslında, Google güncelleme hakkında daha fazla bilgi sunduğundan, alakalı içeriğin arama sıralamalarındaki en önemli unsurlardan biri olmaya devam ettiğini onayladılar.

"Sistemlerimiz, sayfa deneyiminin bazı yönleri vasatın altında olsa bile, genel olarak en iyi bilgilere sahip sayfalara öncelik vermeye devam edecek. İyi bir sayfa deneyimi, harika ve alakalı içeriğe sahip olmayı geçersiz kılmaz."

Google Sayfa Deneyimi Sıralaması Güncellemesine Nasıl Hazırlanırsınız?

Bu güncellemeyle ilgili bilinmeyen faktörler ve Google'ın 6 aylık bildirim penceresi nedeniyle, değişiklik bunun bir sıralama faktörü olacağının sinyallerini veriyor gibi görünüyor. Bu nedenle, hem SEO hem de geliştirme ekiplerinin site(ler)inizin mevcut Önemli Web Verileri performansını incelemesi ve sıralama sinyali güncellemesiyle ilgili sorunları gözden geçirmek ve güncellemek için hızlı bir şekilde harekete geçmesi şiddetle tavsiye edilir. Tepki vermek yerine proaktif olmanız önemlidir, çünkü herhangi bir sıralama düşüşünün telafisi oldukça zaman alabilir. SEO'nun uzun bir oyun olduğunu hepimiz biliyoruz!

Site Sorunları Nasıl Belirlenir, Sorunlara Göre Sonraki Adımlar ve Ek İpuçları?

Önemli Web Verileri, sitenizin Google Search Console hesabında "Geliştirmeler" altında özetlenmiştir. Ek olarak, hesabın "Genel Bakış" bölümünde kapsayıcı bir görünüm vardır ve bu, aşağıdaki örneğe benzer görünecektir (Hesabınız sitenize özgü potansiyel sorunlara bağlı olduğundan, muhtemelen bazı farklılıklar olacaktır). Hem Masaüstü hem de Mobil için özetlenen bir bölüm de vardır. Bu örnekte, Mobil ile ilgili sorunlara bakıyoruz.

Eylül 2020 itibarıyla tüm siteler mobil öncelikli dizine eklendiğinden , geliştirme süresinin öncelikle Mobil konulara harcanmasını öneriyoruz. Bununla birlikte, siteniz duyarlıysa, muhtemelen Mobil'de yaptığınız güncellemeler Masaüstü'nü de olumlu yönde etkileyecektir. Ek olarak, sitenin boyutuna bağlı olarak, "zayıf" ve "geliştirilmesi gereken" sorunlar olabilir. "İyileştirme gerekiyor" öğeleri, daha sonra ayrıntılı olarak ele alacağımız çabaya karşı etkiye veya 80/20 kuralına değmeyebileceğinden, "zayıf" URL'lere odaklanmanızı şiddetle öneririz!

Google Search Console'da özetlenen ve optimum performanstan daha düşük performans gösteren URL'leri incelerken, Google'dan John Mueller'in Google'ın bazı durumlarda temel web vitals puanını birden çok sayfanın ortalaması olarak nasıl hesaplayabileceği hakkında ortaya koyduğu şeyi akılda tutmak önemlidir:

Soru budur:

"Bu bir sıralama sinyali haline geldiğinde... sayfa düzeyinde mi yoksa alan düzeyinde mi olacak?"

Müller cevap verdi:

“…Alan verilerine olan şey şu ki, her sayfa için veri noktalarımız yok.

Bu nedenle, çoğunlukla, ayrı sayfalardan oluşan bir tür gruplandırmaya ihtiyacımız var.

Ve sahip olduğumuz veri miktarına bağlı olarak, bu, tüm web sitesinin (alan türü) bir gruplandırması olabilir.

...Sanırım Chrome Kullanıcı Deneyimi Raporunda, alt etki alanı olacak kaynağı ve oradaki protokolü kullanıyorlar.

Yani bu, kapsayıcı türden bir gruplandırma olacaktır.

Ve bir web sitesinin ayrı bölümleri için daha fazla veriye sahipsek, bunu kullanmaya çalışırız.

Ve bunun arama konsolunda da göreceğiniz bir şey olduğuna inanıyorum, burada tek bir URL gibi göstereceğiz ve şunu söyleyeceğiz… bununla ilişkili pek çok başka sayfa var. Ve bu, orada kullanacağımız türden bir gruplama.

Kendinize, Önemli Web Verileri hakkındaki konuşmanın başlangıcında bunu neden gündeme getirdiğimizi soruyor olabilirsiniz. Mueller, URL sorunlarını özetleyen Google Arama Konsolu raporunun, aynı sorunlara sahip sayfaları kategorize etmeye ve bir grup halinde raporlamaya çalıştığını açıklıyor. Ne yazık ki, pratikte, bu URL gruplamaları, deneyimlerimize göre bazı web siteleri için pek yardımcı olmadı.

Zaman zaman, Google Arama Konsolu raporunda "düşük" performansa sahip olarak belirtilen URL'leri inceleyeceğiz, ancak aynı sayfaların Lighthouse ve Page Speed ​​Insights ile test edildiğinde temiz bir sağlık raporuna sahip göründüğünü göreceğiz.

Özet olarak, Google Search Console raporunda özetlenen URL sorunlarını incelerken, "biraz şüpheyle ele almanızı" öneririz. En iyi tahminimiz, Google'ın sayfalar için "web vitals" puanını, gerçek dünya tarama verilerinin (Google-speak'teki "alan verileri") 28 günlük geçmişine dayalı olarak sıralamak niyetinde olmasıdır. Ancak, sayfa yoğun bir şekilde trafiğe çıkmıyorsa, bu gerçek dünya verilerinin tüm etki alanından (veya Google-speak'te "kaynak") toplanması muhtemeldir. Search Console, web vitals'ınızın bir miktar TLC'ye ihtiyaç duyduğu gerçeğini belirlemede faydalı olsa da, denetiminiz için ona güvenmeyin. Ayrıca, düzeltmeleri gerçekleştirirken ve denetlerken veya doğrularken saha verilerinin (birden çok sayfa için olabilir ve her zaman 28 günlük bir yeniden inceleme aralığının üzerinde olabilir) aksine laboratuvar verilerini (gerçek zamanlı olarak test edilen sayfaların bireysel sonuçları) incelemeye dikkat edin.

Bir sorununuz olduğunu anladığınızda, kaynak sayfaları belirleyemiyorsanız, temel şablonlarınızın her biri için laboratuvar testi örnek sayfalarıyla başlayın. Örneğin, ana sayfa, ürün sayfası, kategori sayfası, blog makalesi vb. Çoğu zaman, belirli bir sayfa türünün her örneğinde yapısal sorunlar bulunabilir ve bir web geliştiricisi tarafından temel şablonun güncellenmesiyle bir kez düzeltilebilir. kod. Bu işe yaramazsa, en çok ziyaret edilen sayfalardan başlayarak, tek tek sayfaların bir alt kümesinin benzer bir analizini düşünün. Bu süreçte yararlı bulduğumuz bir araç, Screaming Frog aracılığıyla Önemli Web Verilerini denetlemektir .

Kümülatif Düzen Kayması (CLS) İyileştirme Kılavuzu

Kümülatif Düzen Kayması (CLS) , sayfanın ömrü boyunca meydana gelen her beklenmedik düzen kayması için tüm ayrı düzen kayma puanlarının toplamını ölçer. Görünür bir öğe, işlenmiş bir çerçeveden diğerine konumunu değiştirdiğinde bir düzen kayması gerçekleşir.

Google, birkaç yol gösterici ilkeye bağlı kalarak çoğu web sitesi için CLS'nin nasıl iyileştirileceğine ilişkin aşağıdaki kılavuzu önerir:

• Resimlerinize ve video öğelerinize her zaman boyut niteliklerini ekleyin veya gerekli alanı CSS en boy oranı kutuları gibi bir şeyle ayırın . Bu yaklaşım, resim yüklenirken tarayıcının belgede doğru miktarda alan ayırabilmesini sağlar. Özellik ilkelerini destekleyen tarayıcılarda bu davranışı zorlamak için boyutlandırılmamış ortam özelliği ilkesini de kullanabileceğinizi unutmayın .
• Bir kullanıcı etkileşimi dışında, asla mevcut içeriğin üzerine içerik eklemeyin. Bu, meydana gelen herhangi bir düzen kaymasının beklendiğini garanti eder.
• Düzen değişikliklerini tetikleyen özelliklerin animasyonlarına dönüştürme animasyonlarını tercih edin. Geçişleri, durumdan duruma bağlam ve süreklilik sağlayacak şekilde canlandırın.

Google, site genelinde güncellemeleri analiz etmek, test etmek ve dağıtmak için aşağıdaki eylem planını kullanmanızı önerir:

• Üzerinde çalışılması gereken sayfaları belirledikten sonra (yukarıda özetlenmiştir), bir sayfadaki laboratuvar ve saha sorunlarını teşhis etmek için PageSpeed ​​Insights'ı kullanın.
• Sitenizi laboratuvarda yerel olarak optimize etmeye hazır mısınız? Önemli Web Verilerini ölçmek ve tam olarak nelerin düzeltileceği konusunda eyleme geçirilebilir rehberlik almak için Lighthouse ve Chrome DevTools'u kullanın . Web Vitals Chrome uzantısı , masaüstünde gerçek zamanlı bir metrik görünümü sağlayabilir.
• Rehberlik mi arıyorsunuz? web.dev/measure , PSI verilerini kullanarak sayfanızı ölçebilir ve size optimizasyon için önceliklendirilmiş bir dizi kılavuz ve codelab gösterebilir.
• Son olarak, üretimde bir değişikliği devreye almadan önce Core Web Vitals'ta herhangi bir gerileme olmadığından emin olmak için çekme isteklerinde Lighthouse CI kullanın.

CLS'nin nasıl iyileştirileceğine ilişkin ayrıntılı bir inceleme için bkz . CLS'yi Optimize Etme .

En Büyük İçerikli Boya (LCP) İyileştirme Rehberi

En Büyük İçerikli Boyama (LCP) metriği, görünüm alanında görünen en büyük görüntünün veya metin bloğunun oluşturma süresini bildirir.

Şu anda Largest Contentful Paint API'de belirtildiği gibi, Largest Contentful Paint için dikkate alınan öğe türleri şunlardır:

• <img> öğeleri
• < svg> öğesinin içindeki <image> öğeleri
• <video> öğeleri (poster görüntüsü kullanılır)
• url() işlevi aracılığıyla yüklenen arka plan görüntüsüne sahip bir öğe (bir CSS gradyanının aksine )
• Metin düğümlerini veya diğer satır içi düzey metin öğelerini alt öğelerini içeren blok düzeyi öğeler

Google, temel olarak dört faktörden etkilenen LCP'nin nasıl iyileştirileceğine ilişkin aşağıdaki kılavuzu önerir:

• Yavaş sunucu yanıt süreleri
• Oluşturmayı engelleyen JavaScript ve CSS
• Kaynak yükleme süreleri
• İstemci tarafı oluşturma

LCP'nin nasıl iyileştirileceğine ilişkin ayrıntılı bilgi için bkz . LCP'yi Optimize Etme . LCP'yi de iyileştirebilecek bireysel performans teknikleri hakkında ek rehberlik için, bakınız:

• PRPL modeliyle anında yüklemeyi uygulayın
• Kritik İşleme Yolunu Optimize Etme
• CSS'nizi optimize edin
• Resimlerinizi Optimize Edin
• Web Yazı Tiplerini Optimize Edin

JavaScript'inizi optimize edin (istemci tarafından oluşturulan siteler için)

Geliştirmenin Bugüne Kadarki Önemli Web Hayati Bulguları

Geliştirme ekibimiz, Core Web Vitals sıralama güncellemesinin çoğunun, yapılan güncellemelerin Google tarafından belirlenen standartları karşılamasını sağlamak için geliştirme tarafında kapsamlı testler gerektireceğini gördü.

Daha küçük siteler için pek çok durumda, bu öğelerin çoğu web geliştiricilerinin kontrolü dışında olacaktır. Örneğin, sunucu hızı büyük ölçüde barındırma sağlayıcısı tarafından kontrol edilir ve paylaşılan barındırma için (WP Engine veya Shopify gibi), geliştiricilerin kontrolü olmayacaktır. Benzer şekilde, kullanıma hazır site temalarında genellikle işlemeyi engelleyen Javascript ve CSS "hazırlanmış" olacaktır. Bu durumlarda, bildirilen sorunların çoğunu ele almak pratik olmayabilir. Bu nedenlerden dolayı, geliştirme ekibinin değiştirebileceği ve değiştirmesi gereken (1) hangi sorunların en etkili olduğu ve (2) hangi sorunların koddan kaynaklandığı kesişimini belirlemek için kritik bir analiz gereklidir.

Müşterilerimizin birçoğunda Önemli Web Verileri sorunlarını inceleme sürecini başlattıktan sonra, Google tarafından sağlanan ilgili araçların çoğunun, sorunları tanımlayabildiği sürece (içerik yükü kaymaları gibi) olgunlaşmamış kaldığını, ancak henüz olgunlaşmamış olduğunu gördük. belirli bir nedeni belirlemede her zaman yardımcı olur. Bunun, bu aracın gelecek yinelemelerinde (özellikle Chrome Geliştirici Araçları'nda) olgunlaşmasını beklesek de, belirli sorunları belirlemek için alternatif tanılama işlemlerinin gerekli olabileceğini bulduk.

Ayrıca, bu ölçümleri iyileştirmek için çalışmanın, bir bütün olarak sayfa hızı performansını iyileştirmeye benzer nitelikte olduğunu bulduk. Her durumda, "mükemmel puan" arayışına karşı tavsiyede bulunuyoruz. Bunun yerine 80/20 kuralı geçerlidir. Düşük asılı meyveyi ele alırsanız, ölçümlerinizde büyük olasılıkla önemli bir gelişme göreceksiniz. Bundan sonra, iyileştirme daha fazla zaman alıcı, daha pahalı ve daha az etkili hale gelir.

Google'ın tüm resim, video ve kapsayıcı öğelerine alan koruyan işaretleme veya CSS ekleme önerisi gibi temel rehberlik, genellikle uygulanması kolay olan iyi bir öneridir. Diğer sorunların izini sürmek daha zordur ve ölçümleriniz üzerinde aşırı bir etkiye sahip olmadıkça (önerilen araçlardan bazıları tarafından bildirildiği gibi), bu sorunları bir kenara bırakmak en iyisi olabilir.

Site mimarisi, bu öğelerin ele alınabileceği göreceli kolaylıkta da önemli bir rol oynayacaktır. Shopify ve WordPress gibi popüler site platformlarının yanı sıra WP Bakery ve Shogun gibi grafik sayfa oluşturucular, HTML oluşturma sürecinin bir bölümünü "perde arkasında" yönetir. Sayfa oluşturucu bileşenleri tarafından gizlenen sorunlar (örneğin, bazı resimlerin geç yüklenmesi), sitede temel değişiklikler veya platform, tema veya eklenti/uygulama satıcısının desteği olmadan kolayca ele alınamayabilir.

Yukarıdaki kavram, widget'ları sayfanıza tembel bir şekilde yüklemek için javascript kullanan üçüncü tarafları kapsar (örneğin, Klaviyo gibi e-posta platformlarından katıştırılmış kayıt formları). Bazı durumlarda, rahatsız edici bileşenin yerleştirme kodunun etrafına düzgün ve açıkça boyutlandırılmış bir kapsayıcı öğe yerleştirmek uygulanabilir bir çözümdür. Diğer durumlarda, satıcının kendisinin bir değişiklik yapması gerekebilir.

Kolayca erişilebilen temel site şablonlarında (ör. ürün sayfaları, ürün toplama sayfaları vb.) Bu genellikle tek bir kod değişikliğinin onlarca veya yüzlerce site sayfasındaki sonuçları iyileştirmesine izin verir. Ardından, sitedeki neredeyse her zaman en çok ziyaret edilen sayfa olduğu için ana sayfaya gidin. Son olarak, sorunun ciddiyetine ve sayfanın görünürlüğüne göre düzeltme gerektiren diğer tek tek sayfalara öncelik verin.

Sayfa hızı iyileştirmelerinde olduğu gibi, Önemli Web Verilerini yönetmek önemlidir, ancak bu, Google'ın sıralama algoritmasındaki birçok değişken arasında yalnızca bir değişkendir ve SEO, zaman ve bütçe için rekabet eden diğer site ve iş önceliklerine karşı da dengelenmelidir.