ThemesCorners
Blog
12 menit bacaoleh ThemesCorners

Headless WordPress dengan Next.js — Panduan Pragmatis

Kapan headless, kapan tidak, dan stack persis yang kami pakai saat bilang ya.

Kami dapat pertanyaan ini sekali seminggu: "Haruskah kami buat situs WordPress kami headless dengan Next.js?" Jawaban jujurnya adalah "kemungkinan tidak, tapi inilah kapan ya dan bagaimana." Tulisan ini jawaban itu lengkap.

Apa sebenarnya "headless"

Di setup WordPress tradisional, WordPress menghasilkan HTML yang dilihat pengunjung. PHP yang sama yang menjalankan admin juga me-render halaman publik.

Di setup headless, WordPress hanya menyajikan data — melalui REST API atau WPGraphQL. Frontend terpisah (Next.js, Astro, SvelteKit, Nuxt — tapi paling umum Next.js) mengambil data itu dan me-render situs publik.

Anda pertahankan:

  • Pengalaman editor WordPress untuk author konten
  • Ekosistem plugin untuk fungsionalitas backend (WooCommerce, ACF, dll.)

Anda lepaskan:

  • Live preview yang "tinggal jalan"
  • Sebagian besar plugin WordPress frontend (page builder, banner cookie, popup)
  • Output frontend beberapa plugin SEO (Anda harus implementasi ulang)

Anda dapat:

  • Situs publik jauh lebih cepat (biasanya 60–80% peningkatan LCP)
  • Workflow developer modern (TypeScript, hot reload, library komponen)
  • Deployment terpisah — frontend dan backend rilis independen
  • Frontend dapat di-deploy ke host modern mana pun (Vercel, Netlify, Cloudflare Pages)

Kapan headless

Skenario jujur di mana matematika bekerja:

Ya — publikasi atau situs konten berlalu lintas tinggi

Kalau Anda publikasi banyak, dapat banyak trafik, dan perlu optimasi Core Web Vitals, headless menang. Gap performa antara WordPress PHP ter-cache dan frontend Next.js yang dibangun benar nyata dan dapat diukur.

Ya — konten multi-channel (web + app mobile + suara)

Kalau Anda juga memberi konten yang sama ke app mobile, smart speaker, atau integrasi partner, headless memungkinkan Anda melayani semua consumer dari API yang sama. Mencoba ekstrak data dari instalasi WordPress tradisional untuk pemakaian non-web menyakitkan.

Ya — design system mensyaratkan komponen React

Kalau brand Anda punya library komponen React dan Anda mau konten WordPress di-render lewatnya, headless adalah jawaban paling bersih.

Mungkin — situs korporat dengan tim dev kuat

Kalau Anda punya engineer yang tahu React dan lebih suka kerja di Next.js daripada PHP, headless masuk akal bahkan tanpa argumen performa. Kebahagiaan developer Anda input nyata.

Kapan JANGAN headless

Sama jujurnya:

Tidak — situs bisnis kecil tipikal

Kalau situs Anda brosur 20 halaman dengan blog dan form kontak, headless lebih banyak kerja daripada nilainya. Kombinasi WordPress tradisional + tema bagus mendapat 90% performa headless dengan 10% kompleksitas.

Tidak — toko WooCommerce

Ini kasus paling sulit. WooCommerce punya ratusan touchpoint frontend — update cart, alur checkout, integrasi payment gateway, manajemen subscription. Mengimplementasi ulang semua itu di frontend headless adalah berbulan-bulan kerja, dan Anda dapat sesuatu yang halus-lebih-buruk dari yang WooCommerce kirim default. Pakai WooCommerce Blocks saja.

Tidak — editor yang bergantung pada live preview

Kalau author Anda hidup di live preview ("ganti kata, refresh, lihat"), headless akan membuat mereka frustrasi. Preview di setup headless selalu sedikit terlambat — by design.

Tidak — ketergantungan plugin berat

Lihat plugin aktif Anda. Apakah Anda bergantung pada yang inject output frontend (UI tweak Yoast, runtime page builder, popup Mailchimp, widget chat)? Masing-masing tugas migrasi terpisah di headless. Kalau lebih dari lima, biaya migrasi membengkak.

Stack yang kami pakai

Saat kami bilang ya ke headless, inilah stack persisnya:

Backend (WordPress)

  • WordPress dengan editor, WPGraphQL, dan plugin frontend minimal.
  • Advanced Custom Fields dengan jembatan ACF + WPGraphQL untuk konten terstruktur.
  • WP Migrate DB Pro atau serupa untuk sync environment.
  • Tidak ada plugin frontend. Matikan apa pun yang menghasilkan HTML untuk situs publik — tidak ada situs publik untuk WordPress render.
  • Host di paket managed WP kecil ($20–35/bulan sudah cukup — beban jauh lebih rendah).

Frontend (Next.js)

  • Next.js 16+ dengan App Router dan Cache Components.
  • TypeScript, Tailwind CSS v4, shadcn/ui untuk komponen.
  • next-mdx-remote kalau sebagian konten hidup di MDX di samping WordPress.
  • Host di Vercel (atau Cloudflare Pages, atau Netlify).

Strategi caching

Bagian paling rumit. Caching headless berlapis:

  1. Static generation untuk halaman yang jarang berubah (about, contact, archive).
  2. Cache Components (Next 16) untuk halaman yang sesekali berubah dengan tag per halaman.
  3. On-demand revalidation dipicu webhook WordPress — saat post terbit, hit endpoint Next.js yang panggil revalidateTag('post-123').
  4. Background refresh untuk beranda dan halaman trafik tinggi via cron.

Autentikasi untuk preview

Satu-satunya cara membuat preview tidak menyebalkan adalah set up route preview ter-autentikasi:

// app/preview/route.ts
import { draftMode } from 'next/headers';

export async function GET(req: Request) {
  const url = new URL(req.url);
  const secret = url.searchParams.get('secret');
  const slug = url.searchParams.get('slug');
  if (secret !== process.env.PREVIEW_SECRET) {
    return new Response('Invalid token', { status: 401 });
  }
  draftMode().enable();
  return Response.redirect(new URL(`/blog/${slug}`, req.url));
}

Lalu tambahkan tombol kustom di admin WordPress yang mengarah ke /preview?secret=...&slug=... per post.

Sekuens migrasi

Untuk situs existing yang ingin Anda headless-kan:

  1. Audit tipe konten. Katalogkan setiap post type, custom field, dan taxonomy yang perlu di-render. Apa pun yang hilang dari daftar ini akan hilang di frontend baru.
  2. Audit plugin frontend. Buat daftar setiap plugin yang memancarkan HTML, JS, atau CSS ke situs publik. Masing-masing tugas re-implementasi.
  3. Bangun frontend paralel. Situs Next.js di subdomain (mis. next.example.com), rendering konten penuh, belum ada trafik.
  4. Jalankan keduanya paralel minimal 30 hari. Bandingkan analytics, conversion rate, error rate side by side.
  5. Switch DNS hanya setelah parity terbukti. Pertahankan wp-admin WordPress dapat diakses di admin.example.com.
  6. Monitor 90 hari sebelum mendeklarasikan sukses. Beberapa breakage hanya muncul di tugas kuartalan.

Ringkasan jujur

Headless WordPress teknologi indah untuk sedikit situs yang benar-benar butuh. Untuk yang lain, situs WordPress tradisional yang dibangun baik dengan tema cepat (seperti milik kami) memberi Anda 90% manfaat dengan sebagian kecil kompleksitas.

Putuskan berdasarkan alur kerja editorial aktual dan gap performa aktual — bukan karena headless terdengar lebih modern. Memang lebih modern. Juga lebih banyak kerja.

Artikel terkait