Core Web Vitals Budget untuk Marketer Indonesia 2026: Kerangka 4 Angka yang Wajib Disepakati dengan Developer di Proyek Next.js

TL;DR: Core Web Vitals budget adalah ambang batas performa yang disepakati di awal proyek antara marketer dan developer. Empat angka utama: LCP di bawah 2,5 detik, INP di bawah 200 ms, CLS di bawah 0,1, dan JavaScript bundle di bawah 170 KB. Tanpa budget eksplisit, optimasi performa jadi argumen tanpa ujung.

Dalam 3 proyek website terakhir yang saya kerjakan di awal 2026, ada satu pola yang berulang. Marketer bilang "tolong dibuat cepat", developer balas "sudah saya optimasi". Tiga bulan kemudian skor PageSpeed turun, traffic organik anjlok, tidak ada yang bisa ditunjuk tanggung jawabnya. Akar masalahnya: tidak pernah ada angka spesifik yang disepakati di awal.

Solusinya: Core Web Vitals budget. Ini bukan dokumen panjang, cukup 4 angka yang dipasang di file lighthouse-budget.json dan dijalankan otomatis di CI/CD setiap pull request. Artikel ini menjelaskan kerangka 4 angka tersebut, kenapa dipilih, dan cara memasangnya di proyek Next.js.

Empat Angka Wajib

Tim Atmo LMS yang saya kelola di awal 2026 memakai 4 ambang batas berikut. Angka ini sesuai standar Google "good" threshold dan terbukti realistis untuk situs konten dengan backend Supabase.

Bundle JavaScript bukan bagian resmi Core Web Vitals, tapi punya korelasi kuat dengan ketiganya. Bundle gemuk berarti main thread sibuk, INP melambat, dan LCP mundur karena hydration lama. Tetapkan budget bundle supaya tidak ada library besar yang masuk diam-diam.

Kenapa Sepakat di Awal, Bukan di Akhir

Optimasi performa di akhir proyek 3 sampai 5 kali lebih mahal dibanding di awal. Saya pernah memperbaiki LCP 5,8 detik menjadi 1,9 detik di sebuah situs e-commerce, butuh refactor image strategy, font loading, dan code splitting selama 6 minggu. Kalau budget ditetapkan di awal dan dimonitor per pull request, perbaikan ukurannya cuma 1 sampai 2 hari per masalah.

Kesepakatan ini juga melindungi marketer dari permintaan tambahan yang merusak performa. Saat tim ingin pasang chat widget pihak ketiga seberat 80 KB, jawaban "ini akan membuat bundle melebihi budget" lebih kuat dari "ini akan memperlambat situs".

Cara Memasang di Next.js

Saya pakai 3 alat yang saling melengkapi di proyek Next.js 2026:

Pertama, next.config.ts mengaktifkan tracking Web Vitals di production. Pakai experimental.webVitalsAttribution untuk mendapat detail LCP sub-parts supaya bisa tahu mana yang lambat: TTFB, resource load, atau render delay.

Kedua, Lighthouse CI dijalankan di GitHub Actions setiap pull request. File lighthouse-budget.json berisi 4 angka tadi. Kalau gagal, PR diblokir.

Ketiga, Real User Monitoring pakai library web-vitals v4 yang dikirim ke endpoint internal. Lab data Lighthouse berguna untuk regresi, tapi data lapangan yang menentukan pengalaman pengguna sebenarnya. Tim Atmo LMS memantau metrik mingguan di dashboard internal supaya marketer dan developer punya bahasa yang sama.

Cara Diskusi dengan Developer

Saat menyampaikan budget ini ke developer, hindari frame "tolong yang cepat". Pakai bahasa konkret: "Kita target LCP di bawah 2,5 detik, INP di bawah 200 ms, CLS di bawah 0,1, bundle di bawah 170 KB. Apa konsekuensi terhadap arsitektur yang kamu rencanakan?". Pertanyaan ini menghormati keahlian developer dan memaksa diskusi trade-off di awal.

Trade-off yang sering muncul: animasi kompleks vs INP, font web custom vs LCP, third-party script analitik vs CLS. Marketer perlu siap merelakan sebagian "nice to have" demi target performa yang disepakati.

Pertanyaan Umum

Apa beda LCP dan FCP, mana yang lebih penting?

LCP mengukur waktu sampai elemen konten terbesar muncul, FCP mengukur konten pertama apapun. LCP lebih penting karena merepresentasikan pengalaman pengguna melihat konten utama. Google sudah menjadikan LCP bagian Core Web Vitals, FCP hanya metrik pendukung.

Berapa biaya tambahan untuk memasang budget ini di proyek baru?

Hampir nol kalau dipasang di awal. File konfigurasi Lighthouse Budget kurang dari 30 baris, GitHub Actions gratis untuk repo publik, library web-vitals open source. Biaya muncul kalau ada library besar yang harus diganti supaya muat di budget bundle.

Apa terjadi kalau salah satu budget terlampaui?

Kalau dipasang di CI, pull request akan gagal sampai diperbaiki. Tim Atmo LMS punya kebijakan: budget hanya boleh dilonggarkan setelah diskusi mingguan, bukan diam-diam di PR individual. Ini menjaga akuntabilitas.

Apakah Next.js 15 sudah optimal default untuk Core Web Vitals?

Default-nya bagus, terutama dengan App Router dan static generation. Tapi developer masih bisa membuat kesalahan: gambar tanpa dimensi, third-party script blocking, atau client component berlebihan. Budget membantu mendeteksi sebelum production.

Catatan Penutup

Core Web Vitals budget bukan cuma soal teknis. Ini alat komunikasi yang menghapus ambiguitas antara tim marketing dan teknis. Empat angka di awal proyek menghemat berminggu-minggu argumen di kemudian hari. Mulai dari proyek berikutnya, tetapkan budget sebelum baris kode pertama ditulis. Untuk standar resmi, rujuk ke dokumentasi Web Vitals dari Google.