SW implementation done
This commit is contained in:
@@ -0,0 +1,27 @@
|
||||
## 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.
|
||||
|
||||
Reference in New Issue
Block a user