Het inzetten van een servicemedewerker kan het gedrag van een website op onverwachte manieren veranderen. Omdat Workbox het eenvoudig maakt om een servicemedewerker te schrijven en in te zetten, kan het gemakkelijker zijn om enkele effecten te missen die een servicemedewerker op een website heeft zodra deze is geïmplementeerd.
Dit betekent niet dat het gebruik van Workbox tot slechte resultaten leidt, maar wel dat het gemak dat het biedt ervoor kan zorgen dat je gemakkelijker in valkuilen terechtkomt als je niet weet wat er komt kijken bij het inzetten van een servicemedewerker.
Valkuilen voorkomen
Precaching is eerder in deze documenten besproken, zonder volledig in te gaan op de vraag hoe deze praktijk averechts kan werken. Er kunnen problemen optreden als u precaching op te veel assets toepast, of als de servicemedewerker wordt geregistreerd voordat de pagina de kans heeft gehad om het laden van kritieke assets te voltooien.
Omdat het standaardgedrag van workbox-webpack-plugin is om de servicemedewerker te instrueren om gegenereerde assets automatisch vooraf in de cache op te slaan, kan dit problematisch zijn op een manier die gemakkelijk over het hoofd wordt gezien, omdat de drempel voor adoptie laag is.
workbox-webpack-plugin. In dit voorbeeld worden standaard 14 assets in het huidige project vooraf in de cache geplaatst, met een totaal van in totaal 352 kilobytes.Wanneer een servicemedewerker tijdens de installatie assets vooraf in de cache plaatst, worden tegelijkertijd een of meer netwerkverzoeken gestart. Dit kan problematisch zijn voor de gebruikerservaring als het niet op het juiste moment wordt getimed. Zelfs als de timing precies goed is, kan er nog steeds data worden verspild als de hoeveelheid vooraf in de cache opgeslagen assets niet op de een of andere manier wordt beperkt.
Het zit allemaal in de timing
Als een servicemedewerker iets precacheert, is het tijdstip waarop het wordt geregistreerd van belang. Servicemedewerkers worden vaak geregistreerd met behulp van inline <script> -elementen. Dit betekent dat HTML-parsers de registratiecode van servicemedewerkers kunnen ontdekken voordat de kritieke elementen van de pagina zijn geladen.
Dit is een probleem. Een servicemedewerker moet in het ergste geval idealiter prestatieneutraal zijn en de prestaties niet verslechteren. Doe gebruikers een plezier en registreer een servicemedewerker wanneer de laadgebeurtenis van de pagina load . Dit verkleint de kans dat precaching het laden van de kritieke assets van een pagina verstoort, wat op zijn beurt betekent dat de pagina sneller interactief kan worden zonder te maken te krijgen met netwerkverzoeken voor assets die misschien pas later nodig zijn.
Houd rekening met datagebruik
Ongeacht de timing omvat precaching het verzenden van netwerkverzoeken. Als een manifest van activa die vooraf in de cache moeten worden geplaatst, niet zorgvuldig is samengesteld, kan het resultaat een bepaalde hoeveelheid verspilling zijn.
Verspilde gegevens zijn een potentiële afweging van precaching, maar niet iedereen heeft toegang tot snel internet of zelfs onbeperkte data-abonnementen! Overweeg bij precaching vooral grote assets te verwijderen en vertrouw op runtime caching om ze vast te leggen in plaats van dure aannames te doen.
Het opstarten van servicemedewerkers kan netwerkaanvragen vertragen
Servicemedewerkers worden in een ander proces uitgevoerd dan de rest van de code van een website. Dit proces start en stopt regelmatig. Wanneer een servicemedewerker een ophaalgebeurtenis moet afhandelen nadat hij inactief is geweest, moet de browser eerst tijd besteden aan het opstarten van de servicemedewerker. Deze extra overhead voordat een verzoek kan worden afgehandeld, is klein vergeleken met het voordeel van het leveren van een antwoord vanuit de cache in plaats van vanuit het netwerk.
Bij het gebruik van strategieën die niet vanuit de cache kunnen werken en naar het netwerk moeten gaan (vooral bij het afhandelen van navigatieverzoeken ) voegt de opstarttijd altijd enige vertraging toe . Afhankelijk van de mogelijkheden van het apparaat en/of de CPU-druk kan een navigatieverzoek een merkbare vertraging ondervinden als gevolg van het langzaam opstarten van servicemedewerkers. Als u een servicemedewerker inzet zonder dat u zich bewust bent van deze vertraging, kunnen gebruikers onbedoeld prestatieproblemen ondervinden.
Dit probleem is opgelost met Navigation Preload , maar wordt nog niet in alle browsers ondersteund . Het gebruik ervan is echter het overwegen waard, en wordt verderop in deze documentatie besproken.
Cache-first-strategieën kunnen averechts werken
Cachingstrategieën die eerst de cache raadplegen (of alleen de cache raadplegen) zijn geweldig voor zowel offline toegang als prestaties. In bepaalde gevallen veroorzaken ze echter vaak problemen.
Runtimecaching van statische assets zonder versiebeheer
Bundelaars geven statische assets doorgaans een versie met een op inhoud gebaseerde hash in de bestandsnaam (bijvoorbeeld styles.a4edf38c.css ). Bij servicemedewerkers die cachingstrategieën gebruiken die eerst de cache raadplegen voor statische assets, en een netwerk-eerst-strategie gebruiken voor pagina-opmaak, zouden er geen caching-problemen moeten zijn, omdat naar bijgewerkte assets wordt verwezen in de opmaak die altijd uit het netwerk wordt opgehaald.
Er doen zich problemen voor in situaties waarin statische assets zonder versiebeheer tijdens runtime in de cache worden opgeslagen met behulp van deze strategieën. Als de functionaliteit van een website wordt geleverd door app.js en er een cache-first runtime-strategie wordt gebruikt, wordt app.js later bijgewerkt zonder dat de bestandsnaam wordt gewijzigd. De aanvankelijk in de cache opgeslagen versie wordt nog steeds vanuit de cache aangeboden in plaats van bijgewerkt.
De oplossing is om een strategie te gebruiken die het netwerk raadpleegt voor updates, zoals netwerk-eerst of verouderd-terwijl-revalideren. Als alternatief kunnen buildtools een precache-manifest voor deze assets genereren, omdat de precaching-logica van Workbox ze up-to-date houdt.
Hoe dan ook, overweeg sterk om versies van statische assets te beheren, hetzij door een hash in de assetnaam, hetzij in de queryreeks. Dit voorkomt problemen met verouderde assets bij servicemedewerkers die cache-first runtime-strategieën gebruiken voor statische assets.
Houd rekening met opslagquota
Het is gebruikelijk om van tijd tot tijd updates voor servicemedewerkers uit te rollen, en wanneer updates worden uitgerold, worden oude caches met verlopen namen meestal opgeschoond tijdens de activering van de nieuwe servicemedewerker.
Sommige service worker-iteraties hebben echter een lange levensduur, of cachenamen worden mogelijk niet bijgewerkt in nieuwe updates. Wanneer dit gebeurt, kunnen oude statische assets zich opstapelen in caches terwijl er updates voor worden uitgerold. Browsers stellen opslagquota in en de limieten kunnen variëren. Dat is een goede reden om er rekening mee te houden!
Workbox kan deze problemen goed verhelpen, maar opslagquota kunnen nog steeds worden overschreden. Met de workbox-expiration-module kunt u de caches nauwkeuriger beheren.
Geen schrik hebben
Het inzetten van een servicemedewerker is geen kleinigheid. Toch zou het geen beangstigende prestatie moeten zijn als je een beetje planning en oplettendheid hebt over wat het inzetten van een servicemedewerker met Workbox inhoudt. Naarmate u verdergaat, zal deze documentatie u helpen om met zorg en vertrouwen door deze problemen heen te komen.