Sahada Web Verileri'ni ölçmek için en iyi uygulamalar

Mevcut analiz aracınızla Web Verileri'ni ölçme.

Sayfalarınızın gerçek dünyadaki performansını ölçme ve raporlama imkanına sahip olmak, zaman içindeki performansı teşhis etmek ve iyileştirmek açısından çok önemlidir. Alan verileri olmadan, sitenizde yaptığınız değişikliklerin gerçekten istenen sonuçları sağlayıp sağlamadığından emin olmak imkansızdır.

Birçok popüler Gerçek Kullanıcı İzleme (RUM) analiz sağlayıcısı, araçlarında Önemli Web Verileri metriklerini (ve diğer Web Verileri'ni) zaten desteklemektedir. Şu anda bu RUM analiz araçlarından birini kullanıyorsanız sitenizdeki sayfaların önerilen Core Web Vitals eşiklerini karşılama ve gelecekte regresyonları önleme konusunda ne kadar başarılı olduğunu değerlendirebilirsiniz.

Core Web Vitals metriklerini destekleyen bir analiz aracı kullanmanızı önersek de kullandığınız analiz aracı bu metrikleri desteklemiyorsa mutlaka geçiş yapmanız gerekmez. Neredeyse tüm analiz araçları, özel metrikleri veya etkinlikleri tanımlamak ve ölçmek için bir yol sunar. Bu da, Önemli Web Verileri metriklerini ölçmek ve bunları mevcut analiz raporlarınıza ve kontrol panellerinize eklemek için büyük olasılıkla mevcut analiz sağlayıcınızı kullanabileceğiniz anlamına gelir.

Bu kılavuzda, Önemli Web Verileri metriklerini (veya herhangi bir özel metriği) bir üçüncü taraf veya şirket içi analiz aracıyla ölçmeye yönelik en iyi uygulamalar ele alınmaktadır. Ayrıca, hizmetlerine Önemli Web Verileri desteğini eklemek isteyen analiz sağlayıcıları için bir rehber görevi görebilir.

Özel metrikleri veya etkinlikleri kullanma

Yukarıda belirtildiği gibi, çoğu analiz aracı özel verileri ölçmenize olanak tanır. Analiz aracınız bunu destekliyorsa bu mekanizmayı kullanarak Önemli Web Verileri metriklerinin her birini ölçebilmeniz gerekir.

Bir analiz aracında özel metrikleri veya etkinlikleri ölçmek genellikle üç adımlı bir işlemdir:

  1. Özel metriği aracınızın yöneticisinde tanımlayın veya kaydedin (gerekirse). (Not: Tüm analiz sağlayıcıları, özel metriklerin önceden tanımlanmasını gerektirmez.)
  2. Ön uç JavaScript kodunuzdaki metriğin değerini hesaplayın.
  3. Ad veya kimliğin 1. adımda (gerekirse) tanımlanan değerle eşleştiğinden emin olarak metrik değerini analiz arka ucunuza gönderin.

1. ve 3. adımlarla ilgili talimatlar için analiz aracınızın dokümanlarına bakabilirsiniz. 2. adım için Önemli Web Verileri metriklerinin her birinin değerini hesaplamak amacıyla web-vitals JavaScript kitaplığını kullanabilirsiniz.

Aşağıdaki kod örneğinde, bu metrikleri kod içinde izlemenin ve analiz hizmetine göndermenin ne kadar kolay olabileceği gösterilmektedir.

import {onCLS, onINP, onLCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  const body = JSON.stringify({name, value, id});
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

Ortalamalardan kaçınma

Bir performans metriğindeki değer aralığını, ortalama hesaplayarak toplamak cazip gelebilir. Ortalamalar, büyük miktarda verinin derli toplu bir özeti oldukları için ilk bakışta kullanışlı görünür ancak sayfa performansını yorumlamak için ortalamalara güvenme dürtüsüne yenilmemelisiniz.

Tek bir kullanıcının oturumunu temsil etmediğinden ortalamalar sorunludur. Dağılımın herhangi bir aralığındaki aykırı değerler, ortalamayı yanıltıcı şekillerde çarpıtabilir.

Örneğin, küçük bir kullanıcı grubu aşırı yavaş ağlar veya maksimum değer aralığına yakın cihazlar kullanıyor olabilir. Ancak kullanıcı oturumlarını, ortalamayı bir sorun olduğunu gösterecek şekilde etkilemek için yeterli sayıda hesaba katılmamış olabilir.

Mümkün olduğunda ortalamalar yerine yüzdelik dilimleri kullanın. Belirli bir performans metriğine ait bir dağılımdaki yüzdelik dilimler, web sitenizdeki tüm kullanıcı deneyimlerini daha iyi açıklar. Bu sayede, gerçek deneyimlerin alt kümelerine odaklanabilirsiniz. Bu sayede, tek bir değerden daha fazla bilgi edinebilirsiniz.

Dağıtımı bildirebildiğinizden emin olma

Önemli Web Verileri metriklerinin her birinin değerlerini hesapladıktan ve özel metrik veya etkinlik kullanarak analiz hizmetinize gönderdikten sonraki adım, toplanan değerleri gösteren bir rapor ya da kontrol paneli oluşturmaktır.

Önerilen Core Web Vitals eşiklerini karşıladığınızdan emin olmak için raporunuzun her metriğin değerini 75. yüzdelik dilimde göstermesi gerekir.

Analiz aracınız yerleşik bir özellik olarak niceliksel raporlamayı sunmuyorsa, büyük olasılıkla tüm metrik değerlerini artan düzende listeleyen bir rapor oluşturarak bu verileri manuel olarak alabilirsiniz. Bu rapor oluşturulduktan sonra, söz konusu rapordaki tüm değerlerin yer aldığı tam, sıralanmış listede% 75'lik bir oranla elde edilen sonuç, söz konusu metriğin 75. yüzdelik dilimi olur ve verilerinizi nasıl segmentlere ayırırsanız (cihaz türü, bağlantı türü, ülke vb.) segmentlere ayırın.

Analiz aracınız size varsayılan olarak metrik düzeyinde raporlama ayrıntı düzeyini sağlamıyorsa, analiz aracınız özel boyutları destekliyorsa muhtemelen aynı sonucu elde edebilirsiniz. İzlediğiniz her bir metrik örneği için benzersiz, özel bir boyut değeri ayarlayarak özel boyutu rapor yapılandırmasına dahil ederseniz tekil metrik örneklerine göre dökümü alınmış bir rapor oluşturabilirsiniz. Her örneğin benzersiz bir boyut değeri olacağından gruplandırma yapılmaz.

Web Verileri Raporu, Google Analytics'in kullanıldığı bu tekniğe bir örnektir. Rapor kodu açık kaynaklıdır. Böylece geliştiriciler, bu bölümde açıklanan tekniklere örnek olarak bu rapora başvurabilir.

Web Verileri Raporu'nun
ekran görüntüleri

Verilerinizi doğru zamanda gönderin

Bazı performans metrikleri sayfanın yüklenmesi bittikten sonra hesaplanabilirken, bazıları (ör. CLS) sayfanın tüm kullanım ömrünü dikkate alır ve yalnızca sayfa yüklemeyi kaldırma işlemi başladıktan sonra nihaidir.

Ancak hem beforeunload hem de unload etkinlikleri güvenilir olmadığından (özellikle mobilde) ve kullanımları önerilmediğinden (bir sayfanın Geri-İleri Önbelleği için uygun olmasını engelleyebileceğinden) bu durum sorunlu olabilir.

Bir sayfanın tüm kullanım ömrünü izleyen metrikler için en iyi yöntem, visibilitychange etkinliği sırasında sayfanın görünürlük durumu hidden olarak değiştiğinde metriğin mevcut değerini göndermektir. Bunun nedeni, sayfanın görünürlük durumu hidden olarak değiştiğinde, sayfadaki herhangi bir komut dosyasının tekrar çalışabileceğinin garantisi olmamasıdır. Bu durum özellikle, tarayıcı uygulamasının herhangi bir sayfa geri çağırması tetiklenmeden kapatılabildiği mobil işletim sistemleri için geçerlidir.

Mobil işletim sistemlerinin sekmeler arasında, uygulama değiştirirken veya tarayıcı uygulamasını kapatırken genellikle visibilitychange etkinliğini tetiklediğini unutmayın. Bir sekmeyi kapatırken veya yeni bir sayfaya giderken de visibilitychange etkinliğini tetiklerler. Bu durum, visibilitychange etkinliğini unload veya beforeunload etkinliklerinden çok daha güvenilir hale getirir.

Zaman içindeki performansı izleme

Analiz uygulamanızı Önemli Web Verileri metriklerini hem izlemek hem de raporlamak üzere güncelledikten sonra, sıradaki adım sitenizdeki değişikliklerin zaman içinde performansı nasıl etkilediğini izlemektir.

Değişikliklerinizin sürümü

Değişiklikleri izleme konusunda naif (ve sonuç olarak da güvenilir olmayan) bir yaklaşım, değişiklikleri üretime dağıtmak ve ardından dağıtım tarihinden sonra alınan tüm metriklerin yeni siteye, dağıtım tarihinden önce alınan tüm metriklerin de eski siteye karşılık geldiğini varsaymaktır. Ancak birçok faktör (HTTP, hizmet çalışanı veya CDN katmanında önbelleğe alma dahil) bunun çalışmasını engelleyebilir.

Dağıtılan her değişiklik için benzersiz bir sürüm oluşturup analiz aracınızda bu sürümü izlemek çok daha iyi bir yaklaşımdır. Çoğu analiz aracı, sürüm ayarlamayı destekler. Sizinkinde yoksa özel bir boyut oluşturabilir ve bu boyutu dağıtılan sürümünüze ayarlayabilirsiniz.

Deney yapma

Aynı anda birden fazla sürümü (veya denemeyi) izleyerek sürüm oluşturmayı bir adım ileri taşıyabilirsiniz.

Analiz aracınız deneme grupları tanımlamanıza olanak tanıyorsa, bu özelliği kullanın. Aksi takdirde, metrik değerlerinizin her birinin raporlarınızda belirli bir deneme grubuyla ilişkilendirilebildiğinden emin olmak için özel boyutları kullanabilirsiniz.

Analytics'te denemeler sayesinde, kullanıcılarınızın bir alt grubuna deneme amaçlı bir değişiklik uygulayabilir ve bu değişikliğin performansını kontrol grubundaki kullanıcıların performansıyla karşılaştırabilirsiniz. Bir değişikliğin performansı gerçekten artıracağından emin olduktan sonra bunu tüm kullanıcılara sunabilirsiniz.

Ölçümün performansı etkilemediğinden emin olun

Gerçek kullanıcılar üzerinde performansı ölçerken, çalıştırdığınız performans ölçüm kodunun sayfanızın performansını olumsuz etkilememesi son derece önemlidir. Etkileniyorsa performansınızın işletmenizi nasıl etkilediğiyle ilgili çıkardığınız sonuçlar güvenilir olmaz çünkü analiz kodunun varlığının en büyük olumsuz etkiye sahip olup olmadığını hiçbir zaman bilemezsiniz.

Üretim sitenize RUM analiz kodunu dağıtırken her zaman bu ilkelere uyun:

Analizlerinizi erteleme

Analytics kodu her zaman eşzamansız ve hiçbir engellemeyen şekilde yüklenmeli ve genellikle en son yüklenmelidir. Analiz kodunuzu engelleyici bir şekilde yüklemeniz LCP'yi olumsuz etkileyebilir.

Önemli Web Verileri metriklerini ölçmek için kullanılan API'lerin tümü, eşzamansız ve ertelenmiş komut dosyası yüklemeyi desteklemek için (buffered işaretiyle) özel olarak tasarlanmıştır. Böylece komut dosyalarınızın erken yüklenmesi için acele etmenize gerek yoktur.

Sayfa yükleme zaman çizelgesinde daha sonra hesaplanamayan bir metriği ölçüyorsanız yalnızca dokümanınızın <head> öğesinde önceden çalıştırılması gereken kodu satır içine almanız (bu bir oluşturmayı engelleyen istek değildir) ve geri kalanını ertelemeniz gerekir. Sırf tek bir metrik için gerekli olduğu için tüm analizlerinizi erkenden yüklemeyin.

Uzun görevler oluşturma

Analytics kodu genellikle kullanıcı girişlerine yanıt olarak çalışır. Ancak analiz kodunuz çok sayıda DOM ölçümü yapıyor veya işlemciyi yoğun şekilde kullanan başka API'ler kullanıyorsa analiz kodunun kendisi giriş yanıt hızının zayıf olmasına yol açabilir. Ayrıca, analiz kodunuzu içeren JavaScript dosyası büyükse bu dosyayı yürütmek ana iş parçacığını engelleyebilir ve sayfanın Sonraki Boyama ile Etkileşimi (INP) olumsuz etkileyebilir.

Engellemeyen API'ler kullanma

sendBeacon() ve requestIdleCallback() gibi API'ler, özellikle kritik olmayan görevleri, kullanıcı açısından kritik görevleri engellemeyecek şekilde çalıştırmak için tasarlanmıştır.

Bu API'ler, RUM analiz kitaplığında kullanılabilecek harika araçlardır.

Genel olarak, tüm analiz işaretçileri (varsa) sendBeacon() API kullanılarak gönderilmeli ve tüm pasif analiz ölçüm kodu boşta kalma dönemlerde çalıştırılmalıdır.

İhtiyacınız olandan fazlasını takip etmeyin

Tarayıcı çok sayıda performans verisini açığa çıkarır, ancak verilerin kullanılabilir olması, bunları mutlaka kaydedip analiz sunucularınıza göndermeniz gerektiği anlamına gelmez.

Örneğin, Resource Timing API, sayfanızda yüklenen her bir kaynak için ayrıntılı zamanlama verileri sağlar. Ancak bu verilerin tamamının, kaynak yükü performansını iyileştirmede önemli veya yararlı olması pek olası değildir.

Kısacası, sadece mevcut verileri izlemekle yetinmeyin, verileri izleyen kaynakları tüketmeden önce verilerin kullanılmasını sağlayın.