Website sudah dipercepat, lalu tiga rilis berikutnya menambahkan widget, font, dan script baru. Beberapa bulan kemudian masalah yang sama muncul kembali. Perbaikan sekali saja tidak cukup jika proses rilis tidak melihat biaya tambahan.
Performance budget adalah batas yang disepakati untuk membantu tim menilai perubahan. Nilainya perlu berangkat dari template, fungsi halaman, dan bukti baseline. Ia berguna ketika menghasilkan keputusan yang jelas saat batas terlewati.
Pilih ukuran yang dapat ditindaklanjuti
Budget dapat memakai ukuran resource, jumlah request, atau metrik pengalaman. Ukuran transfer membantu mengawasi pertumbuhan aset; metrik waktu membantu melihat dampak yang dialami pengguna. Keduanya menjawab pertanyaan berbeda. Pengantar performance budgets.
Jangan hanya memasang batas skor Lighthouse. Skor dapat berubah karena kondisi pengujian dan komposisi penilaiannya. Simpan ukuran individual, versi alat, serta kondisi tes agar hasilnya bisa dijelaskan.
Pilih sedikit ukuran yang terkait masalah nyata. Jika galeri merupakan komponen terberat, pantau gambar awal serta LCP. Jika filter sering lambat, tambahkan pengujian interaksi yang benar-benar menjalankan filter.
Buat baseline per template
Halaman artikel, kategori, dan produk memiliki pekerjaan berbeda. Menggunakan satu halaman homepage untuk mewakili semuanya akan meninggalkan banyak area tanpa perlindungan.
Ambil sampel yang cukup menantang untuk setiap template: artikel dengan diagram, kategori dengan daftar panjang, serta produk dengan beberapa varian. Catat data contoh yang digunakan agar tes berikutnya tidak tiba-tiba memakai isi lebih ringan.
| Template | Sampel tetap | Pemeriksaan yang relevan |
|---|---|---|
| Artikel | Judul panjang dan beberapa gambar | Gambar awal, font, CLS saat membaca |
| Kategori | Banyak hasil dan filter | Transfer awal, render daftar, interaksi filter |
| Produk | Galeri dan pilihan varian | LCP, perubahan varian, stabilitas layout |
| Formulir | Validasi dan hasil pengiriman | Script awal, respons input, fungsi submit |
Budget sebaiknya memiliki pemilik. Jika semua orang menerima peringatan tetapi tidak ada yang memutuskan tindak lanjut, laporan hanya menambah kebisingan.
Contoh: script baru melewati batas kategori
Berikut angka ilustratif untuk menunjukkan cara mengambil keputusan, bukan rekomendasi batas universal:
| Ukuran | Baseline | Batas internal contoh | Kandidat rilis |
|---|---|---|---|
| JavaScript awal terkompresi | 180 KB | 220 KB | 295 KB |
| Gambar tampilan awal | 260 KB | 340 KB | 275 KB |
| LCP lab median sampel | 2,1 detik | 2,5 detik | 2,8 detik |
Tim menemukan library filter baru masuk ke semua halaman, termasuk artikel yang tidak memakai filter. Tindakan yang masuk akal adalah memeriksa pemuatan per route atau komponen, lalu menguji ulang kategori dan artikel.
Jangan menyimpulkan seluruh kenaikan LCP disebabkan library hanya dari tabel. Gunakan trace untuk menghubungkan perubahan resource dengan penundaan yang teramati. Budget menunjukkan lokasi penyelidikan, bukan otomatis membuktikan sebab.
Tentukan keputusan saat batas terlewati
Bedakan peringatan dan penghentian rilis. Perubahan kecil yang berada dalam variasi alat dapat memerlukan pemeriksaan. Regresi besar yang konsisten pada fungsi penting dapat menjadi alasan menahan rilis sesuai kebijakan tim.
Jika ada pengecualian, catat alasan, pemilik, batas waktu peninjauan, dan rencana pengurangan biaya. “Dibutuhkan bisnis” terlalu luas tanpa menjelaskan fungsi yang diberikan dan alternatif yang sudah diperiksa.
Satu fitur mungkin layak memakai resource lebih besar. Namun keputusan itu harus terlihat, bukan tersembunyi di bawah kenaikan batas setiap kali tes gagal.
Jalankan tes dengan kondisi yang stabil
Gunakan konfigurasi perangkat dan jaringan yang sama untuk perbandingan lab. Jalankan pengulangan yang cukup untuk mengenali variasi, lalu simpan median atau ringkasan yang disepakati bersama rentangnya. Jangan memilih hasil tercepat dari banyak percobaan.
Jika data pihak ketiga berubah-ubah, pisahkan tes komponen aplikasi yang terkontrol dari pemeriksaan integrasi nyata. Jelaskan apa yang tidak tercakup ketika memakai fixture atau mock. Hasil fixture tidak membuktikan layanan pihak ketiga sedang sehat.
Periksa pengalaman setelah rilis
Tes pra-rilis membantu menangkap regresi yang dapat direproduksi. Sesudah rilis, pantau error, fungsi penting, serta data pengalaman lapangan bila tersedia. Pengunjung nyata membawa variasi perangkat, jaringan, cache, dan isi yang tidak seluruhnya ada di lab.
Tinjau budget saat template atau kebutuhan produk berubah secara substansial. Simpan baseline lama agar alasan perubahannya tetap dapat dilacak. Budget yang baik membuat biaya sebuah keputusan terlihat dan menjaga perbaikan teknis bertahan pada rilis berikutnya.
