Anggaran performa membantu menjaga aplikasi web tetap cepat dengan menetapkan batas jelas pada waktu muat, ukuran JS, dan Core Web Vitals, serta audit cepat dan aturan perbaikan terlebih dahulu.
Anggaran performa adalah sekumpulan batas yang disepakati sebelum Anda membangun. Bisa berupa batas waktu (seberapa cepat halaman terasa), batas ukuran (berapa banyak kode yang dikirim), atau batas sederhana (jumlah permintaan, gambar, skrip pihak ketiga). Jika Anda melewati batas, itu diperlakukan seperti persyaratan yang rusak, bukan tugas "baik untuk diperbaiki nanti".
Kecepatan biasanya memburuk karena pengiriman bersifat aditif. Setiap widget baru menambah JavaScript, CSS, font, gambar, panggilan API, dan pekerjaan tambahan untuk browser. Perubahan kecil pun menumpuk hingga aplikasi terasa berat, terutama di ponsel kelas menengah dan jaringan lambat tempat sebagian besar pengguna nyata berada.
Opini tidak melindungi Anda di sini. Satu orang bilang “terasa baik di laptop saya,” yang lain bilang “lambat,” dan tim berdebat. Anggaran mengakhiri perdebatan dengan mengubah performa menjadi kendala produk yang bisa diukur dan ditegakkan.
Inilah tempat pemikiran Addy Osmani cocok: perlakukan performa seperti batasan desain dan aturan keamanan. Anda tidak “mencoba” tetap aman atau “berharap” tata letak terlihat bagus. Anda menetapkan standar, memeriksanya terus-menerus, dan memblokir perubahan yang merusaknya.
Anggaran menyelesaikan beberapa masalah praktis sekaligus. Mereka membuat trade-off menjadi eksplisit (menambah fitur berarti membayar biayanya di tempat lain), menangkap regresi lebih awal (saat perbaikan lebih murah), dan memberi semua orang definisi yang sama tentang "cukup cepat." Mereka juga mengurangi kepanikan di akhir yang sering muncul tepat sebelum peluncuran.
Contoh situasi yang dibuat untuk anggaran: Anda menambahkan library chart kaya fitur untuk satu tampilan dashboard. Library itu dikirim ke semua orang, membesarakan bundle utama, dan menunda tampilan pertama yang bermakna. Tanpa anggaran, ini lolos karena fiturnya “berfungsi.” Dengan anggaran, tim harus memilih: muat malas library chart, ganti library, atau sederhanakan tampilan.
Ini semakin penting ketika tim bisa menghasilkan dan mengiterasi aplikasi dengan cepat, termasuk alur build yang digerakkan chat seperti Koder.ai. Kecepatan bagus, tapi juga memudahkan pengiriman dependensi ekstra dan ornamen UI tanpa disadari. Anggaran menjaga iterasi cepat agar tidak berubah jadi produk yang lambat.
Pekerjaan performa gagal saat Anda mengukur segalanya dan tidak memiliki kepemilikan. Pilih satu alur halaman yang penting bagi pengguna nyata, dan perlakukan itu sebagai jangkar anggaran Anda.
Mulai yang baik adalah perjalanan utama di mana kecepatan memengaruhi konversi atau pekerjaan harian, seperti “beranda ke pendaftaran,” “muatan pertama dashboard setelah login,” atau “checkout dan konfirmasi pembayaran.” Pilih sesuatu yang representatif dan sering terjadi, bukan kasus tepi.
Aplikasi Anda tidak berjalan di laptop Anda. Anggaran yang tampak baik di mesin cepat bisa terasa lambat di ponsel kelas menengah.
Putuskan satu kelas perangkat target dan satu profil jaringan untuk memulai. Buat sederhana dan tuliskan sebagai kalimat yang bisa diulang semua orang.
Contoh: ponsel Android kelas menengah dari 2–3 tahun terakhir, di 4G saat bergerak (bukan Wi‑Fi kantor), mengukur cold load lalu satu navigasi kunci, di region yang sama dengan sebagian besar pengguna.
Ini bukan memilih kasus terburuk. Ini memilih kasus umum yang benar‑benar bisa Anda optimalkan.
Angka hanya penting jika dapat dibandingkan. Jika satu kali run adalah “Chrome dengan ekstensi di MacBook” dan berikutnya “mobile throttled,” garis tren Anda jadi berisik.
Pilih satu lingkungan baseline dan patuhi itu untuk pemeriksaan anggaran: versi browser yang sama, pengaturan throttling sama, jalur pengujian yang sama, dan status cache yang sama (cold atau warm). Jika pakai perangkat nyata, gunakan model perangkat yang sama.
Sekarang definisikan "cukup cepat" dalam istilah perilaku, bukan demo yang sempurna. Contoh: “pengguna bisa mulai membaca konten dengan cepat” atau “dashboard terasa responsif setelah login.” Terjemahkan itu menjadi satu atau dua metrik untuk perjalanan ini, lalu tetapkan anggaran di sekitarnya.
Anggaran paling efektif ketika menutupi apa yang dirasakan pengguna dan apa yang bisa dikontrol tim. Set yang baik mengombinasikan metrik pengalaman (bagian "apakah terasa cepat?") dengan batas sumber daya dan CPU (bagian "kenapa jadi lambat?").
Ini melacak bagaimana halaman berperilaku bagi pengguna nyata. Yang paling berguna memetakan langsung ke Core Web Vitals:
Anggaran waktu adalah bintang utara Anda karena mereka cocok dengan frustrasi pengguna. Tapi mereka tidak selalu memberitahu apa yang harus diperbaiki, jadi Anda juga perlu jenis anggaran di bawah ini.
Ini lebih mudah ditegakkan dalam build dan review karena konkret.
Anggaran bobot membatasi total JavaScript, total CSS, bobot gambar, dan bobot font. Anggaran permintaan membatasi jumlah permintaan dan skrip pihak ketiga, mengurangi overhead jaringan dan kerja “kejutan” dari tag, widget, dan tracker. Anggaran runtime membatasi long tasks, waktu main-thread, dan waktu hidrasi (khususnya untuk React), yang sering menjelaskan mengapa halaman terasa lambat di ponsel kelas menengah.
Contoh React praktis: ukuran bundle mungkin terlihat baik, tetapi sebuah carousel baru menambah rendering sisi-klien yang berat. Halaman ter-load, namun mengetuk filter terasa tersendat karena hidrasi memblokir main thread. Anggaran runtime seperti “tidak ada long task lebih dari X ms saat startup” atau “hidrasi selesai dalam Y detik di perangkat menengah” bisa menangkap ini bahkan saat anggaran bobot tidak menunjukkan masalah.
Pendekatan terkuat memperlakukan semua ini sebagai satu sistem: anggaran pengalaman menentukan keberhasilan, dan anggaran ukuran/permintaan/runtime menjaga rilis tetap jujur dan memudahkan menjawab “apa yang berubah?”.
Jika Anda menetapkan terlalu banyak batas, orang berhenti memperhatikan. Pilih 3–5 anggaran yang paling terasa oleh pengguna dan yang bisa Anda ukur pada setiap pull request atau rilis.
Set starter praktis (sesuaikan angkanya nanti):
Dua ambang membuat semuanya masuk akal. “Peringatan” memberi tahu Anda sedang mengarah ke batas. “Gagal” memblokir rilis atau mengharuskan persetujuan eksplisit. Itu membuat batas menjadi nyata tanpa menciptakan kebakaran terus‑menerus.
Tuliskan anggaran di satu tempat bersama sehingga tidak diperdebatkan saat rilis sibuk. Singkat dan spesifik: halaman atau alur yang dicakup, di mana pengukuran dijalankan (audit lokal, CI, build staged), perangkat dan profil jaringan yang digunakan, dan tepatnya bagaimana metrik didefinisikan (field vs lab, gzip vs raw, level route vs seluruh app).
Mulai dengan baseline yang bisa Anda ulangi. Pilih satu atau dua halaman kunci dan uji pada profil perangkat dan jaringan yang sama setiap kali. Jalankan tes setidaknya tiga kali dan catat median sehingga satu run aneh tidak menentukan arah Anda.
Gunakan sheet baseline sederhana yang mencakup metrik pengguna dan metrik build. Contoh: LCP dan INP untuk halaman, plus total ukuran JavaScript dan total byte gambar untuk build. Ini membuat anggaran terasa nyata karena Anda bisa melihat apa yang dikirim aplikasi, bukan hanya tebakan dari tes lab.
Tetapkan anggaran sedikit lebih baik dari kondisi hari ini, bukan angka fantasi. Aturan praktis: perbaikan 5–10 persen dari median saat ini pada setiap metrik yang Anda pedulikan. Jika LCP baseline Anda 3.2s, jangan langsung lompat ke 2.0s. Mulai ke 3.0s, lalu perketat setelah terbukti bisa mempertahankannya.
Tambahkan pemeriksaan cepat ke setiap rilis sebelum pengguna melihatnya. Buat cukup cepat agar orang tidak melewatkannya. Versi sederhana: jalankan audit halaman tunggal pada halaman yang disepakati, gagalkan build jika JS atau gambar melebihi anggaran, simpan hasil per commit sehingga Anda bisa melihat kapan berubah, dan selalu uji pola URL yang sama (jangan data acak).
Tinjau pelanggaran mingguan, bukan hanya ketika ada keluhan. Perlakukan pelanggaran seperti bug: identifikasi perubahan yang menyebabkannya, tentukan apa yang diperbaiki sekarang dan apa yang dijadwalkan. Perketat perlahan, hanya setelah Anda bisa mempertahankannya beberapa rilis.
Saat ruang lingkup produk berubah, perbarui anggaran dengan sengaja. Jika Anda menambahkan tool analitik baru atau fitur berat, catat apa yang bertambah (ukuran, permintaan, runtime), apa yang akan Anda lakukan untuk menebusnya nanti, dan kapan anggaran harus kembali.
Anggaran hanya membantu jika Anda bisa memeriksanya dengan cepat. Tujuan audit 10 menit bukan membuktikan angka sempurna. Ini untuk melihat apa yang berubah sejak build baik terakhir dan memutuskan apa yang diperbaiki duluan.
Mulai dengan satu halaman yang mewakili penggunaan nyata. Lalu jalankan cek cepat yang sama setiap waktu:
Dua tampilan biasanya memberi jawaban dalam hitungan menit: network waterfall dan timeline main-thread.
Di waterfall, cari satu permintaan yang mendominasi jalur kritis: skrip besar, font yang memblokir, atau gambar yang dimulai terlambat. Jika sumber LCP tidak diminta lebih awal, halaman tidak bisa memenuhi anggaran LCP tak peduli seberapa cepat server.
Di timeline, cari long tasks (50 ms atau lebih). Klaster long tasks saat startup sering berarti terlalu banyak JavaScript pada muatan pertama. Satu chunk besar biasanya masalah routing atau shared bundle yang membengkak seiring waktu.
Audit cepat gagal ketika setiap run berbeda. Tangkap beberapa dasar supaya perubahan jelas: URL halaman dan versi build, perangkat dan profil jaringan pengujian, deskripsi elemen LCP, angka kunci yang Anda lacak (mis. LCP, total JS bytes, jumlah permintaan), dan catatan singkat tentang pelaku terbesar.
Pengujian desktop baik untuk umpan balik cepat dan pemeriksaan PR. Gunakan perangkat nyata saat Anda mendekati anggaran, saat halaman terasa nge-lag, atau saat pengguna Anda mayoritas mobile. CPU mobile membuat long tasks jelas, dan di situlah banyak rilis “terasa baik di laptop saya” runtuh.
Saat anggaran gagal, langkah terburuk adalah “optimalkan semuanya.” Gunakan urutan triase yang bisa diulang sehingga setiap perbaikan punya hasil yang jelas.
Mulai dari yang paling diperhatikan pengguna, lalu turun ke penyesuaian halus:
Sebuah tim mengirim dashboard baru dan tiba‑tiba melewati anggaran LCP. Daripada mengutak-atik header cache, mereka menemukan elemen LCP adalah gambar chart full-width. Mereka mengubah ukurannya, menyajikan format lebih ringan, dan hanya memuat apa yang penting lebih awal. Selanjutnya mereka menyadari library chart besar dimuat di semua route. Mereka hanya memuatnya di halaman analitik dan menunda widget dukungan pihak ketiga sampai setelah interaksi pertama. Dalam sehari, dashboard kembali ke dalam anggaran, dan rilis berikutnya punya jawaban jelas “apa yang berubah.”
Mode kegagalan terbesar adalah memperlakukan anggaran sebagai dokumen sekali jadi. Anggaran hanya bekerja saat mudah diperiksa, sulit diabaikan, dan terikat pada cara Anda mengirim.
Kebanyakan tim terjebak beberapa perangkap:
Polanya sering fitur “kecil” yang menarik library baru. Bundle bertambah, LCP melambat satu detik di jaringan lambat, dan tak ada yang menyadari sampai tiket dukungan muncul. Anggaran ada agar perubahan itu terlihat saat review.
Mulai sederhana dan jaga pemeriksaan konsisten. Pilih 2–4 anggaran yang memetakan pengalaman pengguna dan perketat perlahan. Kunci setup pengujian dan tuliskan. Lacak setidaknya satu sinyal pengguna nyata jika bisa, dan gunakan tes lab untuk menjelaskan "mengapa", bukan untuk memenangkan argumen. Saat dependensi menambah bobot signifikan, minta catatan singkat: berapa biayanya, apa yang digantikan, dan kenapa sepadan. Paling penting, masukkan pemeriksaan anggaran ke jalur rilis normal.
Jika anggaran terasa seperti gesekan konstan, biasanya itu tidak realistis untuk kondisi hari ini, atau tidak terkait keputusan nyata. Perbaiki dua hal itu dulu.
Tim kecil mengirim dashboard analytics React dalam seminggu. Awalnya terasa cepat, tapi setiap rilis Jumat membuatnya sedikit lebih berat. Setelah sebulan, pengguna mulai bilang layar pertama “nge-hang” dan filter terasa laggy.
Mereka berhenti berdebat tentang “cukup cepat” dan menuliskan anggaran yang terkait dengan apa yang diperhatikan pengguna:
Pelanggaran pertama muncul di dua tempat. Bundle JS awal membengkak karena chart, library tanggal, dan UI kit ditambahkan. Pada saat sama, header dashboard diganti dengan file yang lebih besar “sementara,” mendorong LCP melewati batas. INP memburuk karena tiap perubahan filter memicu re-render berat dan perhitungan mahal di main thread.
Mereka memperbaiki sesuai urutan yang menghasilkan kemenangan cepat dan mencegah regresi berulang:
Kembalikan LCP di bawah batas dengan mengubah ukuran dan mengompres gambar, menetapkan dimensi gambar eksplisit, dan menghindari font blocking pada tampilan pertama.
Potong JS awal dengan menghapus library yang tak dipakai, memecah route non-kritis, dan lazy-load chart.
Perbaiki INP dengan memoize komponen mahal, debounce input filter, dan memindahkan kerja berat dari jalur panas.
Tambahkan pemeriksaan anggaran ke setiap rilis sehingga jika metrik rusak, rilis menunggu.
Setelah dua rilis, LCP turun dari 3.4s ke 2.3s, dan INP membaik dari ~350ms ke di bawah 180ms pada perangkat uji yang sama.
Anggaran hanya membantu jika orang bisa mengikutinya dengan cara yang sama setiap kali. Jaga kecil, tulis, dan jadikan bagian dari pengiriman.
Pilih beberapa metrik yang cocok untuk aplikasi Anda, tetapkan ambang “peringatan vs gagal”, dan dokumentasikan tepat bagaimana Anda menguji (perangkat, browser, jaringan, halaman/alur). Simpan laporan baseline dari rilis terbaik saat ini dan beri label jelas. Putuskan apa yang dihitung sebagai pengecualian yang valid dan apa yang tidak.
Sebelum setiap rilis, jalankan audit yang sama dan bandingkan dengan baseline. Jika ada regresi, catat di tempat Anda melacak bug dan perlakukan seperti langkah checkout yang rusak, bukan tugas "nanti". Jika Anda mengirim dengan pengecualian, rekam pemilik dan tanggal kedaluwarsa (sering 1–2 sprint). Jika pengecualian terus diperpanjang, anggaran perlu dibahas ulang.
Pindahkan anggaran lebih awal ke perencanaan dan estimasi: “Layar ini menambah library chart, jadi kita perlu menghapus sesuatu atau lazy-load.” Jika Anda membangun dengan Koder.ai (Koder.ai), Anda juga bisa menulis batasan ini di Planning Mode, lalu iterasi dalam potongan kecil dan gunakan snapshot serta rollback saat perubahan mendorong aplikasi melewati batas. Intinya bukan alatnya, melainkan kebiasaan: setiap fitur baru harus membayar biayanya, atau tidak dikirim.
A performance budget adalah seperangkat batas keras (waktu, ukuran, jumlah permintaan, kerja CPU) yang disepakati tim sebelum pembangunan dimulai.
Jika sebuah perubahan melewati batas itu, perlakukan seperti persyaratan yang rusak: perbaiki, kurangi scope, atau setujui pengecualian dengan pemilik dan tanggal kedaluwarsa.
Karena performa memburuk secara bertahap. Setiap fitur menambah JavaScript, CSS, gambar, font, panggilan API, dan tag pihak ketiga.
Anggaran menghentikan penurunan itu dengan memaksa trade-off: jika Anda menambah beban atau kerja, Anda harus membayarnya kembali (lazy-load, bagi route, sederhanakan UI, hapus dependensi).
Pilih satu perjalanan pengguna nyata dan satu setup pengujian yang konsisten.
Contoh yang baik: hal yang sering dan penting untuk bisnis, seperti:
Hindari kasus tepi di awal; Anda butuh alur yang bisa diukur setiap rilis.
Mulailah dengan satu target yang mewakili pengguna tipikal, misalnya:
Tuliskan dan stabilkan itu. Jika Anda mengubah perangkat, jaringan, cache, atau path pengujian, tren Anda akan menjadi berisik.
Gunakan set kecil yang mencakup apa yang dirasakan pengguna dan apa yang bisa dikendalikan tim:
Metrik timing menunjukkan rasa sakit; batas ukuran dan runtime membantu menemukan penyebabnya dengan cepat.
Set starter yang praktis:
Gunakan dua ambang:
Ini menghindari kepanikan terus-menerus namun tetap membuat batasnya nyata saat dilanggar.
Lakukan urutan ini:
Tidak selalu berkaitan dengan ukuran bundle. Aplikasi bisa terasa lambat karena main thread sibuk.
Penyebab React umum:
Tambahkan anggaran runtime (mis. batasi long tasks saat startup atau tetapkan batas waktu hidrasi) untuk menangkap masalah ini.
Iterasi cepat bisa menambahkan dependensi, hiasan UI, dan skrip pihak ketiga yang tersebar ke semua pengguna.
Solusinya: jadikan anggaran bagian dari workflow:
Ini menjaga iterasi cepat tetap menghasilkan produk yang cepat.
Pilih 3–5 anggaran dulu. Sesuaikan setelah melihat baseline dan riwayat rilis.
Perlakukan pelanggaran seperti bug: cari commit penyebab, perbaiki atau kurangi scope, dan cegah pengulangan.
