Pelajari alasan data RUM dapat menampilkan angka Core Web Vitals yang berbeda dari CrUX.
Dipublikasikan: 15 Agustus 2022, Terakhir diperbarui: 17 Desember 2025
Chrome User Experience Report (CrUX) memberikan metrik pengalaman pengguna terkait cara pengguna Chrome yang sebenarnya menjelajahi tujuan populer di web. Data ini otomatis dikumpulkan oleh Chrome dari pengguna yang telah mengaktifkan fitur ini, dan tersedia berdasarkan kriteria kelayakan CrUX.
Oleh karena itu, data CrUX tersedia untuk jutaan situs. Banyak pemilik situs yang belum pernah memiliki akses ke data lapangan, dan CrUX telah memungkinkan banyak situs melihat nilai data ini untuk pertama kalinya. Sebagai set data publik, CrUX juga dapat digunakan untuk analisis kompetitif dan tolok ukur metrik pengalaman pengguna.
Pemantauan Pengguna Nyata (RUM) mirip dengan CrUX, tetapi alih-alih Chrome mengumpulkan metrik pengalaman pengguna secara otomatis, kode disertakan di situs untuk melakukan pengumpulan ini dan mengirimkannya kembali ke penyedia RUM atau solusi analisis untuk analisis lebih lanjut.
Karena kedua solusi tersebut mengukur metrik pengalaman pengguna, wajar jika kita berasumsi bahwa keduanya akan setara. Perbedaan ini mungkin membingungkan. Panduan ini akan menjelaskan alasan hal itu dapat terjadi, dan menawarkan saran tentang tindakan yang harus dilakukan jika jumlahnya tidak sesuai.
Manfaat melengkapi CrUX dengan solusi RUM
CrUX adalah alat yang bagus untuk mendapatkan tampilan yang konsisten di seluruh situs dan—sebagai set data Google untuk program Core Web Vitals—situs mungkin ingin terus memantau apa yang ditampilkan. Tujuan CrUX adalah memberikan ringkasan yang relevan secara statistik dari jutaan situs untuk perbandingan silang.
Namun, untuk pembahasan mendalam dalam menyelidiki alasan data menampilkan angka tersebut, berinvestasi dalam 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 berbagai cara.
Analisis yang lebih mendalam untuk menyelidiki masalah
CrUX sering kali dapat digunakan untuk menunjukkan apakah Anda memiliki masalah di situs, tetapi tidak selalu menunjukkan dengan tepat di mana masalah tersebut berada atau mengapa masalah tersebut terjadi. Solusi RUM—baik yang dikembangkan sendiri melalui library web-vitals atau beberapa dari banyak produk komersial—dapat membantu menjembatani kesenjangan tersebut.
Dengan menggunakan solusi RUM, Anda dapat mengakses data yang jauh lebih mendetail untuk semua halaman dan di semua browser. Alat ini juga memungkinkan Anda menyegmentasikan dan menganalisis data ini dengan cara yang tidak dilakukan CrUX, sehingga Anda dapat melihat perincian dan menyelidiki area masalah situs. Apakah performa tersebut dipengaruhi oleh segmen pengguna tertentu? Atau pengguna yang melakukan tindakan tertentu? Kapan tepatnya masalah ini mulai terjadi? Pertanyaan-pertanyaan ini jauh lebih mudah dijawab dengan data tambahan yang dapat diberikan oleh alat RUM.
Menghubungkan 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 pekerjaan 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 terkenal adalah metrik "Waktu untuk Tweet pertama" Twitter. Pengukuran khusus situs ini kemudian dapat dikaitkan dengan peningkatan Core Web Vitals dan metrik bisnis.
Perbedaan antara dua set data lapangan
Seorang pria dengan satu jam tangan tahu jam berapa sekarang. Seorang pria dengan dua jam tangan tidak pernah yakin.
Hukum Segal
Jika Anda memiliki dua sumber data, perbedaan di antara keduanya sering kali dapat membingungkan dan membuat frustrasi. Sama seperti pentingnya memahami perbedaan antara metrik lab dan lapangan, mungkin juga ada perbedaan antara dua sumber data lapangan. Meskipun data akan sama dalam kondisi ideal, ada banyak alasan mengapa data tersebut dapat 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 berasumsi bahwa produk RUM hanya melihat data lapangan, banyak produk yang juga menawarkan komponen lab.
Data lab sangat berguna justru karena kondisi tetap yang diukur. Metrik ini dapat digunakan untuk memantau perubahan atau regresi yang tidak terduga di lingkungan produksi tanpa gangguan dari populasi kolom yang berubah. Namun, data lab mungkin tidak mewakili pengalaman pengguna yang sebenarnya, sehingga metrik lapangan dapat menunjukkan hasil yang cukup 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
Chrome User Experience Report, seperti namanya, hanya tersedia untuk Chrome. Meskipun ada banyak browser berbasis Chromium (Edge, Opera, dan Brave, beberapa di antaranya) yang menggunakan banyak codebase Chrome, 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. WebView Android 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 oleh karena itu kemungkinan akan memberikan representasi luas dari performa situs Anda dalam sebagian besar kasus—mengukur browser tersebut saja sama sekali bukan ukuran dari semua pengguna Anda. Hal ini mungkin menjelaskan 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 mengunjungi dari lebih banyak negara dengan infrastruktur jaringan yang lebih baik, menyertakan mereka dapat menghasilkan metrik performa keseluruhan yang tinggi. Di sisi lain, mengecualikannya—seperti yang dilakukan CrUX—dapat menyebabkan data yang condong ke ujung bawah pengunjung situs (contoh studi kasus). Pengguna Android biasanya mencakup berbagai perangkat, kemampuan perangkat, dan pasar.
Solusi RUM dapat memperoleh 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-berbasis Chromium juga diukur oleh solusi RUM, tetapi mungkin memiliki kumpulan metrik yang lebih terbatas. Misalnya, Cumulative Layout Shift (CLS) hanya tersedia di browser berbasis Chromium. Beberapa metrik berbasis render lainnya seperti LCP, INP, dan bahkan First Contentful Paint (FCP) dapat diukur dengan cara yang cukup berbeda (lihat nanti).
Pengguna yang diikutsertakan
Selain terbatas pada pengguna Chrome, CrUX juga dibatasi dengan hanya mengukur sebagian 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 berdampak buruk pada beberapa pemuatan halaman awal jika konfirmasi tidak diberikan hingga halaman kedua atau berikutnya, saat beberapa aset situs telah di-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 cukup.
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 minimum 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, dan menjelaskan alasan 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 berdasarkan perangkat seluler, desktop, dan tablet - meskipun banyak alat berfokus pada dua perangkat pertama dan mungkin tidak menampilkan data tablet, atau mungkin menyertakannya dalam perangkat seluler atau desktop. Karakteristik performa di perangkat seluler versus desktop bisa sangat berbeda—baik dalam hal konten yang ditampilkan maupun kemampuan perangkat yang melihatnya.
Data RUM akan memungkinkan segmentasi traffic yang serupa, 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 data yang setara dengan memfilter menurut jenis perangkat dan browser Chrome.
Pengambilan sampel
Solusi RUM biasanya memungkinkan penyesuaian frekuensi sampling pengunjung yang memilih ikut serta dan datanya dikumpulkan. Hal ini dapat digunakan untuk mengurangi volume data yang perlu dianalisis, dan untuk mengurangi biaya layanan RUM komersial. Jika ukuran sampel tersebut terlalu kecil dan tidak mewakili populasi yang lebih luas, metrik yang dihasilkan juga akan miring. Diskusikan dengan penyedia RUM Anda ukuran sampel yang sesuai untuk situs Anda.
Agregasi data
Data lapangan 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 perbedaan antara CrUX dan RUM.
Rentang waktu
Data CrUX didasarkan pada periode geser traffic selama 28 hari, dan jangka waktu ini tidak dapat diubah—meskipun data BigQuery CrUX disimpan untuk setiap bulan, sehingga Anda dapat melihat bulan-bulan sebelumnya, dan CrUX History API juga memberikan data historis selama periode mingguan. Keduanya masih memberikan data berdasarkan periode pengamatan 28 hari.
Data RUM biasanya memungkinkan perincian yang jauh lebih besar untuk memungkinkan melihat dampak perubahan jauh lebih cepat. Namun, saat memilih periode yang lebih singkat, data RUM dapat terpengaruh secara tidak semestinya oleh fluktuasi traffic dan pengunjung situs. Saat membandingkan data RUM dengan data CrUX, selalu pastikan Anda melihat performa selama 28 hari. Setelah Anda yakin bahwa datanya serupa, Anda dapat melihat jangka waktu lain untuk mempelajari data RUM lebih lanjut.
Agregasi statistik
Metrik CrUX diukur pada persentil ke-75, yaitu dengan melihat nilai yang dicapai oleh 75% kunjungan halaman. Akan ada nilai ekstrem dalam data lapangan dan dengan menghapus 25% pengalaman terburuk, tujuannya adalah memberikan nilai yang dapat dicapai oleh sebagian besar pengunjung.
Produk RUM sering kali memberikan lebih banyak opsi tentang 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 serupa.
Data histogram di CrUX mencakup semua data yang tersedia—bukan hanya persentil ke-75—dan menampilkan jumlah kunjungan 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 set data yang berbeda, penting untuk memahami metrik apa yang diukur, dan bagaimana metrik tersebut digunakan.
Metrik yang diukur
Data CrUX adalah set data Google dari inisiatif Core Web Vitals dan utamanya 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 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 Core Web Vitals harus menganggap halaman lulus jika memenuhi target yang direkomendasikan pada persentil ke-75 untuk semua Core Web Vitals. Jika INP tidak ada untuk halaman tanpa interaksi, hanya LCP dan CLS yang harus lulus.
Perbedaan metrik di berbagai browser
CrUX hanya mengukur di browser Chrome, dan Anda dapat melihat Log Perubahan Web Vitals untuk mengetahui perubahannya di setiap versi Chrome.
Namun, solusi RUM akan mengukur dari berbagai browser yang lebih luas. Browser berbasis Chromium (Edge, Opera, dan sebagainya) kemungkinan akan serupa dengan Chrome, kecuali jika Chrome menerapkan perubahan baru seperti yang tercantum dalam Changelog.
Untuk browser non-Chromium, perbedaannya bisa lebih terlihat. Metrik berbasis render seperti LCP, INP, dan FCP, misalnya, tersedia di Safari dan Firefox, tetapi diukur dengan cara yang berbeda. Hal ini dapat menyebabkan perbedaan yang signifikan dalam 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. Kapan tepatnya 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 render 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 daripada kedua peristiwa tersebut.
Selain itu, dalam data lapangan, elemen LCP dapat berbeda 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 Satu Halaman (SPA)—akan dibahas lebih lanjut nanti—maka 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 origin, RUM dapat menyegmentasikannya lebih lanjut untuk mengidentifikasi setiap sesi masalah LCP.
Cumulative Layout Shift (CLS) diukur selama masa aktif halaman, sehingga CLS pemuatan halaman awal mungkin tidak mewakili halaman yang menyebabkan pergeseran lebih besar setelah halaman dimuat dan pengguna berinteraksi dengannya. Oleh karena itu, mengambil nilai CLS hanya setelah pemuatan halaman—seperti yang dilakukan banyak produk RUM—akan memberikan hasil yang berbeda dibandingkan mengambil nilai CLS setelah pengguna selesai dengan halaman tersebut.
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 Core Web Vitals 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 kapan Core Web Vitals diukur oleh penyedia RUM Anda sangat penting saat melihat perbedaan yang tidak dapat dijelaskan antara kedua sumber data tersebut.
Aplikasi web satu halaman
Aplikasi web satu halaman (SPA) berfungsi dengan memperbarui konten di halaman saat ini, bukan melakukan navigasi halaman yang sebenarnya di tingkat browser. Artinya, browser tidak menganggapnya sebagai navigasi halaman, meskipun pengguna mengalaminya demikian. Core Web Vitals API yang disediakan oleh browser tidak akan mempertimbangkan hal ini, sehingga CrUX tidak mendukung navigasi halaman ini. Upaya sedang dilakukan untuk menyelesaikan masalah ini—lihat postingan Mengukur navigasi ringan untuk mengetahui informasi selengkapnya.
Beberapa penyedia RUM mencoba mendeteksi "navigasi ringan" di SPA, tetapi jika mereka juga mengatribusikan metrik Core Web Vitals ke "navigasi ringan" tersebut, hal ini akan menyebabkan perbedaan dengan CrUX karena API yang mendasarinya tidak mendukung hal ini untuk banyak metrik.
Perbedaan CrUX dan Web API
Selain perbedaan dalam tayangan halaman mana yang diukur, dan apa yang diukur, ada beberapa skenario lain yang lebih rumit yang perlu diperhatikan dan dapat menyebabkan perbedaan dalam data CrUX dan RUM. Beberapa di antaranya disebabkan oleh batasan Web API yang digunakan untuk mengukur metrik, dan beberapa di antaranya adalah hasil yang ditampilkan oleh API perlu diperlakukan secara berbeda untuk skenario tertentu. Dokumentasi Core Web Vitals 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 memperlakukan hal ini sebagai pemuatan halaman, solusi RUM perlu melakukan langkah-langkah tambahan agar halaman ini dihitung jika ingin cocok dengan CrUX. Pemuatan halaman ini jauh lebih cepat dan dapat menghasilkan performa keseluruhan yang lebih baik yang dilaporkan untuk situs, sehingga tidak menyertakannya dapat menghasilkan metrik performa halaman keseluruhan yang lebih buruk. Lihat solusi RUM Anda untuk memahami apakah solusi tersebut menangani halaman yang dipulihkan bfcache.
iFrame
Untuk alasan keamanan dan privasi, halaman tingkat teratas tidak memiliki akses ke konten dalam iframe (bahkan iframe dengan asal yang sama). Artinya, metrik performa untuk konten di dalamnya hanya dapat diukur oleh iframe itu sendiri, dan bukan melalui Web API di halaman yang membingkai. Jika konten iframe menyertakan elemen LCP, atau konten yang memengaruhi CLS atau INP yang dialami pengguna, konten ini 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 sehingga mengukur metrik dalam iframe saat melaporkan Core Web Vitals. Hal ini lebih akurat mencerminkan pengalaman pengguna, tetapi dapat menjadi alasan lain perbedaan untuk situs yang menggunakan iframe.
Satu contoh konkret tentang bagaimana hal ini dapat menyebabkan perbedaan antara data LCP di CrUX dan RUM adalah <video> yang disematkan. Frame pertama yang dirender dari elemen <video> yang diputar otomatis secara inline dapat dihitung sebagai kandidat LCP, tetapi penyematan untuk layanan streaming video populer dapat menempatkan elemen ini dalam <iframe>. CrUX dapat memperhitungkan hal ini, karena dapat mengakses konten <iframe>, tetapi solusi RUM tidak dapat melakukannya.
Resource lintas origin
Media LCP yang ditayangkan dari domain lain mungkin tidak memberikan waktu render di PerformanceObserver API—kecuali jika header Timing-Allow-Origin (TAO) disediakan—karena batasan keamanan browser untuk mengurangi serangan pengaturan waktu. Hal ini kembali ke waktu pemuatan resource, tetapi mungkin sangat berbeda dari waktu konten benar-benar dirender.
Hal ini dapat menyebabkan situasi yang tampaknya mustahil, yaitu LCP dilaporkan oleh API web lebih awal daripada FCP. Hal ini tidak benar, tetapi hanya terlihat demikian karena pembatasan keamanan ini.
Masalah ini diselesaikan pada akhir tahun 2024 dan waktu render yang sedikit lebih kasar tersedia mulai Chrome 133 meskipun Timing-Allow-Origin tidak disediakan.
Sekali lagi, CrUX melaporkan data waktu render untuk Core Web Vitals. Situs disarankan untuk membatasi konten lintas origin yang memengaruhi metrik Core Web Vitals dan mengaktifkan TAO jika memungkinkan, jika ingin mengukur hal ini dengan lebih akurat. Resource lintas origin lainnya mungkin tunduk pada batasan serupa.
Tab latar belakang
Jika halaman tidak dibuka di tab latar belakang, halaman tersebut akan tetap memunculkan metrik menggunakan Web API. Namun, peristiwa ini tidak dilaporkan oleh CrUX karena memberikan pengaturan waktu yang tidak konsisten dengan pengalaman pengguna. Solusi RUM juga harus mempertimbangkan untuk mengabaikan hal ini, atau setidaknya menjelaskan cara penayangan halaman ini diperlakukan.
Jadi, apa yang bisa kita lakukan?
Kami telah menunjukkan alasan mungkin adanya perbedaan antara data CrUX dan RUM, baik karena perbedaan metodologi yang digunakan masing-masing atau 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 akan menjelaskan mengapa sangat tidak mungkin mendapatkan angka yang sama persis di setiap set data.
Jika perbedaannya sedikit (misalnya, melaporkan LCP 2,0 detik versus 2,2 detik), kedua set data akan berguna dan biasanya dapat dianggap kurang lebih sinkron.
Jika perbedaan yang jelas membuat Anda mempertanyakan akurasi 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 lebih cocok—Anda tetap harus bertanya mengapa Anda melihat perbedaan ini dalam data keseluruhan dan apa artinya. Apakah pengguna non-Chrome memengaruhi metrik Anda secara positif atau negatif? Apakah hal ini memberi Anda lebih banyak insight tentang masalah performa yang dapat Anda prioritaskan?
Jika pengguna non-Chrome mendapatkan hasil yang berbeda, Anda dapat menggunakan insight berharga yang diberikan RUM ini untuk melakukan pengoptimalan secara berbeda. Misalnya, API tertentu tidak tersedia di browser tertentu, tetapi Anda dapat mempertimbangkan alternatif untuk browser yang tidak didukung guna meningkatkan pengalaman pengguna browser tersebut. Atau, Anda dapat memberikan pengalaman yang berbeda, tetapi lebih berperforma, kepada pengguna di perangkat atau jaringan yang terbatas. 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 perbedaan tersebut, kedua alat ini dapat sangat berguna untuk memahami pengalaman pengguna situs Anda, dan membantu meningkatkannya meskipun angkanya tidak sama. Gunakan data RUM untuk melengkapi data CrUX dan memungkinkan Anda mempelajari lebih dalam apa yang disampaikan CrUX secara umum dengan menyegmentasikan traffic untuk membantu Anda mengidentifikasi apakah ada area tertentu di situs atau basis pengguna Anda yang perlu diperhatikan.
Melihat tren untuk mengetahui apakah peningkatan Anda memberikan dampak positif yang diharapkan sering kali lebih penting daripada memastikan setiap angka sama persis di antara kedua sumber data. Seperti yang disebutkan sebelumnya, RUM memungkinkan Anda melihat jangka waktu yang berbeda untuk mendapatkan gambaran awal tentang skor CrUX 28 hari Anda—meskipun melihat jangka waktu yang terlalu singkat dapat menyebabkan data yang rusak, itulah sebabnya CrUX menggunakan 28 hari.
Sering kali tidak ada jawaban "benar" atau "salah" dalam berbagai metrik ini - metrik tersebut hanyalah lensa yang berbeda untuk melihat pengguna Anda dan cara mereka menggunakan situs Anda. Selama Anda memahami alasan terjadinya perbedaan ini, dan pengaruhnya terhadap pengambilan keputusan, hal itulah yang lebih penting untuk melayani pengunjung situs Anda dengan lebih baik.