Lighthouse: Cara Mengukur Kecepatan Situs dan Menemukan Perbaikan
Lighthouse adalah alat audit otomatis yang mengidentifikasi masalah dan kemungkinan perbaikan dalam kinerja halaman web, aksesibilitas, praktik terbaik, dan optimisasi mesin pencari (SEO). Analisis pemuatan halaman di Chrome DevTools, telusuri metrik lambat ke permintaan, file, atau tugas eksekusi yang terlibat, ubah satu hal, dan ukur kembali di bawah kondisi yang sama. Skor tunggal tidak mewakili pengalaman setiap pengunjung atau menentukan peringkat pencarian halaman.
Lighthouse dan PageSpeed Insights: apa perbedaannya?
Tinjauan resmi Lighthouse menjelaskan cara menjalankan audit melalui Chrome DevTools, baris perintah, atau modul Node. Pemula dapat memulai dengan panel yang disertakan dalam Chrome desktop tanpa menginstal ekstensi. Jalur ini juga berguna untuk halaman yang memerlukan login atau halaman pengembangan lokal.
Dokumentasi PageSpeed Insights membedakan data laboratorium dan data lapangan. Data laboratorium adalah diagnostik Lighthouse yang dihasilkan dalam kondisi tertentu. Data pengalaman pengguna nyata berasal dari Chrome User Experience Report (CrUX), mencakup periode pengumpulan 28 hari terakhir. Jika sampel suatu halaman terlalu sedikit, layanan dapat menampilkan data untuk origin (skema URL, host, dan port yang sama) atau tidak menyediakan data pengguna nyata. Adanya hasil laboratorium tidak berarti statistik pengunjung nyata tersedia untuk halaman tersebut.
Untuk pemeriksaan cepat pada URL publik, masukkan ke PageSpeed Insights, analisis, dan pilih hasil untuk perangkat seluler dan desktop secara terpisah. Untuk halaman yang hanya terlihat setelah masuk, atau URL lokal yang tidak dapat diakses dari luar, gunakan DevTools lokal alih-alih layanan eksternal. Jangan mengirim URL pribadi atau token akses ke layanan analisis eksternal.
Pengukuran dalam sebuah laporan menggambarkan URL target dan kondisi menjalankan tes. Demonstrasi menggunakan URL contoh publik tidak mengukur situs web yang menerbitkan panduan atau situs web Anda sendiri. Pisahkan bagian pengalaman pengguna nyata dari bagian diagnostik Lighthouse saat membaca laporan.
Pilih halaman dan kondisi pengukuran terlebih dahulu
- Target: tentukan URL yang akan diuji, termasuk artikel representatif, daftar, atau halaman produk daripada hanya halaman utama. Jangan menggabungkan template yang berbeda seolah-olah itu adalah hasil sebelum-dan-sesudah untuk halaman yang sama.
- Status: catat apakah ini kunjungan pertama atau ulang, status masuk, dan bagaimana banner persetujuan ditangani. Untuk halaman publik yang tidak memerlukan login, profil terpisah atau jendela incognito dapat membantu mengurangi efek ekstensi.
- Lingkungan: catat versi Chrome dan Lighthouse, pilihan mobile atau desktop, metode pembatasan jaringan dan CPU, serta waktu pengukuran. Hindari menjalankan unduhan besar atau pekerjaan berat lainnya pada saat yang sama.
- Penyimpanan: Menghapus penyimpanan akan menghapus penyimpanan situs untuk mendekati kunjungan awal. Hal ini dapat memengaruhi status login dan persetujuan, jadi jangan mengaktifkannya sembarangan di sesi yang berisi pekerjaan penting. Saat melakukan audit pada halaman dengan sesi login aktif, pilih pengaturan yang mempertahankan status yang diperlukan dan gunakan secara konsisten dalam perbandingan berikutnya.
Melakukan audit saat masuk sebagai administrator dapat memuat skrip, bilah alat, dan kebijakan cache yang berbeda dari yang digunakan oleh pengunjung anonim. Ukur halaman publik secara terpisah ketika pertanyaannya berkaitan dengan pembaca biasa. Jika targetnya adalah fitur untuk pengguna yang sudah masuk, catat status itu secara eksplisit.
Analisis pemuatan halaman di Chrome DevTools
- Buka halaman di Chrome desktop. Periksa apakah alamat publik benar, misalnya, dan bahwa halaman belum dialihkan ke layar kesalahan.
- Buka DevTools, misalnya dengan F12 atau Ctrl+Shift+I di Windows. Jika tab Lighthouse tersembunyi, temukan melalui menu overflow tab atau Alat lainnya di menu DevTools. Nama menu dapat berbeda tergantung bahasa dan versi browser.
- Untuk audit pemuatan halaman awal, pilih Navigation di bawah Mode. Pilih Mobile atau Desktop di bawah Perangkat. Mode Mobile adalah tes laboratorium dengan pembatasan tertentu, bukan reproduksi kinerja setiap ponsel nyata.
- Pilih Kinerja di bawah Kategori, tambahkan Aksesibilitas, Praktik Terbaik, atau SEO jika diperlukan. Periksa pengaturan pembersihan penyimpanan dan throttling dan pertahankan nilainya sama selama perbandingan.
- Pilih Analisis pemuatan halaman, atau tombol mulai yang setara di versi Anda. Halaman akan dimuat ulang, jadi simpan formulir yang belum selesai atau pekerjaan lain yang belum disimpan sebelumnya. Hindari berinteraksi dengan halaman selama analisis dan tunggu laporan.
- Periksa URL yang diminta, URL akhir, pengaturan, dan versi. Simpan laporan sebagai HTML atau JSON, pilih format yang diperlukan jika menu ekspor menyediakan pilihan itu. Laporan dapat berisi alamat internal atau informasi diagnostik, jadi pertimbangkan isinya sebelum dibagikan.
Pilih mode berbeda untuk skenario selain audit pemuatan dasar. Dokumentasi alur pengguna Lighthouse membedakan Navigation untuk satu navigasi, Timespan untuk periode yang dapat mencakup interaksi, dan Snapshot untuk keadaan halaman saat ini. Jangan membandingkan hasil Timespan atau Snapshot seolah-olah itu adalah skor kinerja lengkap Navigation. Pertimbangkan Snapshot ketika pertanyaannya berkaitan dengan keadaan tertentu, seperti aksesibilitas saat menu terbuka.
Baca metrik dan petunjuk diagnostik sebelum melihat skor
Penjelasan penghitungan skor kinerja menjelaskan skor sebagai rata-rata tertimbang dari nilai metrik yang telah ditransformasikan. Mengurangi jumlah peringatan diagnostik tidak menaikkan skor dalam jumlah yang setara. Skor 90–100 ditampilkan sebagai baik, 50–89 perlu perbaikan, dan 0–49 buruk. Rentang ini menafsirkan satu kali pengukuran; bukan batas semua keterlambatan yang dapat diterima pengguna nyata.
| Metrik | Apa yang diukurnya | Petunjuk yang perlu diperiksa terlebih dahulu |
|---|---|---|
| FCP: First Contentful Paint | Waktu hingga konten pertama ditampilkan. | Respons awal server dan gaya atau skrip yang memblokir render. |
| LCP: Largest Contentful Paint | Ketika konten utama yang besar di viewport ditampilkan. | Elemen yang diidentifikasi dalam laporan, dan keterlambatan dalam memulai, mentransfer, atau menampilkan permintaan gambarnya. |
| TBT: Total Blocking Time | Jumlah bagian yang memblokir dari tugas main-thread yang panjang selama pemuatan. | Eksekusi JavaScript yang panjang, skrip startup yang tidak perlu, dan kode pihak ketiga. |
| CLS: Cumulative Layout Shift | Jumlah pergerakan tata letak yang tidak terduga. | Gambar atau iklan tanpa ruang yang disediakan, dan elemen yang dimasukkan terlambat. |
| Speed Index (indeks kecepatan) | Seberapa cepat konten yang terlihat muncul. | Periode keterlambatan tampilan awal, dipertimbangkan bersamaan dengan rekaman visual. |
Dokumentasi TBT mendefinisikan tugas panjang sebagai tugas yang melebihi 50 milidetik, menghitung kelebihan di atas 50 milidetik sebagai waktu pemblokiran. TBT bukanlah metrik yang sama dengan Interaction to Next Paint (INP), yang berkaitan dengan respons terhadap interaksi pengguna. Periksa metrik Core Web Vitals pengguna nyata—LCP, INP, dan CLS—secara terpisah dalam data lapangan.
Perluas Insight dan diagnostik laporan untuk menemukan elemen dan sumber daya yang terpengaruh. Jika elemen LCP adalah gambar di viewport awal, mulailah dengan ukuran transfer dan waktu permintaannya. Untuk pergeseran tata letak yang besar, periksa apakah ruang disediakan untuk gambar dan iklan. Hanya menunda pemuatan gambar layar pertama yang penting atau menunda setiap skrip dengan cara yang sama dapat merugikan tampilan atau fungsi yang diperlukan, jadi identifikasi penyebab dan penggunaannya terlebih dahulu.
Untuk penyelidikan lebih mendalam, lanjutkan dengan rekaman dan Insights di panel Performa, seperti dijelaskan dalam panduan Lighthouse dan panel Performa Chrome. Skor Aksesibilitas atau SEO yang tinggi tidak menjamin kepatuhan aksesibilitas sepenuhnya atau peringkat pencarian yang tinggi. Penggunaan keyboard dan kualitas konten yang sebenarnya, di antara hal-hal lain di luar pemeriksaan otomatis, tetap perlu ditinjau.
Ubah satu hal dan ukur lagi di bawah kondisi yang sama
- Pilih satu masalah dengan dampak pengguna yang substansial dan penyebab yang spesifik. Untuk gambar yang terlalu besar di viewport awal, misalnya, pertama-tama bereksperimenlah dengan gambar yang sesuai dengan ukuran tampilannya.
- Simpan file, pengaturan, dan laporan asli. Lakukan perubahan secara lokal atau di lingkungan pengujian, dan verifikasi bahwa cache menyajikan file baru setelah penyebaran. Jangan menyembunyikan fungsi yang diperlukan atau menyajikan halaman berbeda hanya untuk audit demi mendapatkan skor lebih tinggi.
- Ulangi pengukuran dengan URL, status login, mode perangkat, dan pengaturan pembatasan yang sama. Bandingkan metrik mentah dan rentang serta median dari pengulangan, bukan hanya satu skor terbaik. Jika Anda memilih lima kali pengulangan per kondisi, misalnya, gunakan jumlah itu sebelum dan sesudah perubahan.
- Periksa bahwa metrik target membaik dan bahwa tata letak, tombol, formulir, dan interaksi keyboard masih berfungsi. Jika perubahan tidak membantu atau merusak fungsi, kembalikan file dan pengaturan yang disimpan dan selidiki penyebab lain.
Panduan variasi hasil pengukuran menjelaskan bahwa perubahan jaringan, perangkat, server, dan halaman dapat mengubah skor tanpa perubahan kode. Status iklan dan banner persetujuan juga merupakan kondisi perbandingan. Catat tanggal, URL, versi alat, pengaturan, metrik, dan perubahan yang dilakukan dalam laporan. Evaluasi metrik pengguna nyata setelah periode pengumpulan dan jumlah sampelnya mencukupi.
Ketika analisis gagal atau hasilnya berbeda secara substansial
Jika suatu halaman gagal dimuat, akses diblokir, atau pengalihan gagal, periksa URL akhir dan respons HTTP normal sebelum menafsirkan skor. Jangan melepas autentikasi untuk membuka halaman pribadi ke pengujian eksternal. Untuk pengukuran lokal, periksa pengaturan login dan penghapusan penyimpanan. Jika ekstensi mungkin terlibat, ulangi target yang sama di lingkungan dengan pengaruh ekstensi yang lebih sedikit.
Perbedaan antara PageSpeed Insights dan skor PC Anda tidak otomatis berarti kegagalan. Pertama bandingkan versi Lighthouse, jalur akses server, pengaturan perangkat dan pembatasan, serta status cookie. Jangan mencoba untuk membuat skor seluler dan desktop sama; bandingkan perubahan sebelum-dan-sesudah dalam setiap kondisi dan pertimbangkan metrik pengunjung nyata.
