Partials: Component Chunk Links
Use chunk preloading selectively on high-traffic routes to reduce interaction delay, while avoiding brittle preloads tied to unstable chunk names.
Prerequisites
- - Build output inspection for your deployment target.
- - Performance traces from real routes, not synthetic assumptions.
- - A release process that can update preload hints when bundles change.
Step 1: Preload the stable entry script
Start with the shared loader entrypoint before preloading individual chunks.
<link rel="preconnect" href="/stencil" />
<link rel="modulepreload" href="/stencil/diwa-components.esm.js" />Step 2: Add route-specific chunk hints carefully
Only preload chunks you verified as stable and frequently needed on first interaction.
<!-- Optional and deployment-specific -->
<link rel="modulepreload" href="/stencil/p-diwaswitch.entry.js" />Step 3: Validate impact with metrics
Track route-level interaction timing and remove hints that do not improve user-perceived performance.
// pseudo-metric check
performance.mark('diwa-first-action-start');
// ... first user interaction ...
performance.mark('diwa-first-action-end');
performance.measure('diwa-first-action', 'diwa-first-action-start', 'diwa-first-action-end');Implementation Notes
- - Prefer preload for stable assets and prefetch for speculative navigation assets.
- - Keep preload usage narrow to avoid bandwidth contention on low-end devices.
- - Re-evaluate hints when changing bundler, deployment paths, or release channels.
Troubleshooting
- - If preload links 404, re-check output file names in the deployed build.
- - If performance regresses, remove low-value hints and prioritize critical path assets.
- - If hydration races appear, ensure loader bootstrap order is still deterministic.