Pelajari alasan alat yang memantau metrik Core Web Vitals dapat melaporkan angka yang berbeda, dan cara menafsirkan perbedaan tersebut.
Google menyediakan sejumlah alat untuk membantu pemilik situs memantau skor Core Web Vitals mereka. Alat-alat ini termasuk dalam dua kategori utama:
- Alat yang melaporkan data lab—data yang dikumpulkan di lingkungan terkendali dengan pengaturan perangkat dan jaringan yang telah ditentukan sebelumnya.
- Alat yang melaporkan data lapangan—data yang dikumpulkan dari pengguna sebenarnya yang berkunjung di situs Anda.
Masalahnya adalah, kadang-kadang data yang dilaporkan oleh alat lab cukup berbeda dari data yang dilaporkan oleh alat lapangan! Data lab Anda mungkin menunjukkan bahwa situs Anda berperforma baik, tetapi data lapangan menunjukkan bahwa situs peningkatan performa. Selain itu, data kolom mungkin menyatakan semua halaman Anda baik, 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 bisa berbeda di semua Metrik Web Vitals:
Perbedaan antara alat-alat adalah sumber kebingungan yang dapat dimengerti developer. Postingan ini menjelaskan alasan utama perbedaan ini dapat ada—dengan contoh spesifik yang mencakup setiap metrik Core Web Vitals—dan apa yang harus dilakukan saat Anda menemukan perbedaan pada halaman.
Data lab versus data lapangan
Untuk memahami mengapa alat lab dan lapangan mungkin melaporkan nilai yang berbeda—bahkan untuk halaman web yang sama persis—Anda perlu memahami perbedaan antara lab dan field layanan otomatis dan data skalabel.
Data lab
Data lab ditentukan dengan memuat halaman web dalam lingkungan yang terkontrol dengan serangkaian kondisi jaringan dan perangkat yang telah ditentukan. Kondisi ini dikenal sebagai lab, terkadang juga disebut sebagai lingkungan sintetis.
Alat Chrome yang melaporkan data lab umumnya berjalan Mercusuar.
Tujuan dari uji lab adalah untuk mengontrol sebanyak mungkin faktor, hasilnya (sebanyak mungkin) konsisten dan dapat direproduksi dari run ke run.
Data kolom
Data kolom ditentukan dengan memantau semua pengguna yang mengunjungi halaman dan mengukur kumpulan metrik performa tertentu untuk setiap pengguna perorangan pengalaman yang lancar bagi developer. Karena data lapangan didasarkan pada kunjungan pengguna nyata, hal ini mencerminkan perangkat aktual, kondisi jaringan, dan lokasi geografis pengguna.
Data kolom biasanya juga dikenal sebagai Pemantauan Pengguna Nyata (RUM); dua suku dapat dipertukarkan.
Alat Chrome yang melaporkan data kolom umumnya mendapatkan data tersebut dari Chrome Laporan Pengalaman Pengguna (CrUX). Pemilik situs juga biasanya (dan direkomendasikan) untuk mengumpulkan data lapangan sendiri karena dapat memberikan lebih banyak hasil analisis yang bisa ditindaklanjuti dibanding hanya menggunakan CrUX.
Hal terpenting untuk dipahami tentang data lapangan adalah tidak hanya satu angka, itu adalah distribusi angka. Artinya, untuk beberapa orang yang mengunjungi situs Anda, mungkin dimuat dengan sangat cepat, sementara situs lain mungkin dimuat dengan sangat lambat. Data kolom untuk situs Anda adalah kumpulan lengkap dari semua data performa kumpulkan dari pengguna Anda.
Misalnya, laporan CrUX menunjukkan distribusi metrik performa dari Pengguna Chrome selama periode 28 hari. Jika Anda melihat hampir semua laporan CrUX, Anda dapat melihat bahwa beberapa pengguna yang mengunjungi situs mungkin memiliki pengalaman yang sangat baik saat orang lain mungkin memiliki pengalaman yang sangat buruk.
Jika sebuah alat melaporkan satu angka untuk metrik tertentu, alat itu umumnya akan mewakili titik tertentu dalam distribusi. Alat yang melaporkan Core Web Skor kolom vital melakukannya menggunakan skor persentil.
Dengan melihat LCP dari data kolom pada screenshot di atas, Anda dapat melihat distribusi di mana:
- 88% kunjungan menunjukkan LCP 2,5 detik atau kurang (baik).
- 8% kunjungan menunjukkan LCP antara 2,5 dan 4 detik (perlu peningkatan).
- 4% kunjungan menunjukkan LCP lebih 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 nilai ini lebih dari 1,8 detik yang ditampilkan di data kolom, itu masih merupakan LCP yang valid untuk halaman ini—ini adalah salah satu dari banyak nilai yang membentuk distribusi penuh pengalaman pemuatan.
Alasan data lab dan lapangan berbeda
Seperti yang dijelaskan di bagian atas, data lab dan data lapangan mengukur berbagai hal.
Data lapangan mencakup berbagai kondisi jaringan dan perangkat serta berbagai jenis perilaku pengguna. Hal ini juga mencakup faktor lain yang memengaruhi pengalaman pengguna, seperti pengoptimalan browser back/forward cache (bfcache), atau pengoptimalan platform seperti Cache AMP.
Sebaliknya, data lab sengaja membatasi jumlah variabel yang digunakan. J uji lab terdiri dari:
- Satu perangkat...
- tersambung ke satu jaringan...
- dijalankan dari satu lokasi geografis.
Detail dari setiap uji lab mungkin atau mungkin tidak secara akurat mewakili Persentil ke-75 data kolom untuk halaman atau situs tertentu.
Lingkungan lab yang terkontrol berguna saat melakukan proses debug pada masalah atau pengujian fitur sebelum diterapkan ke produksi, tetapi saat Anda mengontrol faktor-faktor ini Anda secara eksplisit tidak mewakili varians yang Anda lihat di dunia nyata di semua jenis jaringan, kemampuan perangkat, atau lokasi geografis. Anda umumnya tidak menangkap dampak kinerja dari perilaku pengguna yang nyata, seperti men-scroll, memilih teks, atau mengetuk elemen pada halaman.
Selain kemungkinan diputusnya hubungan antara kondisi lab dan kondisi sebagian besar pengguna di dunia nyata, ada juga sejumlah perbedaan yang lebih kecil yang penting untuk dipahami untuk memanfaatkan sebaik-baiknya lab Anda dan data lapangan, serta perbedaan apa pun yang mungkin Anda temukan.
Beberapa bagian selanjutnya menjelaskan secara detail tentang alasan paling umum di sana bisa jadi ada perbedaan antara data lab dan data lapangan untuk masing-masing Metrik Android vitals:
LCP
Elemen LCP yang berbeda
Elemen LCP yang diidentifikasi dalam uji lab mungkin bukan LCP yang sama pengguna lihat saat mengunjungi laman Anda.
Jika Anda menjalankan laporan Lighthouse untuk laman tertentu, hasilnya akan sama LCP setiap saat. Tetapi jika Anda melihat data {i>field<i} untuk halaman yang sama, biasanya Anda akan menemukan berbagai elemen LCP yang berbeda, yang bergantung pada jumlah situasi spesifik untuk setiap kunjungan halaman.
Misalnya, semua faktor berikut dapat berkontribusi pada LCP yang berbeda untuk halaman yang sama:
- Ukuran layar perangkat yang berbeda menyebabkan elemen yang berbeda terlihat dalam area pandang.
- Jika pengguna login, atau jika konten yang dipersonalisasi ditampilkan di beberapa elemen LCP bisa sangat berbeda dari satu pengguna ke pengguna lain.
- Mirip dengan poin sebelumnya, jika pengujian A/B dijalankan di halaman, pengujian itu dapat menghasilkan elemen yang sangat berbeda yang ditampilkan.
- Serangkaian {i>font<i} yang diinstal pada sistem pengguna dapat memengaruhi ukuran teks pada halaman (dan elemen mana yang merupakan elemen LCP).
- Pengujian lab biasanya dijalankan pada "dasar" halaman URL—tanpa parameter kueri atau fragmen hash yang ditambahkan. Namun pada kenyataannya, pengguna sering membagikan URL yang berisi ID fragmen atau fragmen teks, sehingga elemen LCP dapat sebenarnya berasal dari tengah atau bawah laman (bukan "di atas lipat").
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 dengan sangat cepat—misalnya paragraf teks yang dirender dengan {i>font<i} sistem—kemudian meskipun beberapa pengguna tersebut memiliki gambar berukuran besar dan lambat dimuat sebagai LCP mereka, , mungkin tidak memengaruhi skor halaman tersebut jika terjadi kurang dari 25% jumlah pengunjung.
Atau, hal sebaliknya bisa jadi benar. Uji lab mungkin mengidentifikasi blok sebagai elemen LCP karena mengemulasi ponsel Moto G4 yang memiliki area pandang yang relatif kecil dan banner besar halaman akan dirender terlebih dahulu di luar layar. Namun, data lapangan Anda mungkin mencakup sebagian besar pengguna Pixel XL dengan dengan layar yang lebih besar, jadi banner besar yang dimuat dengan lambat adalah elemen LCP mereka.
Efek status cache di LCP
Pengujian lab biasanya memuat halaman dengan cold cache, tetapi saat pengguna sungguhan melakukan kunjungan halaman tersebut, mungkin sebagian resource-nya sudah di-cache.
Laman mungkin dimuat dengan lambat saat pengguna pertama kali memuat, tetapi jika konfigurasi cache yang benar, saat berikutnya pengguna mengembalikan halaman mungkin langsung dimuat.
Meskipun beberapa alat lab mendukung beberapa operasi pada halaman yang sama (untuk menyimulasikan bagi pengunjung yang kembali), alat lab tidak mungkin mengetahui berapa persentase kunjungan dunia nyata 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 di dunia nyata jauh lebih cepat daripada yang ditunjukkan oleh data lab mereka.
Pengoptimalan AMP atau Signed HTTP Exchange
Situs yang dibuat dengan AMP atau yang menggunakan Signed HTTP Exchange (SXG) dapat dipramuat oleh agregator konten seperti Google Telusuri. Hal ini dapat menghasilkan performa pemuatan yang jauh lebih baik untuk 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 laba yang terlihat dari pengoptimalan ini, dan bahkan mereka tidak dapat mengetahui berapa persentase lalu lintas yang berasal dari platform seperti Google Search dibandingkan dengan sumber lain.
Efek bfcache di LCP
Saat halaman dipulihkan dari bfcache, pengalaman pemuatan sudah dekat seketika, dan pengalaman ini disertakan dalam bidang Anda data Anda.
Pengujian lab tidak mempertimbangkan bfcache, jadi jika halaman Anda bfcache-friendly, kemungkinan akan menghasilkan skor LCP yang lebih cepat di kolom.
Efek interaksi pengguna pada LCP
LCP mengidentifikasi waktu render gambar atau blok teks terbesar dalam area pandang, tetapi elemen terbesar tersebut dapat berubah saat halaman dimuat atau jika elemen akan ditambahkan secara dinamis ke area pandang.
Di lab, browser akan menunggu hingga halaman dimuat sepenuhnya sebelum menentukan apa elemen LCP. Namun di lapangan, browser akan berhenti pemantauan untuk 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 "muncul" dimuat, persis seperti yang ditampilkan oleh ingin dideteksi. Itu juga tidak masuk akal untuk mempertimbangkan elemen yang ditambahkan ke area pandang setelah pengguna berinteraksi, karena elemen-elemen itu mungkin baru dimuat karena tindakan yang dilakukan pengguna.
Implikasinya adalah data kolom untuk halaman dapat dilaporkan lebih cepat Waktu LCP, bergantung pada perilaku pengguna di halaman tersebut.
INP
INP memerlukan interaksi pengguna nyata
Metrik INP mengukur seberapa responsif halaman terhadap interaksi pengguna, pada saat pengguna benar-benar memilih untuk berinteraksi dengan aplikasi.
Bagian kedua dari kalimat itu sangat penting karena uji lab, bahkan uji coba yang mendukung perilaku pengguna skrip, tidak dapat memprediksi secara akurat kapan pengguna akan memilih 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 jumlah thread utama yang diblokir selama pemuatan halaman.
Idenya adalah bahwa laman dengan banyak JavaScript sinkron atau sumber daya tugas rendering cenderung memiliki thread utama yang diblokir saat pengguna pertama kali berinteraksi. Namun, jika pengguna menunggu untuk berinteraksi dengan laman sampai JavaScript selesai dieksekusi, INP mungkin sangat rendah.
Kapan pengguna akan memilih untuk berinteraksi dengan suatu halaman sangat bergantung pada apakah perangkat terlihat interaktif, dan ini tidak dapat diukur dengan TBT.
TBT tidak mempertimbangkan penundaan ketuk
Jika situs tidak dioptimalkan untuk tampilan seluler, browser akan menambahkan parameter 300 md delay setelah ketukan apa pun sebelum menjalankan pengendali peristiwa. Mereka melakukan ini karena mereka perlu tentukan apakah pengguna mencoba mengetuk dua kali untuk zoom sebelum mereka dapat mengaktifkan peristiwa mouse atau klik.
Penundaan ini diperhitungkan dalam INP halaman karena berkontribusi pada input sebenarnya latensi yang dialami pengguna. Namun, karena secara teknis penundaan ini tidak Long Tugas, ini tidak memengaruhi TBT halaman. Artinya, halaman mungkin memiliki INP yang buruk meskipun memiliki skor TBT yang sangat baik.
Pengaruh status cache dan bfcache di INP
Dengan cara yang sama, {i>caching<i} yang tepat dapat meningkatkan LCP di lapangan, hal itu juga dapat meningkatkan INP.
Di dunia nyata, pengguna mungkin memiliki JavaScript untuk situs yang sudah cache, sehingga pemrosesannya bisa memakan waktu lebih sedikit waktu dan mengakibatkan penundaan yang lebih kecil.
Hal yang sama juga berlaku untuk halaman yang dipulihkan dari bfcache. Dalam kasus tersebut, JavaScript dipulihkan dari memori, jadi mungkin hanya ada sedikit atau tidak ada pemrosesan sama sekali.
CLS
Efek interaksi pengguna terhadap CLS
CLS yang diukur di lab hanya mempertimbangkan pergeseran tata letak yang terjadi di atas di lipatan dan selama pemuatan, tetapi ini hanyalah sebagian dari apa yang sebenarnya memperbaikinya.
Di kolom, CLS mempertimbangkan semua tata letak yang tidak terduga pergeseran yang terjadi di seluruh masa aktif halaman, termasuk konten yang bergeser saat pengguna men-scroll atau terhadap permintaan jaringan yang lambat setelah interaksi pengguna.
Misalnya, cukup umum bagi halaman untuk menjalankan lambat memuat gambar atau iframe tanpa dimensi, dan yang dapat menyebabkan tata letak bergeser ketika pengguna menggulir ke bagian laman tersebut. Tetapi, perubahan itu mungkin hanya terjadi jika pengguna men-scroll ke bawah, yang sering kali tidak terdeteksi dalam uji lab.
Konten yang dipersonalisasi
Konten yang dipersonalisasi—termasuk iklan yang ditargetkan dan pengujian A/B—memengaruhi elemen yang ingin yang dimuat di halaman. Hal ini juga memengaruhi cara pemuatannya karena personalisasi konten sering dimuat kemudian dan dimasukkan ke dalam konten utama laman, menyebabkan pergeseran tata letak.
Di lab, halaman biasanya dimuat tanpa konten yang dipersonalisasi, atau dengan konten untuk "pengguna uji coba" umum, yang mungkin memicu atau tidak memicu pergeseran dilihat oleh pengguna di dunia nyata.
Karena data lapangan mencakup pengalaman semua pengguna, jumlah (dan derajat) pergeseran tata letak yang dialami di halaman tertentu sangat bergantung pada konten apa 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 pemuatan web lambat font, dan kedua masalah ini cenderung memengaruhi pengalaman saat pengguna pertama kali mengunjungi situs, saat cache mereka kosong.
Jika sumber daya halaman di-cache atau jika halaman dipulihkan dari {i>bfcache<i}, browser biasanya dapat langsung {i>render<i} gambar dan {i>font<i}, tanpa menunggu untuk diunduh. Hal ini dapat menyebabkan nilai CLS yang lebih rendah di kolom daripada yang dilaporkan oleh alat lab.
Apa yang harus dilakukan jika hasilnya berbeda
Umumnya, jika Anda memiliki data {i>field<i} dan data lab untuk halaman tertentu, data lapangan adalah apa yang harus Anda gunakan untuk memprioritaskan upaya Anda. Karena data {i>field<i} mewakili apa yang dialami pengguna nyata, itu adalah cara paling akurat untuk benar-benar memahami kesulitan apa yang pengguna Anda dan apa yang perlu ditingkatkan.
Di sisi lain, jika data {i>field<i} Anda menunjukkan skor yang baik secara menyeluruh, tetapi data lab Anda menunjukkan masih ada yang perlu ditingkatkan, tidak ada salahnya dalam memahami pengoptimalan lebih lanjut apa yang dapat dilakukan.
Selain itu, meskipun data lapangan menangkap pengalaman pengguna nyata, data lapangan hanya jadi bagi pengguna yang berhasil memuat situs Anda. Data lab dapat terkadang membantu mengidentifikasi peluang untuk memperluas jangkauan situs Anda dan lebih mudah diakses oleh pengguna dengan jaringan lebih lambat atau perangkat kelas bawah.
Secara keseluruhan, data lab dan data lapangan adalah bagian penting dari efektivitas pengukuran performa. Keduanya memiliki kekuatan dan keterbatasan, dan jika jika hanya menggunakan satu, Anda mungkin melewatkan kesempatan untuk meningkatkan pengalaman yang lebih baik bagi pengguna Anda.