Maak je site sneller met Fastest Cache - Cache Varnish

Procédure

Waarom de laadsnelheid van je site versnellen?

Het is goed om te weten dat de laadsnelheid van je site cruciaal is voor het succes ervan. Voor een bedrijf geeft het bijvoorbeeld een eerste indruk aan bezoekers. Bovendien, als het laden van uw site te lang duurt , kan dit invloed hebben op de ranking in de belangrijkste zoekmachines en krijgt u niet genoeg exposure om uw site in leven te houden.

Er staat geen limiet op de laadtijd van je webpagina's. De meeste websites hebben echter minder dan drie seconden nodig om te laden.

Wat is Fastest Cache en waarvoor wordt het gebruikt?

De Fastest Cache tool is een systeem dat is ontworpen en ontwikkeld door LWS omde laadprestaties van je website te optimaliseren door het gebruik van pagina caching mechanismen die zijn geconfigureerd op webserver niveau. De tool combineert de technologieën van NGINX en Varnish.

NGINX is een prestatiegerichte webserver die veel meer aanvragen kan verwerken dan Apache (zie onze blogpost getiteld"Apache VS Nginx: Prestatietest"). Het wordt voornamelijk gebruikt op Fastest Cache om beveiligde toegang tot je site te beheren op https://, schadelijke HTTP-verzoeken te elimineren (zie LWS Protect) en HTTP-verzoeken te routeren naar Varnish-cache servers.

Varnish is een HTTP-service die een mechanisme voor het cachen van pagina's implementeert om het resultaat van een HTTP-aanvraag in het geheugen op te slaan.

Met de juiste configuraties kan NGINX meer aanvragen naar je website verwerken en kan Varnish het laden van pagina's versnellen en tegelijkertijd het CPU- en geheugenverbruik verminderen.

Hoe werkt de Fastest Cache service?

1. Werking zonder cache

Om beter te begrijpen hoe het werkt, zullen we beginnen met te kijken hoe het werkt zonder een cache plugin, zodat bezoekers je site kunnen zien.

1. De bezoeker vraagt de pagina op van de webserver. Voorbeeld: index.php

2. De webserver voert de nodige scripts uit (PHP, Perl, NodeJS, enz.)

3. De webserver ontvangt het resultaat van de uitvoering

4. De webserver verstuurt de HTML-pagina die het resultaat is van de uitvoering van het script.

2. Werking met de Fastest Cache-module

Als Fastest Cache geactiveerd is, wordt er een cache-server tussen de bezoeker en de webserver geplaatst.

Het doel is om het aantal benodigde scriptuitvoeringen te verminderen door het resultaat van de uitvoering in het geheugen te bewaren voor toekomstige verzoeken die hetzelfde antwoord vereisen. Hierdoor hoeft hetzelfde script niet meerdere keren te worden uitgevoerd om hetzelfde resultaat te bereiken.

Dit elimineert de tijd die wordt besteed aan het wachten tot het script is uitgevoerd tijdens het laden van de pagina en bespaart tegelijkertijd de bronnen die worden gebruikt tijdens het uitvoeren van het script.

1. De bezoeker vraagt de pagina op bij de webserver. Voorbeeld: index.php
2. Fastest Cache controleert of de pagina al is aangemaakt en opgeslagen in het cachegeheugen.

• Zo ja, dan wordt de pagina direct teruggestuurd naar de bezoeker zonder de webservice te hoeven benaderen en zonder het script uit te voeren.
• Zo niet, dan wordt de pagina opgevraagd om te worden gegenereerd op de webservice, wat resulteert in de uitvoering van het script (PHP, NodeJS, Perl, Ruby, enz.).

3. Zodra de pagina is gegenereerd, bepaalt Fastest Cache of de pagina in de cache kan worden opgeslagen (via headers, URL, enz.).

• Zo ja, dan wordt de pagina opgeslagen in de cache en teruggestuurd naar de bezoeker.
• Zo niet, dan wordt de pagina opgeslagen in het microcachegeheugen (cachegeheugen met een korte geldigheidsperiode) en teruggestuurd naar de bezoeker.

We kunnen zien dat wanneer een pagina in het cachegeheugen wordt opgeslagen, verwerking door de webserver en het uitvoeren van scripts worden vermeden.

Cacheerbaar, niet-cacheerbaar en microcache

Wanneer de webservice een nieuw antwoord aan Fastest Cache geeft, wordt dit geanalyseerd om te bepalen of het wel of niet in het cachegeheugen bewaard moet worden voor toekomstig gebruik.

Sommige pagina-inhoud mag niet in de cache worden opgeslagen, zoals het resultaat van een registratieformulier, het resultaat van een betaalpagina, enz. omdat deze gegevens bevatten die variëren afhankelijk van gebruikers en gebeurtenissen.

Om te bepalen of een pagina al dan niet in de cache kan worden geplaatst, gebruikt Fastest Cache verschillende mechanismen:

• HTTP-verzoeken met andere HTTP-werkwoorden dan HEAD en GET worden systematisch uitgesloten van de cache.
• HTTP-verzoeken met cookies worden ook uitgesloten. Cookies die worden gebruikt door Google Analytics, XiTi, DoubleClick, Quant Capital, AddThis en Cloudflare worden verwijderd voordat ze worden gedetecteerd. Op dezelfde manier worden cookies die zijn gekoppeld aan bekende CMS automatisch beheerd als de cachingmodus overeenkomt met het CMS.
• HTTP-verzoeken beschermd door .htaccess-wachtwoorden
• Als het antwoord van de webserver cache-instructies voor de browser bevat (header cache-control), wordt hier automatisch rekening mee gehouden door Fastest Cache en wordt de pagina in het cachegeheugen bewaard.

Als een HTTP-verzoek van het type GET is en niet wordt beschermd door .htaccess of cookies bevat, en geen specifieke browser cache-instructies heeft, wordt het enkele seconden in de microcache bewaard.

De microcache kan daarom gebruikt worden om pieken in de vraag naar niet-gecacheerde pagina's op te vangen. Dit lost bijvoorbeeld het probleem op van overbelasting en traagheid bij een golf van zoekopdrachten naar hetzelfde product op een e-commercewinkel.

Presentatie van de interface en activering van de service

Fastest Cache verschijnt als een pictogram in cPanel in de sectie "Prestaties".

Eenmaal in de interface worden het hoofddomein, extra domeinen en subdomeinen in de lijst weergegeven.

• De kolom"Cachestatus" toont de activeringsstatus van de cache. Als deze is ingesteld op"Ingeschakeld", dan is de cache geactiveerd.
• De knop"Cache wissen" verwijdert alle cachegegevens voor deze specifieke domeinnaam.
• De knop"Deactiveer cache" wordt gebruikt om caching uit te schakelen.
• De knop"Cache inschakelen" schakelt caching in.
• De knop"Bedrijfsmodus wijzigen" wordt gebruikt om het gedrag van het caching-systeem te wijzigen. Deze modi worden kort daarna uitgelegd.

De verschillende cache modi

Standaard kiest het cachingsysteem voor de modus "Algemeen gebruik ", die geschikt is voor algemeen gebruik. Er zijn echter nog andere modi:

Ontwikkelaarsmodus: identiek aan het uitschakelen van de cache, hiermee kun je het cache-systeem uitschakelen tijdens je ontwikkelingsperioden.
WordPress: een cachingmodus die beter geschikt is voor WordPress, met verbeterd beheer van mappen (wp-content, wp-admin, enz.) en cookies die specifiek zijn voor WordPress.
Prestashop : een cachingmodus die beter geschikt is voor Prestashop, met verbeterd beheer van mappen en cookies.

Cache wissen

Naast de cPanel-interface voor het wissen van de cache, is het mogelijk om de cache handmatig te wissen vanaf de SSH-terminal van het cPanel-account of vanaf een script dat op de server wordt gehost.

1. De cache wissen met cURL

Om de cache van een pagina te wissen :

curl -X 'PURGE' http://mon-site-web.com/mapage.php

Dit wist de cache van de URL http://mon-site-web.com/mapage.php.

De cache van een map wissen :

curl -X 'PURGE -H 'X-Purge-Method:regex' 'http://mon-site-web.com/wp-content/uploads/.*'

Dit wist alle caches van URL's die beginnen met 'http://mon-site-web.com/wp-content/uploads/'.

De cache van een site wissen

curl -X 'FULLPURGE' http://mon-site-web.com

Voor alle drie de commando's zijn twee retours mogelijk:

HTTP-code 200: het zuiveren is gelukt, zonder fouten.

HTTP-code 405: zuiveren is niet toegestaan of heeft niet plaatsgevonden.

2. Zuiveren met een plugin of module

De meeste plugins/modules met Varnish-integratie zijn compatibel met het interne zuiveringsmechanisme van Fastest Cache.

Hier zijn een paar plugins die zijn getest en geverifieerd als compatibel:

• WP Rocket: https: //wp-rocket.me
• Proxy Cache Purge: https: //wordpress.org/plugins/varnish-http-purge/

HTTPS-detectie en omleidingen

De HTTPS-status en -poorten die op Apache worden aangegeven, worden gewijzigd door de mod_fastestcache-module die in Apache is ingebouwd. Het is daarom over het algemeen niet nodig om wijzigingen aan te brengen.

Als HTTPS-detectie echter niet functioneel is met Fastest Cache, kan dit oneindige omleidingslussen veroorzaken. Het zal daarom nodig zijn om de detectiegegevens aan te passen.

De vertrouwde HTTP-headers voor detectie zijn :

• X-Forwarded-Proto
• X-Forwarded-Port

Dus als je de volgende HTTPS-omleiding gebruikt met een .htaccess :

RewriteEngine On RewriteCond %{SERVER_PORT} ^80$ RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

en het werkt niet, kunt u de variabele SERVER_PORT vervangen door X-Forwarded-Proto :

RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{HTTPS} !on RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R]

CloudFlare en andere CDN's

CloudFlare CDN's hebben HTTP-verzoekfilters die de "PURGE" en "FULLPURGE" verzoeken kunnen blokkeren die worden gebruikt door Fastest Cache om de cache te zuiveren.

We raden aan om slechts één niveau van cache te gebruiken, Cloudflare of Fastest Cache.

Beide samen gebruiken kan leiden tot ongewenst gedrag. Test beide en gebruik degene die het beste bij je behoeften past.