In deze documentatie is eerder sprake geweest van precaching , maar niet genoeg over hoe u dit op de juiste manier kunt doen. Dit is belangrijk, want ongeacht of u Workbox gebruikt, kunt u gemakkelijk te veel precaches maken en mogelijk gegevens en bandbreedte verspillen. U moet voorzichtig zijn met de manier waarop uw precaching-payload de gebruikerservaring beïnvloedt.
Terwijl u dit document leest, moet u begrijpen dat dit algemene richtlijnen zijn. Uw applicatiearchitectuur en -vereisten vereisen mogelijk dat u dingen anders doet dan hier wordt voorgesteld, maar deze richtlijnen dienen als goede standaarden.
Doen: kritieke statische assets vooraf in cache plaatsen
De beste kandidaten voor precaching zijn kritische statische assets, maar wat telt als een 'kritieke' asset? Vanuit het perspectief van een ontwikkelaar kan het verleidelijk zijn om een hele applicatie als 'kritiek' te beschouwen, maar het perspectief van de gebruiker is het allerbelangrijkste. Beschouw kritische assets als zaken die absoluut noodzakelijk zijn om een gebruikerservaring te bieden:
- Globale stijlbladen.
- JavaScript-bestanden die globale functionaliteit bieden.
- Applicatieshell HTML, als dat van toepassing is op uw architectuur.
Let op: dit zijn algemene richtlijnen, geen harde aanbevelingen. Bij het vooraf cachen van assets kunt u het beste kiezen voor minder in plaats van meer.
Doen: precache een offline fallback voor websites met meerdere pagina's
Voor typische websites met meerdere pagina's vertrouwt u mogelijk op een netwerk-eerst of netwerk-alleen caching-strategie om navigatieverzoeken af te handelen.
In dergelijke gevallen wilt u er zeker van zijn dat uw servicemedewerker de cache vooraf in de cache plaatst en reageert met een offline reservepagina wanneer de gebruiker offline een navigatieverzoek indient. Een manier om dit in Workbox te doen is door een netwerkstrategie te gebruiken met een offline fallback, waarbij ook gebruik wordt gemaakt van de vooraf geladen navigatie :
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
Dit zorgt ervoor dat als een gebruiker offline gaat en naar een pagina navigeert die niet in de cache staat, hij of zij op zijn minst wat offline inhoud te zien krijgt.
Misschien wel: overweeg speculatieve precaching
Dat is een groot 'misschien', maar er zit een potentieel voordeel in het vooraf cachen van assets die alleen in bepaalde scenario's worden gebruikt. Denk er eens op deze manier over na: gebruikers zullen vooraf een aantal extra gegevensdownloads moeten uitvoeren, met als speculatief voordeel dat toekomstige verzoeken om die activa sneller zullen worden aangevraagd.
Nu het grote voorbehoud: wees heel voorzichtig als u besluit dit te doen. Het is gemakkelijk om daarbij gegevens te verspillen, en het moet een datagestuurde beslissing zijn. Vermijd bovendien het speculatief vooraf cachen van assets die vaak veranderen, omdat de gebruiker extra gegevensgebruik zal oplopen elke keer dat de precaching-code een nieuwe revisie detecteert. Observeer gebruikersstromen in uw analyses om te zien waar gebruikers naartoe gaan. Als u twijfels heeft over het speculatief vooraf cachen van activa, is dat waarschijnlijk een goed teken om het niet te doen.
Misschien niet doen: statische HTML vooraf cachen
Deze richtlijn is meer van toepassing op statische sites waar afzonderlijke HTML-bestanden worden gegenereerd door een statische sitegenerator of handmatig worden gemaakt, in plaats van dynamisch te worden gegenereerd of geleverd door een applicatie-backend. Als dit uw architectuur beschrijft, is het waarschijnlijk het beste als u niet elk HTML-bestand voor uw website vooraf in de cache plaatst.
Een probleem met het vooraf in de cache plaatsen van de HTML-bestanden van een hele site is dat de opmaak die nu in de cache wordt geplaatst, altijd later vanuit de cache wordt weergegeven totdat de servicemedewerker is bijgewerkt. Dit is geweldig voor de prestaties, maar kan leiden tot aanzienlijk cacheverloop als de HTML van uw website regelmatig verandert.
Er zijn echter een paar uitzonderingen op deze regel. Als u een kleine website met een paar statische HTML-bestanden implementeert, is het waarschijnlijk prima om al deze pagina's vooraf in de cache op te slaan, zodat ze offline beschikbaar zijn. Als u een bijzonder grote website heeft, overweeg dan speculatief een paar waardevolle pagina's vooraf te cachen en een offline fallback, en vertrouw op runtime caching om andere pagina's voor u in de cache op te slaan.
Niet doen: responsieve afbeeldingen of favicons vooraf in de cache plaatsen
Dit is minder een algemene richtlijn en meer een regel. Responsieve afbeeldingen zijn een complexe oplossing voor een complex probleem: je hebt veel gebruikers op veel apparaten, elk variërend in schermgrootte, pixeldichtheid en ondersteuning voor alternatieve formaten. Als u een hele reeks responsieve afbeeldingen vooraf in de cache plaatst, precacht u waarschijnlijk meerdere afbeeldingen terwijl de gebruiker er uiteindelijk maar één downloadt.
Favicons presenteren een vergelijkbare situatie, in die zin dat websites vaak een hele reeks favicons inzetten voor verschillende scenario's. Meestal wordt slechts één favicon aangevraagd, waardoor het vooraf cachen van een hele favicon-set net zo verspillend is.
Doe uw gebruikers een plezier en plaats responsieve afbeeldingen en faviconsets niet vooraf in de cache. Vertrouw in plaats daarvan op runtime-caching. Als u afbeeldingen vooraf in de cache moet plaatsen, cache dan veelgebruikte afbeeldingen die geen deel uitmaken van een reeks responsieve afbeeldingen of favicons. SVG's zijn minder riskant in termen van datagebruik; een enkele SVG wordt optimaal weergegeven, ongeacht de pixeldichtheid van een bepaald scherm.
Niet doen: polyfills vooraf cachen
Variërende browserondersteuning voor API's is een aanhoudende uitdaging voor webontwikkelaars, en polyfilling is een van de manieren waarop deze uitdaging wordt aangegaan. Eén manier om de prestatiekosten van polyfills te minimaliseren is door functiecontroles uit te voeren en alleen polyfills te laden voor de browsers die ze nodig hebben.
Omdat het voorwaardelijk laden van polyfills tijdens runtime gebeurt met betrekking tot de huidige omgeving, is het precachen van polyfills een gok. Sommige gebruikers zullen hiervan profiteren, terwijl anderen uiteindelijk bandbreedte verspillen aan onnodige polyfills.
Plaats polyfills niet vooraf in de cache. Vertrouw op runtime-caching om ervoor te zorgen dat ze alleen in de cache worden opgeslagen in browsers die dit vereisen om gegevensverspilling te voorkomen.
Conclusie
Precaching vereist vooraf nadenken over welke middelen uw gebruikers daadwerkelijk nodig hebben, maar u kunt dit zeker goed doen op een manier die prioriteit geeft aan toekomstige prestaties en betrouwbaarheid.
Als u niet zeker weet of bepaalde assets vooraf in de cache moeten worden geplaatst, kunt u het beste Workbox vertellen deze assets uit te sluiten en een runtime-cacheroute te maken om ze af te handelen. Hoe dan ook, precaching wordt verderop in deze documentatie gedetailleerd besproken , zodat u deze principes in de toekomst op uw precaching-logica kunt toepassen.