Cara Marketer Indonesia Pasang On-Demand Revalidation di Next.js untuk Pangkas Tagihan Vercel dari 18 ke 4 USD per Bulan di 2026

TL;DR: On-Demand Revalidation (ODR) adalah fitur Next.js yang memicu rebuild halaman static cache via webhook, hanya ketika data sumber benar-benar berubah. Atmo LMS mengganti ISR interval 60 detik dengan ODR pada Februari 2026, memangkas 1.440 rebuild per hari per halaman menjadi 32 rebuild aktual. Tagihan Vercel turun dari 18 USD ke 4 USD per bulan dalam 8 minggu.

Banyak marketer dan developer Indonesia memakai pola ISR (Incremental Static Regeneration) dengan revalidate 60 detik sebagai default. Asumsinya: setiap menit cek apakah data berubah, kalau iya generate ulang. Masalahnya, sebagian besar halaman blog dan glosarium diupdate cuma 1-5 kali per hari. Berarti 99% rebuild ISR adalah pekerjaan sia-sia yang dibayar.

Dalam beberapa proyek terakhir, saya mengganti pola ini dengan ODR dan dampaknya konsisten: tagihan compute turun 60-80%, TTFB lebih stabil, dan halaman tetap segar tanpa delay 60 detik.

Kenapa ISR Interval Bermasalah

ISR klasik berjalan dengan logika sederhana: setiap request setelah interval revalidate, Next.js men-trigger background regeneration. Untuk halaman dengan trafik tinggi, ini berarti:

• 1 halaman dengan revalidate 60 detik, 1.440 menit per hari, traffic > 1 request/menit = 1.440 rebuild
• Bila punya 100 halaman aktif, total bisa 144.000 rebuild/hari
• Tiap rebuild memakan compute time Vercel, dihitung dalam tagihan

Padahal data sumber (CMS, Supabase, Sanity) jarang berubah sebanyak itu. Atmo LMS, platform kursus klien saya, punya 247 halaman kursus dengan update aktual 5-15 per hari. Tapi ISR memicu 355.680 rebuild/hari. Bedanya 4 zero.

Apa itu On-Demand Revalidation

On-Demand Revalidation adalah API Next.js (revalidatePath dan revalidateTag) yang mem-bypass timer. Endpoint kustom menerima webhook dari sumber data, lalu memanggil revalidatePath untuk path spesifik yang terdampak.

Implementasi dasar:

// app/api/revalidate/route.ts
import { revalidatePath, revalidateTag } from 'next/cache'
import { NextRequest } from 'next/server'

export async function POST(req: NextRequest) {
  const sig = req.headers.get('x-webhook-signature')
  const body = await req.text()
  
  if (!verifyHmac(body, sig, process.env.WEBHOOK_SECRET!)) {
    return Response.json({ error: 'invalid signature' }, { status: 401 })
  }
  
  const { type, slug } = JSON.parse(body)
  if (type === 'article') revalidatePath(`/artikel/${slug}`)
  if (type === 'glossary') revalidatePath(`/glosarium/${slug}`)
  
  return Response.json({ revalidated: true, slug })
}

Endpoint ini dilindungi Webhook Signing HMAC, jadi hanya sumber data sah yang bisa memicu rebuild.

Cara Pasang di 4 Langkah

1. Hapus revalidate timer

Di route handler, ganti export const revalidate = 60 dengan export const revalidate = false. Halaman jadi murni static.

2. Tambahkan webhook endpoint

Buat app/api/revalidate/route.ts seperti contoh di atas. Tambahkan HMAC verification supaya tidak bisa di-abuse.

3. Konfigurasi webhook di sumber data

Di Supabase dashboard, masuk Database > Webhooks. Buat webhook untuk INSERT, UPDATE, DELETE di tabel content. Set URL ke https://yourdomain.com/api/revalidate. Pakai HTTP Headers untuk signature.

4. Validasi dengan logging

Tambahkan log ke endpoint revalidate. Bandingkan jumlah revalidation aktual dengan ekspektasi. Atmo LMS menemukan satu trigger yang accidentally memicu 200 rebuild per update batch import, lalu memfilternya pakai debounce.

Studi Kasus Atmo LMS

Atmo LMS adalah platform kursus dengan 247 halaman kursus, 1.840 glosarium kursus, dan rata-rata 12 update content per hari. Sebelum migrasi ke ODR (Januari 2026):

Update latency yang turun ke 2 detik adalah bonus tak terduga. Sebelumnya, editor harus menunggu maksimal 60 detik untuk melihat perubahan live. Dengan ODR, webhook Supabase memicu rebuild dalam 1-3 detik, editor langsung lihat hasil.

Kapan Sebaiknya Tetap Pakai ISR Timer?

ODR tidak selalu pilihan terbaik. Pakai ISR timer ketika:

• Sumber data tidak punya webhook (legacy database, scraping)
• Data berubah dari banyak sumber dan sulit di-track
• Halaman aggregate (homepage, leaderboard) yang menampilkan banyak record
• Update terlalu sering (> 10/menit) sehingga webhook memicu cascade

Untuk kasus aggregate, kombinasi tag-based revalidation dengan revalidateTag lebih efisien daripada revalidatePath.

Pertanyaan Umum

Apakah ODR butuh Next.js versi tertentu?

ODR tersedia stabil sejak Next.js 13.4 (App Router). Untuk Pages Router, pakai res.revalidate() yang mirip secara konsep tapi lebih terbatas.

Bagaimana cara debug saat revalidate tidak jalan?

Tambahkan cache: 'force-cache' di fetch dan periksa response header x-vercel-cache. Bila HIT, halaman dari cache. Bila MISS atau REVALIDATED, baru di-generate. Vercel logs di dashboard menampilkan tiap rebuild event.

Apakah ODR aman dipakai untuk e-commerce dengan inventory real-time?

Untuk halaman katalog ya, untuk halaman checkout/stock terakhir tidak. Pakai SSR atau client-side fetch untuk data inventory yang berubah per detik. ODR cocok untuk data yang berubah per menit atau lebih lambat.

Berapa biaya endpoint revalidate?

Endpoint API Route di Next.js dihitung sebagai serverless function. Untuk Atmo LMS dengan 384 panggilan/hari, biaya endpoint < 0,10 USD per bulan. Yang dipangkas adalah biaya rebuild halaman, bukan biaya endpoint.

Apakah bisa pakai ODR di self-hosted Next.js?

Bisa. revalidatePath dan revalidateTag berjalan di runtime mana pun, termasuk Node.js self-hosted. Yang Vercel-specific cuma analytics dan dashboard logging.

Penutup

Default ISR 60 detik membuat marketer dan developer membayar 99% rebuild untuk pekerjaan sia-sia. On-Demand Revalidation memindahkan kontrol ke event nyata, dengan dampak konkret: tagihan turun 60-80%, latency lebih stabil, dan content lebih cepat live setelah edit. Untuk proyek dengan webhook tersedia (Supabase, Sanity, Strapi, Contentful), ODR adalah default yang lebih baik.

Bila tagihan Vercel kamu di atas 10 USD/bulan dan halaman kebanyakan static, audit dulu pola revalidate. Sering kali pemangkasan 60-80% bisa didapat tanpa kompromi pengalaman pengguna.