Web Vitals Budget untuk Website Bisnis Indonesia: Cara Susun Anggaran Performa yang Lulus Audit 2026

TL;DR: Web Vitals Budget adalah angka batas LCP, INP, dan CLS yang disepakati tim sebelum kode masuk produksi. Anggaran ini memaksa keputusan performa terjadi di tahap perancangan, bukan setelah klien mengeluh halaman lambat. Tim yang menerapkannya umumnya melihat penurunan halaman berstatus poor 30-50% dalam 1-2 kuartal.

Kebanyakan tim marketing mengukur performa hanya saat ada masalah. Halaman lambat dibahas saat bos kirim screenshot, bukan saat fitur baru sedang dirancang. Pola ini wajar tapi mahal: setiap fitur baru menambah JavaScript, gambar, dan font, sementara anggaran performa tidak pernah ditetapkan eksplisit.

Dalam beberapa proyek terakhir bersama klien Atmo dan beberapa LMS lokal, saya melihat satu pola berulang. Halaman utama yang awalnya gesit pelan-pelan melar karena tidak ada yang berani menolak permintaan baru. Setiap minggu ada satu skrip pelacakan baru, satu hero image yang lebih besar, satu komponen interaktif. Tidak ada satu rilis pun yang terlihat berbahaya, tapi enam bulan kemudian halaman butuh empat detik untuk memuat di koneksi 4G Jakarta.

Masalah Klasik: Performa adalah KPI Tanpa Pemilik

Core Web Vitals sudah menjadi sinyal peringkat sejak 2021, dan sejak Maret 2024 INP menggantikan FID sebagai metrik responsivitas. Meski demikian, performa biasanya masuk laporan triwulanan tanpa target eksplisit. Marketer melihat skor merah, developer menjawab "nanti dioptimasi". Tidak ada anggaran berarti tidak ada keputusan harus dibuat.

Web Vitals Budget memecah kebuntuan ini dengan satu pertanyaan: berapa angka maksimum yang masih boleh dirilis? Jika anggaran LCP adalah 2,0 detik dan rilis baru mendorong angka ke 2,3 detik, ada keputusan eksplisit yang harus dibuat. Bukan diskusi abstrak soal "performa", tapi pilihan konkret antara fitur dan kecepatan.

Cara Menyusun Anggaran

Anggaran yang sehat punya tiga lapis: ambang Google sebagai batas atas, angka internal sebagai target, dan marjin aman untuk kondisi lapangan. Saya biasanya merekomendasikan tabel berikut sebagai titik awal yang dapat disesuaikan per situs:

Marjin yang lebih besar untuk CLS dipilih karena layout shift sering terjadi karena iklan, font, atau gambar dinamis yang sulit dikontrol penuh. Marjin INP juga lebih tinggi karena kondisi perangkat menengah ke bawah di Indonesia masih dominan, dan eksekusi JavaScript di perangkat tersebut bisa 2-3 kali lebih lambat dari laptop developer.

Sumber data wajib: Chrome User Experience Report sebagai sumber field, dan Lighthouse CI sebagai sumber lab. Field menggambarkan pengalaman pengguna sebenarnya, lab memberi sinyal cepat di tahap rilis. Keduanya wajib dipantau.

Cara Menegakkan: Pasang di Pipeline

Anggaran tanpa enforcement adalah dokumen mati. Saya pakai tiga gerbang berlapis di proyek-proyek belakangan ini:

Gerbang pertama: Lighthouse CI di pull request. Setiap PR otomatis dijalankan terhadap halaman kunci. Jika hasilnya melampaui anggaran lab, PR diberi label dan diskusi performa terjadi di review code, bukan setelah merge.

Gerbang kedua: Sintesis WebPageTest mingguan. Sekali seminggu, halaman utama dites dari beberapa lokasi (Jakarta, Surabaya, Singapura) dengan profil 4G slow. Hasilnya masuk dashboard tim, dipakai untuk evaluasi tren.

Gerbang ketiga: Field RUM bulanan. Data dari Real User Monitoring memberi gambaran pengguna sebenarnya. Jika anggaran dilampaui di field, audit khusus dijadwalkan kuartal berikutnya.

Studi Kasus: Halaman Pricing Konsultan

Salah satu klien konsultan B2B saya, anggaplah sebut nama proyeknya Atmo, awalnya punya halaman pricing dengan LCP 3,4 detik di field. Anggaran ditetapkan 2,0 detik, marjin 20%. Tiga bulan setelah anggaran diterapkan, dengan tiga audit dan dua refactor komponen pricing tabel, LCP turun ke 1,7 detik. Yang penting, tidak ada rilis baru yang membawa angka kembali naik karena setiap PR pricing-related otomatis di-cek.

Pelajaran yang saya petik: anggaran bekerja bukan karena teknologinya canggih, tapi karena akhirnya ada ambang yang membuat diskusi performa berhenti menjadi opini.

Pertanyaan Umum

Apakah Web Vitals Budget hanya untuk situs besar?

Tidak. Justru situs kecil mendapat manfaat lebih cepat karena perubahan kode masih sederhana. Anggaran membantu menjaga kebiasaan baik sejak awal sebelum kompleksitas membengkak.

Bagaimana jika tim marketing tidak punya developer in-house?

Mulai dengan anggaran observasi: pakai PageSpeed Insights API atau layanan seperti SpeedCurve untuk melacak metrik bulanan. Diskusikan deviasi dengan vendor pengembang sebagai bagian dari kontrak SLA.

Berapa lama hasil terlihat setelah anggaran diterapkan?

Umumnya 4-8 minggu untuk perbaikan lab terlihat, dan 2-3 bulan untuk data field bergeser secara signifikan, karena CrUX butuh waktu mengakumulasi sampel pengguna baru.

Apakah ada angka anggaran yang sama untuk semua industri?

Tidak. E-commerce dengan banyak gambar produk butuh anggaran LCP yang sedikit lebih longgar daripada blog statis. Industri SaaS B2B sering memerlukan anggaran INP lebih ketat karena pengguna berinteraksi intens dengan dashboard.

Penutup

Web Vitals Budget bukan jaminan performa, tapi alat keputusan. Tim yang bersedia menetapkan angka dan menempelkannya di pipeline akan mendapati performa berhenti menjadi krisis berulang. Untuk web bisnis Indonesia 2026, anggaran ini adalah cara paling murah untuk mengubah performa dari laporan menjadi proses.