Belajar Remix - Network Performance & Caching

#Pendahuluan

Episode 9 membahas caching di level halaman. Episode 14 memperluas itu ke level jaringan: bagaimana data bergerak dari server ke pengguna secepat mungkin, dan bagaimana CDN serta edge membantu di tengah jalan.

Poin penting yang sering salah paham: Remix tidak menjalankan cache-nya sendiri — ia bekerja sama dengan infrastruktur HTTP. Remix mengatur header Cache-Control dengan benar, dan CDN di depan server menyimpan salinan halaman sehingga pengguna di ujung dunia dilayani dari lokasi terdekat, bukan dari server utama.

Episode 14 akan membahas strategi HTTP caching, integrasi CDN dan edge cache, prefetching, serta optimasi first load dan navigasi berikutnya.

#Strategi HTTP Caching untuk Remix

#Membangun Cache di Setiap Lapisan

Cache bisa hidup di tiga tempat: browser, CDN, dan server. Header Cache-Control menentukan di mana dan berapa lama data boleh disimpan. Pendekatan Remix adalah memaksimalkan caching yang aman, bukan menerapkan satu kebijakan ke semua halaman.

Kebijakan cache per tipe halaman

export function headers({ loaderData }) {
  if (!loaderData || loaderData.bersifatPribadi) {
    return { "Cache-Control": "private, no-store" };
  }
  return { "Cache-Control": "public, max-age=60, s-maxage=3600" };
}

Fungsi headers menerima loaderData sehingga kebijakan bisa menyesuaikan isi halaman. Data pribadi tidak pernah di-cache publik; halaman publik di-cache agresif.

#Kunci Dua Level: max-age dan s-maxage

max-age berbicara ke browser, s-maxage ke CDN. Memisahkan keduanya memberi kontrol: CDN bisa menyimpan lebih lama dari browser, atau sebaliknya. Ini adalah dasar strategi caching di hampir semua aplikasi Remix production.

#Integrasi CDN dan Edge Cache

#Menempatkan CDN di Depan Aplikasi

CDN seperti Cloudflare atau Fastly berdiri di depan server Remix. Saat pengguna meminta halaman, CDN memeriksa cache-nya; jika kosong atau basi, permintaan diteruskan ke origin dan hasilnya disimpan. Header Cache-Control dari halaman Remix menentukan perilaku CDN secara langsung.

curl -I https://aplikasi-kalian.dev/posts

Perintah curl -I menampilkan header respons, termasuk Cache-Control. Gunakan ini untuk memverifikasi bahwa CDN dan origin mengirim kebijakan yang benar.

Jika header yang diinginkan tidak muncul, cek konfigurasi CDN dan pastikan kebijakan Cache-Control tidak diubah atau ditimpa di lapisan proxy. Sering kali masalah bukan di kode Remix, melainkan di cara platform menghargai header.

#Edge Cache untuk HTML

Untuk halaman yang hampir statis — blog, dokumentasi, landing page — edge cache memberi latensi sangat rendah: pengguna dilayani dari node CDN terdekat tanpa menyentuh server. Halaman login, dasbor, dan halaman pribadi dikecualikan.

#Prefetching Data dan Links

#Link Prefetch

Remix menyediakan prefetch bawaan lewat prop prefetch pada Link. Nilai "intent" me-load data saat link di-hover atau difokuskan; "render" saat link terlihat di layar. Prefetch memindahkan waktu tunggu data ke momen kalian tahu pengguna akan mengklik.

Prefetch saat kursor mendekat

import { Link } from "@remix-run/react";
 
export default function Daftar() {
  return (
    <Link prefetch="intent" to="/posts/berikutnya">
      Posting berikutnya
    </Link>
  );
}

Dengan prefetch, halaman berikutnya sudah punya data saat diklik — navigasi terasa instan. Perhatikan bandwidth: prefetch semua link bisa boros, jadi terapkan pada link yang paling mungkin diklik.

Perlu diingat juga bahwa prefetch bekerja paling baik pada halaman yang datanya tidak terlalu sering berubah. Untuk data yang sangat dinamis seperti skor pertandingan langsung, prefetch bisa menampilkan data yang sudah basi saat halaman terbuka. Pilih target prefetch berdasarkan seberapa sering data berubah.

#Resource Prefetch

Untuk data yang bukan bagian dari navigasi — misalnya cuaca yang ditampilkan di sidebar — gunakan prefetch manual di komponen. Pola ini melengkapi prefetch Link dan membuat aplikasi terasa responsif tanpa menunggu interaksi.

#Optimasi First Load dan Navigasi Berikutnya

#First Load yang Ringan

First load adalah yang paling menentukan kesan pertama. Prioritaskan: kirim HTML berisi konten (bawaan Remix), perkecil CSS dan JavaScript untuk halaman pertama, dan defer aset non-kritis. Ukur first load dengan Lighthouse dan target skor tinggi untuk metrik seperti LCP.

#Navigasi Berikutnya yang Instan

Setelah first load, kecepatan navigasi ditentukan oleh kombinasi: nested routes (hanya bagian berubah yang di-render ulang), prefetch (data sudah siap), dan caching client. Setiap navigasi internal di Remix memakai data cache sehingga route yang sama tidak pernah di-load dua kali tanpa perlu.

#Memantau Hasilnya

Terapkan metrik nyata: waktu sampai konten pertama (FCP), waktu sampai elemen terbesar (LCP), dan interaksi yang lambat. Episode 22 akan membahas observability dan real user monitoring untuk skala produksi.

Yang tak kalah penting adalah mengukur dampak setiap perubahan. Catat skor sebelum dan sesudah menambahkan prefetch atau caching — jika tidak ada perbaikan yang berarti, pertimbangkan apakah perubahan itu layak menambah kompleksitas.

#Penutup

Episode 14 menyatukan performa jaringan: strategi HTTP caching dua level, integrasi CDN dan edge cache, prefetching Link dan data, serta optimasi first load versus navigasi berikutnya. Aplikasi kalian sekarang cepat di jaringan mana pun.

Inti yang harus dibawa pulang:

• Header Cache-Control menentukan perilaku browser, CDN, dan server.
• max-age untuk browser; s-maxage untuk CDN.
• Halaman pribadi tidak boleh di-cache publik.
• CDN di depan origin melayani pengguna dari node terdekat.
• prefetch="intent" menyiapkan data sebelum link diklik.
• First load yang ringan dan navigasi berikutnya yang instan butuh strategi berbeda.

Di episode 15 selanjutnya kita akan membahas advanced patterns dan state — client-side state dengan React hooks, shared state dan server-driven UI, progressive enhancement dan optimistic updates, serta data jangka panjang dengan revalidasi di latar belakang. Jaringan cepat; sekarang saatnya membuat interaksi terasa hidup.