<h2>Ringkasan</h2>
<p>Performance budget adalah batas yang disepakati agar aplikasi tidak bertambah berat tanpa terasa. Batas ini bisa berupa ukuran JavaScript, waktu render, jumlah request, atau target Core Web Vitals.</p>
<p>Budget membantu tim mengambil keputusan sebelum masalah terasa oleh pengguna.</p>
<h2>Tentukan Metrik Utama</h2>
<p>Tidak semua metrik punya bobot yang sama. Untuk aplikasi produk, biasanya metrik berikut paling berguna:</p>
<ul>
<li>Largest Contentful Paint untuk kecepatan konten utama.</li>
<li>Interaction to Next Paint untuk respons interaksi.</li>
<li>Cumulative Layout Shift untuk stabilitas layout.</li>
<li>Ukuran JavaScript awal untuk biaya parsing browser.</li>
</ul>
<h2>Buat Batas yang Realistis</h2>
<p>Budget yang terlalu ideal sering diabaikan. Mulailah dari kondisi aplikasi sekarang, lalu turunkan secara bertahap.</p>
<p>Contoh target awal:</p>
<pre><code class="language-txt">initial-js: &#x3C; 180 KB gzip
lcp-mobile: &#x3C; 2.8s
cls: &#x3C; 0.1
critical-api: &#x3C; 800ms
</code></pre>
<h2>Integrasikan ke Workflow</h2>
<p>Performance check sebaiknya hadir di pull request, bukan hanya setelah produksi bermasalah. Gunakan Lighthouse CI, bundle analyzer, atau synthetic test sederhana untuk memberi sinyal lebih cepat.</p>
<h2>Penutup</h2>
<p>Performance budget bukan soal mengejar angka sempurna. Tujuannya menjaga aplikasi tetap terasa cepat saat fitur terus bertambah.</p>


Panduan praktis menjaga ukuran bundle, waktu render, dan pengalaman pengguna tetap sehat.