Pelajari alasan alat yang memantau metrik Data Web Inti dapat melaporkan angka yang berbeda, dan cara menafsirkan perbedaan tersebut.
Google menyediakan sejumlah alat untuk membantu pemilik situs memantau skor Data Web Inti mereka. {i>Tool<i} ini terbagi dalam dua kategori utama:
- Alat yang melaporkan data lab—data yang dikumpulkan di lingkungan terkontrol dengan setelan jaringan dan perangkat yang telah ditentukan.
- Alat yang melaporkan data lapangan—data yang dikumpulkan dari pengguna sungguhan yang mengunjungi situs Anda.
Masalahnya, terkadang data yang dilaporkan oleh alat lab bisa sedikit berbeda dengan data yang dilaporkan oleh alat lapangan. Data lab Anda mungkin menunjukkan bahwa situs Anda berperforma baik, tetapi data kolom Anda menunjukkan bahwa situs tersebut perlu ditingkatkan. Atau, data kolom Anda mungkin menunjukkan bahwa semua halaman Anda bagus, tetapi data lab Anda mungkin melaporkan skor yang sangat rendah.
Contoh nyata laporan PageSpeed Insights berikut dari web.dev menunjukkan bahwa dalam beberapa kasus, data lab dan lapangan dapat berbeda di semua metrik Data Web Inti:
Perbedaan di antara alat-alat ini dapat membingungkan developer. Postingan ini menjelaskan alasan utama terjadinya perbedaan ini—dengan contoh spesifik yang mencakup setiap metrik Data Web Inti—dan apa yang harus dilakukan ketika menemukan perbedaan di halaman Anda.
Data lab versus data lapangan
Untuk memahami mengapa alat lab dan lapangan dapat melaporkan nilai yang berbeda—bahkan untuk halaman yang sama persis—Anda perlu memahami perbedaan antara data lab dan kolom.
Data lab
Data lab ditentukan dengan memuat halaman web di lingkungan yang terkontrol dengan sekumpulan kondisi perangkat dan jaringan yang telah ditetapkan. Kondisi ini dikenal sebagai lingkungan lab, terkadang juga disebut sebagai lingkungan sintetik.
Alat Chrome yang melaporkan data lab umumnya menjalankan Lighthouse.
Tujuan dari uji lab adalah untuk mengontrol sebanyak mungkin faktor, sehingga hasilnya (sebanyak mungkin) konsisten dan dapat direproduksi mulai dari run hingga run.
Data kolom
Data kolom ditentukan dengan memantau semua pengguna yang mengunjungi halaman dan mengukur kumpulan metrik performa tertentu untuk setiap pengalaman individual pengguna tersebut. Karena data lapangan didasarkan pada kunjungan pengguna yang sebenarnya, data tersebut mencerminkan perangkat, kondisi jaringan, dan lokasi geografis pengguna Anda yang sebenarnya.
Data kolom juga dikenal sebagai data Real User Monitoring (RUM); kedua istilah ini dapat dipertukarkan.
Alat Chrome yang melaporkan data kolom umumnya mendapatkan data tersebut dari Laporan Pengalaman Pengguna Chrome (CrUX). Pemilik situs juga umum (dan direkomendasikan) untuk mengumpulkan data lapangan sendiri karena ini dapat memberikan lebih banyak hasil analisis yang bisa ditindaklanjuti daripada hanya menggunakan CrUX saja.
Hal terpenting yang harus dipahami tentang data lapangan adalah bahwa data ini bukan hanya satu angka, melainkan distribusi angka. Artinya, bagi sebagian orang yang mengunjungi situs Anda, situs mungkin akan dimuat dengan sangat cepat, sedangkan bagi pengguna lain, situs mungkin dimuat dengan sangat lambat. Data kolom untuk situs Anda adalah kumpulan lengkap semua data performa yang dikumpulkan dari pengguna.
Misalnya, laporan CrUX menunjukkan distribusi metrik performa dari pengguna Chrome sebenarnya selama periode 28 hari. Jika Anda melihat hampir semua laporan CrUX, Anda dapat melihat bahwa beberapa pengguna yang mengunjungi situs mungkin mendapatkan pengalaman yang sangat baik sementara yang lain mungkin mendapatkan pengalaman yang sangat buruk.
Jika suatu alat melaporkan satu angka untuk metrik tertentu, alat tersebut biasanya akan mewakili titik tertentu dalam distribusi. Alat yang melaporkan skor kolom Core Web Vitals melakukannya menggunakan persentil 75.
Dengan melihat LCP dari data kolom pada screenshot di atas, Anda dapat melihat distribusi dengan:
- 88% kunjungan memperoleh LCP sebesar 2,5 detik atau kurang (baik).
- 8% kunjungan memperoleh LCP antara 2,5 dan 4 detik (perlu peningkatan).
- 4% kunjungan memperoleh LCP lebih besar dari 4 detik (buruk).
Pada persentil ke-75, LCP adalah 1,8 detik:
Data lab dari halaman yang sama menampilkan nilai LCP 3,0 detik. Meskipun 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 penuh pengalaman pemuatan.
Mengapa data lab dan lapangan berbeda
Seperti yang dijelaskan pada bagian di atas, data lab dan data lapangan sebenarnya mengukur hal-hal yang sangat berbeda.
Data kolom mencakup berbagai kondisi jaringan dan perangkat, serta beragam jenis perilaku pengguna. Hal ini juga mencakup faktor lain yang memengaruhi pengalaman pengguna, seperti pengoptimalan browser seperti back/forward cache (bfcache), atau pengoptimalan platform seperti AMP cache.
Sebaliknya, data lab dengan sengaja membatasi jumlah variabel yang terlibat. Pengujian lab terdiri dari:
- Satu perangkat...
- terhubung ke satu jaringan...
- dijalankan dari satu lokasi geografis.
Detail dari uji lab tertentu mungkin atau mungkin tidak secara akurat merepresentasikan persentil ke-75 data lapangan untuk halaman atau situs tertentu.
Lingkungan lab yang terkontrol berguna saat men-debug masalah atau menguji fitur sebelum men-deploy ke produksi. Namun, saat mengontrol faktor-faktor ini, Anda secara eksplisit tidak merepresentasikan varians yang Anda lihat di dunia nyata di semua jenis jaringan, kemampuan perangkat, atau lokasi geografis. Anda secara umum juga tidak merekam dampak performa dari perilaku pengguna nyata, seperti men-scroll, memilih teks, atau mengetuk elemen pada halaman.
Selain kemungkinan terputusnya kondisi lab dan kondisi sebagian besar pengguna di dunia nyata, ada juga sejumlah perbedaan yang lebih halus yang penting untuk dipahami untuk memahami secara optimal data lab dan lapangan Anda, serta perbedaan apa pun yang mungkin Anda temukan.
Beberapa bagian selanjutnya membahas detail yang menyoroti alasan paling umum terjadinya perbedaan antara data lab dan data kolom untuk setiap metrik Vitals Web Inti:
LCP
Elemen LCP yang berbeda
Elemen LCP yang diidentifikasi dalam pengujian lab mungkin bukan elemen LCP yang sama seperti yang dilihat pengguna saat mengunjungi halaman Anda.
Jika Anda menjalankan laporan Lighthouse untuk halaman tertentu, laporan tersebut akan menampilkan elemen LCP yang sama setiap saat. 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 penentuan elemen LCP yang berbeda untuk halaman yang sama:
- Ukuran layar perangkat yang berbeda menyebabkan elemen yang berbeda terlihat di dalam area pandang.
- Jika pengguna login, atau jika konten yang dipersonalisasi ditampilkan dengan cara tertentu, elemen LCP mungkin sangat berbeda dari satu pengguna ke pengguna lainnya.
- Sama seperti poin sebelumnya, jika pengujian A/B dijalankan di halaman, pengujian tersebut dapat menghasilkan elemen yang sangat berbeda yang ditampilkan.
- Kumpulan font yang diinstal pada 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 menambahkan parameter kueri atau fragmen hash apa pun. Namun pada kenyataannya, pengguna sering membagikan URL yang berisi ID fragmen atau fragmen teks, sehingga elemen LCP mungkin sebenarnya berasal dari bagian tengah atau bawah halaman (bukan "paruh atas").
Karena LCP dalam 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 yang besar dan lambat dimuat sebagai elemen LCP, hal ini mungkin tidak memengaruhi skor halaman tersebut jika jumlah pengunjungnya kurang dari 25%.
Atau, bisa jadi hal sebaliknya. Uji lab mungkin mengidentifikasi blok teks sebagai elemen LCP karena mengemulasi ponsel Moto G4 yang memiliki area pandang yang relatif kecil dan banner besar halaman Anda awalnya dirender di luar layar. Namun, data kolom Anda mungkin mencakup sebagian besar pengguna Pixel XL dengan layar yang lebih besar. Jadi, bagi mereka banner besar yang lambat dimuat adalah elemen LCP.
Efek status cache pada LCP
Pengujian lab biasanya memuat halaman yang memiliki cold cache, tetapi saat pengguna sungguhan mengunjungi halaman tersebut, sebagian resource-nya mungkin sudah di-cache.
Saat pertama kali pengguna memuat halaman, halaman mungkin dimuat dengan lambat, tetapi jika halaman telah mengonfigurasi cache yang benar, saat pengguna kembali, halaman tersebut akan 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 sebenarnya yang terjadi dari pengguna baru versus pengguna yang kembali.
Situs dengan konfigurasi cache yang dioptimalkan dengan baik dan banyak pengunjung berulang dapat menemukan bahwa LCP dunia nyata jauh lebih cepat daripada yang ditunjukkan data lab.
Pengoptimalan AMP atau Signed Exchange
Situs yang dibuat dengan AMP atau menggunakan Signed HTTP Exchange (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 melakukan pramuat konten untuk halaman berikutnya di situs mereka, yang juga dapat meningkatkan LCP untuk halaman tersebut.
Alat lab tidak menyimulasikan keuntungan yang terlihat dari pengoptimalan ini. Meskipun demikian, alat lab tidak dapat mengetahui persentase traffic Anda yang berasal dari platform seperti Google Penelusuran dibandingkan dengan sumber lain.
Efek bfcache pada LCP
Saat halaman dipulihkan dari bfcache, pengalaman pemuatan akan berlangsung hampir seketika, dan pengalaman ini disertakan dalam data kolom Anda.
Pengujian lab tidak mempertimbangkan bfcache, sehingga jika halaman Anda cocok untuk bfcache, hal ini mungkin akan menghasilkan skor LCP yang lebih cepat yang dilaporkan di kolom tersebut.
Efek interaksi pengguna pada 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, dalam kolom ini, 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 halaman "muncul" dimuat, yang persis seperti yang ingin dideteksi metrik LCP. Selain itu, tidak masuk akal untuk mempertimbangkan elemen yang ditambahkan ke area tampilan setelah pengguna berinteraksi karena elemen tersebut mungkin hanya dimuat karena sesuatu yang dilakukan pengguna.
Namun, implikasinya adalah data kolom untuk halaman dapat melaporkan waktu LCP yang lebih cepat, bergantung pada perilaku pengguna di halaman tersebut.
FID
FID memerlukan interaksi pengguna secara nyata
Metrik FID mengukur seberapa responsif halaman terhadap interaksi pengguna, pada saat pengguna benar-benar memilih untuk berinteraksi dengannya.
Bagian kedua dari kalimat tersebut sangat penting karena uji 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 dengan FID karena mengukur seberapa banyak thread utama yang diblokir selama pemuatan halaman.
Gagasannya adalah halaman dengan banyak JavaScript sinkron atau tugas rendering intensif lainnya cenderung memiliki thread utama yang diblokir saat pengguna pertama kali berinteraksi. Namun, jika pengguna menunggu berinteraksi dengan halaman hingga JavaScript selesai dieksekusi, FID mungkin menjadi sangat rendah.
Waktu pengguna akan memilih untuk berinteraksi dengan halaman sangat bergantung pada apakah halaman tersebut terlihat interaktif atau tidak, dan 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 apa pun sebelum menjalankan pengendali peristiwa. Mereka melakukan ini karena mereka perlu menentukan apakah pengguna mencoba mengetuk dua kali untuk melakukan zoom sebelum dapat mengaktifkan peristiwa mouse atau klik.
Penundaan ini diperhitungkan dalam FID halaman karena berkontribusi pada latensi input sebenarnya yang dialami pengguna. Namun, karena penundaan ini secara teknis bukan Tugas Panjang, penundaan ini tidak memengaruhi TBT halaman. Hal ini berarti halaman mungkin memiliki FID yang buruk meskipun memiliki skor TBT yang sangat bagus.
Efek status cache dan bfcache pada FID
Dengan cara yang sama seperti cache yang tepat dapat meningkatkan LCP di kolom, tindakan ini juga dapat meningkatkan FID.
Di dunia nyata, pengguna mungkin memiliki JavaScript untuk situs yang sudah ada dalam cache, sehingga pemrosesannya dapat memerlukan waktu lebih singkat 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
Efek interaksi pengguna pada CLS
CLS yang diukur di lab hanya mempertimbangkan pergeseran tata letak yang terjadi di paruh atas dan selama pemuatan, tetapi ini hanya subset dari yang sebenarnya diukur oleh CLS.
Di kolom, CLS mempertimbangkan semua pergeseran tata letak yang 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, sangat umum bagi halaman memuat gambar atau iframe dengan lambat tanpa dimensi, dan hal tersebut dapat menyebabkan pergeseran tata letak saat pengguna men-scroll ke bagian halaman tersebut. Namun, pergeseran tersebut hanya dapat 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 apa yang dimuat di halaman. Hal ini juga memengaruhi cara pemuatannya karena konten yang dipersonalisasi sering dimuat kemudian dan disisipkan ke dalam konten utama halaman, sehingga menyebabkan pergeseran tata letak.
Di lab, halaman biasanya dimuat tanpa konten yang dipersonalisasi, atau dengan konten untuk "pengguna uji coba" generik, yang mungkin atau mungkin tidak memicu perubahan yang dilihat oleh pengguna nyata.
Karena data kolom mencakup pengalaman semua pengguna, jumlah (dan tingkat) pergeseran tata letak yang dialami pada halaman tertentu sangat bergantung pada konten yang dimuat.
Efek status cache dan bfcache pada CLS
Dua penyebab paling umum pergeseran tata letak selama pemuatan adalah gambar dan iframe tanpa dimensi (seperti yang disebutkan di atas) dan font web pemuatan yang lambat. Kedua masalah ini lebih cenderung memengaruhi pengalaman pengguna saat pertama kali mengunjungi situs, saat cache-nya kosong.
Jika resource halaman di-cache, atau jika halaman dipulihkan dari bfcache, browser biasanya dapat langsung merender gambar dan font, tanpa perlu menunggu didownload. Hal ini dapat menyebabkan nilai CLS di kolom lebih rendah daripada yang dapat dilaporkan oleh alat lab.
Apa yang harus dilakukan jika hasilnya berbeda
Sebagai aturan umum, jika Anda memiliki data kolom dan data lab untuk halaman tertentu, data kolom adalah yang harus Anda gunakan untuk memprioritaskan upaya Anda. Karena data kolom merepresentasikan pengalaman pengguna nyata, data ini adalah cara paling akurat untuk memahami masalah pengguna dan hal yang perlu ditingkatkan.
Di sisi lain, jika data lapangan Anda menunjukkan skor yang baik secara keseluruhan, tetapi data lab Anda menunjukkan masih ada hal yang dapat ditingkatkan, sebaiknya pahami pengoptimalan lebih lanjut yang dapat dilakukan.
Selain itu, meskipun data kolom merekam pengalaman pengguna yang sebenarnya, data ini hanya melakukannya 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 merupakan bagian penting dari pengukuran performa yang efektif. Keduanya memiliki kekuatan dan keterbatasan, dan jika Anda hanya menggunakan salah satunya, Anda mungkin kehilangan kesempatan untuk meningkatkan pengalaman bagi pengguna.