Mikä on palvelutyöntekijä? Muunna verkkosivustosi hetkessä latautuvaksi tehokeinoksi!

Yritätkö selvittää, mikä on palvelutyöntekijä? Et ole yksin!

Palvelutyöntekijä on skripti, joka suoritetaan taustalla, erillisessä säikeessä selaimen käyttöliittymästä. Service Workerin välimuisti tekee mahdolliseksi sen, että verkkosivusto voi toimia offline-tilassa. Ne ovat tekninen voimanpesä, joka tasoittaa verkkosivuston progressiiviseksi web-sovellukseksi. Ne mahdollistavat syvän alustaintegraation, kuten rikkaan välimuistitallennuksen, push-ilmoitukset ja taustasynkronoinnin.

Palvelutyöntekijät on suunniteltu laajennettavaksi alustaksi, lisäominaisuuksia on parhaillaan suunnitteilla.

Ne eivät pääse käsiksi DOM:iin, mutta pystyvät sieppaamaan kaikki verkkopyynnöt. Tämä antaa kehittäjille mahdollisuuden kontrolloida pyyntöjen käsittelyä, mikä tarjoaa monipuolisen tavan saada verkkosivut toimimaan offline-tilassa.

Palvelutyöntekijöitä on kutsuttu verkkopelin mullistajiksi. En usko, että se on pelkkää liioittelua, sillä ne mahdollistavat monia kipeästi kaivattuja ominaisuuksia ja tekevät vuosia käyttämästäni ydinarkkitehtuurista natiivin.

Palvelutyöntekijät kuulostavat hämmästyttäviltä!

Tämä on avainteknologia tai nykyaikainen web-applikaatioliittymä progressiivisten verkkosovellusten taustalla. Ilman palvelutyöläistä verkkosivusto on vain verkkosivusto, lisää palvelutyöläinen ja sinulla on nyt sovellus.

Palvelutyöntekijöissä on joitakin keskeisiä ominaisuuksia, jotka sinun on ymmärrettävä:

1. Palvelutyöntekijä on JavaScript-tiedosto
2. Ne suoritetaan erillisessä säikeessä käyttöliittymästä
3. Ne eivät pääse suoraan käsiksi DOM:iin
4. Palvelutyöntekijällä on elinkaari tai tapahtumasarja, jonka läpi hän kulkee tullakseen aktiiviseksi, selitetään myöhemmin
5. Ne ovat aktiivisia vain silloin, kun niitä käytetään, joten akkua ei rasiteta
6. Se on eristetty alkuperäiseen tai toimialueeseen, johon se on rekisteröity
7. Palvelutyöntekijät vaativat HTTPS:n
8. Voivat lähettää viestejä käyttöliittymään ja käyttöliittymästä
9. Eivät vaadi avoinna olevaa verkkosivua toimiakseen
10. Tukevat kaikkia yleisimpiä selaimia, mukaan lukien iOS:n Safari
11. Ovat samanlaisia kuin Web Workerit, mutta monin tavoin parempia

• Miten Service Workerit toimivat?
• Palvelutyöntekijöiden laajennettavuus
• Palvelutyöntekijöiden elinkaari
• Kuinka kauan palvelutyöntekijät kestävät?
• Miten tarkistan, onko palvelutyöntekijä rekisteröity?
• Miten poistan palvelutyöntekijän rekisteröinnin
• Palvelutyöntekijöiden välimuisti
• Miten päivitän palvelutyöntekijöiden välimuistin
• Mitkä selaimet tukevat palvelutyöntekijöitä?
• Mitä eroa on Service Workerilla ja Web Workerilla
• Mitä Service Worker ei voi tehdä

Miten Service Workerit toimivat?

Service Worker asettuu selaimen ja verkon väliin ja toimii ikään kuin välityspalvelimena, joka käsittelee joukon muita kuin käyttöliittymäkeskeisiä tehtäviä. Ne ovat tapahtumapohjaisia ja elävät selainprosessin ulkopuolella, jolloin ne voivat toimia ilman aktiivista selainistuntoa. Palvelutyöntekijä on skripti, joka suoritetaan säikeessä erillään käyttöliittymästä. Tämä mahdollistaa sen, että palvelutyöntekijä voi suorittaa muita kuin käyttöliittymän tehtäviä, jolloin verkkosivun suorituskyky paranee.

Palvelutyöntekijät lopetetaan, kun niitä ei käytetä, ja ne palautetaan, kun niitä tarvitaan, mikä estää niitä rasittamasta suorittimen toimintaa ja tyhjentämästä akkuja. Ne toimivat ohjelmoitavana verkkovälittäjänä eli välittäjänä selaimen ja verkon välillä, mikä antaa kehittäjille mahdollisuuden suunnitella, miten verkkopyyntöjä käsitellään.

Ykkösvoima, jonka palvelutyöntekijä tuo verkkosivulle, on mahdollisuus ottaa offline-ominaisuudet käyttöön rakeisella hallinnalla. Tämä onnistuu monipuolisen välimuistiohjausliittymän avulla ja sieppaamalla kaikki verkkopyynnöt ennen kuin ne lähtevät.

Välimuistiohjaus ei ainoastaan mahdollista offline-kokemuksia, vaan verkkosivut voivat latautua välittömästi, kun ne haetaan välimuistista. Palvelutyöntekijän välimuistitallennus tekee verkosta progressiivisen lisäyksen, tai sitä ei tarvita, jotta sivusto olisi käyttökelpoinen.

Palvelutyöntekijän laajennettavuus

Alkiarvioitu palvelutyöntekijän ominaisuus on sen laajennettavuus Palvelutyöntekijät on suunniteltu selkärangaksi, joka tukee lisätoimintoja. Kaksi ensimmäistä ominaisuutta, jotka toimitetaan selaimissa, ovat natiivit push-ilmoitukset ja taustasynkronointi. Lisää uusia API:ita käsitellään parhaillaan, ja niiden pitäisi alkaa ilmestyä selaimiin lähitulevaisuudessa.

Palvelutyöntekijät elävät omassa säikeessään, eikä niillä ole pääsyä DOM:iin. Niillä on myös oma globaali laajuus, johon viitataan ’self’-objektin avulla.

Ne edellyttävät myös, että sivusto palvellaan HTTPS:ää käyttäen. Tämä vaatimus johtuu palvelutyöntekijöiden tarjoamista tehokkaista ominaisuuksista. HTTPS estää monia yleisiä hyökkäyksiä. Nykyään kaikki sivustot tulisi palvella HTTPS:ää käyttäen, koska toteutuksen esteet on poistettu ja niiden tarjoama minimaalinen määrä turvallisuutta.

Ne ovat myös asynkronisia. Tämä tarkoittaa, että kaikki API:t tukevat lupauksia. Tämä tarkoittaa myös sitä, että tietyt API:t ja toiminnot eivät ole käytettävissä palvelutyöntekijöissä. Merkittävin on localStorage. Sen sijaan tiedot tulisi tallentaa käyttämällä IndexedDB:tä.

Palvelutyöntekijän elinkaari

Ennen kuin sukelletaan näihin loistaviin palvelutyöntekijäominaisuuksiin, kehittäjien on ymmärrettävä elinkaari.

Palvelutyöntekijä on rekisteröitävä verkkosivustolla. Koska jotkin selaimet eivät vieläkään tue palvelutyöntekijöitä, kannattaa suorittaa ominaisuuksien tarkistus ennen palvelutyöntekijän rekisteröintiä. Tämä tehdään tarkistamalla, että navigatorissa on ’serviceWorker’.

if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js') .then(function(registration) { // Registration was successful }) .catch(function(err) { // registration failed :( }); } 

Palvelutyöntekijän rekisteröimiseksi kutsutaan navigator.serviceWorker.register. Anna palvelutyöntekijän polku. Register-funktio palauttaa lupauksen.

Onnistuessaan lupaus palauttaa viittauksen palvelutyöntekijän rekisteröintiobjektiin. Sieltä käsin voit suorittaa tiettyjä käyttöliittymätehtäviä tarpeen mukaan.

Palvelutyöntekijän vakiotapahtumat

1. asenna
2. aktivoi
3. hae
4. push (Safari ei tue)
5. synkronoi
6. synkronoi

(suurin osa selaimista ei vielä tue)

Kun palvelutyöntekijä rekisteröidään, ”install”-tapahtuma. Tässä tapahtumassa yleisin tehtävä on nimeltään esivarastointi.

Esivarastointi tarkoittaa sitä, että sivun tai sivuston muodostamiseen tarvittavista omaisuuserätiedostoista laaditaan ennalta määritetty luettelo ja ne lisätään välimuistiin ennen kuin niitä pyydetään. Tämä hyödyntää palvelutyöntekijän välimuistia näiden vastausten säilyttämiseksi.

self.addEventListener("install", event => { event.waitUntil( caches.open(preCacheName) .then(function (cache) { return cache.addAll(precache_urls); }) ); }); 

Asennustapahtuma käynnistyy vain kerran palvelutyöntekijän elinaikana. Tapahtuma laukeaa uudelleen vasta, kun palvelutyöntekijä päivitetään.

Seuraava tapahtuma, joka laukeaa osana rekisteröinnin elinkaarta, on ’activate’. Kun palvelutyöntekijä asennetaan, siitä ei tule heti aktiivista. Luonnollinen järjestys on, että uusi palvelutyöntekijä odottaa, kunnes kaikki palvelutyöntekijän ’asiakkaat’ on suljettu.

Syy siihen, miksi palvelutyöntekijät on suunniteltu niin, että ne eivät ota välittömästi haltuunsa, on se, että ne eivät rikkoisi käyttäjäkokemusta.

SkipWaiting-funktio pakottaa odottavan palvelutyöntekijän aktivoitumaan. Tätä tulisi käyttää vain silloin, kun olet varma, ettei uusi palvelutyöntekijä riko olemassa olevia asiakkaita.

self.skipWaiting(); 

Kun palvelutyöntekijästä tulee aktiivinen, ’activate’-tapahtuma syttyy.

self.addEventListener("activate", event => { //on activate event.waitUntil(clients.claim()); }); 

Tätä tapahtumaa käytetään yleisesti mahdollisten siivous- tai migraatiotehtävien suorittamiseen. Esimerkiksi sellaisten vanhojen välimuistien poistaminen, jotka saattavat olla ristiriidassa uuden palvelutyöntekijän välimuistien kanssa.

Kuinka kauan palvelutyöntekijät kestävät?

Ei ole olemassa mitään tiukkaa sääntöä siitä, kuinka kauan selain pitää palvelutyöntekijän käynnissä. Selaimen sisäisesti selainmoottori käyttää joukon heuristiikkoja päättääkseen, milloin palveluntyöläisprosessi lopetetaan.

Yleisesti, jos verkkosivu on lepotilassa, prosessi pyörii alas minuutin tai kahden, ehkä jo 30 sekunnin kuluttua.

Todellisuudessa tarkka aika riippuu laitteistosta, käyttötavoista jne.

Hyvä uutinen on se, että palvelutyöntekijän käynnistäminen kestää kourallisen millisekunteja. Se on niin nopeaa, että et oikeastaan huomaa mitään latenssia. Sinun ei myöskään tarvitse ohjelmoida mitään erityistä skenaariota varten ilman palvelutyöntekijää, sivustosi vain toimii. Progressiivisen parantamisen taika.

Miten tarkistan, onko palvelutyöntekijä rekisteröity?

Palvelutyöntekijän rekisteröinnin voi tarkistaa monella tavalla. Helpointa on kutsua serviceworkers.getRegistrations-metodia.

 navigator.serviceWorker.getRegistrations().then(registrations => { console.log(registrations); });

Tämän koodin voit lisätä sivujen skriptiin kirjaamaan rekisteröinnin teknistä tukea tai kehittäjien virheenkorjausta varten.

Metodi ’getRegistrations’ palauttaa joukon kaikista palvelutyöntekijöistä, jotka on rekisteröity nykyisessä laajuudessa tai nykyisellä verkkosivustolla.

Jos olet vain kirjaamassa rekisteröintiä konsoliin, sinun olisi parempi tarkastella Dev Tools ’Application’ -välilehteä. Siinä on alipaneeli, joka näyttää visuaalisesti origon rekisteröidyn palvelutyöntekijän. Voit myös käynnistää taustasynkronointitapahtumia ja testata push-ilmoituksia.

Voit myös poistaa palvelutyöntekijän, pakottaa päivityksen ja muuta yleistä hallintaa, joka auttaa kehityksessä.

Todellinen arvo, jonka getRegistrations tarjoaa, on jonkinlainen takaportin tukitoiminto. Me kaikki tiedämme, millaista on yrittää auttaa jotakuta etänä, etkä pääse käsiksi DevTools-työkaluihin, jotta voisit oikeasti vianmääritystä tehdä. Joskus haluat jonkinlaisen visuaalisen tukisivun tai modaalin, joka antaa tietoa sovelluksen tilasta.

Keskivertokuluttaja ei osaa käyttää DevTools-konsolipaneelia. Sen sijaan voit luoda sovelluksen sisälle käyttöliittymän, jolla voit kaikuttaa palvelutyöntekijän rekisteröintiobjektin ominaisuuksia.

Miten poistan palvelutyöntekijän rekisteröinnin

Toivottavasti et törmää skenaarioon, jossa palvelutyöntekijäkoodisi on luonut käyttäjäkokemusvirheen. Siinä tapauksessa on muutamia asioita, joita voit tehdä palvelutyöntekijän poistamiseksi tai rekisteröinnin poistamiseksi.

Useimmat skenaariot, joissa sinun on poistettava palvelutyöntekijä, ovat sovellusta kehitettäessä. Tällöin voit käyttää DevTools-työkaluja palvelutyöntekijän poistamiseen tai poistamiseen.

Jos sinun on poistettava tai poistettava käyttöönotettu palvelutyöntekijä, tilanne muuttuu hieman hankalammaksi. On olemassa ohjelmallisia tapoja, joilla pääset pulasta.

Lue lisää poistotekniikoista.

Palvelutyöntekijän välimuistitallennus

Palvelutyöntekijän määrittely sisältää natiivit välimuistitallennusominaisuudet. Tämä korvaa perinteisen appCachen, joka on aiheuttanut monia hallintaongelmia sen luomisesta lähtien. Palvelutyöntekijän välimuistitallennus on paljon helpommin hallittavissa.

Välimuistitallennusliittymä tarjoaa pysyvyyskerroksen, joka tallentaa verkon vastaukset, joita voidaan kysyä vastaavalla pyynnöllä.

Välimuistitallennuksen avain palvelutyöntekijän välimuistitallennuksen käyttöön on palvelutyöntekijän ’fetch’-tapahtuma. Tämä tapahtuma laukeaa jokaisesta verkkopyynnöstä, jolloin voit siepata pyynnön ja tarkistaa, onko vastaus tallennettu välimuistiin, ennen kuin se menee verkkoon.

Käyttämällä omaisuuseriä paikallisessa välimuistissa voit luopua kalliista verkkopyynnöistä. Tämä tarkoittaa, että sivusto voi toimia, kun verkkoa ei ole, se on offline-tilassa tai verkkoyhteys on huono, palkit ovat matalat tai vääränlainen matkapuhelinyhteys (tunnetaan nimellä LiFi).

self.addEventListener("fetch", event => { event.respondWith( fetchFromCache(event) .catch(() => fetch(request) .then(response => addToCache(cacheKey, request, response)) .catch(() => offlineResponse(resourceType, opts)) ) ); }); 

Yllä olevassa esimerkissä koodi tarkistaa, onko vastaus ollut aiemmin välimuistissa. Jos näin on, välimuistissa oleva vastaus palautetaan. Jos ei, pyyntö välitetään verkkoon.

Kun pyyntö palaa, vastaus tallennetaan välimuistiin ja palautetaan käyttöliittymään.

Jos verkko ei toimi, logiikka palaa offline-vastaukseen.

Esimerkkikoodissa käytetään paljon liikkuvia osia. Annan lisää yksityiskohtia myöhemmissä artikkeleissa.

Miten päivitän palvelutyöntekijän välimuistia

Yleinen harhaluulo on, että kun verkkopyyntö on kerran tallennettu välimuistiin, se säilyy ikuisesti. Tämä ei pidä paikkaansa. Sinulla on täysi kontrolli siihen, milloin ja miten välimuisti mitätöidään ja päivitetään.

Tämä on hyvin monimutkainen ja monimutkainen aihe. Luulen, että voin henkilökohtaisesti eritellä noin kolme tusinaa välimuistististrategiaa, joihin kaikkiin liittyy tapa hallita välimuistin mitätöintiä tai päivittämistä.

Luulen, että avain mitätöintiin on joko mitätöintiajan (time to live) arvon, manifestin tai taustapäivitysprosessin määrittäminen. Jälkimmäisessä voit tehdä HEAD-pyynnön nähdäksesi, onko palvelimella tehty päivitys vertaamalla viimeisimmän päivitetyn otsikon arvoa vastauksen välimuistiin tallennusajankohtaan.

Ei ole olemassa yhtä ainoaa vastausta jokaiseen sovellukseen. Sinun on suunniteltava strategiasi ja oltava valmis mukauttamaan sitä, kun näet, miten sovellustasi käytetään.

Mitkä selaimet tukevat palvelutyöntekijöitä?

Kaikki nykyaikaiset selaimet tukevat palvelutyöntekijöitä, ainakin välimuistitallennusta. Chrome, FireFox ja Edge tukevat natiiveja push-ilmoituksia ja Chromessa ja Edgessä on taustasynkronointituki.

Tämä tarkoittaa, että keskeiset PWA-ominaisuudet ovat käytettävissä kaikissa laitteissa ja selaimissa. Push ja taustasynkronointi ovat parannuksia.

Olemme rakentaneet useita progressiivisia verkkosovelluksia, jotka vaativat kehittyneitä offline-välimuistiinpanostrategioita, jotta sovellukset toimisivat offline-tilassa, jopa iOS:ssä. Nämä sovellukset vaativat, että kaikki pyynnöt, jopa POST-, PUT- ja DELETE-toiminnot, tallennetaan välimuistiin jonoon. Saimme nämä sovellukset synkronoitua jopa iOS:ssä, kun yhteyksien tiedettiin olevan käytettävissä.

Mitä eroa on Service Workerilla ja Web Workerilla

Service Workerit ja Web Workerit ovat samanlaisia työkaluja. Molemmat suorittavat prosesseja käyttöliittymästä erillisessä säikeessä. Todellinen ero on todellisessa käyttökontekstissa.

Kummallakaan ei ole pääsyä DOM- tai ikkunaobjektiin. Ne ovat parempia keskitason tai pitkiä, prosessi-intensiivisiä tehtäviä varten.

Webworkerit suoritetaan vain silloin, kun verkkosivu on avoinna ja tehtävä käynnistetään sivulla olevasta skriptistä.

Palvelutyöntekijä voi myös suorittaa sivun ollessa avoinna, mutta sen voi käynnistää myös alustan tapahtuma, kuten push-ilmoitus. Verkkosivun ei tarvitse olla auki, jotta palvelutyöläinen voi suorittaa.

Palvelutyöläiset toimivat myös välittäjinä verkon ja käyttöliittymän välillä. Jos käytetään sivua (yleisin skenaario), kaikki HTTPS-verkkopyynnöt kulkevat palvelutyöläisen kautta, kuten opit välimuistitallennusta käsittelevässä osiossa.

Käyttöliittymän ja molempien työläisten välinen kommunikointi tapahtuu postMessage-metodin ja message-tapahtuman avulla. Jos olet tehnyt monisäikeistä ohjelmointia, tämä malli on hyvin tuttu.

Mitä palvelutyöntekijä ei voi tehdä

Palvelutyöntekijät eivät pääse käsiksi ikkunaobjektiin

Ikkunaobjekti suoritetaan UI-säikeessä, erillään palvelutyöntekijäsäikeestä. Tämä tarkoittaa, että palvelutyöntekijä ei voi suoraan käsitellä DOM-elementtejä. Palvelutyöntekijä ja ikkuna voivat kommunikoida postMessage-metodin kautta. Tämä mahdollistaa viestien välittämisen edestakaisin. Kummallakin puolella on oltava logiikka, joka käsittelee viestejä ja käynnistää erilaisia työnkulkuja.

Palvelutyöntekijät vaativat HTTPS:n

Koska palvelutyöntekijöillä on niin paljon valtaa, ne otetaan käyttöön vain, jos sivu palvellaan HTTPS:ää käyttäen. Näin varmistetaan tietty turvallisuustaso, jotta Service Worker voi tehdä niitä asioita, joita se on suunniteltu tekemään.

HTP:n kautta service worker olisi altis man in the middle -hyökkäyksille. Kehittäjät voivat työskennellä localhostilla, mikä estää meitä asentamasta paikallista TLS-varmentetta.

Muilla sanoilla vastaus kysymykseen toimiiko palvelutyöntekijä HTTP:llä on ei. Sivusto renderöi edelleen, mutta service worker ei rekisteröidy eikä sitä suoriteta.

Ovat vain asynkronisia

Service workerit ovat asynkronisia, mikä tarkoittaa, että ne käyttävät Promises-ohjelmia ja Promises-ohjelmia käyttäviä API:ita ja luottavat niihin. Tämä tarkoittaa, että synkroniset API:t, kuten XHR ja localStorage, eivät ole palvelutyöntekijän käytettävissä. Ei hätää, voit käyttää Fetch API:ta (joka korvasi XHR:n) ja IndexedDB:tä. Useimmat API:t, jotka eivät ole suoraan vuorovaikutuksessa ikkunaobjektin kanssa, ovat käytettävissä service workerissa.