28 lines
1.3 KiB
Markdown
28 lines
1.3 KiB
Markdown
## Why
|
|
|
|
Improve page load performance (especially repeat visits) by caching key assets closer to the user and reducing unnecessary network requests.
|
|
|
|
## What Changes
|
|
|
|
- Add a Service Worker to the site so the browser can cache and serve core assets efficiently.
|
|
- Pre-cache the critical shell (CSS, JS, fonts, icons) and use a runtime caching strategy for images and other large assets.
|
|
- Ensure safe update behavior on deploy (new service worker activates and old caches are cleaned up).
|
|
- Keep development experience predictable (service worker disabled or bypassed in dev by default).
|
|
|
|
## Capabilities
|
|
|
|
### New Capabilities
|
|
|
|
- `service-worker-performance`: Provide a service worker-based caching strategy that improves perceived load time and reduces network usage on repeat visits, while ensuring safe updates on new deploys.
|
|
|
|
### Modified Capabilities
|
|
|
|
- (none)
|
|
|
|
## Impact
|
|
|
|
- Adds new client-side assets for the service worker (e.g., `sw.js`) and registration logic in the site layout.
|
|
- Changes browser caching behavior; must avoid serving stale HTML indefinitely and ensure caches are versioned/invalidated on deploy.
|
|
- Service workers require a secure context (HTTPS) in production; local dev behavior should be explicitly controlled to avoid confusing caching during iteration.
|
|
|