- [Instructor] When we think about the web, typically we think about being online. But now we have new use cases in the modern world. For example, we might be able to work offline. Also, there are loads of slow connections out there, such as 2G or 3G connections, when we are working with similar networks. Sometimes we are on LTE, so 4G, but have an unreliable connection. Also we have now Progressive Web Apps, or PWAs, and they will need someone to cache and serve the files of the app.
And finally, we all want faster web user experiences. We also have new goals now, mostly regarding web performance. We have new metrics and new goals to achieve to provide the best possible experience for our users. We usually want to offer a consistent experience across different contexts. For example, the user might be on its own home with WiFi connection, or the user might be in roaming, for example, using 3G.
And when we are serving mobile users, and we know that we want to serve mobile users, we are using similar connections. And these networks have high latency, which means the data takes more time to get to the user, so we need some help. In the past, we had some solutions for offline access. For example, Google Gears, Application Cache, that was part of the original HTML5 spec and is now deprecated, and also Apache Cordova, or PhoneGap, that let us create offline apps for the store.
But they all their own challenges. So fortunately, now we have a new spec from the W3C, known as Service Workers. So it's in a standard spec for browsers. It's on top of the web worker spec. A service worker manages a scope. For now, let's say that it's just a folder in the domain. It have some abilities on that scope, and it works completely detached from any browser's tab or PWA's process.
We mentioned that a service worker has one scope. The scope, it's an origin and a path, which means that's just a protocol, a host and a port, plus a path. So let's see these with examples. If we have a website like https://mydomain.com/, so the root folder, that's one scope. We can have a different scope if we have a subfolder, such as myapp in the same domain, that's a different scope.
Also, we can have another web server in a different port. And in that case, it would be a different scope. And finally, when you are working with subdomains, we are also working with completely different scope. So one service worker will be responsible only for one scope. Inside the browser environment, we have several things in memory. For example, several tabs in the browser, several progressive web apps in stand-alone mode, like any other app, and even Iframes, all of them being served from mydomain.com.
When we have that situation, we always have only one service worker, so one service worker can be pointing to several clients, that's the name, clients. Several clients from the same scope will always be pointing to the same service worker. The service worker will be registered by a page. Any page in the scope can register the service worker. There is no permission involved for registration, which means the user will never receive any dialogue for the service worker, and there is no limit in the amount of service workers that a user or a browser can install.
On most situations, the service worker will be installed forever, so it's not going to be uninstalled automatically, or uninstalled when the user clears the cache. On most situations, later we will get more details in the lifecycle of the service worker.
- Service worker life cycle
- Registering service workers
- Handling service worker events
- Updating service workers
- Acting as a network proxy
- Configuring cache storage
- Communicating with clients
- Optimizing web performance