Arsitektur island — kenapa Astro, bukan Next

Portal berita adalah kasus terbaik untuk Astro dan kasus terburuk untuk SPA. Alasannya bukan selera — ia turun langsung dari bentuk trafikmu.

Perbandingan yang sebenarnya

Framework modern membagi diri berdasarkan apa yang dikirim ke browser. Tiga jawaban yang berbeda:

Kenapa ini penting justru di trafik besar

Bayangkan halaman artikel di portalmu. Isinya: judul, byline, tanggal, badan artikel, gambar, daftar artikel terkait, dan — di kaki halaman — satu widget "berita terpopuler" yang bisa difilter per periode.

Di framework hidrasi penuh, seluruh pohon komponen itu dikirim sebagai JavaScript dan dijalankan ulang di browser hanya supaya widget terpopuler di kaki halaman bisa diklik. Pembaca membayar 200–400 KB JavaScript untuk membaca teks yang sudah ada di HTML.

Di Astro, yang dikirim adalah HTML, ditambah JavaScript untuk widget itu saja — biasanya belasan kilobyte. Sisanya tidak pernah menjadi JavaScript sama sekali:

---
import Layout from "../layouts/Artikel.astro";
import BadanArtikel from "../components/BadanArtikel.astro";
import Terpopuler from "../components/Terpopuler.vue";

const artikel = await ambilArtikel(Astro.params.slug);
---
<Layout judul={artikel.judul}>
  <BadanArtikel artikel={artikel} />

  <!-- Ini satu-satunya yang jadi JavaScript di halaman ini -->
  <Terpopuler client:visible />
</Layout>

BadanArtikel.astro tidak punya runtime. Ia dijalankan sekali saat render dan hasilnya HTML. Terpopuler.vue punya runtime, dan client:visible menyuruh Astro mengirim JavaScript-nya hanya saat komponen itu masuk viewport — jadi pembaca yang tidak pernah menggulir sampai kaki halaman tidak pernah mengunduhnya.

Konsekuensi yang paling menentukan untuk kasusmu

Bandingkan dengan CI3-mu sekarang: tiap pembaca anonim yang membuka artikel yang sama tetap membangunkan PHP, membuka sesi, dan memukul MySQL. Perbedaannya bukan "Astro lebih cepat dari PHP" — dua-duanya cepat kalau diukur per request. Perbedaannya adalah berapa banyak request yang sampai ke origin sama sekali.

Lalu bagaimana dengan paywall?

Ini keberatan pertama yang wajar: kalau halamannya di-cache dan sama untuk semua orang, bagaimana membedakan member dan non-member?

Jawabannya server islands — pulau yang dirender di server, per pembaca, setelah kerangka halamannya sudah sampai. Kerangkanya tetap di-cache; hanya blok kecil itu yang dinamis:

<BadanArtikel artikel={artikel} potong={artikel.premium} />

<!-- Dirender di server, per pembaca, di luar cache halaman -->
<GerbangPaywall server:defer artikelId={artikel.id}>
  <div slot="fallback" class="paywall-skeleton">Memuat…</div>
</GerbangPaywall>

Ini dibahas tuntas di Fase 1 dan Fase 5. Yang perlu kamu bawa dari sini cuma satu kalimat: halaman bisa tetap cacheable meski isinya berbeda antar pembaca — dan itulah yang tidak bisa dilakukan CI3 tanpa menulis ulang cara sesinya bekerja.

Kapan Astro justru pilihan yang salah

Portalmu ada di sisi yang benar: mayoritas mutlak trafiknya adalah pembaca anonim membaca satu artikel lalu pergi. Bagian "aplikasi"-nya — dashboard member, riwayat tagihan, filter data perusahaan — nyata tapi kecil, dan itu tepat yang dilayani island.

Empat direktif hidrasi yang akan kamu pakai

client:only adalah yang paling sering disalahgunakan. Ia melewati render server sepenuhnya, jadi isinya tidak ada di HTML — artinya tidak terbaca mesin pencari dan menimbulkan pergeseran tata letak saat muncul. Untuk portal berita yang hidup dari SEO, pakai hanya kalau memang tidak ada jalan lain.