Pelajari alasan data RUM dapat menampilkan angka Data Web Inti yang berbeda dari CrUX.
Laporan Pengalaman Pengguna Chrome (CrUX) memberikan metrik pengalaman pengguna terkait kualitas pengalaman yang didapatkan pengguna Chrome di berbagai tujuan populer di web. Data ini dikumpulkan secara otomatis oleh Chrome dari pengguna yang telah memilih untuk ikut serta, dan disediakan berdasarkan kriteria kelayakan CrUX.
Oleh karena itu, data CrUX tersedia untuk jutaan situs. Banyak pemilik situs yang belum memiliki akses ke data lapangan sebelumnya, dan CrUX telah memungkinkan banyak situs melihat nilai ini untuk pertama kalinya. Sebagai set data publik, CrUX juga dapat digunakan untuk analisis kompetitif dan benchmark metrik pengalaman pengguna.
Real User Monitoring (RUM) mirip dengan CrUX, tetapi bukannya Chrome yang otomatis mengumpulkan metrik pengalaman pengguna, kode disertakan di situs untuk melakukan pengumpulan ini dan mengirimkannya kembali ke penyedia RUM atau solusi analisis untuk analisis lebih lanjut.
Dengan kedua solusi yang mengukur metrik pengalaman pengguna, wajar untuk mengasumsikan bahwa keduanya harus setara. Hal ini dapat membingungkan saat kita melihat perbedaan. Panduan ini akan menjelaskan mengapa hal itu dapat terjadi, dan menawarkan saran tentang tindakan yang harus dilakukan jika angkanya tidak sesuai.
Manfaat melengkapi CrUX dengan solusi RUM
CrUX adalah alat yang efektif untuk memberikan tampilan yang konsisten di berbagai situs dan—sebagai set data resmi untuk program Core Web Vitals—situs mungkin ingin memperhatikan apa yang ditampilkan. Tujuan CrUX adalah memberikan ringkasan yang relevan secara statistik dari jutaan situs untuk perbandingan silang.
Namun, untuk mempelajari lebih dalam tentang alasan data mengapa menunjukkan angka yang sama, berinvestasi pada solusi RUM lengkap untuk melengkapi CrUX dapat memberi Anda akses ke informasi yang lebih mendetail daripada yang dapat disediakan dalam set data yang dapat dikueri secara publik. Hal ini dapat membantu Anda menjelaskan dan meningkatkan metrik dengan beberapa cara.
Analisis yang lebih mendalam untuk menyelidiki masalah
CrUX sering kali dapat digunakan untuk menunjukkan jika Anda memiliki masalah di situs, tetapi belum tentu tepat di bagian situs mana masalah tersebut berada atau mengapa. Solusi RUM—baik yang dibuat sendiri melalui library web-vitals atau beberapa dari banyak produk komersial—dapat membantu menjembatani kesenjangan tersebut.
Dengan solusi RUM, Anda dapat mengakses data yang jauh lebih mendetail untuk semua halaman dan browser. Fitur ini juga memungkinkan Anda menyegmentasikan dan menganalisis data ini dengan cara yang tidak dilakukan CrUX, sehingga Anda dapat melihat perincian dan menyelidiki area masalah di situs. Apakah masalah tersebut memengaruhi segmen pengguna tertentu? Atau pengguna yang melakukan tindakan tertentu? Tepatnya kapan masalah dimulai? Pertanyaan-pertanyaan ini jauh lebih mudah dijawab dengan data tambahan yang dapat diberikan oleh alat RUM.
Kaitkan dengan metrik bisnis lainnya
RUM juga memungkinkan Anda membandingkan metrik performa web secara langsung dengan metrik bisnis apa pun, yang menunjukkan nilai investasi dalam performa, dan performa lain yang harus diprioritaskan. Kami memiliki banyak studi kasus dengan bisnis yang melakukan korelasi ini, seperti Farfetch atau The Economic Times.
Mengumpulkan data performa lainnya
Solusi RUM memungkinkan pengumpulan metrik kustom lainnya, yang terkait langsung dengan bisnis spesifik Anda. Salah satu contoh yang lebih dikenal adalah metrik "Waktu hingga Tweet pertama" Twitter. Kemudian, ukuran khusus situs ini dapat dikorelasikan dengan peningkatan Core Web Vitals dan metrik bisnis.
Perbedaan antara dua set data bidang
Pria dengan satu jam tahu waktunya. Pria dengan dua jam tidak pernah yakin.
Hukum Segal
Setiap kali Anda memiliki dua sumber data, Anda mungkin merasa bingung dan frustrasi karena perbedaannya. Dengan cara yang sama seperti memahami perbedaan antara metrik kolom dan lab, ada juga perbedaan antara dua sumber data kolom. Meskipun data tersebut akan sama di dunia ideal, ada banyak alasan mengapa mereka bisa berbeda.
Data lab versus data lapangan
Hal pertama yang harus diperiksa adalah apakah Anda melihat metrik lab (sintetis) atau metrik lapangan (RUM). Meskipun wajar untuk mengasumsikan bahwa produk RUM hanya melihat data kolom, banyak produk juga menawarkan komponen lab.
Data lab sangat berguna karena kondisi tetap yang digunakan untuk mengukurnya. Alat ini dapat digunakan untuk memantau perubahan atau regresi yang tidak terduga dalam lingkungan produksi tanpa derau perubahan populasi kolom. Namun, data lab mungkin tidak mewakili pengalaman pengguna yang sebenarnya, sehingga metrik lapangan dapat menunjukkan hasil yang sangat berbeda.
Populasi
Set data yang digunakan oleh solusi CrUX dan RUM mungkin berbeda karena perbedaan kunjungan halaman yang diukur bergantung pada browser, pengguna, situs, dan perangkat yang dibandingkan.
Browser yang disertakan
Seperti namanya, Laporan Pengalaman Pengguna Chrome hanya untuk Chrome. Meskipun ada banyak browser berbasis Chromium (Edge, Opera, dan Brave) yang juga mendukung metrik yang sama dengan Chrome karena codebase intinya yang sama, hanya pengguna Chrome yang memasukkan data ke CrUX. Pembatasan ini juga berarti pengguna Chrome di iOS tidak disertakan, karena menggunakan mesin browser Webkit yang mendasarinya. Android WebView juga tidak dihitung sebagai "Chrome", sehingga data dari pengguna ini tidak disertakan—meskipun Tab Khusus Chrome disertakan.
Meskipun Chrome adalah salah satu browser paling populer di dunia—dan kemungkinan besar akan memberikan gambaran luas tentang performa situs Anda dalam kebanyakan kasus—hanya mengukur browser tersebut sama sekali bukan ukuran dari semua pengguna Anda. Hal ini dapat menjelaskan salah satu perbedaan utama antara RUM dan CrUX. Hal ini terutama berlaku untuk teknik performa yang mengandalkan API atau format gambar yang hanya tersedia di Chrome, misalnya.
Kurangnya data iOS juga dapat menyebabkan bias. Misalnya, karena pengguna iOS biasanya menggunakan perangkat berperforma lebih tinggi atau berkunjung dari lebih banyak negara dengan infrastruktur jaringan yang lebih baik, termasuk pengguna tersebut dapat menyebabkan metrik performa yang tinggi secara keseluruhan. Di sisi lain, mengecualikannya—seperti yang dilakukan CrUX—dapat menyebabkan data yang terdistorsi ke ujung bawah pengunjung situs (contoh studi kasus). Pengguna Android biasanya mencakup berbagai perangkat, kemampuan perangkat, dan pasar yang lebih luas.
Solusi RUM dapat mendapatkan data untuk browser non-Chrome, dan khususnya dari browser berbasis Chromium yang sering kali memiliki metrik yang sama (seperti Core Web Vitals) bawaan. Browser non-Chromium juga diukur oleh solusi RUM, tetapi mungkin memiliki kumpulan metrik yang lebih terbatas. Misalnya, Cumulative Layout Shift (CLS) dan Interaction to Next Paint (INP) hanya tersedia di browser berbasis Chromium. Beberapa metrik lain seperti First Contentful Paint (FCP) dapat diukur dengan cara yang sangat berbeda (lihat nanti).
Pengguna yang diikutsertakan
Selain dibatasi untuk pengguna Chrome, CrUX juga dibatasi lebih lanjut dengan hanya mengukur subkumpulan pengguna Chrome yang telah memilih untuk membagikan data CrUX saat browser diinstal.
Penyedia RUM juga hanya melihat sebagian pengguna, biasanya karena perintah banner cookie—yang meminta pengguna untuk ikut serta dalam pengumpulan data RUM—atau pemblokir pelacakan. Hal ini dapat berpengaruh buruk pada beberapa pemuatan halaman awal jika konfirmasi tidak diberikan hingga halaman kedua atau berikutnya, saat beberapa aset situs telah disimpan dalam cache dari halaman sebelumnya. Jika hal ini sering terjadi, metrik mungkin tampak lebih baik di RUM daripada yang sebenarnya jika pemuatan halaman awal yang lebih lambat dikecualikan dalam jumlah kasus yang memadai.
Situs yang disertakan
CrUX hanya ditujukan untuk melaporkan situs publik, sehingga ada kriteria kelayakan lain yang dapat menyebabkan data tidak dicatat di CrUX. Kriteria yang paling penting adalah situs harus dapat ditemukan secara publik dan cukup populer untuk memastikan ukuran sampel minimal yang dapat digunakan untuk menarik kesimpulan yang bermakna. Umumnya, hal ini akan menyebabkan tidak ada data yang tersedia di CrUX. Perbedaan ini tidak terlalu membingungkan dibandingkan dengan data yang tersedia tetapi berbeda, tetapi menjelaskan mengapa hal itu terjadi.
Namun, jika halaman tertentu di situs ditandai sebagai dapat diindeks, tetapi halaman lainnya tidak, Anda mungkin hanya melihat sebagian URL di CrUX. Jika origin dapat ditemukan secara publik, semua kunjungan halaman dalam origin tersebut akan disertakan dalam data tingkat origin, tetapi data tingkat URL mungkin tidak tersedia.
Perangkat
CrUX menyegmentasikan data menurut perangkat seluler, desktop, dan tablet - meskipun banyak alat yang berfokus pada dua perangkat pertama dan mungkin tidak mengekspos data tablet, atau mungkin menyertakannya dalam perangkat seluler atau desktop. Karakteristik performa pada seluler versus desktop bisa sangat berbeda—baik dari segi konten yang ditayangkan, maupun dalam kemampuan perangkat untuk melihatnya.
Data RUM akan memungkinkan segmentasi traffic dengan cara yang sama, tetapi sering kali menampilkan data gabungan secara default. RUM mungkin hanya mengizinkan segmentasi menurut jenis perangkat (misalnya, seluler) atau browser (misalnya, Chrome), tetapi tidak keduanya untuk hanya melihat traffic Chrome seluler. Saat membandingkan dengan data CrUX, pastikan Anda membandingkan secara sejenis dengan memfilter berdasarkan jenis perangkat dan browser Chrome.
Pengambilan sampel
Solusi RUM biasanya memungkinkan penyesuaian rasio pengambilan sampel dari pengunjung yang memilih untuk ikut serta dalam pengumpulan data. Hal ini dapat digunakan untuk mengurangi volume data yang perlu dianalisis, dan untuk mengurangi biaya layanan RUM komersial. Jika ukuran sampel terlalu kecil dan tidak mewakili populasi yang lebih luas, metrik yang dihasilkan juga akan condong ke arah yang sama. Diskusikan dengan penyedia RUM Anda ukuran sampling yang sesuai untuk situs Anda.
Agregasi data
Data kolom pada dasarnya akan menyertakan banyak sekali titik data dari metrik yang sama dibandingkan dengan data lab, yang akan memberikan satu nilai. Jika data ini digabungkan secara berbeda untuk pelaporan, hal ini dapat menyebabkan alasan lain terjadinya perbedaan antara CrUX dan RUM.
Rentang waktu
Data CrUX didasarkan pada periode geser traffic 28 hari, dan jangka waktu ini tidak dapat diubah—meskipun data BigQuery CrUX disimpan untuk setiap bulan, sehingga Anda dapat melihat bulan sebelumnya, dan CrUX History API juga memberikan data historis selama periode mingguan. Keduanya masih menyediakan data berdasarkan periode 28 hari.
Data RUM biasanya memungkinkan perincian yang jauh lebih besar agar dampak perubahan dapat terlihat lebih cepat. Namun, saat memilih periode yang lebih kecil, data RUM dapat sangat terpengaruh oleh fluktuasi traffic situs dan pengunjung. Saat membandingkan data RUM dengan data CrUX, selalu pastikan Anda melihat performa selama 28 hari. Setelah yakin bahwa datanya serupa, Anda dapat melihat jangka waktu lain untuk melihat perincian data RUM.
Agregasi statistik
Metrik CrUX diukur pada persentil ke-75—yaitu, dengan melihat nilai yang dicapai oleh 75% kunjungan halaman. Akan ada ekstrem dalam data lapangan dan menghapus 25% pengalaman terburuk. Hal ini dimaksudkan untuk memberikan nilai yang dapat diharapkan oleh sebagian besar pengunjung secara wajar.
Produk RUM sering kali memberikan lebih banyak opsi cara menggabungkan metrik, termasuk persentil ke-75, median, dan persentil lainnya. Jika membandingkan nilai RUM dengan data CrUX, Anda harus memastikan bahwa Anda melihat data persentil ke-75 untuk membandingkan data yang sama.
Data histogram di CrUX mencakup semua data yang tersedia—tidak hanya persentil ke-75—dan menampilkan jumlah tayangan halaman di setiap rating, tetapi skor gabungan akan didasarkan pada persentil ke-75. Data CrUX ini ditampilkan di alat seperti PageSpeed Insights:
Perbedaan metrik
Ada banyak metrik yang digunakan untuk mengukur performa web. Jadi, saat membandingkan dua kumpulan data yang berbeda, penting untuk memahami metrik yang diukur, dan cara metrik tersebut digunakan.
Metrik yang diukur
Data CrUX adalah set data resmi dari inisiatif Core Web Vitals dan terutama mengukur metrik ini (LCP, CLS, dan INP), dengan beberapa metrik tambahan untuk melengkapinya.
Alat RUM biasanya menyertakan Core Web Vitals ini, tetapi sering kali juga menyertakan banyak metrik lainnya. Beberapa penyedia RUM juga mengukur pengalaman pengguna menggunakan kombinasi mereka sendiri dari semua metrik ini, mungkin untuk memberikan "indeks kepuasan" atau semacamnya. Saat membandingkan data RUM dengan CrUX, pastikan Anda membandingkan data yang serupa.
Alat yang menilai status lulus atau gagal Data Web Inti harus menganggap halaman lulus jika memenuhi target yang direkomendasikan pada persentil ke-75 untuk semua Data Web Inti. Jika INP tidak ada untuk halaman tanpa interaksi, hanya LCP dan CLS yang perlu lulus.
Perbedaan metrik di seluruh browser
CrUX hanya mengukur di browser Chrome, dan Anda dapat melihat Log Perubahan Web Vitals untuk melihat perubahannya pada setiap versi Chrome.
Namun, solusi RUM akan mengukur dari berbagai browser. Browser berbasis Chromium (Edge, Opera, dan sebagainya) kemungkinan akan mirip dengan Chrome, kecuali jika Chrome menerapkan perubahan baru seperti yang tercantum dalam Log Perubahan.
Untuk browser non-Chromium, perbedaannya dapat lebih terlihat. Misalnya, First Contentful Paint (FCP) tersedia di Safari dan Firefox, tetapi diukur dengan cara yang berbeda. Hal ini dapat menyebabkan varians yang signifikan pada waktu yang dilaporkan. Seperti yang dinyatakan sebelumnya, jika Anda ingin membandingkan RUM dengan CrUX, sebaiknya filter hanya pengguna Chrome untuk memungkinkan perbandingan yang setara.
Waktu metrik
Metrik Core Web Vitals disediakan oleh API browser web, tetapi bukan berarti tidak ada potensi perbedaan nilai yang dilaporkan menggunakan API tersebut. Waktu pengukuran metrik dilakukan—saat pemuatan halaman atau selama siklus proses halaman penuh—dapat menyebabkan perbedaan. Alat RUM mungkin tidak selalu mengukur metrik dengan cara yang sama—meskipun menggunakan nama yang sama—dan API browser yang sama untuk mendapatkan data, yang dapat membingungkan.
Largest Contentful Paint (LCP) adalah metrik pemuatan halaman. Sejumlah elemen LCP dapat dilaporkan oleh Web API jika elemen yang lebih besar dimuat nanti setelah rendering awal. Elemen LCP akhir adalah saat halaman selesai dimuat atau pengguna berinteraksi dengan halaman. Oleh karena itu, perbedaan dapat muncul jika elemen LCP dilaporkan lebih awal dari kedua peristiwa tersebut.
Selain itu, dalam data kolom, elemen LCP dapat berbeda-beda bergantung pada cara halaman dimuat. Untuk pemuatan halaman default yang menampilkan bagian atas konten halaman, elemen LCP akan bergantung terutama pada ukuran layar. Namun, jika halaman dibuka dengan link anchor di bagian bawah dokumen, atau dibuka dengan deep link ke Aplikasi Web Satu Halaman (SPA)—selengkapnya nanti—elemen LCP dapat berbeda.
Jangan berasumsi bahwa pengaturan waktu LCP yang diberikan di CrUX atau RUM didasarkan pada elemen yang sama dengan alat lab. Meskipun CrUX akan memberi Anda nilai LCP keseluruhan per halaman atau asal, RUM dapat menyegmentasikan ini lebih lanjut untuk mengidentifikasi sesi masalah LCP individual.
Pergeseran Tata Letak Kumulatif (CLS) diukur sepanjang masa aktif halaman, sehingga CLS pemuatan halaman awal mungkin tidak mewakili halaman yang menyebabkan pergeseran yang lebih besar nanti setelah halaman dimuat dan pengguna berinteraksi dengannya. Mengambil nilai CLS hanya setelah pemuatan halaman—seperti yang dilakukan banyak produk RUM—sehingga akan memberikan hasil yang berbeda daripada mengambil nilai CLS setelah pengguna selesai dengan halaman.
Metrik responsivitas Interaction to Next Paint (INP) memerlukan input untuk diukur, dan mengamati semua interaksi klik, ketuk, dan keyboard selama masa aktif halaman, dengan cara yang mirip dengan CLS, sehingga nilai INP yang dilaporkan mungkin sangat berbeda jika diukur setelah pengguna melakukan sejumlah interaksi di halaman.
CrUX akan mengikuti dokumentasi Data Web Inti dan mengukurnya selama masa aktif halaman. Banyak penyedia RUM memilih untuk mengukur metrik ini setelah pemuatan halaman, atau pada waktu lain (misalnya, saat pesan ajakan (CTA) utama diklik) karena berbagai alasan.
Memahami dari penyedia RUM Anda kapan Data Web Inti diukur adalah hal yang penting saat melihat varians yang tidak dapat dijelaskan antara kedua sumber data.
Aplikasi web satu halaman
Aplikasi web satu halaman (SPA) bekerja dengan memperbarui konten di halaman saat ini, bukan melakukan navigasi halaman yang sebenarnya di tingkat browser. Artinya, browser tidak melihatnya sebagai navigasi halaman, meskipun pengguna mengalaminya seperti itu. API Data Web Inti yang disediakan oleh browser tidak akan mempertimbangkan hal ini, sehingga CrUX tidak mendukung navigasi halaman ini. Pekerjaan sedang berlangsung untuk menyelesaikan masalah ini—lihat postingan Bereksperimen dengan mengukur navigasi virtual untuk informasi selengkapnya.
Beberapa penyedia RUM memang mencoba mendeteksi "navigasi ringan" di SPA, tetapi jika mereka juga mengaitkan metrik Core Web Vitals ke "navigasi ringan", hal itu akan menyebabkan perbedaan dengan CrUX karena API dasar tidak mendukung ini untuk banyak metrik.
Perbedaan CrUX dan Web API
Selain perbedaan halaman yang diukur dan apa yang diukur, ada beberapa skenario lain yang lebih rumit yang perlu diketahui dan dapat menyebabkan perbedaan dalam data CrUX dan RUM. Beberapa hal ini disebabkan oleh keterbatasan Web API yang digunakan untuk mengukur metrik, dan beberapa hal lainnya disebabkan oleh hasil yang ditampilkan oleh API yang perlu diperlakukan secara berbeda untuk skenario tertentu. Dokumentasi Data Web Inti mencantumkan perbedaan ini untuk LCP dan CLS, tetapi perbedaan utamanya juga dicatat di bagian berikut.
Back-forward cache
CrUX menganggap pemulihan Back/forward cache (atau bfcache) sebagai navigasi halaman meskipun tidak menghasilkan pemuatan halaman konvensional. Karena Web API tidak memperlakukannya sebagai pemuatan halaman, solusi RUM perlu mengambil langkah tambahan agar halaman ini dihitung jika ingin cocok dengan CrUX. Ini adalah pemuatan halaman yang jauh lebih cepat yang dapat menghasilkan performa yang lebih baik secara keseluruhan yang dilaporkan untuk situs, sehingga tidak menyertakannya dapat menghasilkan metrik performa halaman yang lebih buruk secara keseluruhan. Lihat solusi RUM Anda untuk memahami apakah solusi tersebut menangani halaman yang dipulihkan bfcache.
iFrame
Untuk alasan keamanan dan privasi, halaman tingkat atas tidak memiliki akses ke konten dalam iframe (bahkan iframe dengan origin yang sama). Artinya, metrik performa untuk konten di dalamnya hanya dapat diukur oleh iframe itu sendiri, dan bukan melalui Web API di halaman framing. Jika konten iframe menyertakan elemen LCP, atau konten yang memengaruhi CLS atau INP yang dialami pengguna, konten tersebut tidak akan tersedia untuk solusi RUM (termasuk library JavaScript web-vitals Google).
Namun, CrUX, yang diukur oleh browser Chrome itu sendiri, bukan JavaScript di halaman, tidak memiliki batasan ini dan juga mengukur metrik dalam iframe saat melaporkan Core Web Vitals. Hal ini lebih akurat mencerminkan pengalaman pengguna, tetapi dapat menjadi alasan lain terjadinya perbedaan untuk situs yang menggunakan iframe.
Salah satu contoh konkret bagaimana hal ini dapat menghasilkan perbedaan antara data LCP di CrUX dan RUM adalah disematkan <video>. Frame pertama yang digambar elemen <video> yang diputar otomatis dengan playsinline dapat dihitung sebagai kandidat LCP, tetapi penyematan untuk layanan streaming video populer dapat menempatkan elemen ini di <iframe>. CrUX dapat memperhitungkan hal ini, karena dapat mengakses konten <iframe>, tetapi solusi RUM tidak dapat melakukannya.
Resource lintas origin
Media LCP yang disalurkan dari domain lain tidak memberikan waktu render di PerformanceObserver API—kecuali jika header Timing-Allow-Origin (TAO) disediakan—karena pembatasan keamanan browser untuk mengurangi serangan pengaturan waktu. Hal ini kembali ke waktu pemuatan resource, tetapi mungkin sangat berbeda dengan saat konten benar-benar digambar.
Hal ini dapat menyebabkan situasi yang tampaknya tidak mungkin terjadi ketika LCP dilaporkan oleh API web lebih awal daripada FCP. Hal ini tidak benar, tetapi hanya muncul karena pembatasan keamanan ini.
Sekali lagi, CrUX melaporkan data waktu render untuk Data Web Inti. Situs disarankan untuk membatasi konten lintas-asal yang memengaruhi metrik Core Web Vitals dan mengaktifkan TAO jika memungkinkan jika ingin mengukurnya dengan lebih akurat. Resource lintas origin lainnya mungkin tunduk pada batasan serupa.
Tab latar belakang
Jika tidak dibuka di tab latar belakang, halaman akan tetap memunculkan metrik menggunakan Web API. Namun, hal ini tidak dilaporkan oleh CrUX karena memberikan pengaturan waktu yang tidak konsisten dengan pengalaman pengguna. Solusi RUM juga harus mempertimbangkan untuk mengabaikannya, atau setidaknya menjelaskan cara penayangan halaman ini diperlakukan.
Jadi, apa yang dapat kita lakukan?
Kami telah menunjukkan mengapa mungkin ada perbedaan antara data CrUX dan RUM, baik karena perbedaan metodologi yang digunakan masing-masing maupun karena pengguna dan kunjungan halaman yang disertakan atau dikecualikan. Idealnya, kedua set data tersebut akan tetap mewakili performa situs Anda agar berguna, tetapi alasan yang diberikan harus menjelaskan mengapa sangat tidak mungkin untuk mendapatkan angka yang sama persis di masing-masing set data.
Jika perbedaannya sedikit (misalnya melaporkan LCP 2,0 detik versus 2,2 detik), kedua set data akan berguna dan biasanya dapat dianggap hampir sinkron.
Ketika perbedaan pengucapan membuat Anda mempertanyakan keakuratan data, Anda harus mencoba memahami perbedaan tersebut. Dapatkah data RUM difilter agar lebih selaras dengan CrUX (hanya melihat pengguna Chrome, untuk desktop atau seluler, dengan nilai persentil ke-75 selama 28 hari) untuk mengurangi perbedaan ini?
Jika demikian—dan Anda dapat membuat data tersebut lebih cocok—Anda tetap harus bertanya mengapa Anda melihat perbedaan ini dalam keseluruhan data dan apa artinya. Apakah pengguna non-Chrome memberikan distorsi pada metrik Anda secara positif atau negatif? Apakah hal ini memberi Anda lebih banyak insight tentang tempat Anda mengalami masalah performa yang dapat diprioritaskan?
Jika pengguna non-Chrome mendapatkan hasil yang berbeda, Anda dapat menggunakan insight berharga yang diberikan RUM untuk melakukan pengoptimalan yang berbeda. Misalnya, API tertentu tidak tersedia di browser tertentu, tetapi Anda dapat mempertimbangkan alternatif untuk browser yang tidak didukung untuk meningkatkan pengalamannya juga. Atau, Anda dapat memberikan pengalaman yang berbeda, tetapi lebih berperforma kepada pengguna di perangkat atau jaringan yang dibatasi. CrUX terbatas pada data Chrome, tetapi Anda harus mempertimbangkan semua pengalaman pengunjung situs untuk membantu memprioritaskan peningkatan. Data RUM dapat mengisi kesenjangan tersebut.
Setelah Anda memahami alasan perbedaannya, kedua alat ini dapat sangat berguna untuk memahami pengalaman pengguna di situs Anda, dan untuk membantu meningkatkannya meskipun jumlahnya tidak sama. Gunakan data RUM untuk melengkapi data CrUX dan memungkinkan Anda mempelajari informasi yang diberikan CrUX di tingkat tinggi dengan menyegmentasikan traffic untuk membantu Anda mengidentifikasi apakah ada area tertentu di situs atau basis pengguna yang perlu diperhatikan.
Melihat tren untuk melihat apakah peningkatan Anda memberikan dampak positif yang diharapkan sering kali lebih penting daripada memastikan setiap angka cocok persis antara dua sumber data. Seperti yang disebutkan sebelumnya, RUM memungkinkan Anda melihat berbagai jangka waktu untuk mendapatkan gambaran awal tentang skor CrUX 28 hari Anda—meskipun melihat jangka waktu yang terlalu singkat dapat menyebabkan data yang berisi derau, sehingga CrUX menggunakan 28 hari.
Sering kali tidak ada jawaban "benar" atau "salah" dalam berbagai metrik ini. Metrik ini hanyalah sudut pandang yang berbeda pada pengguna dan bagaimana pengalaman mereka di situs Anda. Selama Anda memahami alasan perbedaan ini terjadi, dan pengaruhnya terhadap pengambilan keputusan Anda, hal itulah yang lebih penting untuk melayani pengunjung situs dengan lebih baik.
Ucapan terima kasih
Gambar thumbnail oleh Steven Lelham di Unsplash