Aanbevolen procedures voor instellingen voor cachebeheer voor uw website

Het is je misschien opgevallen dat, wanneer je een site voor de tweede keer bezoekt, deze er niet uitziet zoals verwacht en sommige stijlen kapot zijn, waardoor alles er raar uitziet. Gewoonlijk is de oorzaak van dit probleem slecht gedefinieerd cachebeleid dat voorkomt dat u de laatste wijzigingen ontvangt na de meest recente implementatie. In dit artikel zal ik u de juiste cache-instellingen en technieken tonen om u te helpen uw website voor elke gebruiker up-to-date te houden na elke implementatie.

Voor degenen onder u die gewoon de best practices willen krijgen en deze willen gaan gebruiken, volgt u de link hier naar het einde van het artikel.

Hoe werkt de cache achter de schermen?

Uw browser probeert bij elk verzoek aan de website / resource zo min mogelijk gegevens te laden door in het cachegeheugen opgeslagen informatie uit het lokale geheugen te lezen. Dit is alleen mogelijk, we bieden voldoende instructies voor de browser om uit te leggen welke bronnen deze moet behouden en voor hoe lang.

Deze instructies fungeren als richtlijnen; om uw browser hierover te informeren, moet u ze toevoegen aan de HTTP-informatie van de reactie. De meest voorkomende richtlijnen die bij het cacheproces betrokken zijn, zijn "Cache-Control", "Expires", "Etag" en "Last-Modified".

Bijna elke webserver heeft standaard enkele cache-instellingen in koptekstantwoorden, maar het is niet duidelijk wat we krijgen als er geen cachebeleid is.

Zonder instellingen voor cachebeheer gaat de browser naar de webserver voor elk verzoek om bronnen en leest daar informatie van. Dit verhoogt de laadtijden van de getroffen site, voegt extra belasting toe aan uw webserver bij het overdragen van informatie en verhoogt het aantal oproepen naar uw backend.

Verzoeken stroom zonder cache-instellingen

Het is aan de browser om te beslissen wat te doen en hoe informatie te cachen zonder instructies van de server. Momenteel downloaden Chrome en Safari elke keer gegevens uit de backend, zonder cache-instructies. Dit kan echter veranderen en tot ander gedrag leiden, vooral op andere platforms.

Laten we, om duidelijk te definiëren wat te doen met bepaalde bestanden, diep ingaan op de richtlijnen voor het leren van cache, deze stapsgewijs toevoegen aan antwoordkoppen en kijken naar het resultaat.

Etag (entiteitstag)

Etag is een van de cache-instellingen. Het belangrijkste idee achter deze HTTP-header is om uw browser op de hoogte te houden van wijzigingen in relevante bronnen zonder volledige bestanden te downloaden. De server kan iets soortgelijks berekenen met de hash-som van elk bestand en deze hash-som vervolgens naar de client verzenden. De volgende keer dat de client toegang probeert te krijgen tot deze bron, in plaats van het bestand te downloaden, verzendt de browser iets als dit in de HTTP-header: If-None-Match: W / “1d2e7–1648e509289”. De server zal deze hash-som vervolgens vergelijken met de hash-som van het huidige bestand en, als er verschil is, de client dwingen een nieuw bestand te downloaden. Anders wordt de client geïnformeerd dat deze een versie in de cache moet gebruiken.

Verzoeken stroom met Etag - 1e ladingVerzoekstroom met Etag - 2e lading

Met een Etag-cachebeleid ingeschakeld, gaan we altijd naar de server om de hash-som van een bestand te controleren en pas daarna zal de browser beslissen om het uit de cache te halen of het volledig te laden. Wanneer een bron niet is gewijzigd, zijn er slechts 80-100 bytes nodig om te verifiëren, ongeacht wat u aanvraagt, of dit nu een bestand van 10 KB of 10 MB is.

Laatst gewijzigd

Een andere cache-instelling is de "Last Modified" HTTP-header. Het hoofdidee lijkt erg op Etag, maar het gedrag van de browser is een beetje anders. Servers hebben een tijdstempel van de laatste gewijzigde datum voor elk bestand; na het laden van het eerste bestand, kan de client de server vragen of de bron is gewijzigd sinds het specifieke moment waarop de bestanden voor het laatst door de client zijn geopend. Hiertoe verzendt de browser If-Modified-Since: vr, 13 jul 2018 10:49:23 GMT in de HTTP-header. Als de bron is gewijzigd, moet de browser een nieuw bestand downloaden, anders gebruikt hij een versie in de cache.

De realiteit is dat browsers hun interne cachebeleid hebben en zelf kunnen beslissen of ze een bron uit de cache nemen of een nieuwe kopie downloaden.

Last-Modified is een zwakke caching-header, omdat de browser een heuristiek toepast om te bepalen of het item uit de cache moet worden opgehaald of niet, en de heuristiek varieert tussen browsers.
Handleiding met praktische tips voor Google-caching
Verzoeken stroom met Last-Modified - 1e ladingVerzoeken stroom met Last-Modified - 2e lading (Perfect Scenario)Verzoekstroom met Last-Modified - 2e lading (veel voorkomend geval)

Als gevolg hiervan kunnen we niet alleen op Last-Modified vertrouwen, dus ik geef er de voorkeur aan deze volledig uit mijn serverinstellingen te verwijderen om het verkeer te verminderen, zelfs als het maar enkele bytes zijn.

Cache-Control max-leeftijd

Met deze richtlijn kunnen we de browser vertellen hoe lang het bestand in de cache moet blijven sinds de eerste keer laden. De tijd dat de browser het bestand in de cache moet bewaren, moet in seconden worden gedefinieerd, meestal weergegeven als deze Cache-Control: max-age = 31536000. Met dit beleid slaat de browser het proces van het indienen van verzoeken aan uw server volledig over en worden bestanden zeer snel geopend. Maar hoe kunnen we er zeker van zijn dat het bestand zo lang niet zal veranderen? Wij niet.

Dus, om de browser te dwingen een nieuwe versie van het benodigde bestand te downloaden, gebruiken we een techniek die wordt geïmplementeerd door veel tools voor het bouwen van middelen, zoals Webpack of Gulp. Elk bestand wordt vooraf gecompileerd op de server en hash-bedragen worden toegevoegd aan de bestandsnamen, zoals "app-72420c47cc.css". Zelfs kleine wijzigingen in het bestand worden weerspiegeld in de hash-som, wat garandeert dat het als anders wordt herkend. Na de implementatie krijgt u dus een nieuwe versie van het bestand. Dit kan van toepassing zijn op al onze CSS-, JS- en afbeeldingsbestanden (max-age = 31536000); nadat we iets hebben gewijzigd, vraagt ​​de browser gewoon om een ​​nieuw bestand met een nieuwe hash-som, die het vervolgens in de cache opslaat.

no-cache

Het lastige deel van de bovenstaande techniek is dat je je html-bestanden niet kunt vergeten; Als je die instelling ook op die instellingen toepast, krijg je nooit nieuwe links voor je CSS-, JS- of afbeeldingsbestanden totdat je een herlaadbeurt forceert.

Ik raad u aan Cache-Control: no-cache toe te passen op HTML-bestanden. Het gebruik van "no-cache" betekent niet dat er helemaal geen cache is, het vertelt de browser eenvoudig om middelen op de server te valideren voordat het uit de cache wordt gebruikt. Daarom moeten we het gebruiken met Etag, dus browsers sturen een eenvoudig verzoek en laad de extra 80 bytes om de status van het bestand te verifiëren.

Laatste instellingen

  • Gebruik Gulp, Webpack of iets dergelijks om unieke hash-cijfers toe te voegen aan uw css-, js- en afbeeldingsbestanden (zoals app-67ce7f3483.css);
  • Voor js, css en afbeeldingsbestanden stelt u Cache-Control in: public, max-age = 31536000, geen Etag, geen Last-Modified instellingen.
  • Gebruik voor html-bestanden Cache-Control: no-cache en Etag.

Dus zoals we kunnen zien, zijn zelfs voor de hand liggende en veel voorkomende dingen, zoals het opslaan van statische bestanden, niet vanzelfsprekend als we dieper duiken. Goed onderzoek kan voorkomen dat u fouten maakt en verkeer op uw server verminderen, waardoor de laadsnelheid van de sitesnelheid wordt verkort.

Tik op de -knop als u dit artikel nuttig vond!

Heeft u vragen of feedback? Maak verbinding via Pixel Point