Fastest Cache : uw site versnellen met Varnish en NGINX

Procédure

Waarom de laadsnelheid van uw site versnellen? 

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

Er bestaat geen grens die niet overschreden mag worden 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 waarvoor dient het? 

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

NGINX is een prestatiegerichte webserver waarmee veel meer verzoeken kunnen worden verwerkt in vergelijking met de traditionele webserver Apache HTTPd Server (zie ons blogartikel met de titel “Apache VS Nginx : Prestatietest”). LWS gebruikt NGINX om een hoog volume aan HTTP-verzoeken vooraf te kunnen ontvangen zonder prestatieverlies. Deze kunnen vervolgens efficiënt worden gefilterd om kwaadaardige verzoeken te verwijderen (zie LWS Protect) en de HTTP-verzoeken door te sturen naar de Varnish- of LiteSpeed-cacheserver, afhankelijk van de keuze van de klant in zijn hostinginterface.

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

Met de juiste configuraties stelt NGINX u in staat meer verzoeken op uw website te ontvangen, en Varnish zorgt er zowel voor dat de laadtijd van uw pagina wordt versneld als dat uw CPU- en RAM-geheugenverbruik wordt verlaagd.

Hoe werkt de Fastest Cache-service? 

Werking zonder cache

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

1. De bezoeker vraagt de pagina op bij de webserver. Voorbeeld: index.php
2. De webserver voert de nodige scripts uit (PHP, Python, Node.js ...)
3. De webserver ontvangt het resultaat van de uitvoering
4. De webserver verstuurt de HTML-pagina die voortkomt uit het resultaat van de scriptuitvoering

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 benodigde scriptuitvoeringen te verminderen door het uitvoeringsresultaat in het geheugen te bewaren voor toekomstige verzoeken die dezelfde reactie 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 op de laadtijd van de pagina en besparen we bovendien 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 reactie uit de cache kan worden gehaald:

• Zo ja, dan wordt de pagina rechtstreeks aan de bezoeker teruggegeven zonder toegang tot de webservice en zonder het script uit te voeren
• Zo nee, dan wordt de pagina gegenereerd door de webserver, wat leidt tot de uitvoering van het script (PHP, Node.js, Perl, Ruby, ...). Zodra de pagina is gegenereerd, bepaalt Fastest Cache of de reactie in cache kan worden bewaard.
  • Zo ja, dan wordt de pagina opgeslagen in het cachegeheugen en teruggestuurd naar de bezoeker
  • Zo nee, dan wordt de pagina teruggestuurd naar de bezoeker zonder in het cachegeheugen te worden opgeslagen

We zien dat wanneer een pagina in het cachegeheugen is opgeslagen, de verwerking door de webserver en de uitvoering van het script worden vermeden, wat de uitvoeringstijd en het bronverbruik aanzienlijk vermindert.

Gedrag van het cachesysteem

Fastest Cache baseert zich op meerdere signalen om het toegepaste cachegedrag te bepalen:

• Extensie van het bestand in de URL
• Aanwezigheid en inhoud van URL-parameters (query strings)
• Antwoordheader Cache-Control
• Cookies

Fastest Cache detecteert ook bepaalde CMS’en en extensies/modules en implementeert specifieke cachegedragingen die aan deze tools gekoppeld zijn.

Gedrag bij ontvangst van het verzoek

Fastest Cache cached alleen de HTTP-methoden GET en HEAD.

Wanneer een bezoeker een URL bezoekt, normaliseert Fastest Cache het verzoek door cookies en URL-parameters te verwijderen die geen invloed hebben op de uiteindelijke weergave van het script aan de serverzijde (Google Analytics-URL-parameters, cookies gekoppeld aan Javascript-scripts ...).

Zodra het verzoek is genormaliseerd, wordt gecontroleerd of het een HTTP-authenticatie bevat (HTTP-verzoekheader Authorization) of of er nog cookies overblijven (HTTP-verzoekheader Cookie). Zo ja, dan wordt het verzoek zonder langs het cachesysteem te gaan naar de webserver teruggestuurd.

Gedrag bij het versturen van het antwoord

Als het verzoek bij ontvangst niet langs de cache is gegaan, analyseert Fastest Cache opnieuw de door de webserver geleverde HTTP-reactie en controleert of het mogelijk is om de reactie voor toekomstig gebruik in cache op te slaan.

Als de HTTP-reactie een HTTP-antwoordheader Cdn-Cache-Control bevat, volgt Fastest Cache onmiddellijk wat daarin is gedefinieerd:

• Als no-store, no-cache of private daarin is gedefinieerd, stuurt Fastest Cache de reactie terug naar de bezoeker zonder deze in de cache te bewaren.
• Als s-maxage of max-age daarin is gedefinieerd, gebruikt Fastest Cache deze waarde onmiddellijk als bewaartermijn van de pagina in de cache.

Als Cdn-Cache-Control is gedefinieerd samen met Set-Cookie, wordt Cdn-Cache-Control genegeerd en wordt de reactie niet in de cache bewaard.

De statische bestanden die overeenkomen met de thema’s, plugins, uploads en WordPress-core worden automatisch 30 dagen in cache bewaard.

Als de HTTP-reactie afkomstig is van het page-cache-systeem van LWS Optimize, WP Fastest Cache, Airlift, W3 Total Cache, WP Rocket, WP Optimize of FastPixel, wordt deze 7 dagen in cache bewaard. Deze WordPress-plugins zullen zelf de Varnish-cache legen wanneer zij de page-cache verwijderen.

Als de HTTP-reactie afkomstig is van de map /_next/static, wordt deze ook 7 dagen in cache bewaard.

Als de HTTP-reactie een HTTP-code 404 retourneert, wordt deze 900 seconden in cache bewaard. Dit voorkomt extra onnodige verzoeken naar de MySQL-database, met name voor WordPress.

Als de HTTP-reactie een HTTP-code 500 retourneert, wordt de reactie nooit in cache bewaard.

Als de HTTP-reactie een cookie bevat (HTTP-antwoordheader Set-Cookie), wordt de reactie nooit in cache bewaard.

Als de HTTP-reactie een HTTP-antwoordheader Cache-Control of Surrogate-Control bevat, volgt Fastest Cache het verwachte cachegedrag voor browsers. Als deze headers samen met Cdn-Cache-Control worden geleverd, negeert Fastest Cache Cache-Control en Surrogate-Control ten gunste van Cdn-Cache-Control. Dit maakt het bijvoorbeeld mogelijk om de browser te dwingen bij elk bezoek een HTTP-verzoek te doen om een artikellijst te raadplegen, zonder dat de artikellijst uit de servercache wordt weggelaten.

Presentatie van de interface en activering van de service

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

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

• De kolom “Cachestatus” toont de activatiestatus van de cache. Als deze op “Geactiveerd” staat, is de cache geactiveerd.
• De knop “Cache legen” maakt het mogelijk om alle gecachte gegevens voor deze specifieke domeinnaam te verwijderen.
• De knop “Cache deactiveren” maakt het mogelijk om caching uit te schakelen.
• De knop “Cache activeren” maakt het mogelijk om caching in te schakelen.
• De knop “Werkwijze wijzigen” maakt het mogelijk om het gedrag van het cachesysteem te wijzigen. Deze modi worden zo meteen uitgelegd.

De verschillende cachemodi

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

Ontwikkelaarsmodus : identiek aan het deactiveren van de cache, dit maakt het mogelijk om het cachesysteem te omzeilen tijdens uw ontwikkelingsperiodes.
WordPress : een cachemodus die beter geschikt is voor WordPress, waarbij het beheer van mappen (wp-content, wp-admin, …) en specifieke WordPress-cookies is verbeterd.
Prestashop : een cachemodus die beter geschikt is voor 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 via de SSH-terminal van het cPanel-account of via een script dat op de server wordt gehost.

Wanneer deze methoden vanuit uw hosting worden uitgevoerd (PHP-script van uw site, Cron-taak of SSH-terminal), is noch een API-token noch een identificatie vereist: Fastest Cache accepteert HTTP-methoden PURGE rechtstreeks.

Cache legen met cURL

De cache van een pagina legen:

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

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

De cache van een map legen:

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

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

De cache van een site legen

curl -X PURGE https://mon-site-web.com/.*

Voor al deze drie opdrachten zijn drie uitkomsten mogelijk:

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

HTTP-code 4xx : het legen is niet toegestaan.

HTTP-code 5xx : er is een fout opgetreden.

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

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

 'PURGE',
        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($site . '/.*') . PHP_EOL;
}
else {
    foreach ($pages as $page) {
        echo date('Y-m-d H:i:s') . ' ' . $page . ' : HTTP ' . purger($site . $page) . PHP_EOL;
    }
}

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

curl -s -o /dev/null -X PURGE 'https://mon-site-web.com/.*'

Leegmaken met een plugin of module

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

Hier zijn enkele geteste en bevestigde compatibele plugins:

• LWS Optimize
• WP Fastest Cache
• WP Rocket
• Proxy Cache Purge

HTTPS-detectie en omleidingen

De HTTPS-status en de in Apache aangegeven poorten worden in de omgeving geïnjecteerd en vereisen doorgaans geen aanvullende wijzigingen.

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

De vertrouwde HTTP-headers voor detectie zijn:

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

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

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 kunnen HTTP-verzoeken filteren die de “PURGE”-verzoeken zouden kunnen blokkeren die door Fastest Cache worden gebruikt om de cache te legen. Het wordt dan aangeraden om het IP-adres van de server op te geven bij uw leegmaakactie met curl om de CDN’s te omzeilen tijdens leegmaakacties :

curl -X PURGE --resolve mon-site-web.com:443:IP_DU_SERVEUR 'https://mon-site-web.com/.*'

CDN’s kunnen ook een extra cachelaag bevatten die u onafhankelijk moet beheren van de cache die door Fastest Cache wordt geleverd.