Belajar Microfrontend - Performance: Lazy Load & Core Web Vitals

#Pendahuluan

Setelah memahami arsitektur dan tooling, kita masuk ke isu yang paling sering dikeluhkan orang tentang microfrontend: performan. Kekhawatiran klasiknya — "bukankah memuat banyak aplikasi membuat situs lambat?" — memang valid jika salah desain, tapi bisa dihindari sepenuhnya dengan strategi yang benar.

Mengapa penting? Karena Core Web Vitals (LCP, INP, CLS) memengaruhi SEO, konversi, dan pengalaman user. Microfrontend yang buruk bisa merusak metrik ini, tapi yang baik bisa mencapai performa setara monolit — bahkan sama-sama bagus. Episode ini membahas caranya.

#Levels of Loading

#Jangan Load Semua Remote di Awal

Prinsip pertama: jangan memuat semua remote saat initial load. Hanya host (dan remote untuk rute yang diakses) yang diambil konsumen di awal. Remote lain di-load lazy per route.

#Lazy per Route

Seperti episode 6, host memuat remote hanya saat user mengunjungi rutenya. Ini menjaga bundle host awal kecil.

#Preload Saat Idle/Hover

Untuk mengurangi latensi saat user berinteraksi, kita bisa preload remote critical saat idle atau saat user hover di UI yang menuju ke suatu tempat:

import { preloadRemote } from '@module-federation/enhanced/runtime'
 
// saat browser idle
if ('requestIdleCallback' in window) {
  window.requestIdleCallback(() => {
    preloadRemote({ nameOrAlias: 'catalog' })
  })
}

Preload membuat remote siap sebelum benar-benar di-klik, mengecilkan perceived latency.

#Shared Chunks

Karena kita memakai satu React shared (episode 5), tidak ada pengunduhan React ganda. Remote chunk ter-split per route, sehingga hanya kode yang memang dipakai yang dimuat:

• Satu React di shared → duplikasi kecil.
• Remote chunk dipecah → bundle remote ringan per halaman.

Dampak: ukuran JS total bisa hampir setara monolit yang ter-code-split dengan baik.

#Bundle Analysis

Untuk tahu remote mana yang berat, gunakan @module-federation/devtools dan analisis bundle:

pnpm --filter storefront-catalog run build
npx vite-bundle-visualizer

Analisis ini menampilkan ukuran per chunk sehingga kita bisa mengidentifikasi remote yang boros (misal menginclude library besar yang tidak seharusnya).

#Web Vitals & Prioritas Loading

Karena loading remote menambah kerja browser, kita harus memprioritaskan:

• LCP harus dari host (konten utama), bukan remote sekunder yang lambat.
• Defer remote sekunder agar tidak menghambat rendering utama.
• Prioritize host saat LCP, load remote lain belakangan.

Perencanaan ini penting karena LCP sangat terpengaruh waktu pemuatan remote yang berada di jalur critical.

#Manifest Preloading (Hot Start)

Module Federation 2.0 mendukung preloading manifest — manifest remote sudah diketahui/termuat sejak awal (bisa di-inline), sehingga saat remote benar-benar dimuat, browser tahu direktori chunk tanpa menunggu fetch manifest lagi. Ini menghasilkan hot start untuk remote.

remotes: {
  catalog: {
    type: 'module',
    entry: 'http://cdn.example.com/catalog/mf-manifest.json',
    preloadRemote: true,
  },
}

#Pola ESM Waterfall

Dengan mengombinasikan preload manifest, preload remote, dan loading lazy, kita bisa menghindari waterfall (antrian request beruntun yang memperlambat). Tujuannya: Lighthouse 100 bahkan dengan dynamic remotes.

#Penutup

Pada episode 12 ini, kalian telah memahami strategi performa microfrontend.

Inti yang harus dibawa pulang:

• Lazy per route: jangan load semua remote di awal; preload saat idle/hover.
• Shared chunks: satu React mengurangi duplikasi; remote chunk ter-split per route.
• Bundle analysis dengan @module-federation/devtools + visualizer.
• Web Vitals: prioritize host untuk LCP, defer remote sekunder.
• Manifest preloading → hot start; hindari ESM waterfall; target Lighthouse 100.

Di episode 13 selanjutnya, kita akan membahas isolasi, sandbox & keamanan remote — isolasi global scope, CSP & XSS, remote dari supply chain terpercaya, guardrails input, dan error boundary global. Pastikan performa kalian sudah diukur!