Fastest Cache: accelerera din webbplats med Varnish och NGINX

Procédure

Varför påskynda webbplatsens laddningshastighet? 

Det är bra att veta att din webbplats laddningshastighet är avgörande för att säkerställa dess framgång. För ett företag till exempel ger detta ett första intryck till dess besökare. Dessutom kan en alltför lång laddningstid för den påverka din webbplats sökmotoroptimering i de viktigaste sökmotorerna och kommer inte att ge tillräcklig exponering för att få den att leva vidare.

Det finns ingen gräns som inte får överskridas när det gäller laddning av dina webbsidor. Däremot är laddningstiden för de flesta webbplatser under tre sekunder.

Vad är Fastest Cache och vad används det till? 

Verktyget Fastest Cache är ett system som har utformats och utvecklats av LWS för att optimera laddningsprestandan för din webbplats genom att använda sidcachemekanismer, konfigurerade på webbservernivå. Verktyget kombinerar de tekniker som tillhandahålls av NGINX och Varnish.

NGINX är en prestandainriktad webbserver som gör det möjligt att hantera betydligt fler förfrågningar jämfört med den traditionella webbservern Apache HTTPd Server (se vårt blogginlägg med titeln “Apache VS Nginx : Prestandatest”). LWS använder NGINX för att kunna ta emot en hög volym HTTP-förfrågningar i förväg utan prestandakompromisser. Dessa kan sedan effektivt filtreras och skadliga förfrågningar elimineras (se LWS Protect) och HTTP-förfrågningarna skickas vidare till cache-servern Varnish eller LiteSpeed, beroende på kundens val via dess webbhotellsgränssnitt.

Varnish är en HTTP-tjänst som implementerar en sidcachemekanism som gör det möjligt att cacha resultatet av en HTTP-förfrågan i RAM-minnet.

Med rätt konfigurationer på plats gör NGINX det möjligt att ta emot fler förfrågningar på din webbplats, och Varnish gör det både möjligt att påskynda sidans laddningstid och att minska din CPU- och RAM-minnesförbrukning.

Hur fungerar tjänsten Fastest Cache?

Funktion utan cache

För att bättre förstå hur det fungerar ska vi först se hur det går till utan något cachesystem, så att besökaren kan se din webbplats.

1. Besökaren begär sidan från webbservern. Exempel: index.php
2. Webbservern utför nödvändiga skriptkörningar (PHP, Python, Node.js …)
3. Webbservern tar emot resultatet av körningen
4. Webbservern skickar HTML-sidan som skapats utifrån resultatet av skriptkörningen

Funktion med modulen Fastest Cache

När Fastest Cache är aktiverat introduceras en cache-server mellan besökaren och webbservern.

Syftet är att minska antalet nödvändiga skriptkörningar genom att behålla resultatet av körningen i minnet för kommande förfrågningar som kräver samma svar. Detta gör att samma skript inte behöver köras flera gånger för att ge samma resultat.

På så sätt eliminerar vi väntetiden för skriptkörningen från sidans laddningstid och sparar samtidigt de resurser som används under skriptkörningen.

11. Besökaren begär sidan från webbservern. Exempel: index.php
2. Fastest Cache kontrollerar om svaret kan hämtas från cachen :

• Om ja, returneras sidan direkt till besökaren utan att behöva komma åt webbservicen och utan att köra skriptet
• Om nej, genereras sidan av webbservern, vilket innebär att skriptet körs (PHP, Node.js, Perl, Ruby, …). När sidan har genererats avgör Fastest Cache om svaret kan sparas i cache.
  • Om ja, sparas sidan i cacheminnet och skickas tillbaka till besökaren
  • Om nej, skickas sidan tillbaka till besökaren utan att sparas i cacheminnet

Vi ser att när en sida lagras i cacheminnet undviks bearbetning av webbservern samt skriptkörningen, vilket avsevärt minskar exekveringstiden och resursförbrukningen.

Cache-systemets beteende

Fastest Cache baseras på flera signaler för att avgöra vilket cachebeteende som ska användas :

• Filändelse i URL:en
• Förekomst och innehåll av URL-parametrar (query strings)
• Svarshuvud för Cache-Control
• Cookies

Fastest Cache upptäcker också vissa CMS:er och tillägg / moduler och implementerar specifika cachebeteenden kopplade till dessa verktyg.

Beteende vid mottagning av begäran

Fastest Cache cachar endast HTTP-metoderna GET och HEAD.

När en besökare besöker en URL normaliserar Fastest Cache begäran genom att ta bort cookies och URL-parametrar som inte påverkar den slutliga renderingen av skriptet på serversidan (Google Analytics-URL-parametrar, cookies kopplade till JavaScript-skript ...).

När begäran har normaliserats kontrolleras om den innehåller HTTP-autentisering (HTTP-begäranshuvudet Authorization) eller om det fortfarande finns cookies kvar (HTTP-begäranshuvudet Cookie). Om ja, skickas begäran tillbaka till webbservern utan att gå via cachesystemet.

Beteende vid sändning av svaret

Om begäran inte gick förbi cachen vid mottagandet av begäran analyserar Fastest Cache på nytt det HTTP-svar som webbservern tillhandahåller och kontrollerar om det är möjligt att cacha svaret för framtida användning.

Om HTTP-svaret tillhandahåller ett HTTP-svarshuvud för Cdn-Cache-Control följer Fastest Cache omedelbart det som anges där :

• Om no-store, no-cache eller private anges där skickar Fastest Cache svaret till besökaren utan att behålla det i cachen.
• Om s-maxage eller max-age anges där använder Fastest Cache omedelbart detta värde som retentionstid för sidan i cachen.

Om Cdn-Cache-Control är definierat med Set-Cookie kommer Cdn-Cache-Control att ignoreras och svaret kommer inte att behållas i cachen.

Motsvarande statiska filer för WordPress-teman, tillägg, uppladdningar och kärna sparas automatiskt i cache i 30 dagar.

Om HTTP-svaret kommer från sidcachesystemet LWS Optimize, WP Fastest Cache, Airlift, W3 Total Cache, WP Rocket, WP Optimize eller FastPixel, sparas det i cache i 7 dagar. Dessa WordPress-plugins kommer själva att rensa Varnish-cachen när de tar bort sidcachen.

Om HTTP-svaret kommer från mappen /_next/static, sparas det också i cache i 7 dagar.

Om HTTP-svaret returnerar en HTTP-kod 404, sparas det i cache i 900 sekunder. Detta gör det möjligt att undvika ytterligare onödiga förfrågningar till MySQL-databasen, särskilt för WordPress.

Om HTTP-svaret returnerar en HTTP-kod 500, sparas svaret aldrig i cache.

Om HTTP-svaret innehåller en cookie (HTTP-svarshuvudet Set-Cookie) sparas svaret aldrig i cache.

Om HTTP-svaret tillhandahåller ett HTTP-svarshuvud för Cache-Control eller Surrogate-Control, följer Fastest Cache det förväntade cachebeteendet för webbläsare. Om dessa huvuden tillhandahålls med Cdn-Cache-Control, ignorerar Fastest Cache Cache-Control och Surrogate-Control till förmån för Cdn-Cache-Control. Detta gör det till exempel möjligt att tvinga webbläsaren att göra en HTTP-förfrågan för att visa en artikel lista vid varje besök, utan att artikel listan saknas i servercachen.

Presentation av gränssnittet och aktivering av tjänsten

Fastest Cache visas som en ikon i cPanel i avsnittet “Performance”.

När du är i gränssnittet visas huvuddomenen, de extra domänerna och underdomänerna i listan.

• Kolumnen “Cachestatus” visar cacheaktiveringens status. Om den står på “Aktiverad” är cachen aktiverad.
• Knappen “Töm cachen” gör det möjligt att ta bort alla cachade data för just det domännamnet.
• Knappen “Inaktivera cachen” gör det möjligt att inaktivera cachelagringen.
• Knappen “Aktivera cachen” gör det möjligt att aktivera cachelagringen.
• Knappen “Ändra driftläge” gör det möjligt att ändra cache-systemets beteende. Dessa lägen förklaras strax efter.

De olika cache-lägena

Som standard väljer cache-systemet läget « Allmän användning » som passar för allmän användning. Det finns dock andra lägen :

Utvecklarläge : identiskt med att inaktivera cachen, detta gör det möjligt att kringgå cachesystemet under dina utvecklingsperioder.
WordPress : ett cacheläge som är mer anpassat till WordPress där hanteringen av mapparna (wp-content, wp-admin, …) och de WordPress-specifika cookies förbättras.
Prestashop : ett cacheläge som är mer anpassat till Prestashop där hanteringen av mappar och cookies förbättras.

Rensning av cache

Utöver cPanel-gränssnittet som gör det möjligt att tömma cachen, går det att manuellt tömma cachen från SSH-terminalen för cPanel-kontot eller från ett skript som finns på servern.

Eftersom dessa metoder körs från ditt webbhotell (PHP-skript på din webbplats, Cron-jobb eller SSH-terminal) kräver de varken API-token eller inloggningsuppgifter: Fastest Cache accepterar direkt HTTP-metoderna PURGE.

Töm cache med cURL

Töm cachen för en sida :

curl -X PURGE https://min-webbplats.com/minsida.php

Detta gör det möjligt att tömma cachen för URL:en https://mon-site-web.com/mapage.php.

Töm cachen för en mapp :

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

Detta gör det möjligt att tömma alla cacheminnen för URL:er som börjar med 'https://mon-site-web.com/wp-content/uploads/'

Töm cachen för en webbplats

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

För alla dessa tre kommandon är tre svar möjliga :

HTTP-kod 200 : rensningen genomfördes utan fel.

HTTP-kod 4xx : rensningen är inte tillåten.

HTTP-kod 5xx : ett fel har uppstått.

Automatisk rensning med ett PHP-skript (Cron-jobb)

Följande skript tömmer cachen för hela webbplatsen, eller bara för några sidor. Kopiera det till en fil purge-cache.php på ditt webbhotell och ange sedan din domän i $site. Om du bara vill tömma vissa sidor, lista dem i $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') . ' fullständig tömning : 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;
    }
}

För att köra det automatiskt, till exempel varje natt, skapar du ett Cron-jobb som kör den här filen med PHP. Om du bara vill tömma hela cachen kan Cron-jobbet också köra direkt :

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

Rensning med ett plugin eller modul

De flesta plugins/moduler med Varnish-integration är kompatibla med Fastest Caches interna rensningsmekanism.

Här är några testade och verifierade kompatibla plugins :

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

HTTPS-detektering och omdirigeringar

HTTPS-statusen och de portar som anges på Apache injiceras i miljön och kräver normalt inga ytterligare ändringar.

Om HTTPS-detekteringen inte fungerar med Fastest Cache kan detta dock orsaka oändliga omdirigeringsloopar. Därför kommer det att vara nödvändigt att ändra detekteringsuppgifterna.

De betrodda HTTP-huvudena för detektering är :

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

Om du använder följande HTTPS-omdirigering med en .htaccess :

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

och det inte fungerar kan du ersätta variabeln SERVER_PORT med X-Forwarded-Proto :

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

CloudFlare och andra CDN:er

CDN:er av typen CloudFlare kan filtrera HTTP-förfrågningar som kan blockera förfrågningar “PURGE” och som används av Fastest Cache för att tömma cachen. Du rekommenderas då att ange serverns IP-adress vid din rensning med curl för att kringgå CDN:er vid rensningsåtgärder :

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

CDN:er kan också innehålla ett extra cachelager som du måste hantera oberoende av cachen som tillhandahålls av Fastest Cache.