Mengapa Google Lighthouse Tidak Menyertakan INP
Alat Lighthouse milik Google tidak menyertakan metrik INP. Seorang Advokat Pengembang Kinerja Web di tim Google Chrome menjelaskan alasannya.
- Lighthouse tidak dapat mengukur INP secara langsung karena kurangnya interaksi pengguna.
- Total Blocking Time berfungsi sebagai proksi untuk INP dalam pengujian Lighthouse.
- Alur pengguna khusus memungkinkan pengukuran INP untuk perjalanan pengguna yang diketahui.
Lighthouse Google tidak menggunakan metrik Interaksi untuk Mengecat Berikutnya ( INP ) dalam pengujian standarnya, meskipun INP merupakan salah satu Core Web Vitals .
Barry Pollard, Advokat Pengembang Kinerja Web di Google Chrome, menjelaskan alasan di balik hal ini dan menawarkan wawasan dalam mengukur INP.
Lighthouse Mengukur Pemuatan Halaman, Bukan Interaksi
Lighthouse mengukur pemuatan halaman sederhana dan menangkap berbagai karakteristik selama proses tersebut.
Ia dapat memperkirakan Largest Contentful Paint ( LCP ) dan Cumulative Layout Shift ( CLS ) pada kondisi beban tertentu, mengidentifikasi masalah, dan memberikan saran tentang peningkatan metrik ini.
Namun, INP berbeda karena bergantung pada interaksi pengguna.
Pollard menjelaskan:
“Masalahnya adalah bahwa Lighthouse, seperti banyak alat web perf lainnya, biasanya hanya memuat halaman dan tidak berinteraksi dengannya. Tidak ada interaksi = Tidak ada INP yang dapat diukur!”
Alur Pengguna Kustom Memungkinkan Pengukuran INP
Meskipun Lighthouse tidak dapat mengukur INP, mengetahui perjalanan pengguna umum memungkinkan Anda menggunakan “alur pengguna” untuk mengukur INP.
Pollard menambahkan:
“Jika Anda sebagai pemilik situs mengetahui perjalanan pengguna umum, maka Anda dapat mengukurnya di Lighthouse menggunakan ‘alur pengguna’ yang kemudian AKAN mengukur INP.”
Perjalanan pengguna umum ini dapat diotomatisasi dalam lingkungan integrasi berkelanjutan, yang memungkinkan pengembang menguji INP pada setiap komitmen dan menemukan potensi kemunduran.
Total Waktu Pemblokiran Sebagai Proxy INP
Meskipun Lighthouse tidak dapat mengukur INP tanpa interaksi, ia dapat mengukur kemungkinan penyebab , terutama tugas JavaScript yang panjang dan memblokir.
Di sinilah metrik Total Blocking Time (TBT) berperan.
Menurut Pollard:
“TBT (Total Blocking Time) mengukur jumlah waktu semua tugas yang lebih besar dari 50 ms. Teorinya adalah:
- Banyak tugas yang panjang dan menghalangi = risiko tinggi INP!
- Sedikit tugas yang panjang dan menghalangi = risiko INP rendah!”
Keterbatasan TBT Sebagai Pengganti INP
TBT memiliki keterbatasan sebagai pengganti INP.
Pollard mencatat:
“Jika Anda tidak berinteraksi selama tugas yang panjang, maka Anda mungkin tidak memiliki masalah INP. Interaksi juga dapat memuat LEBIH BANYAK JavaScript yang tidak diukur oleh Lighthouse.”
Dia menambahkan:
“Jadi itu petunjuk, tapi bukan pengganti pengukuran INP yang sebenarnya.”
Mengoptimalkan Skor Lighthouse vs. Pengalaman Pengguna
Beberapa pengembang mengoptimalkan skor Lighthouse tanpa mempertimbangkan dampak pada pengguna.
Pollard memperingatkan terhadap hal ini, dengan menyatakan:
“Pola umum yang saya lihat adalah menunda SEMUA JS hingga pengguna berinteraksi dengan halaman: Bagus untuk skor Lighthouse! Sering kali buruk bagi pengguna 😢:
- Kadang-kadang tidak ada yang dimuat hingga Anda menggerakkan mouse.
- Seringkali interaksi pertama Anda mengalami penundaan lebih lama.”
Mengapa Hal Ini Penting
Memahami hubungan Lighthouse , INP, dan TBT diperlukan untuk mengoptimalkan pengalaman pengguna.
Mengenali keterbatasan dalam mengukur INP membantu menghindari optimasi yang salah arah.
Saran Pollard untuk mengukur INP adalah berfokus pada interaksi pengguna nyata untuk memastikan peningkatan kinerja meningkatkan UX.
Karena INP tetap menjadi Web Vital Inti , memahami nuansanya sangat penting untuk menjaganya dalam ambang batas yang dapat diterima.
Aplikasi Praktis
Untuk memantau kinerja situs dan INP:
- Gunakan “alur pengguna” Lighthouse untuk pengukuran INP dalam perjalanan umum.
- Otomatisasi alur pengguna di CI untuk memantau INP dan menangkap regresi.
- Gunakan TBT sebagai proksi INP, tetapi pahami batasannya.
- Prioritaskan pengukuran lapangan untuk data INP yang akurat.
- Seimbangkan pengoptimalan kinerja dengan pertimbangan UX.
