Latency Budget: Cara Marketer dan Developer Indonesia Sepakat Soal Kecepatan Website

TL;DR: Latency budget memecah target Core Web Vitals menjadi alokasi waktu eksplisit per tahap (DNS, TTFB, render, image). Marketer dapat target yang dapat dipertanggungjawabkan, developer dapat batasan teknis yang jelas, dan negosiasi fitur baru menjadi soal trade-off, bukan opini. Tim kecil tanpa budget cenderung kehilangan 0,5-1,2 detik LCP per kuartal akibat akumulasi fitur tanpa kontrol.

Di banyak project klien yang saya tangani, konflik klasik antara marketer dan developer tidak pernah soal kecepatan website. Konfliknya selalu soal definisi cukup cepat. Marketer ingin animasi hero baru karena tim brand bilang itu wow factor. Developer menolak karena akan menambah 600 ms ke LCP. Tanpa kerangka bersama, diskusi berakhir dengan keputusan politik, bukan teknis.

Latency budget memecah kebuntuan ini. Saat tim sepakat di awal bahwa LCP harus di bawah 2,5 detik dan render image punya alokasi 1,2 detik, permintaan tambahan 600 ms berubah dari opini jadi math. Yang menarik, bahkan stakeholder non-teknis mulai paham trade-off setelah melihat pemecahan ini.

Kenapa Target Tunggal Tidak Cukup

Mengatakan situs harus lulus Core Web Vitals adalah target yang bagus untuk presentasi, tapi buruk untuk eksekusi harian. Tim tidak tahu siapa bertanggung jawab atas apa. DNS lambat itu masalah hosting atau frontend? TTFB tinggi karena database atau CDN? Tanpa pemecahan, blame game muncul setiap kali angka turun.

Budget yang eksplisit menyelesaikan ini. Setiap tahap punya owner dan alokasi. Saat budget terlewati, percakapan menjadi: tahap mana yang membengkak, kenapa, dan apa pilihan untuk mengembalikan ke jalur. Lihat panduan resmi soal Web Vitals di web.dev.

Anatomi Latency Budget

Untuk target LCP 2,5 detik di koneksi mobile 4G Indonesia, pemecahan praktis yang saya pakai:

Total: 2500 ms. Buffer 400 ms penting karena lab test selalu lebih optimis dari CrUX data yang dipakai Google untuk ranking. Tanpa buffer, tim akan terus lulus di Lighthouse tapi gagal di field data.

Studi Kasus: Vetmo dan Disiplin Budget

Saat membangun website Vetmo di kuartal pertama 2025, tim menyepakati budget LCP 2,2 detik (lebih ketat dari standar Google). Di tengah project, tim brand minta tambahan video autoplay di hero. Estimasi developer: tambah 800 ms.

Diskusinya jadi konkret. Pilihan A: turunkan kualitas video ke poster image dan defer load. Pilihan B: hapus salah satu komponen di fold yang menelan 300 ms. Pilihan C: minta perpanjangan budget jadi 2,5 detik dan terima risiko ranking. Tim akhirnya pilih B karena video memang krusial untuk konversi adopsi pet, sementara komponen yang dihapus adalah testimonial yang bisa pindah ke section bawah.

Kuncinya: tanpa budget eksplisit, diskusi ini akan jadi marketer vs developer, bukan analisis trade-off. Lihat juga studi kasus Vetmo lengkap untuk konteks bisnisnya.

Pertanyaan Umum

Apakah latency budget berlaku untuk Next.js dan static site?

Ya. Bahkan untuk SSG, budget tetap relevan karena CDN, font, dan image tetap memengaruhi LCP. Static tidak otomatis berarti cepat, hanya menghilangkan TTFB tinggi.

Bagaimana jika tim sangat kecil dan tidak punya developer?

Mulai dari 3 alokasi saja: TTFB (kontrol via hosting), LCP image (kontrol via Next.js Image atau Cloudinary), dan total payload (kontrol via plugin yang dipakai). Lebih sederhana lebih baik daripada tidak ada budget sama sekali.

Kapan budget harus direvisi?

Review kuartalan, atau setiap kali ada major redesign. Budget yang tidak pernah direvisi akan jadi kabuki, dipakai untuk justifikasi tapi tidak benar-benar mengarahkan keputusan.

Apakah ini kompatibel dengan A/B test?

Sangat kompatibel. Justru variant baru harus lulus budget sebelum dikirim ke production test. Banyak A/B test yang gagal bukan karena copy-nya salah, tapi karena variant menambah 400 ms latency yang menggerus konversi.

Mulai dari Satu Halaman

Tidak perlu menerapkan budget ke seluruh situs sekaligus. Pilih halaman yang paling penting untuk konversi (homepage, landing campaign, halaman pricing) dan susun budget untuk halaman itu. Pelajaran dari implementasinya akan menjadi template untuk halaman lain. Yang paling sulit bukan menyusun angkanya, tapi membangun budaya tim yang menghormatinya saat ada permintaan baru.