Belajar Remix - Caching & Performance

#Pendahuluan

Setelah konfigurasi dan environment siap, saatnya berbicara tentang kecepatan. Caching adalah salah satu cara paling efektif membuat aplikasi terasa cepat — dan di Remix, kontrol atas caching sangat eksplisit karena setiap route bisa menentukan header HTTP-nya sendiri.

Poin kuncinya: di Remix, kalian mengontrol header HTTP langsung. Cache-Control yang benar bisa membuat CDN dan browser menyimpan halaman sehingga permintaan tidak selalu sampai ke server. Ini berbeda dari framework yang menyembunyikan HTTP di balik abstraksi.

Episode 9 akan membahas cache headers, stale-while-revalidate, optimasi gambar dan aset, serta monitoring performa dengan Lighthouse.

#Cache Headers dan Cache Control

#headers Export di Route

Setiap route bisa mengekspor fungsi headers untuk mengatur header respons, termasuk Cache-Control. Fungsi ini menerima hasil loader dan header parent, lalu mengembalikan header akhir.

Cache headers pada route statis

export function headers() {
  return {
    "Cache-Control": "public, max-age=60, s-maxage=3600",
  };
}

max-age mengatur caching di browser; s-maxage mengatur caching di CDN dan proxy. Dengan kombinasi di atas, browser menyimpan 60 detik dan CDN 1 jam — keseimbangan antara kecepatan dan kesegaran data.

#Kapan Halaman Boleh Di-Cache

Aturan praktisnya:

• Halaman yang jarang berubah bisa di-cache lama.
• Halaman yang bergantung pada login tidak boleh di-cache publik.
• Header pada route induk menjadi dasar, dan route anak bisa menimpanya.

#Data Revalidation dan Stale-While-Revalidate

#Menjaga Data Tetap Segar

Stale-while-revalidate membuat halaman tetap dianggap segar walau usia cache lewat batas. Saat batas terlampaui, pengguna tetap mendapat versi lama sementara server memuat versi baru di latar belakang. Remix dan CDN modern mendukung pola ini melalui header Cache-Control.

Pola stale-while-revalidate

export function headers() {
  return {
    "Cache-Control": "public, s-maxage=60, stale-while-revalidate=300",
  };
}

stale-while-revalidate=300 berarti versi lama boleh disajikan hingga 300 detik tambahan. Pengguna tidak pernah menunggu, dan data tidak pernah basi lebih dari 5 menit.

#Revalidasi di Tingkat Data

Untuk data yang dibaca loader tetapi berubah lewat action, Remix sudah menangani revalidasi otomatis: setelah action selesai, semua loader route yang terlibat dipanggil ulang. Kalian tidak perlu menulis kode sinkronisasi manual — cukup pastikan loader selalu membaca sumber kebenaran.

#Optimasi Gambar dan Asset Caching

#Gambar sebagai Aset Statis

Untuk aplikasi yang tidak memakai layanan optimasi gambar, tempatkan gambar di folder public atau import lewat bundler. Import lewat bundler memberi keuntungan: nama file diberi hash konten, sehingga browser bisa meng-cache gambar selamanya — file baru otomatis punya nama baru.

public/logo.a1b2c3.png   <- dihasilkan Vite, nama unik per konten

Hash pada nama file memungkinkan Cache-Control sangat panjang tanpa risiko konten basi. Ini adalah cara standar meng-cache aset: immutable karena namanya berubah saat isinya berubah.

#Memuat Gambar dengan Benar

Selain cache, perhatikan cara gambar dimuat: gunakan dimensi yang tepat agar tidak melebihi ukuran yang dibutuhkan, dan pertimbangkan format modern seperti WebP. Gambar yang besar adalah penyumbang bobot halaman terbesar setelah JavaScript.

Aturan yang sama berlaku untuk font. Hindari memuat beberapa varian font sekaligus; gunakan subset dan teknik pemuatan yang tepat. Setiap byte yang tidak perlu berarti waktu render yang lebih lama, terutama di jaringan seluler.

#Performance Monitoring dan Lighthouse

#Audit dengan Lighthouse

Lighthouse mengukur berbagai metrik: waktu sampai konten terlihat (FCP), waktu sampai siap berinteraksi (TTI), dan skor aksesibilitas. Jalankan audit dari devtools browser:

npx lighthouse http://localhost:3000 --preset=desktop

Hasil Lighthouse memberi skor dan daftar perbaikan yang diprioritaskan. Jalankan untuk build production, bukan dev server, karena hasilnya lebih representatif.

Selain Lighthouse, manfaatkan tab Network di devtools untuk melihat langsung header respons. Periksa apakah Cache-Control terpasang dengan benar, berapa ukuran tiap aset, dan apakah ada aset yang dimuat berulang tanpa perlu. Kombinasi Lighthouse dan devtools memberi gambaran utuh dari halaman kalian.

#Menerjemahkan Skor ke Tindakan

Fokus pada metrik yang berdampak nyata: kurangi JavaScript yang dikirim, perkecil gambar, dan gunakan caching. Skor 100 tidak otomatis berarti aplikasi terasa cepat — gabungkan audit dengan pengalaman nyata. Untuk pemantauan real user, episode 22 akan membahas observability lebih lanjut.

#Penutup

Episode 9 memberi kalian toolkit performa: cache headers lewat fungsi headers, pola stale-while-revalidate untuk data semi-dinamis, optimasi gambar dan aset dengan hash, serta audit berkelanjutan dengan Lighthouse. Kecepatan kini bisa diukur, bukan sekadar dirasakan.

Inti yang harus dibawa pulang:

• Fungsi headers di route mengatur Cache-Control untuk browser dan CDN.
• max-age untuk browser; s-maxage untuk CDN; stale-while-revalidate untuk kesegaran.
• Halaman yang butuh login tidak boleh di-cache publik.
• Aset dengan hash nama file bisa di-cache sangat lama tanpa risiko basi.
• Remix merevalidasi loader otomatis setelah action selesai.
• Jalankan Lighthouse pada build production secara rutin.

Di episode 10 selanjutnya kita akan membahas database dan persistence — integrasi ORM seperti Prisma, setup connection pooling dan konfigurasi berbasis environment, querying data di loader dan action, serta transaction handling untuk persisten yang aman. Cache membuat halaman cepat; database membuatnya bermakna.