Difference between revisions of "Service Worker"
From MgmtWiki
(→Context) |
(→Context) |
||
| (17 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | A [[Service Worker]], as defined by the [[World Wide Web Consortium]] (W3C) as a [https://en.wikipedia.org/wiki/Web_worker Web Worker] | + | A [[Service Worker]], as defined by the [[World Wide Web Consortium]] (W3C) as a [https://en.wikipedia.org/wiki/Web_worker Web Worker], is a [[JavaScript]] executed from an [[Web Site]] that runs in the [[background process|background]], independently of user-interface scripts that could be executing in the HTML page.<ref name="WHATWG"> ''Web Workers'' Web Hypertext Application Technology Working Group (2010-06-03) http://www.whatwg.org/specs/web-workers/current-work/</ref> |
| − | |||
==Context== | ==Context== | ||
*The simplest use of workers is for performing a computationally expensive task without interrupting the user interface. | *The simplest use of workers is for performing a computationally expensive task without interrupting the user interface. | ||
*The W3C and the WHATWG are currently in the process of developing a definition for an application programming interface ([[API]]) for web workers.<ref name="WHATWG"/> | *The W3C and the WHATWG are currently in the process of developing a definition for an application programming interface ([[API]]) for web workers.<ref name="WHATWG"/> | ||
| + | *Service workers are a proxy between the browser and the network. By intercepting requests made by the document, service workers can redirect requests to a cache, enabling offline access. Web workers (from [[Web App]]s) are general-purpose scripts that enable us to offload processor-intensive work from the main thread. | ||
| + | |||
| + | ==Problems== | ||
| + | *Native mobile apps deliver rich experiences and high performance, purchased at the expense of storage space, lack of real-time updates, and low search engine visibility.<ref>''Learn Everything About Progressive Web Apps.'' HTML Panda https://www.htmlpanda.com/blog/learn-everything-about-progressive-web-apps/</ref> | ||
| + | *Traditional web apps suffer from the inverse set of factors: lack of a native compiled executable, along with dependence on unreliable and potentially slow web connectivity. | ||
==Solution== | ==Solution== | ||
| + | * Service worker script act as the extra layer between website requests and internet servers. It makes caching any content easier whenever visitor tries to access the [[Progressive Web App]] enabled page. The information is further saved locally on the device of user. | ||
| + | *The standards envision web workers as long-running scripts that are not interrupted by user-interface scripts (scripts that respond to clicks or other user interactions). Keeping such workers from being interrupted by user activities should allow Web pages to remain responsive at the same time as they are running long tasks in the background. | ||
| + | * Service workers can use multi-core CPUs more effectively than the single thread available in the web browsers.<ref> ''HTML Living Standard'' (2017-01-30) https://html.spec.whatwg.org/multipage/workers.html#delegation</ref> | ||
* [https://googlechrome.github.io/samples/service-worker/basic/ Basic Service Worker Sample] from Google to pre-cache script and other files for [[Web App]]. | * [https://googlechrome.github.io/samples/service-worker/basic/ Basic Service Worker Sample] from Google to pre-cache script and other files for [[Web App]]. | ||
| + | |||
| + | ==Troubleshooting== | ||
| + | * using sw-precache to generate a service worker with Polymer CLI build process, so it's intended to update the hash of updated files to signal a need to update the cache. But updated content is not being replaced in cache, so it's getting an old version if refreshed with ctrl+r but the new version if refreshed with ctrl+shift+r. A reason for that can be that the service worker is not being updated. | ||
| + | ** [https://stackoverflow.com/questions/41903097/how-to-force-service-worker-to-update sw-precach has been superseded by Workbox] which generates hashes for the files you want to precache and adds those to the source code of your service worker (I don't know if sw-precache works the same way, Jeff's answer suggests it does). If any of the files you want to precache change -- and you re-run your build -- the updated hashes in your service worker are updated which pretty much guarantees the service worker will be "at least one byte different". | ||
| + | ** When you reload (ctrl-r) or re-visit your app the browser will fetch again the service worker that was registered for it. And, if that service worker has changed, it will be "queued up" to manage the app. But it won't start managing the app until you close all tabs with the app open, and then open a new one. | ||
| + | ** When you hard refresh (shift-ctrl-r) it’ll always load without a controller which is not the same as using your new service worker. | ||
| + | ** For testing during development, I use skip waiting in devtools to make the new service worker replace the old one without waiting for me to close all the tabs. | ||
| + | ** there is a 1 day (24hr) built-in limit for the browser to look for updates to the service worker, but what you need to be mindful of is you still need to call .update() on your ServiceWorkerRegistration object otherwise the original version of the file will be used. | ||
| + | ** While testing changes in Chrome, I always right-click on the refresh button and select 'Empty Cache and Hard Reset' (options are available when developer tools are open) when working on my service worker script. | ||
==References== | ==References== | ||
| Line 15: | Line 31: | ||
===Other References=== | ===Other References=== | ||
* [https://developers.google.com/web/fundamentals/primers/service-workers/Service Workers: an Introduction] for Android | * [https://developers.google.com/web/fundamentals/primers/service-workers/Service Workers: an Introduction] for Android | ||
| + | |||
| + | [[Category:Glossary]] | ||
Revision as of 22:19, 19 January 2021
Contents
Full Title or Meme
A Service Worker, as defined by the World Wide Web Consortium (W3C) as a Web Worker, is a JavaScript executed from an Web Site that runs in the background, independently of user-interface scripts that could be executing in the HTML page.[1]
Context
- The simplest use of workers is for performing a computationally expensive task without interrupting the user interface.
- The W3C and the WHATWG are currently in the process of developing a definition for an application programming interface (API) for web workers.[1]
- Service workers are a proxy between the browser and the network. By intercepting requests made by the document, service workers can redirect requests to a cache, enabling offline access. Web workers (from Web Apps) are general-purpose scripts that enable us to offload processor-intensive work from the main thread.
Problems
- Native mobile apps deliver rich experiences and high performance, purchased at the expense of storage space, lack of real-time updates, and low search engine visibility.[2]
- Traditional web apps suffer from the inverse set of factors: lack of a native compiled executable, along with dependence on unreliable and potentially slow web connectivity.
Solution
- Service worker script act as the extra layer between website requests and internet servers. It makes caching any content easier whenever visitor tries to access the Progressive Web App enabled page. The information is further saved locally on the device of user.
- The standards envision web workers as long-running scripts that are not interrupted by user-interface scripts (scripts that respond to clicks or other user interactions). Keeping such workers from being interrupted by user activities should allow Web pages to remain responsive at the same time as they are running long tasks in the background.
- Service workers can use multi-core CPUs more effectively than the single thread available in the web browsers.[3]
- Basic Service Worker Sample from Google to pre-cache script and other files for Web App.
Troubleshooting
- using sw-precache to generate a service worker with Polymer CLI build process, so it's intended to update the hash of updated files to signal a need to update the cache. But updated content is not being replaced in cache, so it's getting an old version if refreshed with ctrl+r but the new version if refreshed with ctrl+shift+r. A reason for that can be that the service worker is not being updated.
- sw-precach has been superseded by Workbox which generates hashes for the files you want to precache and adds those to the source code of your service worker (I don't know if sw-precache works the same way, Jeff's answer suggests it does). If any of the files you want to precache change -- and you re-run your build -- the updated hashes in your service worker are updated which pretty much guarantees the service worker will be "at least one byte different".
- When you reload (ctrl-r) or re-visit your app the browser will fetch again the service worker that was registered for it. And, if that service worker has changed, it will be "queued up" to manage the app. But it won't start managing the app until you close all tabs with the app open, and then open a new one.
- When you hard refresh (shift-ctrl-r) it’ll always load without a controller which is not the same as using your new service worker.
- For testing during development, I use skip waiting in devtools to make the new service worker replace the old one without waiting for me to close all the tabs.
- there is a 1 day (24hr) built-in limit for the browser to look for updates to the service worker, but what you need to be mindful of is you still need to call .update() on your ServiceWorkerRegistration object otherwise the original version of the file will be used.
- While testing changes in Chrome, I always right-click on the refresh button and select 'Empty Cache and Hard Reset' (options are available when developer tools are open) when working on my service worker script.
References
- ↑ 1.0 1.1 Web Workers Web Hypertext Application Technology Working Group (2010-06-03) http://www.whatwg.org/specs/web-workers/current-work/
- ↑ Learn Everything About Progressive Web Apps. HTML Panda https://www.htmlpanda.com/blog/learn-everything-about-progressive-web-apps/
- ↑ HTML Living Standard (2017-01-30) https://html.spec.whatwg.org/multipage/workers.html#delegation
Other References
- Workers: an Introduction for Android
