Pelajari alasan alat yang memantau metrik Core Web Vitals dapat melaporkan angka yang berbeda, dan cara menafsirkan perbedaan tersebut.
Google menyediakan beberapa alat untuk membantu pemilik situs memantau skor Core Web Vitals mereka. Alat ini terbagi ke dalam dua kategori utama:
- Alat yang melaporkan data lab—data yang dikumpulkan di lingkungan terkontrol dengan setelan perangkat dan jaringan yang telah ditentukan sebelumnya.
- Alat yang melaporkan data kolom—data yang dikumpulkan dari pengguna sebenarnya yang mengunjungi situs Anda.
Masalahnya adalah terkadang data yang dilaporkan oleh alat lab dapat sangat berbeda dengan data yang dilaporkan oleh alat lapangan. Data lab mungkin menunjukkan bahwa situs Anda berperforma baik, tetapi data lapangan menunjukkan bahwa situs tersebut perlu ditingkatkan. Atau, data lapangan Anda mungkin menyatakan bahwa semua halaman Anda bagus, tetapi data lab Anda mungkin melaporkan skor yang sangat rendah.
Contoh nyata laporan PageSpeed Insights dari web.dev berikut menunjukkan bahwa dalam beberapa kasus, data lab dan lapangan dapat berbeda di semua metrik Data Web Inti:
Perbedaan antara alat adalah sumber kebingungan yang dapat dipahami bagi developer. Postingan ini menjelaskan alasan utama perbedaan ini dapat terjadi—dengan contoh spesifik yang mencakup setiap metrik Data Web Inti—dan tindakan yang harus dilakukan saat Anda menemukan perbedaan di halaman.
Data lab versus data kolom
Untuk memahami alasan alat lab dan lapangan mungkin melaporkan nilai yang berbeda—bahkan untuk halaman web yang sama persis—Anda perlu memahami perbedaan antara data lab dan lapangan.
Data lab
Data lab ditentukan dengan memuat halaman web di lingkungan terkontrol dengan kumpulan kondisi jaringan dan perangkat yang telah ditentukan sebelumnya. Kondisi ini dikenal sebagai lingkungan lab, yang terkadang juga disebut sebagai lingkungan sintetis.
Alat Chrome yang melaporkan data lab umumnya menjalankan Lighthouse.
Tujuan pengujian lab adalah mengontrol sebanyak mungkin faktor, sehingga hasilnya (sebanyak mungkin) konsisten dan dapat direproduksi dari satu pengujian ke pengujian lainnya.
Data kolom
Data kolom ditentukan dengan memantau semua pengguna yang mengunjungi halaman dan mengukur serangkaian metrik performa tertentu untuk setiap pengalaman individual pengguna tersebut. Karena data kolom didasarkan pada kunjungan pengguna sebenarnya, data ini mencerminkan perangkat, kondisi jaringan, dan lokasi geografis pengguna Anda yang sebenarnya.
Data kolom juga dikenal sebagai data Pemantauan Pengguna Real (RUM); kedua istilah tersebut dapat saling dipertukarkan.
Alat Chrome yang melaporkan data kolom umumnya mendapatkan data tersebut dari Laporan Pengalaman Pengguna Chrome (CrUX). Hal yang umum (dan direkomendasikan) bagi pemilik situs adalah mengumpulkan data kolom sendiri karena dapat memberikan insight yang lebih bisa ditindaklanjuti daripada hanya menggunakan CrUX saja.
Hal terpenting yang perlu dipahami tentang data kolom adalah data ini bukan hanya satu angka, tetapi merupakan distribusi angka. Artinya, bagi beberapa orang yang mengunjungi situs Anda, situs tersebut mungkin dimuat dengan sangat cepat, sementara bagi orang lain, situs tersebut mungkin dimuat dengan sangat lambat. Data kolom untuk situs Anda adalah kumpulan lengkap semua data performa yang dikumpulkan dari pengguna Anda.
Misalnya, laporan CrUX menunjukkan distribusi metrik performa dari pengguna Chrome sebenarnya selama periode 28 hari. Jika melihat hampir semua laporan CrUX, Anda dapat melihat bahwa beberapa pengguna yang mengunjungi situs mungkin memiliki pengalaman yang sangat baik, sementara pengguna lainnya mungkin memiliki pengalaman yang sangat buruk.
Jika alat melaporkan satu angka untuk metrik tertentu, alat tersebut umumnya akan mewakili titik tertentu dalam distribusi. Alat yang melaporkan skor kolom Core Web Vitals melakukannya menggunakan persentil ke-75.
Melihat LCP dari data kolom pada screenshot di atas, Anda dapat melihat distribusi dengan:
- 88% kunjungan memiliki LCP 2,5 detik atau kurang (baik).
- 8% kunjungan memiliki LCP antara 2,5 dan 4 detik (perlu ditingkatkan).
- 4% kunjungan memiliki LCP lebih dari 4 detik (buruk).
Pada persentil ke-75, LCP adalah 1,8 detik:
Data lab dari halaman yang sama menunjukkan nilai LCP 3,0 detik. Meskipun nilai ini lebih besar dari 1,8 detik yang ditampilkan dalam data kolom, nilai ini masih merupakan nilai LCP yang valid untuk halaman ini—nilai ini adalah salah satu dari banyak nilai yang membentuk distribusi lengkap pengalaman pemuatan.
Alasan data lab dan lapangan berbeda
Seperti yang dijelaskan di bagian atas, data lab dan data lapangan sebenarnya mengukur hal yang sangat berbeda.
Data kolom mencakup berbagai kondisi jaringan dan perangkat serta berbagai jenis perilaku pengguna. Hal ini juga mencakup faktor lain yang memengaruhi pengalaman pengguna, seperti pengoptimalan browser seperti cache kembali/maju (bfcache), atau pengoptimalan platform seperti cache AMP.
Sebaliknya, data lab sengaja membatasi jumlah variabel yang terlibat. Pengujian lab terdiri dari:
- Satu perangkat…
- terhubung ke satu jaringan…
- dijalankan dari satu lokasi geografis.
Detail pengujian lab tertentu mungkin atau mungkin tidak merepresentasikan persentil ke-75 data kolom untuk halaman atau situs tertentu secara akurat.
Lingkungan lab yang terkontrol berguna saat men-debug masalah atau menguji fitur sebelum men-deploy ke produksi, tetapi saat mengontrol faktor-faktor ini, Anda secara eksplisit tidak mewakili varian yang Anda lihat di dunia nyata di semua jenis jaringan, kemampuan perangkat, atau lokasi geografis. Anda juga umumnya tidak menangkap dampak performa dari perilaku pengguna sebenarnya, seperti men-scroll, memilih teks, atau mengetuk elemen di halaman.
Selain kemungkinan perbedaan antara kondisi lab dan kondisi sebagian besar pengguna di dunia nyata, ada juga sejumlah perbedaan yang lebih halus yang penting untuk dipahami agar dapat memaksimalkan data lab dan lapangan, serta perbedaan apa pun yang mungkin Anda temukan.
Beberapa bagian berikutnya membahas secara mendetail alasan paling umum terjadinya perbedaan antara data lab dan data lapangan untuk setiap metrik Data Web Inti:
- Largest Contentful Paint (LCP)
- Interaction to Next Paint (INP)
- Pergeseran Tata Letak Kumulatif (CLS)
LCP
Elemen LCP yang berbeda
Elemen LCP yang diidentifikasi dalam pengujian lab mungkin bukan elemen LCP yang sama dengan yang dilihat pengguna saat mengunjungi halaman Anda.
Jika Anda menjalankan laporan Lighthouse untuk halaman tertentu, laporan tersebut akan menampilkan elemen LCP yang sama setiap kali dijalankan. Namun, jika melihat data kolom untuk halaman yang sama, Anda biasanya akan menemukan berbagai elemen LCP yang berbeda, yang bergantung pada sejumlah situasi khusus untuk setiap kunjungan halaman.
Misalnya, semua faktor berikut dapat berkontribusi pada elemen LCP yang berbeda yang ditentukan untuk halaman yang sama:
- Ukuran layar perangkat yang berbeda akan menghasilkan elemen yang berbeda yang terlihat dalam area pandang.
- Jika pengguna login, atau jika konten yang dipersonalisasi ditampilkan dengan cara tertentu, elemen LCP dapat sangat berbeda dari pengguna ke pengguna.
- Serupa dengan poin sebelumnya, jika pengujian A/B berjalan di halaman, hal ini dapat menghasilkan elemen yang sangat berbeda yang ditampilkan.
- Kumpulan font yang diinstal di sistem pengguna dapat memengaruhi ukuran teks di halaman (dan dengan demikian elemen mana yang merupakan elemen LCP).
- Pengujian lab biasanya dijalankan di URL "dasar" halaman—tanpa parameter kueri atau fragmen hash yang ditambahkan. Namun, di dunia nyata, pengguna sering membagikan URL yang berisi ID fragmen atau fragmen teks, sehingga elemen LCP mungkin sebenarnya berasal dari bagian tengah atau bawah halaman (bukan "di atas lipatan").
Karena LCP di kolom dihitung sebagai persentil ke-75 dari semua kunjungan pengguna ke halaman, jika sebagian besar pengguna tersebut memiliki elemen LCP yang dimuat sangat cepat—misalnya, paragraf teks yang dirender dengan font sistem—maka meskipun beberapa pengguna tersebut memiliki gambar besar yang dimuat lambat sebagai elemen LCP, hal ini mungkin tidak memengaruhi skor halaman tersebut jika terjadi pada kurang dari 25% pengunjung.
Atau, sebaliknya. Pengujian lab mungkin mengidentifikasi blok teks sebagai elemen LCP karena mengemulasikan ponsel Moto G4 yang memiliki area pandang yang relatif kecil dan gambar hero halaman Anda awalnya dirender di luar layar. Namun, data lapangan Anda mungkin sebagian besar mencakup pengguna Pixel XL dengan layar yang lebih besar, sehingga bagi mereka, gambar hero yang lambat dimuat adalah elemen LCP mereka.
Efek status cache pada LCP
Pengujian lab biasanya memuat halaman dengan cache dingin, tetapi saat pengguna sebenarnya mengunjungi halaman tersebut, mereka mungkin sudah memiliki beberapa resource yang di-cache.
Saat pertama kali dimuat oleh pengguna, halaman mungkin dimuat dengan lambat, tetapi jika halaman telah dikonfigurasi dengan cache yang tepat, saat pengguna membukanya lagi, halaman mungkin langsung dimuat.
Meskipun beberapa alat lab mendukung beberapa pengoperasian halaman yang sama (untuk menyimulasikan pengalaman bagi pengunjung yang kembali), alat lab tidak dapat mengetahui persentase kunjungan di dunia nyata yang terjadi dari pengguna baru versus pengguna yang kembali.
Situs dengan konfigurasi cache yang dioptimalkan dengan baik dan banyak pengunjung berulang mungkin menemukan bahwa LCP di dunia nyata jauh lebih cepat daripada yang ditunjukkan data lab mereka.
Pengoptimalan AMP atau Signed HTTP Exchange
Situs yang dibuat dengan AMP atau yang menggunakan Signed Exchanges (SXG) dapat dimuat sebelumnya oleh agregator konten seperti Google Penelusuran. Hal ini dapat menghasilkan performa pemuatan yang jauh lebih baik bagi pengguna yang mengunjungi halaman Anda dari platform tersebut.
Selain pramuat lintas origin, situs itu sendiri dapat memuat konten untuk halaman berikutnya di situsnya, yang juga dapat meningkatkan LCP untuk halaman tersebut.
Alat lab tidak menyimulasikan peningkatan yang terlihat dari pengoptimalan ini, dan meskipun melakukannya, alat lab tidak dapat mengetahui persentase traffic Anda yang berasal dari platform seperti Google Penelusuran dibandingkan dengan sumber lainnya.
Efek bfcache pada LCP
Saat halaman dipulihkan dari bfcache, pengalaman pemuatan hampir seketika, dan pengalaman ini disertakan dalam data kolom Anda.
Pengujian lab tidak mempertimbangkan bfcache, jadi jika halaman Anda cocok dengan bfcache, hal ini kemungkinan akan menghasilkan skor LCP yang lebih cepat yang dilaporkan di lapangan.
Pengaruh interaksi pengguna terhadap LCP
LCP mengidentifikasi waktu render gambar atau blok teks terbesar di area pandang, tetapi elemen terbesar tersebut dapat berubah saat halaman dimuat atau jika konten baru ditambahkan secara dinamis ke area pandang.
Di lab, browser akan menunggu hingga halaman dimuat sepenuhnya sebelum menentukan elemen LCP. Namun, di lapangan, browser akan berhenti memantau elemen yang lebih besar setelah pengguna men-scroll atau berinteraksi dengan halaman.
Hal ini masuk akal (dan diperlukan) karena pengguna biasanya akan menunggu untuk berinteraksi dengan halaman hingga "tampak" dimuat, yang merupakan tujuan metrik LCP untuk mendeteksi. Tidak masuk akal juga untuk mempertimbangkan elemen yang ditambahkan ke area pandang setelah pengguna berinteraksi karena elemen tersebut mungkin hanya dimuat karena sesuatu yang dilakukan pengguna.
Namun, implikasinya adalah data lapangan untuk halaman dapat melaporkan waktu LCP yang lebih cepat, bergantung pada perilaku pengguna di halaman tersebut.
INP
INP memerlukan interaksi pengguna sungguhan
Metrik INP mengukur seberapa responsif halaman terhadap interaksi pengguna, pada saat pengguna benar-benar memilih untuk berinteraksi dengannya.
Bagian kedua dari kalimat tersebut sangat penting karena pengujian lab, bahkan yang mendukung perilaku pengguna skrip, tidak dapat memprediksi secara akurat kapan pengguna akan memilih untuk berinteraksi dengan halaman, sehingga tidak dapat mengukur FID secara akurat.
TBT tidak mempertimbangkan perilaku pengguna
Metrik lab Total Blocking Time (TBT) dimaksudkan untuk membantu mendiagnosis masalah pada INP karena metrik ini mengukur seberapa banyak thread utama diblokir selama pemuatan halaman.
Idenya adalah bahwa halaman dengan banyak JavaScript sinkron atau tugas rendering intens lainnya lebih cenderung memiliki thread utama yang diblokir saat pengguna berinteraksi pertama kali. Namun, jika pengguna menunggu untuk berinteraksi dengan halaman hingga JavaScript selesai dieksekusi, INP mungkin sangat rendah.
Kapan pengguna akan memilih untuk berinteraksi dengan halaman sebagian besar bergantung pada apakah halaman tersebut terlihat interaktif atau tidak, dan hal ini tidak dapat diukur dengan TBT.
TBT tidak mempertimbangkan penundaan ketuk
Jika situs tidak dioptimalkan untuk tampilan seluler, browser akan menambahkan penundaan 300 md setelah ketukan sebelum menjalankan pengendali peristiwa. Hal ini dilakukan karena perlu menentukan apakah pengguna mencoba mengetuk dua kali untuk memperbesar sebelum dapat memicu peristiwa mouse atau klik.
Keterlambatan ini diperhitungkan dalam INP halaman karena berkontribusi pada latensi input yang sebenarnya yang dialami pengguna. Namun, karena penundaan ini secara teknis bukan merupakan Tugas Lama, penundaan ini tidak memengaruhi TBT halaman. Artinya, halaman mungkin memiliki INP yang buruk meskipun memiliki skor TBT yang sangat baik.
Pengaruh status cache dan bfcache pada INP
Dengan cara yang sama seperti caching yang tepat dapat meningkatkan LCP di lapangan, caching juga dapat meningkatkan INP.
Di dunia nyata, pengguna mungkin sudah memiliki JavaScript untuk situs di cache-nya, sehingga pemrosesannya dapat memerlukan lebih sedikit waktu dan menghasilkan penundaan yang lebih kecil.
Hal yang sama juga berlaku untuk halaman yang dipulihkan dari bfcache. Dalam kasus tersebut, JavaScript dipulihkan dari memori, sehingga mungkin ada sedikit atau tidak ada waktu pemrosesan sama sekali.
CLS
Pengaruh interaksi pengguna terhadap CLS
CLS yang diukur di lab hanya mempertimbangkan pergeseran tata letak yang terjadi di atas area pandang dan selama pemuatan, tetapi ini hanyalah sebagian dari apa yang sebenarnya diukur CLS.
Di lapangan, CLS mempertimbangkan semua pergeseran tata letak tidak terduga yang terjadi selama masa aktif halaman, termasuk konten yang bergeser saat pengguna men-scroll atau sebagai respons terhadap permintaan jaringan yang lambat setelah interaksi pengguna.
Misalnya, halaman sering kali memuat gambar atau iframe secara lambat tanpa dimensi, dan hal ini dapat menyebabkan pergeseran tata letak saat pengguna men-scroll ke bagian halaman tersebut. Namun, pergeseran tersebut mungkin hanya terjadi jika pengguna men-scroll ke bawah, yang sering kali tidak akan terdeteksi dalam pengujian lab.
Konten yang dipersonalisasi
Konten yang dipersonalisasi—termasuk iklan yang ditargetkan dan pengujian A/B—memengaruhi elemen yang dimuat di halaman. Hal ini juga memengaruhi cara konten dimuat karena konten yang dipersonalisasi sering dimuat nanti dan disisipkan ke dalam konten utama halaman, sehingga menyebabkan perubahan tata letak.
Di lab, halaman biasanya dimuat tanpa konten yang dipersonalisasi, atau dengan konten untuk "pengguna pengujian" umum, yang mungkin memicu atau tidak memicu perubahan yang dilihat pengguna sebenarnya.
Karena data kolom mencakup pengalaman semua pengguna, jumlah (dan tingkat) perubahan tata letak yang dialami di halaman tertentu sangat bergantung pada konten yang dimuat.
Pengaruh status cache dan bfcache pada CLS
Dua penyebab paling umum dari pergeseran tata letak selama pemuatan adalah gambar dan iframe tanpa dimensi (seperti yang disebutkan di atas) serta font web yang memuatkan lambat, dan kedua masalah ini cenderung memengaruhi pengalaman saat pengguna pertama kali mengunjungi situs, saat cache mereka kosong.
Jika resource halaman di-cache, atau jika halaman itu sendiri dipulihkan dari bfcache, browser biasanya dapat langsung merender gambar dan font, tanpa menunggunya didownload. Hal ini dapat menyebabkan nilai CLS di kolom lebih rendah dari yang mungkin dilaporkan oleh alat lab.
Yang harus dilakukan jika hasilnya berbeda
Sebagai aturan umum, jika Anda memiliki data lapangan dan data lab untuk halaman tertentu, data lapangan adalah data yang harus Anda gunakan untuk memprioritaskan upaya Anda. Karena data kolom mewakili pengalaman pengguna sebenarnya, data ini adalah cara paling akurat untuk benar-benar memahami masalah yang dihadapi pengguna dan hal yang perlu ditingkatkan.
Di sisi lain, jika data lapangan Anda menunjukkan skor yang baik secara menyeluruh, tetapi data lab Anda menunjukkan bahwa masih ada ruang untuk peningkatan, sebaiknya pahami pengoptimalan lebih lanjut yang dapat dilakukan.
Selain itu, meskipun data kolom merekam pengalaman pengguna sebenarnya, data tersebut hanya direkam untuk pengguna yang berhasil memuat situs Anda. Data lab terkadang dapat membantu mengidentifikasi peluang untuk memperluas jangkauan situs Anda dan membuatnya lebih mudah diakses oleh pengguna dengan jaringan yang lebih lambat atau perangkat kelas bawah.
Secara keseluruhan, data lab dan data lapangan adalah bagian penting dari pengukuran performa yang efektif. Keduanya memiliki kelebihan dan keterbatasan, dan jika Anda hanya menggunakan salah satunya, Anda mungkin kehilangan peluang untuk meningkatkan pengalaman bagi pengguna.