1. Tentukan hasil dan batasan
Tunjuk satu pemilik dan tulis hasil yang diinginkan sebelum membuka alat audit. Nyatakan audiens, perjalanan, halaman atau rute, jendela waktu, dan keputusan yang harus didukung pekerjaan. Sasaran yang berguna menggambarkan tugas, misalnya menyelesaikan alur produk-ke-keranjang di perangkat seluler, bukan keinginan samar untuk membuat situs lebih cepat.
Daftar hal yang tidak boleh dilanggar: alur pembelian atau permintaan yang berfungsi, akses akun, perilaku persetujuan, aksesibilitas, ketercrawlan pencarian, dan konten yang disetujui. Kenaikan skor sintetis bukan kemenangan jika formulir gagal, konten tersembunyi dari pencarian, atau penggunaan keyboard menjadi lebih sulit.
Tulis halaman awal, aksi pengguna, dan kondisi akhir sukses dalam satu kalimat.
Pilih hasil yang tidak boleh memburuk, seperti pengiriman berhasil atau tidak adanya blocker aksesibilitas baru.
2. Tangkap baseline yang dapat dibandingkan
Sebelum mengubah kode, konten, konfigurasi, atau tag, simpan daftar URL, tanggal, kondisi pengujian, versi rilis, laporan atau jejak, dan hasil tugas manual. web.dev merekomendasikan merekam keadaan situs sebelum perubahan dan menguji beberapa tipe halaman; untuk aplikasi single-page, sertakan rute, komponen, dan alur alih-alih hanya muatan pertama.
Gunakan lebih dari satu lensa. Lighthouse menyediakan audit otomatis untuk performa, aksesibilitas, SEO, dan lainnya. Uji muatan pertama dengan penyimpanan dibersihkan atau profil bersih, lalu selesaikan tugas target. Jika tersedia data pengguna nyata yang memadai, bandingkan kelompok halaman penting dan kelas perangkat. Core Web Vitals adalah ukuran lapangan: LCP mencakup pemuatan, INP interaktivitas, dan CLS stabilitas visual.
Data lapangan mencerminkan kunjungan nyata; pengujian lab membuat masalah lebih mudah direproduksi. Gunakan keduanya bila tersedia.
Simulasi muatan tidak dapat mengukur INP karena tidak ada input pengguna; Total Blocking Time di lab hanya merupakan proksi.
3. Audit perjalanan dari ujung ke ujung
Kelompokkan temuan berdasarkan perjalanan dan mekanisme. Tinjau ukuran permintaan, waktu, dan dependensi untuk aset halaman dan pihak ketiga. Periksa viewport seluler, jalur keyboard, fokus terlihat, label, pesan kesalahan, heading, tujuan link, zoom, dan apa yang terjadi jika sebuah gambar, skrip, atau layanan yang bergantung pada persetujuan lambat atau tidak tersedia.
Perlakukan keluaran aksesibilitas otomatis sebagai triase. W3C menyatakan tidak ada alat tunggal yang dapat menentukan apakah situs memenuhi standar aksesibilitas; evaluasi manusia yang berpengetahuan diperlukan. Untuk pencarian, pastikan sumber daya yang dirender tetap tersedia bagi perayap selain pengguna. Sertakan pengalihan, canonical, link internal, direktif robots, sitemap, dan data terstruktur ketika perubahan memengaruhi mereka.
Daftar tag manager, analytics, chat, pembayaran, font, CDN, API, dan alat persetujuan yang menjadi dependensi tugas.
Untuk pembayaran, autentikasi, data pengguna, header, atau kontrol keamanan, dapatkan tinjauan keamanan dan pembayaran yang memenuhi syarat.
4. Buat backlog berperingkat
Tulis hipotesis kecil untuk setiap item: pada halaman atau alur ini, ubah mekanisme ini karena bukti menunjukkan penyebab masalah ini; ukur hasil yang diharapkan dan lindungi guardrail yang dinamai. Jaga pengamatan terpisah dari diagnosis. Jejak yang disimpan dapat menunjukkan gambar besar yang menunda konten, tetapi solusi tetap memerlukan tinjauan desain dan konten.
Prioritaskan item berdasarkan Dampak, Keyakinan, Upaya, dan Risiko. Dampak adalah perjalanan prioritas yang terpengaruh. Keyakinan menunjukkan apakah bukti lab, lapangan, dan manual selaras. Upaya mencakup koordinasi, bukan hanya kode. Risiko mencakup dependensi, keamanan, kompleksitas rilis, dan kemudahan pembalikan. Masalah fungsional atau keamanan yang kritis dapat didahulukan di atas model ini dan memerlukan triase spesialis.
Simpan pemilik, tautan bukti, hipotesis, halaman, ukuran, guardrail, dependensi, metode rilis, dan pemicu rollback.
Jangan menggabungkan refaktor yang tidak terkait ke dalam perubahan terukur kecuali keselamatan memerlukannya.
5. Rilis dengan aman dan pertahankan jalan kembali
Sebelum deployment, catat apa yang berubah, pemberi persetujuan, jendela rilis, pemilik verifikasi, kondisi keberhasilan, pemicu rollback, dan metode pemulihan. Uji di lingkungan non-produksi yang representatif bila memungkinkan, termasuk konten, izin, integrasi, pengalihan, pilihan persetujuan, dan jalur kegagalan umum. Produksi masih bisa berbeda karena data, cache, konfigurasi, dan pihak ketiga.
Gunakan rollout kecil, feature flag, aset versi, atau konfigurasi yang dapat dibalik bila platform mendukung. Konfirmasi perilaku cache dan CDN sebelum membandingkan hasil. OWASP memperlakukan konfigurasi dan manajemen deployment sebagai area pengujian keamanan; header, izin, eksposur file, dan pengaturan domain atau cloud sebaiknya bukan perubahan optimasi yang dibuat secara santai.
Tentukan pemicu yang dapat diamati, seperti checkout gagal, navigasi rusak, error klien tak terduga, atau regresi aksesibilitas.
Rencana rollback dapat mengurangi waktu pemulihan tetapi tidak dapat menghilangkan semua risiko; uji pemulihan sebelum mengandalkannya.
6. Verifikasi, putuskan, dan ulangi
Setelah rilis, ulangi pemeriksaan fungsional baseline dan pengujian lab yang dapat dibandingkan. Periksa ulang perangkat, browser, status, dan integrasi yang relevan. Bandingkan serupa dengan serupa: URL, status cache, kelas perangkat, wilayah bila memungkinkan, dan jendela pengukuran. Konfirmasi guardrail serta metrik target.
Berikan waktu agar bukti terkumpul. Google mencatat bahwa perubahan pencarian dapat memakan waktu jam hingga bulan untuk muncul dan menyarankan menunggu beberapa minggu untuk menilai apakah perubahan membantu. Data performa pengguna nyata adalah bukti agregat, bukan putusan rilis instan. Catat apakah perubahan perlu dipertahankan, dimodifikasi, diselidiki, atau di-rollback, lalu buat baseline baru setelah perubahan bermakna pada template, platform, tag, konten, atau dependensi.
Hasil perjalanan yang diharapkan meningkat dan guardrail yang disepakati tetap utuh.
Ambil tindakan ketika bukti lapangan atau tugas bertentangan dengan hasil lab, atau guardrail kritis mengalami regresi.