If you’re looking for the ultimate Web experience, you’ve probably used PWA in your site, and you’ve probably faced some hesitation in writing Service Worker code because Service workers are so important that once registered in a user’s browser, The entire site’s requests are controlled by the Service Worker, and a small problem can become a big one. But now with Workbox 3, any worries about Service workers are no longer an issue.
The popular science Service Worker
If you are already familiar with Service workers, you can skip this section.
Service Worker is an important part of PWA, which is the brain of a website inserted into the user’s browser. A Service Worker is registered on a page like this:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js')
}
Copy the codeWhy is SW the brain of a website? For example, if a SW is registered at the root of www.example.com, the SW can control all requests that the browser makes to www.example.com. By simply listening for fetch events, you can manipulate requests arbitrarily, return data read from CacheStorage, initiate new requests through the FETCH API, or even new a Response and return it to the page.
-
// A bad piece of SW code. After the SW is registered, all requests to the SW control site will return the string "bad", including the HTML of the page
-
self .addEventListener( 'fetch', function(event ) {
-
event.respondWith (
-
new Response ('bad')
-
);
-
});
Copy the codeBecause SW power is too big, it will be like walking on thin ice to write, accidentally some page resources can not be timely and correct update.
A fairly complete example of a Service Worker
Let’s start with a direct hand-written SW file
var cacheStorageKey = 'cachesName';
var cacheList = [
// List of resources to cache immediately after successful registration
]
// The install event is triggered when the browser finishes parsing the SW file
self.addEventListener('install', function(e) {
The install event typically requests the contents of the cacheList to be replaced into the Caches once, using the addAll method
e.waitUntil(
caches.open(cacheStorageKey).then(function(cache) {
return cache.addAll(cacheList)
})
);
});
// Triggers the Activate event when activated
self.addEventListener('activate', function(e) {
// Active events usually do some of the work of releasing expired resources, which are removed from caches when matched
var cacheDeletePromises = caches.keys().then(cacheNames => {
return Promise.all(cacheNames.map(name => {
if (name ! == cacheStorageKey) {
return caches.delete(name);
} else {
return Promise.resolve();
}
}));
});
e.waitUntil(
Promise.all([cacheDeletePromises])
);
});
self.addEventListener('fetch', function(e) {
// Write the cache policy here
e.respondWith(
// Can be returned by matching resources in the cache
caches.match(e.request)
// Can also be pulled from the remote end
fetch(e.request.url)
// You can also build your own
New Response(' make your own ')
// Caches can also be placed with the caches. Put method
);
});
Copy the codeIn fact, all sites SW install and active are similar. They do nothing more than pre-cache resource list and cache cleaning after update. The logic is not too complicated, but the focus is on fetch events. In the above code, I have omitted the fetch event logic, because it would be too much to write carefully, and it would not be helpful to explain the cache policy. Imagine caches where you need to cache different resources with different file extensions, CSS, JS, HTML, images, all requiring a separate cache strategy. You can see how much you need to write in fetch.
Workbox 3
Workbox, defined as a collection of PWA-related tools, has emerged to address this problem, as well as a series of tools around it such as workbox-cli, gulp-workbox, webpack-workbox-plagin, and so on. But none of them are the focus of today’s talk, which is about Workbox itself.
Workbox can be thought of as Google’s official PWA framework, which solves the problem of writing PWA using the underlying API. The underlying API here refers to listening to the install, active and FETCH events of SW for corresponding logical processing, etc. It works like this:
// Start with the Workbox framework
ImportScripts (' https://storage.googleapis.com/workbox-cdn/releases/3.3.0/workbox-sw.js');
workbox.precaching([
// List of resources to cache immediately after successful registration
]);
// HTML cache policy
workbox.routing.registerRoute(
new RegExp(''.*\.html'),
workbox.strategies.networkFirst()
);
workbox.routing.registerRoute(
new RegExp('.*\.(? :js|css)'),
workbox.strategies.cacheFirst()
);
workbox.routing.registerRoute(
new RegExp('https://your\.cdn\.com/'),
workbox.strategies.staleWhileRevalidate()
);
workbox.routing.registerRoute(
new RegExp('https://your\.img\.cdn\.com/'),
workbox.strategies.cacheFirst({
cacheName: 'example:img'
})
);
Copy the codeIt’s much easier to understand the code above, through workbox. Precaching fortress is install later into the contents of the caches of workbox. Routing. The first parameter is a regular in the registerRoute, The workbox. Strategies object provides us with several of the most commonly used strategies, as follows:
Stale-While-Revalidate
Cache First
Network First
Network Only
Cache Only
You can extend these policies via plugin, such as adding a cache expiration time (officially provided). You can even continue to listen for fetch events and then use these policies. The official documentation is here.
Rule of thumb
After a period of use and thinking, I think the most reasonable, the most conservative cache strategy.
HTML. If you want your page to be accessible offline, use NetworkFirst. If offline access is not required, use NetworkOnly.
CSS and JS, the situation is complicated, because the CSS and JS of general sites are in the CDN, SW has no way to determine whether the resources requested from the CDN are correct (HTTP 200), if the cache failed results, the problem will be big. In this case, I suggest using the stale-while-revalidate strategy to ensure the page speed. Even if the page fails, the user will update it after refreshing.
If your CSS, JS and site are in the same domain, and the file name has the Hash version number, you can use Cache First directly.
It is recommended to use Cache First and set a certain invalidation event. The request will not change once.
These are just general strategies, depending on your opinion.
Also, remember that Cache only and Cache first should never be used for any resource that is not in the same domain.
Make a final report
The Service Worker on the home page of Taobao PC has been online for a period of time. After constant adjustment of cache strategy, the benefits are still obvious. The total page download time drops from 1.7s to 1.4s on average, shortening the download time by nearly 18%.
In the previous example, we used Workbox introduced by Google’S CDN address. I have migrated version 3.3.0 to AlicDN and will continue to maintain and update it in the future. The usage method is as follows:
ImportScripts (' https://g.alicdn.com/kg/workbox/3.3.0/workbox-sw.js');
workbox.setConfig({
ModulePathPrefix: 'https://g.alicdn.com/kg/workbox/3.3.0/'
});
Copy the codereference
-
Workbox official documentation
-
Fantastic Workbox 3.0
Photo by Peter Wendt on Unsplash