Pelajari alasan data RUM dapat menampilkan jumlah Data Web Inti yang berbeda dari CrUX.
Laporan Pengalaman Pengguna Chrome (CrUX) memberikan metrik pengalaman pengguna tentang cara pengguna Chrome di dunia nyata menikmati tujuan populer di web. Data ini otomatis dikumpulkan 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 tidak memiliki akses ke data lapangan sebelumnya, dan CrUX telah memungkinkan banyak situs melihat nilainya untuk pertama kalinya. Sebagai {i>dataset<i} publik, CrUX juga dapat digunakan untuk analisis kompetitif dan tolok ukur metrik pengalaman pengguna.
Pemantauan Pengguna Real (RUM) mirip dengan CrUX, tetapi Chrome tidak mengumpulkan metrik pengalaman pengguna secara otomatis, tetapi 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 solusi tersebut seharusnya setara. Perbedaan itu bisa membingungkan jika kita melihat perbedaannya. Panduan ini akan menjelaskan mengapa hal tersebut dapat terjadi, dan menawarkan saran tentang hal yang harus dilakukan jika angkanya tidak selaras.
Manfaat melengkapi CrUX dengan solusi RUM
CrUX adalah alat yang bagus untuk mendapatkan tampilan yang konsisten di seluruh situs dan—sebagai set data resmi untuk program Data Web Inti—situs mungkin ingin memantau apa yang ditampilkannya. Tujuan CrUX adalah memberikan ringkasan yang relevan secara statistik dari jutaan situs untuk perbandingan silang.
Namun, untuk pembahasan lebih mendalam tentang penyelidikan mengapa data menunjukkan hasil yang sebenarnya, 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 dengan beberapa cara.
Analisis lebih dalam untuk menyelidiki masalah
CrUX sering kali dapat digunakan untuk menunjukkan jika Anda memiliki masalah di situs, tetapi bukan persis di mana masalah tersebut berada di situs Anda atau alasannya. Solusi RUM—baik yang dikembangkan sendiri melalui koleksi web-vitals atau beberapa dari banyak produk komersial—dapat membantu menjembatani kesenjangan tersebut.
Menggunakan solusi RUM memberi Anda akses ke data yang jauh lebih mendetail untuk semua halaman Anda dan di semua browser. Hal ini juga memungkinkan Anda untuk menyesuaikan 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? Kapan masalah mulai muncul? Pertanyaan ini akan jauh lebih mudah dijawab dengan data tambahan yang dapat diberikan oleh alat RUM.
Berkorelasi dengan metrik bisnis lainnya
RUM juga memungkinkan Anda membandingkan metrik performa web secara langsung dengan metrik bisnis apa pun, menunjukkan manfaat berinvestasi dalam performa, dan performa lainnya yang perlu 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 dikaitkan langsung dengan bisnis spesifik Anda. Salah satu contoh yang lebih terkenal adalah metrik “Waktu untuk Tweet pertama” Twitter. Tindakan khusus situs ini kemudian dapat dikorelasikan dengan peningkatan Core Web Vitals dan metrik bisnis.
Perbedaan antara dua kumpulan data lapangan
Seorang pria dengan jam tangan tahu jam berapa sekarang. Seorang pria dengan dua jam tangan tidak pernah yakin.
Hukum Segal
Setiap kali Anda memiliki dua sumber data, perbedaannya sering kali dapat membingungkan dan menyulitkan Anda. Dengan cara yang kurang lebih sama seperti jika Anda memahami perbedaan antara metrik lab dan kolom, perbedaan antara dua sumber data kolom juga dapat terjadi. Meskipun data akan sama dalam kondisi ideal, ada banyak alasan mengapa data tersebut bisa berbeda.
Data lab versus data lapangan
Hal pertama yang harus diperiksa adalah apakah Anda melihat metrik lab (sintetik) atau metrik kolom (RUM). Meskipun adalah hal yang wajar untuk mengasumsikan produk RUM hanya melihat data lapangan, banyak juga yang menawarkan komponen lab.
Data lab sangat berguna karena kondisi tetap yang diukur. Model ini dapat digunakan untuk memantau perubahan atau regresi tak terduga dalam lingkungan produksi tanpa adanya perubahan populasi bidang. Namun, data lab mungkin tidak mewakili pengalaman pengguna yang sebenarnya, sehingga metrik kolom dapat menampilkan hasil yang sangat berbeda.
Populasi
Set data yang digunakan oleh solusi CrUX dan RUM dapat berbeda karena perbedaan kunjungan halaman yang diukur, bergantung pada browser, pengguna, situs, dan perangkat yang dibandingkan.
Browser yang disertakan
Laporan Pengalaman Pengguna Chrome, seperti namanya, hanya tersedia untuk Chrome. Meskipun ada banyak browser berbasis Chromium (beberapa di antaranya adalah Edge, Opera, dan Brave) yang juga mendukung metrik yang sama seperti Chrome karena codebase inti bersama, 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 oleh karena itu kemungkinan besar akan memberikan representasi luas tentang performa situs Anda dalam kebanyakan kasus—mengukur bahwa browser tersebut sama sekali bukan ukuran dari semua pengguna Anda. Hal ini dapat menjelaskan satu perbedaan utama antara RUM dan CrUX. Hal ini khususnya berlaku untuk teknik performa yang mengandalkan API atau format gambar yang hanya tersedia di Chrome.
Kurangnya data iOS juga dapat menyebabkan bias. Misalnya, karena pengguna iOS biasanya menggunakan perangkat yang berperforma lebih tinggi atau berkunjung dari lebih banyak negara dengan infrastruktur jaringan yang lebih baik, termasuk pengguna iOS dapat menghasilkan metrik performa yang lebih tinggi secara keseluruhan. Di sisi lain, mengecualikan pengunjung situs—seperti yang dilakukan CrUX—dapat menyebabkan data yang condong ke pihak tingkat bawah pengunjung situs (contoh studi kasus). Pengguna Android biasanya mencakup lebih banyak 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 bawaan yang sama (seperti Core Web Vitals). Browser berbasis non-Chromium juga diukur oleh solusi RUM, tetapi mungkin memiliki kumpulan metrik yang lebih terbatas. Misalnya, Largest Contentful Paint (LCP) dan Cumulative Layout Shift (CLS) saat ini hanya tersedia di browser berbasis Chromium, dan beberapa metrik lainnya dapat diukur dengan cukup berbeda (lihat nanti).
Pengguna yang ikut serta
Selain dibatasi untuk pengguna Chrome, CrUX dibatasi lebih lanjut dengan hanya mengukur sebagian pengguna Chrome yang bersedia membagikan data CrUX saat browser diinstal.
Penyedia RUM juga hanya melihat sebagian pengguna, biasanya karena permintaan banner cookie—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 di-cache dari halaman sebelumnya. Jika hal ini sering terjadi, metrik dapat tampak lebih menguntungkan 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 di situs publik, jadi ada kriteria kelayakan lainnya yang dapat menyebabkan data tidak dicatat dalam CrUX. Yang paling penting dari kriteria ini adalah bahwa situs web harus dapat ditemukan secara publik dan cukup populer untuk memastikan ukuran sampel minimal yang digunakan untuk menarik kesimpulan yang berarti. Dalam kebanyakan kasus, hal ini akan mengakibatkan tidak ada data yang tersedia di CrUX. Perbedaan ini tidak terlalu membingungkan jika dibandingkan dengan data yang tersedia, tetapi cara ini dapat 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 mengelompokkan data berdasarkan perangkat seluler, desktop, dan tablet - meskipun banyak alat berkonsentrasi pada dua hal 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 dalam hal konten yang ditayangkan maupun kemampuan perangkat yang 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) dengan mudah, tetapi tidak keduanya untuk hanya melihat traffic Chrome seluler. Ketika membandingkan dengan data CrUX, pastikan Anda membandingkan yang serupa dengan memfilter menurut jenis perangkat dan browser Chrome.
Pengambilan Sampel
Solusi RUM biasanya memungkinkan penyesuaian frekuensi pengambilan sampel pengunjung yang memilih ikut serta dalam pengumpulan data. Ini dapat digunakan untuk mengurangi volume data yang diperlukan untuk 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 memiliki bias serupa. Diskusikan dengan penyedia RUM Anda tentang ukuran sampel yang sesuai untuk situs Anda.
Agregasi data
Data lapangan pada dasarnya akan mencakup 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 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 disimpan untuk setiap bulan, sehingga Anda dapat melihat bulan-bulan sebelumnya.
Data RUM biasanya memungkinkan perincian yang jauh lebih besar agar dampak perubahan dapat dilihat lebih cepat. Namun, saat memilih periode yang lebih singkat, data RUM dapat terlalu terpengaruh oleh fluktuasi traffic situs dan pengunjung. Saat membandingkan data RUM dengan data CrUX, selalu pastikan Anda mengamati performa selama 28 hari. Setelah mendapatkan data yang serupa, Anda dapat melihat jangka waktu lain untuk melihat perincian data RUM.
Agregasi statistik
Metrik CrUX diukur pada persentil ke-75—yaitu, mengamati nilai yang dicapai 75% kunjungan halaman. Akan ada hal-hal yang ekstrem dalam data lapangan dan menghilangkan 25% pengalaman terburuk. Hal ini dimaksudkan untuk memberikan nilai yang dapat diharapkan oleh sebagian besar pengunjung secara wajar.
Produk RUM sering memberikan lebih banyak pilihan 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.
Data histogram di CrUX mencakup semua data yang tersedia—tidak hanya persentil ke-75—dan menunjukkan 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 kumpulan data yang berbeda, penting untuk memahami metrik apa yang sedang diukur dan bagaimana metrik tersebut digunakan.
Metrik yang diukur
Data CrUX adalah set data resmi dari inisiatif Data Web Inti dan terutama mengukur ketiga metrik ini (LCP, FID, dan CLS), dengan beberapa metrik tambahan untuk melengkapi metrik tersebut.
Alat RUM biasanya menyertakan Data Web Inti ini, tetapi sering kali juga menyertakan banyak metrik lainnya. Beberapa penyedia RUM juga mengukur pengalaman pengguna menggunakan kombinasi mereka sendiri dari semua metrik ini yang mungkin untuk memberikan indeks kebahagiaan atau semacamnya. Ketika membandingkan data RUM dengan CrUX, pastikan Anda membandingkan yang serupa.
Alat yang menilai status lulus/gagal Data Web Inti harus mempertimbangkan halaman yang lulus jika memenuhi target yang direkomendasikan pada persentil ke-75 untuk semua Core Web Vitals. Jika FID tidak ada untuk halaman tanpa interaksi, hanya LCP dan CLS yang perlu diteruskan.
Perbedaan metrik di berbagai browser
CrUX hanya mengukur di browser Chrome, dan Anda dapat melihat Log Perubahan Data Web untuk melihat perubahan ini pada setiap versi Chrome.
Namun, solusi RUM akan mengukur dari variasi browser yang lebih luas. Browser berbasis Chromium (Edge, Opera, dan sebagainya) kemungkinan akan mirip dengan Chrome, kecuali jika Chrome mengimplementasikan perubahan baru seperti yang tercantum dalam Changelog.
Untuk browser non-Chromium, perbedaannya dapat lebih jelas. First Contentful Paint (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 disebutkan sebelumnya, jika Anda ingin membandingkan RUM dengan CrUX, sebaiknya filter hanya pada pengguna Chrome untuk memungkinkan perbandingan yang serupa.
Waktu metrik
Metrik Data Web Inti disediakan oleh API browser web, tetapi itu bukan berarti tidak ada potensi perbedaan nilai yang dilaporkan menggunakan API tersebut. Kapan pengukuran metrik dilakukan—saat pemuatan halaman atau di sepanjang siklus proses halaman penuh—dapat menyebabkan perbedaan. Alat RUM mungkin tidak selalu mengukur metrik dengan cara yang sama—bahkan jika menggunakan nama yang sama—dan API browser yang sama untuk mendapatkan data, dan hal ini bisa 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 sangat bergantung 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)—hal ini dibahas lebih lanjut 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 keseluruhan nilai LCP per halaman atau asal, RUM dapat menyegmentasikan ini lebih lanjut untuk mengidentifikasi setiap sesi masalah LCP.
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 setelah halaman dimuat dan pengguna telah berinteraksi dengannya. Mengambil nilai CLS hanya setelah pemuatan halaman—seperti yang dilakukan banyak produk RUM—oleh karena itu akan memberikan hasil yang berbeda daripada mengambil nilai CLS setelah pengguna selesai dengan halaman.
Penundaan Input Pertama (FID) memerlukan pengukuran input, sehingga tidak dapat diukur saat halaman dimuat. Namun, seperti namanya, FID hanya mengukur input pertama. Metrik responsivitas Interaction to Next Paint (INP) yang lebih baru mengukur semua interaksi sepanjang 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 sepanjang waktu halaman. Banyak penyedia RUM memilih untuk mengukur metrik ini setelah pemuatan halaman, atau di lain waktu (misalnya, saat pesan ajakan (CTA) utama diklik) karena berbagai alasan.
Mendapatkan pemahaman dari penyedia RUM tentang kapan Data Web Inti diukur sangat penting ketika Anda melihat varian yang tidak 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 menjalankan navigasi halaman biasa 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 saat ini tidak mendukung navigasi halaman ini. Saat ini upaya sedang dilakukan 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 mereka juga mengatribusikan metrik Data Web Inti ke "navigasi ringan", hal ini akan menyebabkan perbedaan dengan CrUX karena API yang mendasarinya tidak mendukung hal ini.
Perbedaan CrUX dan Web API
Selain perbedaan terkait kunjungan halaman mana yang diukur dan apa yang diukur, ada beberapa skenario lain yang lebih rumit yang perlu diperhatikan sehingga dapat menyebabkan perbedaan dalam data CrUX dan RUM. Beberapa di antaranya disebabkan oleh keterbatasan Web API yang digunakan untuk mengukur metrik, dan beberapa di antaranya hasil yang ditampilkan oleh API perlu diperlakukan secara berbeda untuk skenario tertentu. Dokumentasi Data Web Inti mencantumkan perbedaan ini untuk LCP, CLS, dan FID, tetapi perbedaan utamanya tercantum di bawah.
Back-forward cache
CrUX menganggap Back/forward cache (atau bfcache) dipulihkan sebagai navigasi halaman meskipun tidak menyebabkan pemuatan halaman secara konvensional. Karena Web API tidak memperlakukannya sebagai pemuatan halaman, solusi RUM perlu mengambil langkah tambahan agar halaman ini dihitung jika ingin cocok dengan CrUX. Pemuatan halaman ini jauh lebih cepat yang dapat menghasilkan pelaporan performa yang lebih baik secara keseluruhan untuk suatu 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 origin yang sama). Artinya, metrik performa untuk konten dalam hal tersebut hanya dapat diukur oleh iframe itu sendiri, bukan melalui Web API di halaman framing. Jika konten iframe menyertakan elemen LCP, atau konten yang memengaruhi CLS, FID, 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, bukan halaman, tidak memiliki batasan ini, dan begitu juga mengukur metrik dalam iframe saat melaporkan Core Web Vitals. Hal ini mencerminkan apa yang dialami pengguna secara lebih akurat, tetapi dapat menjadi alasan lain bagi situs yang menggunakan iframe.
Salah satu contoh konkret bagaimana hal ini dapat menyebabkan perbedaan antara data LCP di CrUX dan RUM adalah <video> yang disematkan. Frame yang pertama kali digambar pada elemen <video> yang diputar otomatis dapat dianggap sebagai kandidat LCP, tetapi penyematan untuk layanan streaming video populer dapat menempatkan elemen ini di <iframe>. Mulai Agustus 2023, CrUX dapat memperhitungkan hal ini karena aplikasi dapat mengakses konten <iframe>, tetapi solusi RUM tidak dapat melakukannya.
Resource lintas asal
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 waktu. Ini kembali ke waktu pemuatan resource, tetapi ini mungkin sangat berbeda dari saat konten benar-benar digambar.
Hal ini dapat menyebabkan situasi yang tampaknya mustahil saat LCP dilaporkan oleh web API lebih awal dari FCP. Sebenarnya tidak demikian tetapi hanya muncul karena pembatasan keamanan ini.
Sekali lagi, CrUX melaporkan data waktu render untuk Core Web Vitals. Situs disarankan untuk membatasi konten lintas asal yang memengaruhi metrik Data Web Inti dan mengaktifkan TAO jika memungkinkan jika ingin mengukurnya dengan lebih akurat. Resource lintas asal lainnya mungkin tunduk kepada batasan serupa.
Tab latar belakang dan pra-rendering
Saat halaman tidak dibuka di latar depan—seperti membukanya di latar belakang atau jika menggunakan opsi pra-render (saat ini dalam pengembangan untuk Chrome)—halaman tersebut akan tetap menampilkan metrik melalui 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 mengabaikan hal tersebut, atau setidaknya menjelaskan bagaimana tayangan halaman ini diperlakukan.
Jadi, apa yang bisa kita lakukan?
Kami telah menunjukkan mengapa ada perbedaan antara data CrUX dan RUM, baik karena perbedaan metodologi yang digunakan maupun karena pengguna dan kunjungan halaman disertakan atau dikecualikan. Idealnya, kedua set data ini tetap akan mewakili performa situs Anda agar bermanfaat, tetapi artikel ini harus menguraikan mengapa sangat tidak mungkin mendapatkan angka yang sama persis di setiap set.
Jika perbedaannya kecil (misalnya melaporkan LCP 2,0 detik versus 2,2 detik), kedua set data tersebut akan berguna dan biasanya dapat dianggap sinkron.
Ketika perbedaan yang jelas membuat Anda mempertanyakan keakuratan data, Anda harus mencoba memahami perbedaan tersebut. Apakah data RUM dapat difilter agar lebih selaras dengan CrUX (hanya memperhatikan 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 masih harus bertanya mengapa Anda melihat perbedaan ini dalam keseluruhan data dan apa artinya. Apakah pengguna non-Chrome mendistorsi metrik Anda dengan cara yang positif atau negatif? Apakah hal ini memberi Anda lebih banyak wawasan tentang bagian yang memiliki masalah performa yang dapat Anda prioritaskan?
Jika pengguna non-Chrome mendapatkan hasil yang berbeda, Anda dapat menggunakan wawasan berharga yang diberikan RUM kepada Anda 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 pengalamannya. Atau, Anda dapat memberikan pengalaman yang berbeda, tetapi berperforma lebih baik kepada pengguna di perangkat atau jaringan yang terbatas. CrUX dibatasi untuk 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, kedua alat tersebut dapat sangat berguna untuk memahami pengalaman pengguna situs Anda, dan untuk membantu meningkatkannya meskipun angkanya tidak identik. Gunakan data RUM untuk melengkapi data CrUX dan memungkinkan Anda menggali informasi yang disampaikan CrUX pada tingkat tinggi dengan menyegmentasikan traffic untuk membantu Anda mengidentifikasi apakah area tertentu di situs atau basis pengguna Anda memerlukan perhatian.
Melihat tren untuk mengetahui bahwa peningkatan Anda memiliki dampak positif yang diharapkan sering kali lebih penting daripada membuat setiap angka sama persis di antara kedua sumber data tersebut. Seperti yang disebutkan di atas, RUM memungkinkan Anda melihat kerangka waktu yang berbeda untuk mengetahui lebih jauh tentang skor CrUX 28 hari Anda — meskipun melihat kerangka waktu yang terlalu singkat dapat menyebabkan data yang bising, oleh karena itu CrUX menggunakan 28 hari.
Sering kali tidak ada jawaban yang "benar" atau "salah" dalam metrik yang berbeda ini - mereka hanya memiliki sudut pandang yang berbeda pada pengguna Anda dan bagaimana mereka mengalami situs Anda. Selama Anda memahami mengapa perbedaan tersebut terjadi dan apa yang dapat dilakukan untuk mendorong pengambilan keputusan, itulah hal yang lebih penting untuk melayani pengunjung situs dengan lebih baik.
Ucapan terima kasih
Banner besar oleh Steven Lelham di Unsplash