Mulai dari perjalanan, bukan rata‑rata seluruh situs
Daftarkan tiga sampai lima perjalanan di mana keterlambatan memiliki biaya jelas bagi pelanggan atau operasi: mendarat di halaman kampanye, menemukan produk, mengirim formulir lead, masuk (sign in), atau menyelesaikan permintaan dukungan. Untuk setiap perjalanan, tulis titik mulai, hasil berguna, kelas perangkat utama, dan halaman atau interaksi yang harus bekerja dengan baik.
Beri setiap perjalanan baris anggarannya sendiri. Sebuah dasbor mungkin memuat lebih banyak kode daripada artikel publik, tetapi aksi filter-nya membutuhkan target responsivitas. Halaman produk kaya media mungkin menerima gambar yang lebih besar, namun butuh batas untuk gambar utama yang terlihat. Ini mencegah jalur kritis lemah tenggelam dalam rata‑rata origin.
Namai apa yang bisa dilihat atau dilakukan pengunjung, seperti membaca penawaran, melihat hasil, atau menerima konfirmasi formulir.
Caching dapat mengubah biaya aset secara material, jadi catat apakah anggaran mencakup kunjungan pertama, kunjungan ulang, atau keduanya.
Pilih hasil dan input yang bisa dikontrol
Gunakan metrik hasil dan batas input. Google menggambarkan Largest Contentful Paint, atau LCP, sebagai performa muat; Interaction to Next Paint, atau INP, sebagai responsivitas interaksi; dan Cumulative Layout Shift, atau CLS, sebagai stabilitas visual. Ambang batas yang direkomendasikan untuk pengalaman baik adalah LCP ≤ 2.5 detik, INP ≤ 200 milidetik, dan CLS ≤ 0.1 pada persentil ke-75, dianggap terpisah untuk mobile dan desktop.
Tambahkan batas yang mengekspos penyebab lebih awal: JavaScript awal, gambar yang diperlukan sebelum konten utama, total transfer untuk rute, permintaan pihak ketiga, dan widget yang diketahui mahal. Lacak ukuran transfer terkompresi secara konsisten. Diagnostik seperti Time to First Byte dapat membantu menyelidiki muat yang lambat, tetapi ia bukan hasil pelanggan itu sendiri.
Gunakan LCP ketika perjalanan bergantung pada konten utama yang menjadi terlihat.
Gunakan INP field untuk pencarian, penyaringan, menu, dan checkout; gunakan proksi lab hanya sebelum ada data field.
Batasi route awal dan kontributor terbesar sehingga pemilik tahu apa yang harus diubah setelah pelanggaran.
Tetapkan angka dari baseline Anda
Tangkap baseline untuk setiap perjalanan. Di PageSpeed Insights, bedakan data field Chrome User Experience Report (CrUX), yang mengagregasi pengalaman pengguna Chrome nyata, dari data lab Lighthouse, yang adalah pengujian terkontrol. Data field memeriksa pengalaman yang mencapai pengguna; tes lab membuat perubahan dapat diulang sebelum rilis.
Segmentasikan setidaknya berdasarkan mobile dan desktop dan, bila memungkinkan, berdasarkan template atau URL kritis. PageSpeed Insights dapat mundur dari data URL ke data origin, dan beberapa halaman tidak memiliki data CrUX. Tandai kasus itu sebagai baseline lab dan tambahkan pengukuran pengguna nyata untuk perjalanan penting. Simpan URL pengujian, profil perangkat dan jaringan, status cache, tanggal, dan versi alat dengan setiap baseline.
Pilih target yang memperbaiki baseline dalam langkah terencana, lalu uji pada kondisi representatif. Anggaran yang memblokir rilis normal akan dilanggar; anggaran yang berada di atas pengalaman saat ini tidak melindungi siapa pun.
Persentil ke-75 adalah nilai di bawah atau sama dengan mana 75% pengalaman yang diobservasi berada; itu bukan rata‑rata.
Jadikan anggaran sebagai aturan rilis
Simpan anggaran di tempat yang versi-able dan dapat ditinjau di samping kode atau checklist rilis. Setiap baris membutuhkan perjalanan, metrik, profil tes atau populasi, ambang peringatan, ambang kesalahan, pemilik, metode pengukuran, dan jalur pengecualian. MDN merekomendasikan tingkat peringatan dan kesalahan: peringatan mendukung perencanaan proaktif, sementara kesalahan adalah batas atas dengan efek negatif yang terlihat.
Otomatiskan pengecekan yang andal. Bundler dapat menolak aset yang ukurannya berlebih atau entry point awal yang terlalu besar; webpack mendukung batas maksimum asset dan entry-point serta petunjuk kesalahan di produksi. Jalankan tes lab yang dapat diulang untuk perjalanan yang terdampak dalam pull request atau kandidat rilis. Simpan metrik field untuk verifikasi pasca-rilis dan prioritisasi ketimbang gerbang build yang tidak andal.
Ketika sebuah batas gagal, kurangi aset, tunda kode nonesensial, ubah pengalaman, pisahkan rilis, atau setujui pengecualian. Jangan menaikkan ambang secara diam‑diam hanya untuk lolos build.
Catat pemilik produk dan teknis, dampak pelanggan, tanggal kedaluwarsa, dan tugas remediasi sebelum rilis.
Blokir ambang kesalahan yang dapat direproduksi pada perjalanan terlindungi; beri tahu dan selidiki ambang peringatan.
Verifikasi dan remediasi setelah peluncuran
Berat halaman tidak memprediksi keseluruhan pengalaman. Urutan permintaan, kerja yang memblokir render, kemampuan perangkat, kondisi jaringan, caching, dan pihak ketiga juga berpengaruh. Pertahankan batas input untuk menangkap pertumbuhan dan ukuran hasil untuk menguji apakah jalur dapat digunakan. Antarmuka W3C Resource Timing mengekspos timing resource dan ukuran transfer, encoded, dan decoded untuk diagnosis lebih mendalam. Detail timing lintas-origin dapat dibatasi oleh izin timing, jadi waterfall yang tidak lengkap tidak membuktikan tidak ada biaya pihak ketiga.
Tinjau hasil field setelah perubahan signifikan pada template, platform, tag pemasaran, atau lalu lintas. Jika LCP memburuk, periksa respons server, resource LCP, dan kerja yang memblokir render. Jika INP memburuk, periksa interaksi aktual; Lighthouse tidak dapat mengukur INP karena tidak ada input pengguna, walaupun Total Blocking Time adalah proksi lab. Gunakan alur kerja optimisasi proaktif SIU untuk mentriase pelanggaran, menstabilkan jalur kritis, dan memverifikasi perbaikan dalam konteks pengukuran yang sama.
Pengecualian yang kadaluwarsa cepat mengungkapkan hutang performa sementara yang menjadi permanen.