Pelajari alasan data RUM dapat menampilkan angka Core Web Vitals yang berbeda dari CrUX.
Chrome User Experience Report (CrUX) memberikan metrik pengalaman pengguna tentang cara pengguna Chrome di dunia nyata menjelajahi tujuan populer di web. Data ini dikumpulkan secara otomatis oleh Chrome dari pengguna yang telah memilih ikut serta, dan tersedia 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 {i>dataset<i} publik, CrUX juga dapat digunakan untuk analisis kompetitif dan tolok ukur metrik pengalaman pengguna.
Pemantauan Pengguna Nyata (RUM) mirip dengan CrUX, tetapi bukannya 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.
Dengan kedua solusi yang mengukur metrik pengalaman pengguna, wajar untuk mengasumsikan bahwa keduanya harus setara. Hal ini bisa membingungkan ketika kita melihat perbedaan. Panduan ini akan menjelaskan alasan terjadinya hal tersebut, dan menawarkan saran tindakan yang harus dilakukan jika jumlahnya 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 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 Anda dalam beberapa cara.
Analisis 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 seperti web-vitals maupun beberapa dari sekian banyak produk komersial—dapat membantu menjembatani kesenjangan tersebut.
Dengan solusi RUM, Anda dapat mengakses data yang jauh lebih mendetail untuk semua halaman dan 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 mereka terpengaruh oleh segmen pengguna tertentu? Atau pengguna yang melakukan tindakan tertentu? Tepatnya kapan masalah dimulai? Ini adalah pertanyaan yang jauh lebih mudah dijawab dengan data tambahan yang dapat disediakan 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 hal lain terkait performa 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 Anda. Salah satu contoh yang paling terkenal adalah "Saatnya untuk Tweet pertama" dari Twitter metrik. Tindakan khusus situs ini kemudian dapat dikorelasikan dengan peningkatan Core Web Vitals dan metrik bisnis.
Perbedaan antara dua set data bidang
Seorang pria dengan jam tangannya tahu jam berapa sekarang. Seorang pria dengan dua jam tidak akan pernah yakin.
Hukum Segal
Setiap kali Anda memiliki dua sumber data, perbedaannya sering kali membingungkan dan menjengkelkan. 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 (sintetik) atau metrik kolom (RUM). Meskipun wajar untuk berasumsi bahwa produk RUM hanya melihat data kolom, banyak juga yang menawarkan komponen lab.
Data lab sangat berguna karena data tersebut diukur dalam kondisi tetap. 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 kolom dapat menunjukkan hasil yang sangat berbeda.
Populasi
Set data yang digunakan oleh solusi CrUX dan RUM mungkin berbeda karena perbedaan dalam pengukuran kunjungan halaman, bergantung pada browser, pengguna, situs, dan perangkat yang dibandingkan.
Browser yang disertakan
Laporan Pengalaman Pengguna Chrome, seperti namanya, hanya untuk Chrome. Meskipun ada banyak browser berbasis Chromium (misalnya, Edge, Opera, dan Brave) yang juga mendukung metrik yang sama seperti Chrome dengan codebase inti bersama, hanya pengguna Chrome yang memasukkan data ke CrUX. Pembatasan ini juga berarti pengguna Chrome di iOS tidak disertakan karena aplikasi ini 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 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, mengecualikan pengunjung situs—seperti yang dilakukan CrUX—dapat menyebabkan data yang tidak akurat ke kalangan pengunjung situs yang lebih rendah (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 yang tidak berbasis Chromium juga diukur oleh solusi RUM, tetapi mungkin memiliki kumpulan metrik yang lebih terbatas. Misalnya, Pergeseran Tata Letak Kumulatif (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 cukup berbeda (lihat nanti).
Pengguna yang ikut serta
Selain dibatasi untuk pengguna Chrome, CrUX dibatasi lebih lanjut dengan hanya mengukur sebagian pengguna Chrome yang telah memilih untuk berbagi data CrUX saat browser diinstal.
Penyedia RUM juga hanya melihat sebagian pengguna, biasanya karena dialog 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 dimaksudkan untuk melaporkan situs publik, sehingga ada kriteria kelayakan lain yang dapat menyebabkan data tidak dicatat di CrUX. Yang paling menonjol dari kriteria ini adalah bahwa situs web harus dapat ditemukan oleh publik dan cukup populer untuk memastikan ukuran sampel yang minimal yang dapat digunakan untuk menarik kesimpulan yang bermakna. Umumnya, hal ini akan mengakibatkan tidak ada data yang tersedia di CrUX. Hal ini tidak terlalu membingungkan dibandingkan dengan data yang tersedia tetapi berbeda, tetapi menjelaskan mengapa hal itu terjadi.
Namun, jika halaman tertentu dari sebuah situs ditandai sebagai dapat diindeks, sedangkan halaman yang lain 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 mengelompokkan data berdasarkan perangkat seluler, desktop, dan tablet - meskipun banyak alat berkonsentrasi pada dua alat pertama dan mungkin tidak mengekspos data tablet, atau dapat 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 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 diperlukan untuk 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 sampel yang sesuai untuk situs Anda.
Agregasi data
Pada dasarnya, data kolom akan mencakup banyak sekali titik data dengan metrik yang sama dibandingkan dengan data lab, sehingga 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 selama 28 hari, dan jangka waktu ini tidak dapat diubah—meskipun data CrUX BigQuery disimpan setiap bulan sehingga Anda dapat melihat bulan sebelumnya, dan CrUX History API juga memberikan data historis selama periode mingguan. Keduanya masih memberikan data berdasarkan periode geser 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 Anda puas dengan data yang sama, 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 opsi yang lebih luas tentang cara menggabungkan metrik, termasuk persentil ke-75, median, dan persentil lainnya. Jika membandingkan nilai RUM dengan data CrUX, Anda perlu memastikan bahwa Anda melihat data persentil ke-75 untuk dibandingkan dengan data yang serupa.
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 muncul 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 apa yang diukur, dan bagaimana 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 kebahagiaan" atau semacamnya. Saat membandingkan data RUM dengan CrUX, pastikan Anda membandingkan data yang sepadan.
Alat yang menilai status lulus atau gagal Core Web Vitals harus mempertimbangkan lulus halaman jika memenuhi target yang direkomendasikan yaitu persentil ke-75 untuk semua Core Web Vitals. Jika INP tidak ada untuk halaman tanpa interaksi, hanya LCP dan CLS yang perlu lulus.
Perbedaan metrik di berbagai browser
CrUX hanya diukur di browser Chrome, dan Anda dapat membaca Log Perubahan Data Web untuk melihat perubahannya pada setiap versi Chrome.
Namun, solusi RUM akan diukur dari berbagai browser yang lebih luas. 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. First Contentful Paint (FCP), misalnya, tersedia di Safari dan Firefox, tetapi diukur dengan cara yang berbeda. Hal ini dapat menyebabkan perbedaan waktu yang signifikan dalam waktu yang dilaporkan. Seperti yang disebutkan sebelumnya, jika Anda ingin membandingkan RUM dengan CrUX, sebaiknya filter hanya pada pengguna Chrome untuk memungkinkan perbandingan sejenis.
Waktu metrik
Metrik Core Web Vitals disediakan oleh API browser web, tetapi bukan berarti tidak ada potensi perbedaan nilai yang dilaporkan menggunakan API tersebut. Tepatnya saat pengukuran metrik dilakukan—saat halaman dimuat atau di sepanjang 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, hal ini dapat membingungkan.
Largest Contentful Paint (LCP) adalah metrik pemuatan halaman. Sejumlah elemen LCP dapat dilaporkan oleh Web API jika elemen yang lebih besar dimuat kemudian setelah render awal. Elemen LCP terakhir 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, 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 tentang hal tersebut akan dibahas nanti—elemen LCP mungkin 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 selama masa aktif halaman, sehingga CLS pemuatan halaman awal mungkin tidak mewakili halaman yang menyebabkan pergeseran lebih besar di kemudian hari setelah halaman dimuat dan pengguna berinteraksi dengannya. Mengambil nilai CLS hanya setelah halaman dimuat—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, serta mengamati semua interaksi klik, ketuk, dan keyboard selama masa aktif halaman, dengan cara yang mirip dengan CLS. Oleh karena itu, nilai INP yang dilaporkan mungkin sangat berbeda jika diukur setelah pengguna melakukan sejumlah interaksi pada halaman.
CrUX akan mengikuti dokumentasi Core Web Vitals dan mengukurnya sepanjang waktu halaman. Banyak penyedia RUM yang memilih untuk mengukur metrik ini baik setelah halaman dimuat, atau di waktu lain (misalnya, saat pesan ajakan (CTA) utama diklik) karena berbagai alasan.
Mendapatkan pemahaman dari penyedia RUM terkait kapan Core Web Vitals diukur adalah hal penting saat melihat perbedaan yang tidak dapat dijelaskan di antara kedua sumber data tersebut.
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 mengatasi masalah ini—lihat postingan Bereksperimen dengan mengukur navigasi virtual untuk informasi selengkapnya.
Beberapa penyedia RUM mencoba mendeteksi "navigasi ringan" di SPA, tetapi jika metrik tersebut juga menghubungkan metrik Core Web Vitals ke "navigasi ringan" hal ini akan menyebabkan perbedaan dengan CrUX karena API yang mendasarinya tidak mendukungnya untuk banyak metrik.
Perbedaan CrUX dan Web API
Selain perbedaan dalam lokasi kunjungan halaman yang diukur dan apa yang diukur, ada beberapa skenario lain yang lebih rumit yang harus diperhatikan yang dapat menyebabkan perbedaan dalam data CrUX dan RUM. Beberapa di antaranya adalah karena keterbatasan 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 disebutkan di bagian berikut.
Back-forward cache
CrUX menganggap Back/forward cache (atau bfcache) dipulihkan 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. Hal ini adalah pemuatan halaman yang jauh lebih cepat yang dapat meningkatkan keseluruhan performa situs, jadi tidak menyertakannya dapat menyebabkan metrik performa halaman secara keseluruhan menjadi 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 origin yang sama). Artinya, metrik performa untuk konten dalam format tersebut hanya dapat diukur oleh iframe, bukan melalui Web API pada halaman framing. 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, begitu juga dengan mengukur metrik dalam iframe saat melaporkan Core Web Vitals. Hal ini mencerminkan pengalaman pengguna secara lebih akurat, tetapi dapat menjadi alasan lain terjadinya perbedaan bagi 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 di elemen <video> yang diputar otomatis dapat dihitung sebagai kandidat LCP, tetapi sematan 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 hal ini 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 terjadi, tetapi hanya muncul karena pembatasan keamanan ini.
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 untuk mengaktifkan TAO jika memungkinkan jika ingin mengukurnya dengan lebih akurat. Resource lintas origin lainnya mungkin tunduk pada batasan serupa.
Tab latar belakang
Saat tidak dibuka di tab latar belakang, halaman tersebut akan tetap memunculkan metrik menggunakan Web API. Namun, 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 bisa 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 akan tetap mewakili performa situs Anda agar berguna, tetapi alasan yang diberikan harus menguraikan mengapa sangat tidak mungkin untuk mendapatkan angka yang sama persis di masing-masing set.
Jika ada sedikit perbedaan (misalnya melaporkan LCP 2,0 detik versus 2,2 detik), kedua set data akan berguna dan biasanya dapat dianggap kurang-lebih 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 mengamati pengguna Chrome, untuk desktop atau seluler, dengan nilai persentil ke-75 selama 28 hari) untuk mengurangi perbedaan ini?
Jika demikian—dan Anda bisa mendapatkan data yang lebih cocok—maka Anda tetap harus bertanya mengapa Anda melihat perbedaan ini dalam data keseluruhan 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 bagian mana yang memiliki masalah performa yang dapat Anda prioritaskan?
Jika pengguna non-Chrome mendapatkan hasil yang berbeda, Anda dapat menggunakan insight berharga yang telah diberikan RUM untuk mengoptimalkan secara berbeda. Misalnya, API tertentu tidak tersedia di browser tertentu, tetapi Anda dapat mempertimbangkan alternatif untuk browser yang tidak didukung guna meningkatkan pengalamannya. Atau, Anda dapat memberikan pengalaman yang berbeda, tetapi berperforma lebih tinggi kepada pengguna di perangkat atau jaringan yang dibatasi. CrUX terbatas pada data Chrome, tetapi Anda harus mempertimbangkan semua pengalaman pengguna untuk membantu menyusun prioritas perbaikan. Data RUM dapat mengisi kesenjangan tersebut.
Setelah Anda memahami alasan terjadinya perbedaan, kedua alat tersebut dapat sangat berguna untuk memahami pengalaman pengguna {i>website<i} Anda, dan untuk membantu meningkatkannya bahkan jika jumlahnya tidak sama. Gunakan data RUM untuk melengkapi data CrUX dan memungkinkan Anda menggali informasi yang disampaikan CrUX secara umum dengan menyegmentasikan traffic untuk membantu Anda mengidentifikasi apakah area tertentu pada situs atau basis pengguna Anda perlu diperhatikan.
Melihat tren untuk mengetahui peningkatan Anda memiliki dampak positif yang diharapkan sering kali lebih penting daripada memiliki setiap angka yang sama persis di antara kedua sumber data. Seperti yang disebutkan sebelumnya, RUM memungkinkan Anda melihat jangka waktu yang berbeda untuk melihat lebih awal skor CrUX 28 hari Anda—meskipun melihat jangka waktu yang terlalu singkat dapat menyebabkan data berisik, oleh karena itu, mengapa CrUX menggunakan 28 hari.
Sering kali tidak ada jawaban yang "benar" atau "salah" menjawab di metrik yang berbeda ini - keduanya hanyalah sudut pandang yang berbeda terhadap pengguna Anda dan bagaimana pengalaman mereka di situs Anda. Selama Anda memahami mengapa perbedaan ini terjadi, dan apa yang dapat dilakukan untuk mendorong pengambilan keputusan, itulah yang lebih penting untuk melayani pengunjung situs Anda dengan lebih baik.
Ucapan terima kasih
Gambar thumbnail oleh Steven Lelham di Unsplash