Våra WordPress-experter föreläser ofta om hur man optimerar hastigheten i WordPress. Därför är det inte konstigt att vi ofta får en hel del frågor om hastighetsoptimering från såväl WordPress-användare som utvecklare. Ibland nämns Cloudflare i dessa diskussioner, och när andra hör vårt svar blir de ofta förvånade.
Vår erfarenhet är att Cloudflare för det mesta gör en WordPress-webbplats långsammare i stället för att snabba upp den. Samtidigt medför det också en säkerhetsrisk. Av den anledningen bestämde vi oss för att skriva ett blogginlägg om våra erfarenheter.
Cloudflare säljer sina tjänster med idéen att en webbplats bör styra sin trafik via Cloudflares servrar i stället för att ta emot besökarna direkt på servern där den egna webbplatsen finns. Cloudflare menar att detta gör webbplatsen säkrare, snabbare och mer tillförlitlig.
Utöver dessa förbättringar samlar de in data som hjälper utvecklare att bättre förstå vad som händer på webbplatsen ifråga. I viss mån stämmer alla dessa påståenden, även om fördelarna vanligtvis är relativt marginella och därför inte är värda det extra besväret. Förbättringarna åtföljs dessutom av några nackdelar som inte beskrivs i deras marknadsföring.
Prestandaförbättringar enbart för webbplatser som saknar befintlig cachelösning på HTTP-nivån
Cloudflares påståenden om prestandaförbättringar bygger på att de har servrar över hela världen. När en webbplats är ansluten till Cloudflare kommer dess besökare att styras till någon av Cloudflares servrar i deras närhet. De erbjuder cachelagring från sina servrar på HTTP-nivån, vilket innebär att besökaren kan ladda hem webbsidan från en server som ligger närmare än vad webbplatsens egen server ligger.
Hur stor förbättring detta innebär beror på ett antal olika faktorer:
- Använder webbplatsen redan nu cachelagring på HTTP-nivån eller inte?
- Har Cloudflare några servrar som ligger så pass mycket närmare besökarna att detta kan ha någon verklig effekt? Och är deras server och deras nätverk snabbare än andra lösningar för cachelagring på HTTP-nivån?
- Hur stor del av trafiken kan betjänas av HTTP-cachen?
Seravo tillhandahåller cachelagring på HTTP-nivån som en standardfunktion sedan 2014. Nuförtiden har de flesta webbhotell infört åtminstone någon typ av HTTP-cachning i sina miljöer, under förutsättning att de försöker följa med i senaste praxis och aktuell teknik, såsom NGINX och Varnish. Cloudflare kan ge betydande prestandaförbättringar för en webbplats som finns på ett webbhotell som helt saknar cachelagring på HTTP-nivån, men att i det fallet aktivera Cloudflare innebär inte att man faktiskt löser det underliggande problemet.
Om en WordPress-sida finns sparad i cacheminne på HTTP-nivån kan den levereras blixtsnabbt av HTTP-cacheservern, med en laddningstid på cirka 1–5 millisekunder. Hur lång tid det tar för besökaren att ta emot dessa lagrade data beror dels på sidans storlek, dels på nätverksförbindelsens hastighet och eventuella fördröjning. Eftersom Cloudflare har servrar över hela världen är fördröjningen alltid liten. Vi gjorde några mätningar från en laptop på vårt Tammerforskontor, och i nedanstående tabell ser du vilka fördröjningar vi har uppmätt.
| Serverplacering | Fördröjning |
| Tammerfors | 11 ms |
| Helsingfors | 7 ms |
| Stockholm | 15 ms |
| Tyskland | 32 ms |
| Centrala USA | 126 ms |
Som du ser ökar fördröjningen märkbart först när man kopplar upp sig till en annan kontinent. Just av den anledningen kan Seravos kunder välja mellan flera olika serverplatser. Om kundens huvudmarknad exempelvis är USA, kan de välja att lägga upp sin webbplats på vårt kluster därborta, under förutsättning att GDPR eller andra prioriteringar inte står i vägen för detta.
Men fördröjning bara på grund av det geografiska avståndet är långtifrån hela sanningen. Fördröjningen beror på olika nätverksinställningar, hur snabbt ”handskakningen” för en TCP/IP-förbindelse sker för varje ny förbindelse och givetvis även hastigheten hos besökarens internetförbindelse. Tänk på skillnaderna mellan en tillförlitlig uppkoppling via fiberkabel från kontoret på ett stort företag och när du använder internet från din mobil och befinner dig i rörelse. Avståndet i sig självt är inte nödvändigtvis den viktigaste faktorn för att motverka hög fördröjning. I kampen mot hög fördröjning är det viktigaste att man hanterar den multiplicerade fördröjningen på rätt sätt.
Med multiplicerad fördröjning menas att varje enskilt element, varje bild eller enstaka fil från webbplatsen hämtas enskilt i stället för att hela sidan laddas in över en gemensam förbindelse och med komprimering – vilket leder till multiplicerad fördröjning på grund av att varje förfrågan sker över en separat förbindelse. Se till att du använder protokollet HTTP/2 för att dataöverföringen sker över en gemensam, komprimerad förbindelse, vilket eliminerar problemet med multiplicerad fördröjning. Seravo använder HTTP/2 som en standardfunktion för alla sina kunder sedan år 2016 och redan innan dess rullade vi ut en liknande teknik för förbättrad hantering av förbindelser med hjälp av SPDY.
Vid våra mätningar upptäckte vi dessutom att även om Clouflare styr all inkommande trafik till den server som finns närmast besökaren och de levererar webbplatsen från sitt HTTP-cacheminne, kommer laddningstiden ändå att vara direkt beroende av besökarens geografiska avstånd till den ursprungliga webbservern. Vi mätte på en webbplats som med Cloudflare hade en fördröjning på 10 millisekunder vid mätning från Finland, men 160 millisekunder vid mätning från USA. Om du använder Cloudflare bör du därför se till att mäta och kontrollera att du faktiskt får lägre fördröjning från världens alla hörn, eftersom det är den enda verkliga fördelen med Cloudflare.
Den sista frågan man bör ställa sig, och den som för övrigt kan ha störst inverkan, är hur stor del av webbplatsen som faktiskt cache-lagras på HTTP-nivån. Som ett exempel är det typiskt för en WooCommerce-butik att överhuvudtaget inte använda cachelagring på HTTP-nivån, eftersom varje kund har en cookie sparad i sin webbläsare för att säkerställa att de de sidor och det innehåll det får ta emot är personligt anpassade.
Om du använder Cloudflare på en webbplats som arbetar på detta sätt fördubblar du fördröjningen eftersom Cloudflares server behöver hämta sidan från den ursprungliga servern varje gång en besökare ansluter till Cloudflare. Besökaren behöver sedan vänta medan Cloudflares server och din egen webbserver pratar med varandra och överför data, istället för att skicka det efterfrågade innehållet omedelbart och mycket snabbare direkt från den ursprungliga servern.
Resultat från WebPageTest
WebPageTest.org är en oberoende tjänst för mätning av hastighet och prestanda hos webbplatser, vilken erbjuder omfattande information om hur din webbplats laddas in och uppträder. Just därför rekommenderar vi dem. Nedan visas två olika uppsättningar av mätningar för en webbplats som laddas snabbt och en som laddas långsamt. Den ena uppsättningen av mätningar gjordes med Cloudflare aktiverat, och den andra när det var inaktiverat.
Vi konfigurerar WebPageTest för att mäta laddtiderna från sin Amsterdam-server, något som bör gynna Cloudflare, eftersom webbplatserna finns på våra servrar i Finland. Om vi hade mätt direkt från Finland skulle vi ha fått ännu snabbare resultat, därför valde vi att använda Amsterdam som en neutral plats för att jämna ut förutsättningarna.
Trots att vi mätte från Amsterdam kan du se att Cloudflares hade ingen, eller rentav negativ påverkan på laddtiderna. I synnerhet var detta sant för den långsamma webbplatsen, en WooCommerce-webbplats där cachelagring på HTTP-nivå var avstängd. Där ökade laddtiden på grund av de extra signalvägarna. Denna typ av webbplats bör fokusera på att förbättra och optimera databasen och webbplatsens programkod. För dem innebär Cloudflare inga extra fördelar.
En mellanhand ger sämre säkerhet
När Cloudflare är aktivt på en webbplats ansluter webbläsaren till Cloudflares servrar när besökaren skriver in webbplatsens URL i adressraden. Uppkopplingen mellan dem skyddas av HTTPS-kryptering som tillhandahålls av Cloudflare. Cloudflares server avkrypterar besökarens förfrågan och kopplar upp sig mot den faktiska servern där själva webbplatsen finns. Slutanvändaren har ingen möjlighet att kontrollera att dennes information överförs i krypterad form. Webbplatsens ägare tvingas att lita på att Cloudflare klarar att trygga säkerheten för deras system och förhindra dataläckor. Hittills har de bara haft en större incident, Cloudbleed.
Vissa organisationer har begränsningar för till vilka platser deras avkrypterade data får exporteras. I dessa fall är Cloudflare uteslutet eftersom de kan avkryptera informationen på vilken som helst av de platser där de har sina servrar, vilket kan leda till att okrypterade data kan komma att behandlas i ett land där de inte borde bearbetas.
Som mellanhand kan Cloudflare eventuellt dölja grundläggande problem och förhindra att användbar information loggas. För slutanvändaren kan det se ut som om trafiken är krypterad och har stöd för HTTP/2, även om den kanske inte är krypterad mellan Cloudflare och den ursprungliga servern. Eftersom all trafik styrs via Cloudflare kan det också bli långt svårare att utreda säkerhetsintrång eftersom loggarna kommer att vara fyllda med Cloudflares IP-adresser, snarare än IP-adresserna för den faktiska besökaren.
I sitt marknadsföringsmaterial förklarar Cloudflare hur de filtrerar trafik och skydda webbplatser mot säkerhetsintrång och överbelastningsattacker. Vi har inte kunnat upptäcka att deras filtrering på något sätt skulle ta hänsyn till vad som är specifikt för WordPress, vilket innebär att de troligen inte skyddar mot attacker mot den programvaran som används på webbplatsen.
På nätverksnivån fungerar deras skydd. Men skydd mot överbelastningsattacker på nätverksnivån är idag redan en standardfunktion hos majoriteten av nätverksutrustning och operatörer av datacentraler.
Vilka använder Cloudflare?
Av alla våra kunder är det bara fem som använder Cloudflare. Om du har din webbplats hos oss finns det inga tekniska hinder för att styra trafiken via Cloudflare. I vissa fall kan det rentav visa sig vara fördelaktigt. Men, som vi har visat här, behöver nyttan mätas och bekräftas, man bör inte nöja sig med bara magkänsla och marknadsföringsmaterial.
Vierityspalkki är en populär finsk blogg om webbteknik, trender och branschen i allmänhet. När de jämförde 33 olika finska webbyråer med avseende på hur snabbt deras egna webbplatser laddas använde ingen av de 10 byråerna i toppen Cloudflare. Om målet är att ha en webbplats som laddas så snabbt som möjligt bör du koncentrera dina ansträngningar på själva webbplatsen och dess webbhotell.
Vad du bör fokusera på?
Flaskhalsarna för prestandan hos en WordPress-webbplats är antingen databasen eller dålig kod. Varken det ena eller det andra blir till något problem om du anlitar en bra webbyrå och kör webbplatsen hos Seravo eller något liknande webbhotell.
Vi har valt att fokuserar på att utveckla en tjänst som är till verklig nytta, baserat på verkliga data och fakta, för de kunder som använder vår webbhotellsplattform och som är optimerad för WordPress. Vår uppsättning av funktioner utformades från första början och utvecklas ständigt med fokuset att ge både utvecklare och webbplatsägare en maximalt enkel och tillförlitlig erfarenhet av serverhantering och drift. WordPress har sina utmaningar och problem, men med Seravo får du ut mesta möjliga ur din WordPress-lösning.
Som kund hos Seravo stödjer du även indirekt WordPress och communityn kring öppen källkod och utveckling. En av de bästa platserna för att få råd och kunskap om WordPress och hastighetsoptimering av webbplatser är i WordPress-communityn. Kom fram och hälsa på oss om du skulle hitta oss på någon WordCamp eller något annat evenemang för öppen källkod.