Snabba upp din webbplats med Fastest Cache - Cache Varnish

Procédure

Varför snabba upp laddningshastigheten för din webbplats?

Det är bra att veta att laddningshastigheten på din webbplats är avgörande för hur framgångsrik den blir. För ett företag, till exempel, ger den ett första intryck till besökarna. Om din webbplats tar för lång tid att ladda kan det dessutom påverka dess ranking i de viktigaste sökmotorerna och inte ge dig tillräckligt med exponering för att hålla din webbplats vid liv.

Det finns ingen gräns för hur lång tid det får ta att ladda dina webbsidor. De flesta webbplatser tar dock mindre än tre sekunder att ladda.

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 attoptimera laddningsprestandan på din webbplats genom att använda mekanismer för sidcache som konfigureras på webbservernivå. Verktyget kombinerar de tekniker som tillhandahålls av NGINX och Varnish.

NGINX är en prestandaorienterad webbserver som kan hantera många fler förfrågningar än Apache (se vårt blogginlägg med titeln"Apache VS Nginx: Prestandatest"). Den används huvudsakligen på Fastest Cache för att hantera säker åtkomst till din webbplats på https://, eliminera skadliga HTTP-förfrågningar (se LWS Protect) och dirigera HTTP-förfrågningar till Varnish-cacheservrar.

Varnish är en HTTP-tjänst som implementerar en sidcachemekanism för att cacha resultatet av en HTTP-begäran i minnet.

Med rätt konfigurationer på plats kan NGINX hantera fler förfrågningar till din webbplats och Varnish kan påskynda sidans laddningstider samtidigt som CPU- och minnesförbrukningen minskas.

Hur fungerar tjänsten Fastest Cache?

1. Drift utan cache

För att få en bättre förståelse för hur det fungerar börjar vi med att titta på hur det fungerar utan ett cacheplugin så att besökare kan se din webbplats.

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

2. Webbservern kör de nödvändiga skripten (PHP, Perl, NodeJS, etc.)

3. Webbservern tar emot resultatet av exekveringen

4. Webbservern skickar den HTML-sida som är resultatet av skriptexekveringen.

2. Drift med modulen Fastest Cache

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

Syftet är att minska antalet skriptexekveringar som krävs genom att hålla resultatet av exekveringen i minnet för framtida förfrågningar som kräver samma svar. Detta eliminerar behovet av att köra samma skript flera gånger för att uppnå samma resultat.

Det eliminerar den tid som går åt till att vänta på att skriptet ska exekveras vid sidladdning och sparar samtidigt de resurser som används när skriptet exekveras.

1. Besökaren begär sidan från webbservern. Exempel: index.php
2. Fastest Cache kontrollerar om sidan redan har genererats och lagrats i cacheminnet.

• Om så är fallet returneras sidan direkt till besökaren utan att denne behöver gå till webbtjänsten och utan att skriptet exekveras.
• Om inte, begärs att sidan ska genereras på webbtjänsten, vilket resulterar i att skriptet (PHP, NodeJS, Perl, Ruby etc.) körs.

3. När sidan har genererats avgör Fastest Cache om sidan kan cachas (via headers, URL, etc.).

• Om ja, sparas sidan i cacheminnet och skickas tillbaka till besökaren.
• Om inte, sparas sidan i mikrocacheminnet (cacheminne med kort giltighetstid) och skickas tillbaka till besökaren.

Vi kan se att när en sida lagras i cacheminnet undviks bearbetning av webbservern och exekvering av skript.

Cache, icke-cache och mikrocache

När webbtjänsten skickar ett nytt svar till Fastest Cache analyseras det för att avgöra om det ska sparas i cacheminnet för framtida användning eller inte.

Vissa sidors innehåll bör inte cachas, t.ex. resultatet av ett registreringsformulär, resultatet av en betalningssida etc., eftersom de innehåller data som varierar beroende på användare och händelser.

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

• HTTP-förfrågningar som använder andra HTTP-verb än HEAD och GET utesluts systematiskt från cacheminnet.
• 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 raderas innan de upptäcks. På samma sätt hanteras cookies som är kopplade till kända CMS automatiskt om cacheläget motsvarar CMS.
• HTTP-förfrågningar som skyddas av .htaccess-lösenord
• Om webbserversvaret innehåller instruktioner om webbläsarens cache (header cache-control) kommer detta automatiskt att beaktas av Fastest Cache och sidan kommer att sparas i cacheminnet.

Om en HTTP-begäran är av typen GET och varken skyddas av .htaccess eller innehåller cookies, och inte har några specifika instruktioner för webbläsarens cache, sparas den i mikrocachen i några sekunder.

Mikrocachen kan därför användas för att övervinna problem med toppar i efterfrågan på icke-cachade sidor. Detta löser till exempel problemet med överbelastning och långsamhet i händelse av 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 "Prestanda".

I gränssnittet visas huvuddomänen, ytterligare domäner och underdomäner i listan.

• Kolumnen"Cache Status" visar status för cacheaktivering. Om den är inställd på"Enabled" är cachen aktiverad.
• Knappen"Purgecache" raderar alla cachade data för det här domännamnet.
• Knappen"Deactivatecache" används för att avaktivera cachelagring.
• Knappen "Enablecache" aktiverar cachelagring.
• Knappen"Ändra driftläge" används för att ändra beteendet hos cachelagringssystemet. Dessa lägen förklaras strax efteråt.

De olika cachelägena

Som standard väljer cachesystemet läget "General use ", som lämpar sig för allmänt bruk. Det finns dock andra lägen:

Utvecklarläge: identiskt med att avaktivera cacheminnet, vilket gör att du kan åsidosätta cachematsystemet under dina utvecklingsperioder.
WordPress: ett cacheläge som är bättre anpassat till WordPress, med förbättrad hantering av mappar (wp-content, wp-admin etc.) och cookies som är specifika för WordPress.
Prestashop : ett cacheläge som är bättre anpassat till Prestashop, med förbättrad hantering av mappar och cookies.

Rensning av cache

Förutom cPanel-gränssnittet för rensning av cachen är det möjligt att rensa cachen manuellt från SSH-terminalen på cPanel-kontot eller från ett skript som finns på servern.

1. Rensa cacheminnet med cURL

För att rensa cacheminnet för en sida :

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

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

Rensa cacheminnet för en mapp :

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

Detta rensar alla cacher för webbadresser som börjar med "http://mon-site-web.com/wp-content/uploads/".

Rensning av en webbplats cache

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

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

HTTP-kod 200: rensningen lyckades utan några fel.

HTTP-kod 405: rensningen är inte auktoriserad eller ägde inte rum.

2. Rensning med ett insticksprogram eller en modul

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

Här är några plugins som har testats och verifierats för att vara kompatibla:

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

HTTPS-detektering och omdirigeringar

Den HTTPS-status och de portar som anges på Apache modifieras av mod_fastestcache-modulen som är inbyggd i Apache. Det är därför i allmänhet inte nödvändigt att göra några ändringar.

Om HTTPS-detektering inte fungerar med Fastest Cache kan detta dock orsaka oändliga omdirigeringsloopar. Det kommer därför att bli nödvändigt att ändra detekteringsdata.

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

• X-vidarebefordrad-proto
• X-vidarebefordrad-port

Så 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 SERVER_PORT-variabeln 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

CloudFlare CDN:er har HTTP-förfrågningsfilter som kan blockera "PURGE"- och "FULLPURGE"-förfrågningarna som används av Fastest Cache för att rensa cacheminnet.

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

Att använda båda tillsammans kan leda till oönskat beteende. Testa båda och använd den som bäst passar dina behov.