Snabba upp hastigheten på din webbplats med Fastest Cache - Varnish-cache

Procédure

Varför påskynda laddningshastigheten för din webbplats? 

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

Det finns ingen tröskel som inte får överskridas när det gäller laddning av dina webbsidor. Laddningstiden för de flesta webbplatser är dock mindre än 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 teknikerna som tillhandahålls av NGINX och Varnish.

NGINX är en prestandainriktad webbserver som kan hantera mycket fler förfrågningar än Apache (se vårt blogginlägg med titeln “Apache VS Nginx : Test de performance”). Den används främst i Fastest Cache för att hantera säker https://-åtkomst till din webbplats, eliminera skadliga HTTP-förfrågningar (se LWS Protect) och dirigera HTTP-förfrågningar till Varnish-cacheservrarna.

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 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 samtidigt möjligt att både påskynda sidans laddningstid och minska din CPU- och minnesanvändning.

Hur fungerar tjänsten Fastest Cache?

1. Funktion utan cache

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

11. Besökaren begär sidan från webbservern. Exempel: index.php

22. Webbservern utför nödvändiga skriptkörningar (PHP, Perl, NodeJS, …)

33. Webbservern tar emot resultatet av körningen

44. Webbservern skickar HTML-sidan som kommer från resultatet av skriptkörningen

2. Funktion med modulen Fastest Cache

När Fastest Cache är aktiverat införs en cacheserver 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 behöver samma svar. Detta gör att man slipper köra samma skript flera gånger för att nå 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 sidan redan har genererats och sparats i cacheminnet

• Om ja returneras sidan direkt till besökaren utan att det är nödvändigt att nå webbservicen och utan att köra skriptet
• Om nej begärs att sidan ska genereras på webbservicen, vilket resulterar i att skriptet körs (PHP, NodeJS, Perl, Ruby, …).

33. När sidan har genererats avgör Fastest Cache om sidan kan sparas i cache (via headers, URL, …)

• Om ja lagras sidan i cacheminnet och skickas tillbaka till besökaren
• Om nej lagras sidan i microcache-minnet (cacheminne med kort giltighetstid) och skickas tillbaka till besökaren

Det konstateras att när en sida lagras i cacheminnet undviks bearbetning av webbservern samt körning av skriptet.

Cacheable, non cacheable och microcache

När webbservicen tillhandahåller ett nytt svar till Fastest Cache analyseras detta för att avgöra om det ska sparas i cacheminnet för framtida användning eller inte.

Viss sidinnehåll bör inte lagras i cacheminnet, såsom resultatet av ett registreringsformulär, resultatet av en betalningssida, … eftersom de innehåller data som varierar beroende på användare och händelser.

För att avgöra om en sida kan cachas eller inte använder Fastest Cache flera mekanismer:

• HTTP-förfrågningar som använder andra HTTP-verb än HEAD och GET kommer systematiskt att uteslutas från cachen.
• HTTP-förfrågningar som innehåller cookies kommer också att uteslutas. Cookies som används av Google Analytics, XiTi, DoubleClick, Quant Capital, AddThis och Cloudflare tas bort före detektering. På samma sätt hanteras cookies kopplade till kända CMS automatiskt om cacheläget motsvarar CMS:et.
• HTTP-förfrågningar skyddade av .htaccess-lösenord
• Om webbserverns svar innehåller instruktioner för webbläsarcache (header cache-control) kommer detta automatiskt att beaktas av Fastest Cache och sidan lagras i cacheminnet.

Om en HTTP-förfrågan är av typen GET och den varken är skyddad av .htaccess eller innehåller cookies, och den inte har någon specifik instruktion för webbläsarcache, lagras den i microcachen under några sekunder.

Microcachen gör det därmed möjligt att avhjälpa problem med toppar i efterfrågan på sidor som inte är cachade. Detta gör det till exempel möjligt att lösa överbelastning och långsamhet vid en våg av sökningar efter samma produkt i en e-handelsbutik.

Presentation av gränssnittet och aktivering av tjänsten

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

När du är inne i gränssnittet visas huvuddomänen, de ytterligare domänerna och underdomänerna i listan.

• Kolumnen “Cache-status” visar cacheaktiveringens tillstånd. Om den står på “Aktiverad” är cachen aktiverad.
• Knappen “Rensa cachen” gör det möjligt att ta bort all cachelagrad data för just det domännamnet.
• Knappen “Inaktivera cachen” gör det möjligt att inaktivera cachningen.
• Knappen “Aktivera cachen” gör det möjligt att aktivera cachningen.
• Knappen “Ändra driftläge” gör det möjligt att ändra cache-systemets beteende. Dessa lägen förklaras strax efteråt.

De olika cachelägena

Som standard väljer cachesystemet läget “Allmän användning” som passar 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 bättre anpassat för WordPress där hanteringen av mappar (wp-content, wp-admin, …) och specifika WordPress-cookies förbättras.
Prestashop : ett cacheläge som är bättre anpassat för Prestashop där hanteringen av mappar och cookies förbättras.

Rensning av cachen

Utöver cPanel-gränssnittet som gör det möjligt att rensa cachen, kan cachen även rensas manuellt från cPanel-kontots SSH-terminal eller från ett skript som ligger på servern.

Körda från din webbhotellsmiljö (PHP-skript på din webbplats, Cron-uppgift eller SSH-terminal) kräver dessa metoder varken API-token eller identifikationsuppgifter: Fastest Cache accepterar direkt HTTP-metoderna PURGE och FULLPURGE. Token lwsapitoken gäller endast för LWS Cache, cachen i LWS Panel (se denna hjälp).

1. Rensa cache med cURL

Rensa cachen för en sida:

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

Detta kommer att rensa cachen för URL:en http://mon-site-web.com/mapage.php.

Rensa cachen för en mapp:

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

Detta kommer att rensa alla cacher för URL:er som börjar med 'http://mon-site-web.com/wp-content/uploads/'

Rensa cachen för en webbplats

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

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

HTTP-kod 200 : rensningen gick bra utan fel.

HTTP-kod 405 : rensningen är inte tillåten eller har inte utförts.

2. Automatisk rensning med ett PHP-skript (Cron-uppgift)

Följande skript tömmer cachen för hela webbplatsen, eller bara för några få sidor. Kopiera det till en fil purge-cache.php på ditt webbhotell, och ange sedan din domän i $site. För att bara rensa vissa sidor, lista dem i $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') . ' fullständig rensning : 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 : rensning utförd. HTTP 405 : rensning nekad eller inte utförd.

För att köra det automatiskt, till exempel varje natt, skapa en Cron-uppgift som kör denna fil med PHP. Om du bara vill tömma hela cachen kan Cron-uppgiften också köra direkt:

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

3. Rensning med ett plugin eller en modul

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

Här är några testade plugins som bekräftats vara kompatibla:

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

HTTPS-detektering och omdirigeringar

HTTPS-statusen och de portar som anges på Apache ändras av modulen mod_fastestcache som är integrerad i Apache. Det är därför vanligtvis inte nödvändigt att göra några ändringar.

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

Följande HTTP-rubriker används som tillförlitliga för detektering:

• 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 detta 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 har HTTP-förfrågningsfilter som kan blockera förfrågningarna “PURGE” och “FULLPURGE” som används av Fastest Cache för att rensa cachen.

Vi rekommenderar att du bara använder en nivå av cache, alltså antingen Cloudflare eller Fastest Cache.

Deras kombinerade användning kan medföra oönskade beteenden. Testa båda, använd det som passar ditt behov bäst.