Studi Kasus Atmo LMS: Pakai On-Demand ISR dengan revalidateTag Pangkas Waktu Publish dari 45 Menit ke 6 Detik di 2026

TL;DR: Atmo LMS sebelumnya menunggu cron 45 menit setiap admin menerbitkan materi baru. Dengan on-demand ISR memakai revalidateTag pada Next.js App Router, waktu propagasi turun ke 6 detik median per April 2026, tanpa menambah biaya server karena halaman tetap dilayani dari edge CDN.

Saat kuartal pertama 2026, tim Atmo LMS mengeluh konten baru yang sudah diterbitkan instruktur tidak segera muncul di katalog. Penyebabnya bukan teknologi, melainkan strategi cache awal yang memakai ISR berbasis interval 2700 detik. Pengguna akhir baru melihat materi setelah cron jalan. Tujuan refactor ini sederhana, propagasi cepat tanpa kehilangan keunggulan static rendering.

Konteks Pipeline Sebelumnya

Versi lama menggunakan generateStaticParams plus revalidate: 2700. Ketika ada materi baru, halaman /kursus dan /kursus/[slug] hanya direfresh setiap 45 menit. Hasilnya bagus untuk TTFB, tetapi buruk untuk pengalaman editor yang ingin melihat hasil publikasinya seketika. Sinyal ini juga memengaruhi SEO karena Googlebot kadang melihat versi lama saat re-crawl.

Diagnosa: Mismatch Kebutuhan dan Strategi Cache

Saya memetakan kebutuhan tim dalam tiga kategori, dengan toleransi staleness berbeda.

Toleransi staleness ditetapkan bersama tim konten, bukan asumsi engineer. Pendekatan ini selaras dengan rekomendasi Next.js docs tentang revalidateTag.

Solusi: On-Demand ISR dengan revalidateTag

Implementasi inti ada di tiga lapisan. Pertama, fetch di server component diberi tag eksplisit. Kedua, server action publish memanggil revalidateTag setelah insert berhasil. Ketiga, webhook backup dipasang sebagai jaring pengaman jika admin publish dari panel non-Next.js. Pendekatan ini saya bahas lebih dalam di glosarium on-demand ISR dan revalidate-tag.

Snippet inti:

await fetch('https://api.atmo.id/courses', { next: { tags: ['kursus-list'] } });

export async function publishCourse(form: FormData) {
  await db.courses.insert({ ... });
  revalidateTag('kursus-list');
  revalidateTag('kursus-detail');
}

Catatan penting, server action harus dijalankan di environment Node, bukan edge, agar interaksi dengan Supabase aman.

Hasil yang Diukur

Pengukuran dilakukan dengan tracking custom event dari panel admin Atmo, lalu dibandingkan via field data di CrUX.

Biaya egress hanya naik tipis karena halaman tetap dilayani dari cache CDN sebagian besar waktu. Angka di atas berdasarkan data internal Atmo LMS Mei 2026 dan dapat berbeda di skala traffic lain.

Pelajaran untuk Tim Lain

Refactor ini berhasil bukan karena teknologi rumit, melainkan kesepakatan toleransi staleness. Marketer dan editor sering ingin instan, sementara engineer berpikir efisiensi. Tabel toleransi di atas menjadi alat komunikasi yang netral. Strategi cache yang baik adalah strategi yang disetujui kedua sisi, lalu dipantau via observability.

Pertanyaan Umum

Apakah on-demand ISR menggantikan revalidate berbasis waktu?

Tidak menggantikan. Keduanya saling melengkapi. Gunakan revalidate berbasis waktu untuk halaman yang jarang berubah, dan on-demand untuk halaman editorial.

Bagaimana jika webhook gagal?

Pasang fallback revalidate berbasis waktu dengan interval longgar, misalnya 1 jam. Pendekatan ini memastikan halaman tetap segar meski webhook gagal sekali dua kali.

Apakah ini aman untuk Supabase RLS?

Aman, asal pemanggilan revalidateTag dilakukan dari server action yang sudah memvalidasi sesi pengguna.

Penutup

On-demand ISR bukan sekadar trik performa, tetapi alat komunikasi antara tim teknis dan tim konten. Saat ekspektasi propagasi disepakati lebih dulu, implementasinya menjadi sederhana. Atmo LMS membuktikan bahwa pemangkasan dari 45 menit ke 6 detik cukup dicapai dengan satu fungsi standar Next.js, bukan rewrite besar.