Versnel de snelheid van uw site met Fastest Cache - Varnish-cache

Procédure

Waarom de laadsnelheid van uw site versnellen? 

Het is goed om te weten dat de laadsnelheid van uw site essentieel is voor het succes ervan. Voor een bedrijf bijvoorbeeld geeft dit een eerste indruk aan de bezoekers. Bovendien kan een te lange laadtijd van de site een impact hebben op de SEO van uw site in de belangrijkste zoekmachines en zal dit niet voldoende zichtbaarheid bieden om de site te laten groeien.

Er bestaat geen drempel die niet mag worden overschreden wat betreft het laden van uw webpagina's. De laadtijd van de meeste websites is echter minder dan drie seconden.

Wat is Fastest Cache en waar dient het voor?

De tool Fastest Cache is een systeem dat ontworpen en ontwikkeld is door LWS en waarmee u de laadprestaties van uw website kunt optimaliseren dankzij het gebruik van paginacachemechanismen die op webserverniveau zijn geconfigureerd. De tool combineert de technologieën van NGINX en Varnish.

NGINX is een op prestaties gerichte webserver waarmee veel meer verzoeken kunnen worden verwerkt dan Apache (zie ons blogbericht met de titel “Apache VS Nginx : prestatietest”). Deze wordt voornamelijk gebruikt in Fastest Cache om de beveiligde toegang via https:// van uw site te beheren, kwaadaardige HTTP-verzoeken te elimineren (zie LWS Protect) en HTTP-verzoeken naar de Varnish-cacheservers door te sturen.

Varnish is een HTTP-service die een paginacachemechanisme implementeert waarmee het resultaat van een HTTP-verzoek in het geheugen kan worden gecachet.

Met de juiste configuraties zorgt NGINX ervoor dat er meer verzoeken op uw website kunnen worden opgevangen, en Varnish versnelt zowel de laadtijd van uw pagina als vermindert het uw CPU- en geheugengebruik.

Hoe werkt de Fastest Cache-service?

1. Werking zonder cache

Om de werking beter te begrijpen, bekijken we eerst hoe het verloopt zonder cacheplugin, zodat de bezoeker uw site kan zien.

11. De bezoeker vraagt de pagina op bij de webserver. Voorbeeld: index.php

22. De webserver voert de nodige scripts uit (PHP, Perl, NodeJS, …)

33. De webserver ontvangt het uitvoeringsresultaat

44. De webserver stuurt de HTML-pagina die voortkomt uit het resultaat van de scriptuitvoering

2. Werking met de Fastest Cache-module

Wanneer Fastest Cache is geactiveerd, wordt een cacheserver tussen de bezoeker en de webserver geplaatst.

Het doel is het aantal noodzakelijke scriptuitvoeringen te verminderen door het uitvoeringsresultaat in het geheugen te bewaren voor toekomstige verzoeken die hetzelfde antwoord vereisen. Hierdoor hoeft hetzelfde script niet meerdere keren te worden uitgevoerd om tot hetzelfde resultaat te komen.

Zo elimineren we de wachttijd van de scriptuitvoering uit de laadtijd van de pagina en besparen we tegelijk de middelen die worden gebruikt tijdens de uitvoering van het script.

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

• Zo ja, dan wordt de pagina rechtstreeks aan de bezoeker teruggegeven zonder dat toegang tot de webservice nodig is en zonder het script uit te voeren
• Zo nee, dan wordt de pagina aangevraagd om gegenereerd te worden op de webservice, wat resulteert in de uitvoering van het script (PHP, NodeJS, Perl, Ruby, …).

33. Zodra de pagina is gegenereerd, bepaalt Fastest Cache of de pagina in cache kan worden bewaard (via headers, URL, …)

• Zo ja, dan wordt de pagina in het cachegeheugen opgeslagen en aan de bezoeker teruggestuurd
• Zo nee, dan wordt de pagina in het microcachegeheugen opgeslagen (cachegeheugen met een korte geldigheidsduur) en aan de bezoeker teruggestuurd

We zien dat wanneer een pagina in het cachegeheugen wordt opgeslagen, de verwerking door de webserver evenals de uitvoering van het script wordt vermeden.

Cachebaar, niet-cachebaar en microcache

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

Sommige pagina-inhoud mag niet in het cachegeheugen worden opgeslagen, zoals het resultaat van een inschrijfformulier, het resultaat van een betaalpagina, … omdat die gegevens bevatten die variëren per gebruiker en per gebeurtenis.

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

• HTTP-verzoeken die andere HTTP-verben dan HEAD en GET gebruiken, worden systematisch uitgesloten van de cache.
• HTTP-verzoeken die cookies bevatten, worden eveneens uitgesloten. De cookies die gebruikt worden door Google Analytics, XiTi, DoubleClick, Quant Capital, AddThis en Cloudflare worden vóór de detectie verwijderd. Ook cookies die verband houden met bekende CMS'en worden automatisch beheerd als de cachemodus overeenkomt met het CMS.
• HTTP-verzoeken die door .htaccess-wachtwoorden worden beveiligd
• Als het antwoord van de webserver instructies voor browsercache bevat (cache-control-header), wordt dit automatisch door Fastest Cache in aanmerking genomen en wordt de pagina in het cachegeheugen bewaard.

Als een HTTP-verzoek van het type GET is en niet wordt beveiligd door .htaccess en geen cookies bevat, en geen specifieke browsercache-instructie heeft, dan wordt het gedurende enkele seconden in het microcachegeheugen bewaard.

Het microcache helpt zo om problemen bij pieken in aanvragen op niet-gecachete pagina's op te vangen. Dit maakt het bijvoorbeeld mogelijk om overbelasting en vertragingen op te lossen bij een golf van zoekopdrachten naar hetzelfde product in een e-commercewinkel.

Presentatie van de interface en activering van de service

Fastest Cache wordt weergegeven als een pictogram in cPanel in de sectie “Performance”.

Zodra u zich in de interface bevindt, worden het hoofddomein, de extra domeinen en de subdomeinen in de lijst weergegeven.

• De kolom “Cachestatus” toont de activeringsstatus van de cache. Als deze op “Geactiveerd” staat, dan is de cache geactiveerd.
• De knop “Cache legen” maakt het mogelijk om alle gecachte gegevens voor deze specifieke domeinnaam te verwijderen.
• De knop “Cache uitschakelen” maakt het mogelijk om de caching uit te schakelen.
• De knop “Cache activeren” maakt het mogelijk om de caching te activeren.
• De knop “Wijzig de werkingsmodus” maakt het mogelijk om het gedrag van het cachesysteem aan te passen. Deze modi worden daarna uitgelegd.

De verschillende cachemodi

Standaard kiest het cachesysteem voor de modus “Algemeen gebruik”, die geschikt is voor algemeen gebruik. Er bestaan echter andere modi:

Ontwikkelaarsmodus : identiek aan het uitschakelen van de cache, dit maakt het mogelijk om het cachesysteem te omzeilen tijdens uw ontwikkelingsperiodes.
WordPress : een cachemodus die beter aangepast is aan WordPress, waarbij het beheer van mappen (wp-content, wp-admin, …) en specifieke WordPress-cookies is verbeterd.
Prestashop : een cachemodus die beter aangepast is aan Prestashop, waarbij het beheer van mappen en cookies is verbeterd.

Cache legen

Naast de cPanel-interface waarmee de cache kan worden geleegd, is het mogelijk om de cache handmatig te legen vanuit de SSH-terminal van het cPanel-account of vanuit een script dat op de server wordt gehost.

Opgestart vanuit uw hosting (een PHP-script van uw site, een Cron-taak of de SSH-terminal) vereisen deze methoden geen API-token of inloggegevens: Fastest Cache accepteert rechtstreeks de HTTP-methoden PURGE en FULLPURGE. Het token lwsapitoken heeft enkel betrekking op LWS Cache, de cache van het LWS Panel (zie deze hulp).

1. Cache legen met cURL

De cache van een pagina legen:

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

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

De cache van een map legen:

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

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

De cache van een site legen

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

Voor al deze drie opdrachten zijn twee antwoorden mogelijk:

HTTP-code 200 : het legen is correct verlopen zonder fout.

HTTP-code 405 : het legen is niet toegestaan of is niet uitgevoerd.

2. Automatisch legen met een PHP-script (Cron-taak)

Het volgende script leegt de cache van de volledige site, of slechts van enkele pagina's. Kopieer het naar een bestand purge-cache.php van uw hosting en geef vervolgens uw domein aan in $site. Om slechts bepaalde pagina's te legen, vermeldt u ze in $pages.

 $methode,
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CONNECTTIMEOUT => 5,
        CURLOPT_TIMEOUT        => 20,
    ]);
    curl_exec($ch);
    $code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
    return $code;
}

if (empty($pages)) {
    echo date('Y-m-d H:i:s') . ' volledige leegmaking : HTTP ' . purger('FULLPURGE', $site) . PHP_EOL;
} else {
    foreach ($pages as $page) {
        echo date('Y-m-d H:i:s') . ' ' . $page . ' : HTTP ' . purger('PURGE', $site . $page) . PHP_EOL;
    }
}
// HTTP 200 : leegmaken uitgevoerd. HTTP 405 : leegmaken geweigerd of niet uitgevoerd.

Om het automatisch uit te voeren, bijvoorbeeld elke nacht, maakt u een Cron-taak aan die dit bestand met PHP uitvoert. Als u gewoon de volledige cache wilt legen, kan de Cron-taak ook rechtstreeks het volgende uitvoeren:

curl -s -X FULLPURGE https://mon-site-web.com

3. Legen met een plugin of module

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

Hier zijn enkele geteste en gecontroleerde compatibele plugins:

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

HTTPS-detectie en omleidingen

De HTTPS-status en de poorten die op Apache worden aangegeven, worden gewijzigd door de module mod_fastestcache die in Apache is geïntegreerd. Het is dus doorgaans niet nodig om wijzigingen aan te brengen.

Als de HTTPS-detectie echter niet functioneert met Fastest Cache, kan dit eindeloze omleidingslussen veroorzaken. In dat geval zal het nodig zijn om de detectiegegevens te wijzigen.

De vertrouwde HTTP-headers voor de detectie zijn:

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

Als u de volgende HTTPS-omleiding gebruikt met een .htaccess-bestand:

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

en dit niet werkt, 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

CDN's van het type CloudFlare hebben HTTP-verzoekfilters die de “PURGE”- en “FULLPURGE”-verzoeken kunnen blokkeren die door Fastest Cache worden gebruikt om de cache te legen.

Wij raden u aan slechts één cachlaag te gebruiken, dus ofwel Cloudflare ofwel Fastest Cache.

Hun gecombineerde gebruik kan ongewenst gedrag veroorzaken. Test beide en gebruik wat het beste aansluit bij uw behoefte.