Migrasi Next.js ke Astro + Hono: Data Sebelum dan Sesudah

Apa yang diukur di catatan ini?

fikran.dev pindah dari Next.js 16 yang dibundel OpenNext menjadi Astro 7 dengan Hono di Cloudflare Workers, dan versi baru dirilis ke produksi pada 30 September 2026 pukul 01:34:59 UTC (08:34 WIB). Artikel ini adalah catatan pengukuran atas situs fikran.dev sendiri, bukan studi kasus klien dan bukan tolok ukur umum Astro melawan Next.js. Pada pengukuran lab lokal, JavaScript per halaman turun hampir separuh (beranda dari 243 menjadi 136 KB gzip, sekitar 44 persen) dan skor Lighthouse mobile naik di lima template. Namun data lapangan belum tersedia, satu halaman (Belajar AI) justru turun di produksi, dan risiko kegagalan CPU Worker belum bisa dinyatakan selesai.

Semua angka berasal dari catatan internal repositori fikran.dev bertanggal 28 sampai 30 September 2026. Catatan itu belum tersedia sebagai halaman publik, jadi bagian metodologi di bawah menyebut kondisi tiap pengukuran secara terbuka.

Apa latar belakang migrasi ini?

Migrasi dimulai dari keputusan pemilik situs untuk memperbarui stack ke Astro 7 dan Hono. Dua konteks yang menyertainya dicatat di bawah sebagai latar dan hipotesis, bukan sebagai alasan yang sudah terbukti.

• Kegagalan CPU Worker yang berulang. Pemantauan mencatat respons 503 dengan outcome exceededCpu secara intermiten pada runtime lama. Pada 12 September, verifikasi setelah rilis gagal karena 503 batas CPU. Pada 21 September, telemetri mengonfirmasi exceededCpu di rute /og (CPU 10 ms, wall 12 ms), dan pada 28 September di rute /tools (CPU 10 ms, wall 15 ms). Keduanya rute utilitas yang sengaja noindex, dan pengulangan dengan laju rendah kembali menghasilkan 20 dari 20 respons HTTP 200. Jadi kegagalannya intermiten, bukan menyeluruh.
• Konteks batas CPU. Dokumentasi Cloudflare menyebut batas CPU 10 ms per request HTTP pada paket Workers Free, dan waktu menunggu I/O seperti fetch atau kueri database tidak dihitung. Batas pada paket berbayar jauh lebih tinggi. Angka 10 ms di telemetri sama dengan batas Free tersebut; artikel ini tidak mengevaluasi opsi berpindah paket.
• Kompleksitas runtime. Situs lama berjalan sebagai Next.js 16 lewat OpenNext dengan bucket cache tambahan, dan hampir semua halaman adalah satu komponen React klien besar. Hipotesis awal di spesifikasi migrasi: runtime lebih sederhana tanpa OpenNext, lebih banyak HTML statis sehingga CPU Worker per request halaman editorial turun. Itu hipotesis yang harus dibuktikan telemetri, bukan klaim.

Migrasi ini disepakati sebagai parity: tanpa fitur baru, tanpa perubahan URL, dan tanpa perubahan skema data.

Seperti apa arsitektur sesudah migrasi?

• Astro untuk halaman, Hono untuk sisi HTTP. Halaman memakai Astro 7 dengan island React 19. Hono 4 menangani API, media, sitemap, redirect kanonik, dan header keamanan. Hono dirancang di atas Web Standards dan mendukung Cloudflare Workers.
• Entry Worker berbasis Hono. Berkas Worker utama berisi aplikasi Hono yang menjalankan redirect kanonik, header keamanan HTML, penghapusan trailing slash dengan 308, dan penggantian halaman 404, lalu menyerahkan request ke handler Astro. Alasannya, hasil spike menunjukkan adapter Astro menyajikan HTML prerender dan aset statis sebelum pipeline aplikasi berjalan, sehingga middleware biasa tidak pernah menyentuh halaman prerender.
• Prerender dan on-demand. Astro secara bawaan memprerender halaman, dan halaman tertentu dapat dijadikan on-demand dengan opsi prerender bernilai false. Artikel editorial dalam kode dibangun menjadi satu berkas HTML per slug. Halaman yang perlu D1 atau sesi, seperti hub /blog, artikel dari database, admin, dan API, berjalan on-demand. Sebuah middleware memastikan slug editorial dilayani dari HTML statis lebih dulu, dengan biaya satu pencarian aset tambahan per request dinamis.
• run_worker_first. Secara bawaan Cloudflare menyajikan aset yang cocok sebelum menjalankan Worker. Situs ini memakai pola run_worker_first berupa daftar dengan pola negatif, sehingga HTML tetap melewati Worker (agar redirect dan header berlaku) sementara folder aset besar seperti hasil build dan gambar dilayani langsung.
• Header keamanan. Semua respons HTML, termasuk halaman prerender, membawa CSP mode report-only, X-Frame-Options, nosniff, Referrer-Policy, dan Permissions-Policy.
• Binding tidak berubah. D1 dan R2 sama, tanpa migrasi skema dan tanpa binding baru; sesi dan layanan gambar adapter dimatikan agar tidak menambah resource Cloudflare.

Apa yang sengaja dipertahankan?

Tujuan parity adalah tidak mengubah apa yang dilihat pengunjung dan crawler. Sebelum rilis, skrip parity merekam baseline dari build Next.js dan membandingkannya dengan kandidat pada 74 halaman, 26 path edge (redirect, slash ganda, 404, media, metode non-GET), dan 20 probe API. Hasilnya nol perbedaan yang memblokir; 62 perbedaan yang di-allowlist hanya menyangkut header Cache-Control HTML prerender dan berkas XSL. Title, meta, canonical, JSON-LD, H1, dan teks utama dibandingkan per halaman, dan 35 skrip pemeriksaan otomatis dimigrasikan dan lulus. Setelah rilis, verifier produksi memeriksa 60 halaman sitemap dan 32 tautan llms.txt, semuanya lulus.

Perbedaan yang disengaja atau melekat pada framework:

• Cache-Control HTML prerender kini public dengan max-age 0 dan must-revalidate beserta ETag, bukan s-maxage satu tahun dari OpenNext.
• Navigasi antarhalaman kini memuat halaman penuh, bukan soft navigation router klien. Event page_view tetap satu per muatan halaman.
• Body halaman 404 kini dirender di server.
• Produksi lama ternyata menjalankan React 19.3 canary yang dibundel Next, jadi migrasi memakai React 19.3 stabil.

Review akhir juga menemukan satu regresi perilaku redirect akibat migrasi pada penanganan URL berawalan slash ganda. Temuan ini diperbaiki sebelum rilis dan perilaku edge kembali identik dengan baseline. Pelajarannya: kasus tepi redirect perlu masuk ke uji parity, bukan hanya halaman yang tampil normal.

Bagaimana metode pengukurannya?

Ada tiga rangkaian ukur dengan kondisi berbeda. Membandingkannya secara langsung tanpa memahami perbedaannya akan menyesatkan.

• Lab A/B lokal, 29 September 2026. Lighthouse 13.5 mode mobile, median dari 3 run. Pihak ketiga (analytics dan Google Fonts) diblokir di kedua sisi, dan keduanya dilayani wrangler dev dengan kompresi. Sisi Next.js adalah build dari snapshot sebelum migrasi. Percobaan pertama memakai astro preview yang tidak mengompresi aset sehingga FCP dan LCP tampak memburuk; hasil itu dibuang dan pengukuran diulang secara adil.
• Produksi sebelum cutover, 28 September 2026, sekitar 15:35 WIB. PageSpeed Insights (Lighthouse 13.5.0, HeadlessChromium 153), satu run per perangkat dan template, mobile Moto G Power dengan Slow 4G. Data lapangan (CrUX) tidak tersedia.
• Produksi sesudah cutover, 30 September 2026. API PageSpeed menolak permintaan dengan kuota harian keyless terlampaui (HTTP 429, empat percobaan berjarak 45 detik). Sebagai gantinya Lighthouse 13.5.0 dijalankan lokal terhadap produksi memakai Chrome headless versi 131, preset mobile dengan throttling CPU 4x dan Slow 4G tersimulasi, satu run per URL dan perangkat. Ini bukan tangkapan PSI yang setara; toleransi skor perlu dianggap sekitar 5 sampai 10 poin.
• Telemetri Worker. wrangler tail pada versi rilis, sampel 134 event, ditambah crawl produksi 5 putaran (405 request).

Keterbatasan umum: satu situs, mesin uji tunggal, tiga sampai lima template, dan lab bukan data pengguna nyata. Dokumentasi web.dev menegaskan data lab dan lapangan berbeda dan data lapangan sebaiknya diprioritaskan untuk optimasi.

Hasil 1: apa yang berubah pada lab A/B lokal?

Pembacaannya: TBT, LCP, dan skor membaik di kelima template, dan JavaScript per halaman turun sekitar 44 sampai 50 persen. Sebaliknya FCP tidak membaik: pada empat dari lima template FCP justru sedikit lebih lambat, dengan selisih 79 sampai 125 ms. Percobaan ini tidak menjelaskan penyebabnya.

Hasil 2: bagaimana produksi sebelum dan sesudah cutover?

Peringatan penting: kolom kiri berasal dari PSI dan kolom kanan dari Lighthouse lokal dengan Chrome berbeda, mesin lain, dan satu run. Kenaikan skor mobile sebagian dapat disebabkan mesin uji yang lebih cepat. Perubahan yang paling meyakinkan adalah TBT beranda: 2190 menjadi 310 ms, dan skrip efek WebGL kini muncul sebagai satu long task 132 ms, dibanding sekitar 15 task berdurasi 89 sampai 405 ms pada baseline. Kontribusi migrasi terhadap perubahan itu tidak diisolasi secara terpisah. Di sisi lain TBT mobile naik pada empat dari lima halaman.

Hasil 3: bagaimana keandalan Worker setelah rilis?

Dalam sampel 134 event wrangler tail pada versi baru, seluruhnya berstatus ok, tanpa exception dan tanpa exceededCpu. CPU median 1 ms, persentil ke-95 21 ms, dan maksimum 166 ms, yang terjadi di rute on-demand (hub /blog, artikel dari D1, dan /tools). Wall time persentil ke-95 adalah 83 ms. Crawl produksi lima putaran sebanyak 405 request tidak menghasilkan kegagalan. Halaman prerender nyaris tidak memakai CPU Worker, sedangkan CPU tertinggi ada di rute SSR yang membaca D1 dan dapat mencakup cold start.

Sampel ini diambil dalam jendela rilis yang singkat (jendela rilis 08:34 sampai 08:50 WIB; rentang waktu persis sampel tail tidak dicatat terpisah). Satu kohort bersih tidak menutup risiko CPU 503; pemantauan pada +1, +7, dan +14 hari (1, 7, dan 14 Oktober 2026) masih berjalan.

Apa yang belum membaik atau masih terbuka?

• Belajar AI di mobile memburuk. Skor 66 menjadi 58, LCP 6,4 menjadi 7,0 detik, TBT 90 menjadi 470 ms. Diagnosis menunjukkan HTML server hanya berisi judul cadangan, lalu dokumen disuntikkan di klien dan menyebabkan render delay sekitar 2,6 detik, ditambah skrip ikon dan runtime lama. Struktur halaman ini sengaja dipertahankan demi parity, jadi migrasi tidak memperbaikinya.
• LCP mobile layanan AI engineering masih 5,1 detik. Sebelum migrasi 5,8 detik. Penyebabnya bukan migrasi: gambar hero berukuran sekitar 128 KB tanpa prioritas pemuatan.
• CSS render-blocking dan font. Diagnosis mencatat CSS global yang memblokir render dengan rantai impor Google Fonts, dan sebagian besarnya tidak terpakai per halaman. Ini pekerjaan lanjutan yang belum diukur ulang di catatan ini.
• Data lapangan belum ada. CrUX kosong pada semua pengukuran, sebelum dan sesudah. TBT di lab bukan INP di lapangan.
• PSI produksi belum diambil. Pengambilan ditunda sampai kuota pulih atau tersedia kunci API; kriteria performa migrasi belum boleh dinyatakan tertutup.
• Dampak pencarian belum diukur. Tidak ada klaim ranking, traffic, atau lead dari migrasi ini; pemeriksaan Search Console terjadwal setelah rilis.
• Masalah CPU 503 belum terbukti selesai. Lihat bagian keandalan di atas.

Catatan: perbaikan awal untuk font, CSS, dan gambar hero dirilis setelah pengukuran di atas dan belum diukur ulang.

Pelajaran apa yang bisa dipakai situs lain?

• Rekam baseline sebelum bermigrasi. Snapshot parity 74 halaman membuat regresi bisa dibedakan dari perubahan yang disengaja.
• Periksa siapa yang menyajikan HTML prerender. Di Cloudflare, aset statis dapat dilayani sebelum Worker, sehingga redirect dan header keamanan perlu jalur khusus.
• Jangan mencampur alat ukur tanpa menandainya. Satu rangkaian ukur yang tidak adil dibuang, dan perbedaan PSI dengan Lighthouse lokal dicatat.
• Pisahkan parity dari perbaikan. Perbaikan produk dan keamanan yang sudah tercatat tidak ikut, kecuali yang diputuskan pemilik, supaya regresi mudah dilacak.
• Lab bukan lapangan. Skor bagus di lab tidak menjamin pengalaman pengguna nyata.

Kapan migrasi seperti ini masuk akal?

Bukan rekomendasi universal. Migrasi layak dipertimbangkan bila masalah keandalan atau biaya runtime terukur, halaman sebagian besar berupa konten yang bisa diprerender, dan tersedia baseline, guard otomatis, serta rencana rollback. Biayanya nyata: migrasi ini memindahkan puluhan skrip pemeriksaan dan menguji perilaku edge satu per satu. Untuk pemeriksaan SEO pada Next.js, lihat SEO Next.js, dan untuk memilih teknologi berdasarkan kebutuhan, baca teknologi untuk membuat aplikasi web. Jika Anda membutuhkan aplikasi web atau audit teknis, lihat layanan aplikasi web dan layanan technical SEO, atau hubungi Fikran Dev.

Pertanyaan yang sering diajukan

Apakah data ini membuktikan Astro lebih cepat daripada Next.js?

Tidak. Data berasal dari satu situs, satu mesin uji, dan hanya beberapa template. Perubahan yang diukur juga mencakup pengurangan JavaScript dan penyederhanaan runtime, bukan hanya pergantian framework. Jangan menggeneralisasi angka ini ke situs lain.

Apakah migrasi mengubah URL atau metadata SEO?

Migrasi dirancang sebagai parity: URL, status code, dan metadata dipertahankan. Pemeriksaan parity pada 74 halaman tidak menemukan perbedaan yang memblokir. Dampak migrasi terhadap pencarian belum diukur, dan tidak ada klaim ranking atau traffic di artikel ini.

Apakah artikel ini studi kasus klien?

Bukan. Ini catatan pengukuran atas situs fikran.dev sendiri. Tidak ada klien, proyek pelanggan, atau hasil bisnis yang dilaporkan di sini.

Sumber resmi dan tanggal tinjauan

Konsep prerender dan on-demand dirujuk dari dokumentasi on-demand rendering Astro dan adapter dari panduan integrasi Cloudflare Astro. Batas CPU dirujuk dari limits Cloudflare Workers dan perilaku aset statis serta run_worker_first dari dokumentasi static assets binding. Karakter Hono dirujuk dari dokumentasi Hono, dan perbedaan data lab dan lapangan dari web.dev. Angka pengukuran berasal dari catatan internal fikran.dev bertanggal 28 sampai 30 September 2026. Sumber ditinjau 30 September 2026; hasil ini hanya berlaku untuk situs dan kondisi uji yang dijelaskan.