Varför hemsidor blir snabbare hos Templ

Och det behöver varken vara svårt eller tidskrävande att snabba upp en hemsida. I denna bloggpost förklarar jag webbhotellets betydelse för laddningstid, samt vad vi på Templ gjort för att öka hastigheten på våra kunders hemsidor med ett genomsnitt på över 200%.

Hur viktig är laddningstiden?

Det är inte bara konverteringsgraden som ökar i samband med minskad laddningstid, utan även andra beteenden påverkas, såsom hur länge besökaren stannar på hemsidan, samt hur många som återvänder till den. I slutändan är det varumärket som helhet som skadas om hemsidan är långsam.

Flera stora företag har analyserat hastighetens påverkan:

  • För Amazon innebar en tiondels sekund extra laddtid en minskning i försäljning på 1%. (Gigaspaces.com)
  • Pinterest genomförde en studie 2015, vilken visade att konverteringen på deras mobilanpassade hemsida ökade med 40% i samband med att laddtiden minskade med 60%. (Pinterest Engineering)
  • Google fastställde att en halv sekunds extra laddningstid resulterade i 20% mindre trafik. (Gigaspaces.com)

I flera omfattande studier, som inkluderar en stor volym hemsidor, påvisas hur viktig hastigheten är:

  • 47% av alla besökare förväntar sig att hemsidan laddar på 2 sekunder eller mindre. (Neilpatel.com)
  • 46 % av alla besökare återvänder inte till hemsidor som laddar långsamt. (Exai.com)
  • 70 % av alla konsumenter uppger att laddningstider påverkar deras vilja att handla från en webbshop. (Searchenginejournal.com)
  • 88 % av alla internetanvändare väljer webshoppar som är högpresterande och snabba. (Sweor.com)

På Templ har vi upptäckt att nästintill alla hemsidor har ouppnådd potential när det kommer till hastighet, och ofta är det webbhotellet som är orsaken till att det går långsamt.

Varför är webbhotellet långsamt?

Den vanligaste anledningen till att hemsidor laddar långsammare innan flytt till Templ, är att det tidigare webbhotellets tjänst är så kallad “Shared Hosting”. Det innebär att hemsidan placeras på en fysisk server med resurser som delas av många hemsidor. Förutom att detta riskerar hemsidans säkehet och upptid, så påverkar det även laddningstid negativt. Ett sådant webbhotell är också sällan optimerat för WordPress, och kan oftast inte erbjuda de funktioner som krävs för en riktigt snabb hemsida.

Templs tjänst är så kallad Managed WordPress Hosting, vilket på många sätt skiljer sig från traditionell Shared hosting.

Hur Managed WordPress Hosting påverkar dina laddningstider

Begreppet Managed WordPress Hosting har på senare tid tyvärr blivit något urvattnat. Idag skryter många webbhotell om att de är specialiserade på WordPress, samtidigt som de uppenbart erbjuder hosting även för andra plattformar. Managed WordPress Hosting kräver ett fokus på just WordPress, och att webbhotellet är byggt och har anpassat sin tjänst helt för plattformen.

Faktorer som möjliggör snabbare hemsidor på webbhotell med Managed WordPress Hosting är:

Den senaste tekniken – Använder webbhotellet Nginx/Litespeed, MariaDB, serverbaserad cache, CDN, HTTP3/Quic, senaste versionen av PHP?

Dedikerade resurser – Med resurser dedikerade för en hemsida, riskerar sidan inte att ladda långsamt på grund av överbelastning hos andra hemsidor på samma webbhotell. Överskrids resurserna kommer de i regel tillfälligt skalas upp och du bli notifierad med rekommendation att att uppgradera din plan, så att din laddningstid inte påverkas negativt.

Högpresterande molnservrar – Istället för att hemsidan placeras på en fysisk server i en dammig källare, använder moderna webbhotell ofta molnservrar från tex. Google och Amazon. När hemsidor placeras på Google Cloud Platform åtnjuter de samma teknik som Google själva använder för tjänster såsom Gmail och Google search.

Är Templ snabbare än andra webbhotell som erbjuder Managed WordPress hosting?

Vad som huvudsakligen skiljer Templ från andra webbhotell, förutom redan tidigare nämnda faktorer, är hastighetsoptimering – vilken anpassas efter hemsidan och utförs för hand. Det innebär att Templ kan snabba upp hemsidor ytterligare i samband med flytt från tidigare webbhotell.

Här är exempel på åtgärder Templ vidtar för att snabba upp kunders hemsidor:

WordPress-konfigurering – Optimal konfigurering av WordPress
Genomgång av plugins – Identifierar och ersätter plugins som saktar ned hemsidan.
Databasoptimering – Ersätter äldre databasformat till nyare
Felsökning – Undersöker om hemsidan har allvarliga fel
Serverlogg – Skannar serverloggen efter fel
Bildoptimering – Minska filstorleken på bilder
Aktivera och optimera cache – Kontrollerar och skräddarsyr cache

Tack vare optimeringstjänsten kan vil stoltsera med att samtliga hemsidor som flyttat över till Templ minskat sina laddtider. Här följer några exempel.

Sixtydays.com

Det skandinaviska modemärket Sixtydays, som tidigare använde shared hosting, sänkte sin laddningstid från 5.9 sekunder till 1.6 sekunder, genom att flytta sin hemsida till Templ.

Sixty-days-hemsida

När man undersöker en hemsidas hastighet talar man ofta om TTFB. Det betyder “Time to first byte” och mäter som namnet antyder tiden det tar för första byten på hemsidan att nå besökarens webbläsare. TTFB är alltså ett mått på webbserverns responsivitet, vilken förstås tydligt påverkas av webbhotellet. Sixtydays TTFB gick från 3.4 till 0.6 sekunder i samband med flytten till Templ.

Lotusproshop.se

Lotusproshop säljer skönhetsprodukter och förbättrade laddningstiden med 211% – från 5.6 sekunder till 1.8 sekunder – i samband med flytt till Templ

lotusproshop-hemsida

google-review-yang

Bjork-magnusson.se

Laddtiden på den anrika matgrossisten Björk-Magnussons hemsida gick från 18 sekunder (!) till dryga 1 sekund efter migration till Templ.

bjork-magnusson-hemsida

Theupskillcompany.se

The Upskill Company är innovativt företag inom kompetensförsörjning. Bolagets hemsida laddade redan relativt snabbt hos sitt tidigare webbhotell, men efter flytt till Templ mer än halverades laddningstiden.

theupskillcompany-hemsida

TTFB sänktes från 1 sekund till anmärkningsvärda 0.06 sekunder.

google-review-theupskilcompany

Flowersforfriday.se

Precis som namnet skvallrar om levererar Flowers for Friday blommor varje fredag, till den som vill piffa upp hemmet inför helgen. Webbshoppen är en viktig del i verksamheten och efter flytt till Templ sänktes laddningstiden till 0.7 sekunder från tidigare 3.08 sekunder.

flowers-for-friday-hemsida

Genomsnittlig förbättring

Med hjälp av hastighetsoptimeringar har Templ snabbat upp kunders hemsidor med i genomsnitt 202%, i samband med migrering. Den genomsnittliga laddningstiden innan flytt var 3.1 sekunder, och har i snitt sänkts till 1 sekund.

genomsnittlig-laddtid-templ

TTFB har i genomsnitt förbättrats med 351 % – från 1.9 sekunder till 0.4 sekunder.

genomsnittlig-TTFB

Betygen på Googles verktyg PageSpeed Insights har även de förbättrats, och snittbetyget har på desktop ökat med 27 % – från 61 till 77.6. På mobil är samma ökning 36 % – från 29.8 till 40.7.

pagespeed-insights

Hur snabb kan din hemsida bli?

Vill du veta mer om potentialen för din hemsida, och hur snabb den kan bli? Kontakta oss i chatten eller registrera ett konto på https://templ.io/sv/register/ – så hjälper vi dig att komma igång, och hastighetsoptimerar din hemsida kostnadsfritt.

*Templ har testat hemsidornas startsidor med verktyget tools.pingdom.com. Vid denna publicering, 2021-01-13, har statistiken baserats på 51 test. Hemsidorna som testats och flyttats till Templ har tidigare använt tjänsterna Oderland, Loopia, Binero, Beebyte, Cloudways, Miss Hosting och Siteground, m.fl.

Den kompletta guiden för att snabba upp WordPress (2019)

Jag heter Emanuel är medgrundare här på Templ, ett WordPress-specialiserat webbhotell byggt på Google Cloud.

Vi brinner för att göra hemsidor så snabba som möjligt, så att de blir omtyckta av Google och andra sökmotorer, och så att så många besökare som möjligt kan konverteras till affärer.

Under årens gång har vi hjälpt till att snabba upp hundratals WordPress-sidor och vi har här samlat våra bästa tips om hur du gör WordPress snabbare.

Oavsett vilken nivå av förkunskaper du har så tror vi att du kommer kunna ta med dig flera tips från denna guide och. Nu kör vi!

Faktorer som påverkar laddningstid

Innan vi dyker djupare in på olika sätt att optimera din WordPress-sida så är det viktigt att du förstår dig på grunderna och vilka faktorer det är som påverkar en hemsidas laddningstid.

Det finns i princip 4 olika faktorer som påverkar hur snabbt en hemsida laddas, och de är:

  • Sidans storlek i MB
  • Antal “requests” (eller hur många filer som laddas hem)
  • Om sidan är cachad eller inte
  • Om inte, hur lång tid det tar för servern att generera sidan med hjälp av PHP+MySQL

Med detta i åtanke så finns det alltså 4 olika aspekter man kan jobba med för att snabba upp din hemsida: minska sidans storlek, minska antalet filer som laddas, aktivera cachning samt hålla koden så ren som möjligt (läs: använd så få plugin som möjligt).

Håll dig till ett mätverktyg

Det finns många olika verktyg för att mäta hastigheten på en hemsida. Några av de mest populära verktygen är:

Alla dessa verktyg låter dig mäta hastigheten på din hemsida på ett kontrollerat sätt och alla presenterar också åtgärder som du kan utföra för att snabba upp din WordPress-sida.

Utöver dessa webbaserade verktyg så har även de flesta webbläsarna ett inbyggt verktyg för att mäta hastighet. Vårt favoritverktyg är Google Chromes Developer Tools, främst för att det är så lättillgängligt och ger en mest kontroll. Tänk dock på att när du mäter hastighet på din egen dator så är hastigheten på din internetuppkoppling ytterligare en variabel, medan de webbaserade verktygen mäter oberoende av ens egen uppkoppling.

Hastighetsmätare

Alla ovan nämnda verktyg i sig är bra, men vi rekommenderar att du håller dig till ett och samma verktyg för att mätningarna ska vara så konsekventa som möjligt. Alla verktyg mäter nämligen på lite olika sätt och det är lätt hänt att man jämför äpplen och päron om man använder olika verktyg i sina mätningar.

Ifall du vill öka din förståelse för vad alla olika invändningar så kan du även läsa vårt blogginlägg om det här.

Stirra dig inte blind på din sidas poäng

Många populära verktyg presenterar resultatet av en hastighetsmätning inte bara i siffror så som tid och total datamängd, utan väljer också att summera resultaten till en poäng. Medan poängen kan vara ett snabbt sätt att få sig upp en uppfattning om hur snabb ens sida är så är det också lätt hänt att man fokuserar för mycket på själva poängen än hastigheten i sig.

En del verktyg, så som Google PageSpeed Insights t.ex., är dessutom extremt nitiska i sin poängsättning så att försöka uppnå full poäng är dessutom ouppnåeligt för 99% av WordPress-sidor.

Med detta i åtanke är det viktigt att komma ihåg att den den faktiska hastigheten alltid är viktigare än poängen, och om du har en hemsida som laddar på runt 1 sekund så spelar poängen inte någon roll.

1. Välj ett bra webbhotell

Att välja ett bra webbhotell är A och O om man vill ha en hemsida som laddar snabbt, är tillgänglig 99,99% av tiden och som dessutom erbjuder bra support som kan hjälpa en när problem uppstår.

De flesta känner till att det finns väldigt många webbhotell på marknaden, både svenska och utländska, men vad desto färre kanske känner till är att det många väljer att bara kalla för ”webbhotell” kan faktiskt skilja sig åt väldigt mycket. Därför vill vi gå igenom tre olika typer av webbhotell och klargöra för skillnaden mellan dem så att du förhoppningsvis kan göra ett mer välgrundat val och hitta rätt typ av webbhotell för just dig.

Många webbhotell kan i vissa fall ge sken av att vara snabba om man mäter hastigheten på startsidan som oftast är cachad (vilket vi kommer närmare in på längre ner) men för att alla sidor på en hemsida ska ladda snabbt, inklusive WP Admin och andra dynamiska sidor så som en varukorg och kassa, så finns det inga genvägar utan ett verkligt snabbt webbhotell är ett måste.

1.1 Shared hosting

Shared hosting är den äldsta och vanligaste typen av hosting som webbhotell erbjuder. Vad shared hosting innebär är att webbhotellet tar en fysisk server och sedan placerar hundratals hemsidor på den.

Denna typ av hosting har fördelen att priset kan bli ganska lågt, men det innebär också ofta olika typer av problem vad det gäller prestanda och säkerhet eftersom ett väldigt högt antal hemsidor delar resurser och inte är särskilt isolerade ifrån varandra. Felsäkerheten är också ofta den undermålig då det räcker med att webbhotellet får problem med en enda server för att hundratals kunder eller fler ska drabbas, vilket alltså innebär ökad risk för s.k. ”downtime” (tid då ens hemsida inte går att nå).

Två populära svenska webbhotell som erbjuder shared hosting är Loopia och Oderland, medan GoDaddy och Siteground är två stora internationella alternativ.

1.2 VPS

VPS står för Virtual Private Server och är, som du kanske listat ut, en virtuell server, vilket egentligen är en eller flera fysiska servrar som delats upp med hjälp av mjukvara till många virtuella servrar.

VPS kan ha fördelar vad det gäller prestanda jämfört med shared hosting, men det är upp till en själv som kund att konfigurera hela servern och se till så att allt fungerar. Med VPS får man maximalt med hårdvara per krona men man står också helt ensam och har ingen support när det kommer till mjukvaran på servern, så att placera sin hemsida på en VPS är oftast för svårt och tar alldeles för mycket tid för gemene man.

Är man intresserad av att själv placera sin hemsida på en VPS så kan man kolla in Svenska Glesys, eller de utländska gigaterna Amazon AWS och Google Cloud.

1.3 Managed hosting

Ett relativt nytt alternativ till shared hosting och VPS är managed hosting, vilket är just den typen av hosting som vi här på Templ erbjuder.

Denna typ av webbhotell erbjuder modernare infrastruktur än shared hosting och därmed kortare laddningstider, förbättrad säkerhet och minimal downtime, och eftersom managed hosting fokuserar på enbart WordPress så kan man också förvänta sig bättre support.

Managed hosting ger en mycket bra prestanda samtidigt som man slipper själv hålla på och pilla med optimeringar på servern och sköta saker så som backuper själv.

Medan vi är först på den svenska marknaden att erbjuda managed WordPress hosting så finns det flera utländska alternativ så som WPEngine och Pagely.

1.4 Sökkriterium webbhotell

Oavsett vilken typ av webbhotell du väljer så tycker vi att du bör leta efter dessa funktioner/specifikationer när du väljer webbhotell:

  • PHP 7.3: Varje ny version av PHP kommer vanligtvis med hastighetsoptimeringar så ju nyare version du har tillgång till desto bättre. I dagsläget är det PHP 7.3 som är den senaste stabila versionen även om PHP 7.4 kommer senare i år.
  • HTTP/2 (eller ännu bättre: QUIC eller ”HTTP/3”): Många känner inte ens till att det finns olika versioner av HTTP-protokollet, men faktum är att det är en tungt vägande faktor för hur snabb din hemsida är. HTTP/2 klarar av att hantera flera parallella nedladdningar än dess föregångare, och det finns dessutom ett ännu nyare protokoll som heter QUIC och som är ännu snabbare och kandiderar till att senare komma att kallas HTTP/3.
  • Nginx eller LiteSpeed över Apache: Alla webbhotell använder sig av någon bakomliggande programvara på deras webbserver. Apache är den äldsta och än idag den mest populära, men idag finns det modernare alternativ som har stora fördelar när det kommer till hastighet och skalbarhet, nämligen Nginx och LiteSpeed.
  • Server cache: Det är alltid möjligt att installera olika cache-plugins för att snabba upp WordPress, men ett PHP-baserat cache-plugin kommer aldrig att bli lika snabbt som en cache som körs direkt på servern (mer om detta senare i artikeln), och det finns också andra typer av cache för att snabba upp PHP som måste köras på server-nivå så som Redis och ElasticSearch.
  • Stagingmiljö: En funktion för att enkelt kunna sätta upp en kopia av sin hemsida att använda som testmiljö underlättar så att man enkelt kan testa nya inställningar, plugins och optimeringar utan att behöva riskera att man förstår något på sin skarpa hemsida och stör ens besökare.
  • Servrar nära dina besökare: För att en hemsida ska ladda så snabbt som möjligt så är det viktigt att du placerar din hemsida på ett webbhotell vars servrar ligger nära dina besökare. Med andra ord är det mycket bättre att du väljer ett webbhotell med servrar i Sverige eller andra närliggande länder, snarare än ett webbhotell med sina servrar i ex. USA.
  • CDN: Vi kommer gå mer in på djupet med fördelarna med CDN senare i denna guide, men det kan vara bra att känna till redan nu att vissa webbhotell inkluderar CDN i deras priser medan andra gör det inte, så du gör bäst i att välja ett webbhotell där det ingår istället för att behöva betala extra för det senare.

2. Cache

Om du tidigare har hört något om hur du snabbar upp WordPress så är sannolikheten hög att du hört folk prata om cache.

Men, även om de flesta har hört talas om cachning så råder det stor förvirring kring vad en cache egentligen är för något och de olika typer av cache som kan användas för att minska din hemsidas resursanvändning, skala upp den för att klara av fler besökare och korta ner laddningstider avsevärt.

2.1 Page cache

Vad som gör WordPress och andra publiceringsverktyg så populära är just att de levererar dynamiskt innehåll som är enkelt att ändra och som dessutom kan anpassas efter besökaren.

Medan det förstås på många sätt är suveränt att innehållet på en WordPress-sida inte är statiskt så är det så att det tar längre tid och mer resurser att generera dynamiska sidor för varje besökare än vad det tar att servera statiska HTML-sidor.

Det är här som en page cache kommer in i bilden. Vad en page cache gör är att den lagrar sidor som genereras som statisk HTML, så att samma sidor slipper att generas på nytt av PHP och MySQL vid varje sidvisning. Därför kan användandet av cache snabba upp din hemsida avsevärt.

Hur en sida genereras om den inte finns cachad
Hur en sida genereras om den inte finns cachad
Hur en sida serveras från cache
Hur en sida serveras från cache

Att använda sig av en page cache har framförallt två stora fördelar:

  • Minskad resursanvändning
  • Sidor kan levereras snabbare till besökare (lägre TTFB eller ”time to first byte”)

Page cache med hjälp av plugin
Om du inte redan använder dig av någon cache idag så är det som tur är enkelt fixat i WordPress med hjälp av ett plugin. Det finns en hel uppsjö av olika cache plugin man kan kan välja mellan, och nedan har vi listat ett par olika alternativ som vi kan rekommendera:

Page cache på server-nivå
Medan alla plugins som vi listade ovan gör tricket och låter dig använda dig av en page cache, så är det ännu bättre att använda sig av en cache-lösning som körs direkt på servern istället för som ett WordPress plugin.

En page cache som körs direkt på servern kommer alltid vara ännu snabbare och resurssnålare än en page cache som körs som ett PHP-baserat plugin. Vi på Templ, likt många andra premium webbhotell, erbjuder förstås page cache på servernivå.

Test av page cache:
För att kunna mäta hur stor påverkan varje optimering har så satte vi upp en testsite med det populära temat Flatsome installerat.

Först så testade vi att ladda startsidan utan någon page cache aktiverad och då laddade startsidan på ca 0,7 sekunder och med en TTFB (eller Time To First Byte) på ca 75 millisekunder:

Exempel på ingen page cache
TTFB (Time To First Byte) utan page cache

Sen så aktiverade vi våran serverbaserade page cache och testade igen och då laddade sidan istället på ca 0,6 sekunder och TTFB på ca 16 millisekunder.

Time To First Byte är ett mått på tiden det tar från det att webbläsaren skickar en request tills dess att servern skickat första byten tillbaka. Denna tid inkluderar alltså tiden det tar för servern att generera sidan med hjälp av PHP och MySQL (så tillvida att man inte använder en page cache).

Object cache

En annan typ av cache som vi rekommenderar att använda är object cache. En object cache är en annan typ av cache som istället för att spara hela sidor så sparar den istället vanligt förekommande databasanrop till minnet och slipper på så sätt utföra samma databasanrop upprepade gånger.

Till skillnad från en page cache så har en object cache även påverkan på WP Admin och kan snabba upp din WordPress-sida, speciellt om du har en stor databas innehållandes många blogginlägg, kommentarer, WooCommerce-produkter och ordrar.

Ett exempel på en populär object cache är Redis, vilket många webbhotell i premiumsegmentet erbjuder, och så även vi här på Templ.

Test av Redis object cache
För att lättare kunna illustrera fördelarna med Redis så installerade vi pluginet Query Monitor på vår testsida. Det pluginet låter oss se hur lång tid det tar för servern att generera en sida och även antalet databasanrop som krävdes för att generera en sida.

När vi testade att ladda startsidan på vår testsida utan Redis, och denna gång inloggad som admin så att vi får tillgång till data från Query Monitor så genererades sidan på 0,25 sekunder och 218 databasanrop utfördes:

Exempel utan Redis object cache
218 databasanrop utan Redis

Efter att vi aktiverade Redis så kunde sidan istället genereras på 0,17 sekunder och med hjälp av 72 databasanrop:

Exempel med Redis object cache
72 databasanrop med Redis

Vi sparade alltså inte mindre än 146 databasanrop på vår startsida och sidan kunde genereras 32% snabbare med hjälp av Redis. Inte illa!

Browser cache

En annan typ av cache som du bör använda på din hemsida är browser cache.

Vad en browser cache gör är att den sparar statiska filer i besökarens webbläsare och slipper på så sätt att ladda om samma filer om och om igen vid varje sidvisning. Detta kan vara både bilder, CSS-, JavaScript-filer och andra resurser som din hemsida är beroende av för att kunna visas.

Detta snabbar förstås upp din hemsida avsevärt för sånna besökare som klickar sig in på flera sidor på din hemsida, och det sparar också mycket bandbredd och därmed pengar. Vi rekommenderar alla att se till att använda sig utav browser cache.

Precis som med page cache så finns det många plugins till WordPress som fixar detta åt dig, om inte redan ditt webbhotell har skött denna konfigurering åt dig.

Några plugins som kan hjälpa dig med detta är:

Hur vet man ifall man använder sig av browser cache eller ej?
Du kan enkelt kolla ifall du använder nyttjar browser cache eller ej genom att kolla ifall s.k. ”expiry headers” är satta eller inte.

För att kolla det så kan du gå in under Network-fliken > klicka på någon av resurserna som hämtats > och se ifall du där kan se ”expires” under Response Headers eller inte. Ifall expires är satt så kan browser cache nyttjas.

Kolla ifall du använder browser cache eller ej
Ifall du kan se ”expires” under Response Headers så kan browser cache nyttjas

Test av browser cache
För att försäkra dig om att du testar en sida utan att använda browser cache så kan du kryssa i ”Disable cache”-rutan under Network-fliken i Chromes Developer Tools och kolla hur stor datamängd som laddas hem vid varje sidvisning.

Vår testsida laddar totalt 1.9MB data om vi inte nyttjar browser cache:

Exempel på outnyttjad browser cache
Kryssa i ”Disable cache” för att mäta utan browser cache

Om vi istället kryssar ur ”Disable Cache” och laddar startsidan igen så ser det ut så här:

Exempel på nyttjande av browser cache
Med nyttjande av browser cache så laddas bara 0.16MB istället för 1.9MB

Genom nyttjande av browser cache så kan vi se att enbart 163KB läses in istället, vilket alltså är 91% mindre data och sidan laddade dessutom på under 0,5 sekunder istället för över 0,6. Browser cache gör alltså underverk för besökare som går in på mer än en sida.

3. Optimera bilder och grafik

Det är oftast så att bilder utgör den största delen av den datamängd som hämtas när man besöker din hemsida, därför så är det väldigt viktigt att man jobbar med sina bilder för att ens hemsida ska ladda så snabbt som möjligt.

Det finns många plugins till WordPress som automatiskt komprimerar bilder när du laddar upp dem, och de två mest populära alternativen är i dagsläget:

Genom att komprimera dina bilder väl så kan du ofta snabba upp din hemsida rejält och spara in flera hundra KB på din startsida.

Test av väl komprimerade bilder
För att se hur stor del av den totala datamängden av en sida som utgörs av bilder så kan du trycka på ”Img” över vattenfallet och se ”resources” på raden längst ner.

Så här såg vår testsida ut innan vi komprimerade bilder:

Exempel på sida utan optimerade bilder
301KB av vår testsida utgjordes ursprungligen av bilder

Och efter optimering av bilder så såg det istället ut så här:

Exempel på sida med väl optimerade bilder
219KB bilder efter optimering (minskning med 82KB)

Vi kunde alltså minska den totala storleken på alla bilder på vår testsida från 301KB till 219KB, vilket inte är så illa, men vår testsida var ganska fattig på bilder och många av bilderna var från början redan hyfsat optimerade. Många andra sidor kan dra ännu större nytta av att optimera bilder väl.

Utöver att komprimera bilder så är det även viktigt att du kontrollerar så att bilderna laddar i rimlig storlek. Ibland händer det att man laddar upp bilder direkt från sin kamera till WordPress och att de laddas i sin fulla upplösning och då väger 5-10MB eller ibland mer.

4. Komprimering med gzip

Gzip är en teknik som används för att komprimera data innan det skickas från webbservern till besökaren, och på så sätt minskar den totala datamängden så att sidor kan laddas snabbare. Komprimering med gzip har väldigt stor påverkan på storleken av textfiler så som css och js-filer.

De flesta seriösa webbhotellen aktiverar gzip-komprimering åt sina kunder redan, men för att vara på den säkra sidan så kan du bekräfta att resurser på din sida komprimeras med gzip genom att under Network-fliken klicka på en resurs och kolla under Response Headers så att det där ser ut så här:

Kolla ifall du använder gzip-komprimering eller ej
Bekräfta att du nyttjar gzip-komprimering

Ifall ditt webbhotell inte har konfigurerat gzip åt dig redan så kan det vara så att en del cache-plugin löser den saken åt dig, men det beror på vilket webbhotell du använder. Ifall du är osäker så rekommenderar vi att du kontaktar ditt webbhotell.

Jämförelse, med och utan gzip
För att kunna jämföra skillnaden med och utan gzip så inaktiverade vi först gzip-komprimering på vår testsida, och resultat såg då ut så här:

Exempel utan gzip-komprimering
Vår testsida väger in på 1.8MB utan gzip

Efter det så aktiverade vi gzip igen och vi kan då se att skillnaden är enorm:

Exempel med gzip-komprimering
Med nyttjande av gzip väger sidan istället in på 862KB

Att använda gzip krympte alltså den totala storleken på sidan med över 50% vilket förstås kan ha stor påverkan på laddningstid på sidan.

För den som vill kunna nyttja ännu bättre komprimering än gzip så finns det en nyare och än mer effektiv komprimeringsteknik – brotli (eller bara br) vilket vi på Templ förstås erbjuder.

5. Gå igenom dina plugins

En annan förutsättning för att ha en så snabb sida som möjligt är att hålla antalet plugins som du installerar på din sida till ett minimum. Visst, alla plugins slöar inte nödvändigtvis ner din sida, men i regel är det så att ju fler plugins man har installerat desto segare kommer ens sida att bli.

Medan många WordPress-plugins lägger till funktionalitet som vi inte kan vara utan så bör man också ha de negativa sidorna som många plugins medför, vilka kan vara:

  • Tynger ner databasen – Många plugins lägger till nya tabeller i databasen och lägger till många nya värden i wp_options vilket kan göra din databas trögare.
  • Lägger till JavaScript och CSS-filer på samtliga sidor – Många plugins lägger inte bara till JS och CSS-filer på sidor där de faktiskt används utan på samtliga sidor på din hemsida.
  • Potentiell säkerhetsrisk – Plugins från mindre seriösa utvecklare och som dessutom uppdateras sällan eller aldrig är en potentiell säkerhetsrisk för din sida.

Ytterligare ett problem med att installera plugins som man egentligen inte behöver är att även om man avinstallerar ett plugin i WP Admin så lämnar de typiskt efter sig spår i databasen, vilket förstås gör databasen större och kan även göra din sida slöare, detta trots att du avinstallerat pluginet.

Vi rekommenderar att du går igenom de plugins som du redan har installerat på sida idag och ta bort de som du verkligen inte behöver, och undvik i fortsättningen att installera något som verkligen inte är ett måste.

6. Inaktivera onödiga WordPress-funktioner

Om man kollar under Network-fliken i Chromes Developer Tools och filtrerar efter JS-filer så kan man där ofta se en hel del saker som man inte känner igen och som verkar onödiga. På vår testsida så reagerade vi på dessa filer:

Onödiga JavaScript-filer
Vi kan se flera JavaScript-filer som vi inte behöver

jquery-migrate.min.js
Ett script för bättre bakåtkompabilitet med äldre JavaScripts, något som är onödigt på vår sida då vi inte använder gamla JavaScript som kräver denna. Om du väljer att inaktivera denna på din sida, kolla då så att du inte får upp en massa felmeddelanden på sidan.

wp-embed.min.js
Ett arkiv som är jättebra för bloggar som behöver kunna baka in YouTube-videos i sina inlägg, men något som vi inte behöver på vår sida.

wp-emoji-release.min.js
Detta är ett JavaScript som konverterar textsmileys så som :-) till bildfiler istället, något som idag känns ganska onödigt när våra datorer och mobiler har inbyggt stöd för emojis.

zxcvbn.min.js 
Detta är ett smart litet JavaScript som säkerställer att användarna väljer ett säkert lösenord. Denna JS-fil innehåller dock tusentals och åter tusentals exempel på dåliga lösenord, så denna fil är faktiskt den största filen som läses in på vår sida just nu, och är dessutom helt onödig då vi inte låter ”kunderna” på vår testsida välja sitt eget lösenord.

För att ta bort dessa så lade vi till lite kod i vårt temas functions.php:

// disable zxcvbn
function remove_password_strength_meter() {
  wp_dequeue_script('zxcvbn-async');
  wp_deregister_script('zxcvbn-async');
}
add_action('wp_print_scripts', 'remove_password_strength_meter');

// disable wp-emoji
remove_action( 'wp_head', 'print_emoji_detection_script', 7 ); 
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' ); 
remove_action( 'wp_print_styles', 'print_emoji_styles' ); 
remove_action( 'admin_print_styles', 'print_emoji_styles' );

// disable wp-embed
function my_deregister_scripts(){
  wp_dequeue_script( 'wp-embed' );
}
add_action( 'wp_footer', 'my_deregister_scripts' );

// disable jquery-migrate
function dequeue_jquery_migrate( $scripts ) {
  if ( ! is_admin() && ! empty( $scripts->registered['jquery'] ) ) {
    $scripts->registered['jquery']->deps = array_diff(
      $scripts->registered['jquery']->deps,
      [ 'jquery-migrate' ]
    );
  }
}
add_action( 'wp_default_scripts', 'dequeue_jquery_migrate' );

Efter att ha inaktiverat de WordPress-funktioner som vi ansåg som onödiga på vår testsida så såg resultatet ut så här:

Utan onödiga JavaScript
7 JS-filer färre, och över 400KB insparade

Vi lyckades alltså spara in hela 7 requests och 404KB data bara genom att inaktivera ett par funktioner som vi ansåg som onödiga.

Vilka JavaScript som laddas på din sida beror på vilka plugins du har installerat och att veta vilka som inte används är inte alltid helt enkelt, så detta är något man ibland måste testa noga eller ta hjälp av en expert för att åtgärda.

7. Använd CDN

CDN är en förkortning av Content Delivery Network och är ett nätverk av servrar placerade på olika platser runt jorden och som serverar statiska filer så som bilder, CSS och JavaScript m.m.

CDN

Fördelen med detta märks tydligast för besökare från andra delar av världen än just Sverige, då de kan hämta filer från servrar placerade i närheten av dem istället för att allt måste hämtas från andra sidan jorden.

Ifall ditt webbhotell inte har inbyggt stöd för CDN så finns det några populära alternativ från 3e part som du kan överväga:

Alla CDN-lösningar listade ovan är enkla att komma igång med. Det är bara registrera sig (och betala, om nödvändigt) och sedan konfigurera CDN i WordPress antingen med leverantörernas egna plugin eller med pluginet CDN Enabler.

För att testa fördelarna med CDN så använde vi oss av verktyget Pingdom och mätte tiden det tog att ladda vår testsida från San Francisco i USA. Utan CDN aktiverat såg det ut så här:

Exempel utan CDN
Det tog 2,13 sekunder att ladda sidan från San Francisco utan CDN

Och efter att vi aktiverat vår CDN så kunde vi snabba upp sidan med 33% och siffrorna såg istället ut så här:

Exempel med CDN
1,42 sekunder med CDN

En CDN har förutom fördelen att man snabbare kan servera resurser över hela världen också fördelen att den hjälper till att avlasta ens huvudserver som man vill ska ha så mycket lediga resurser som det bara går för att WordPress ska kunna nyttja så mycket kraft som möjligt och generera sidor snabbare.

Så oavsett ifall dina besökare enbart befinner sig i Sverige så har en CDN ändå fördelar och är något vi rekommenderar att använda.

Summering

För att jämföra vår testsidas laddningstid före och efter våra optimeringar så mätte vi återigen med hjälp av Pingdom, fast denna gång med Frankfurt som mätstation då det är det valet som ligger närmast Sverige, och så här såg siffrorna ut innan vi utförde våra optimeringar:

Pingdom före våra optimeringar
Pingdom före våra optimeringar

Och efter våra optimeringar så såg det istället ut så här:

Pingdom efter våra optimeringar
Pingdom efter våra optimeringar

Våra uppmätta förbättringar enligt Pingdom ser alltså ut så här:

  • Storleken på sidan gick från 1.9MB till 414KB – en minskning med 78%
  • Antalet requests gick från 54 till 47st
  • Laddningstiden sänktes från 856 till 576 millisekunder – 33% snabbare

Med hjälp av dessa relativt enkla knep så lyckades vi förbättra vår hemsida ganska så dramatiskt, och med en laddtid på under 0,6 sekunder så tycker jag att vi kan känna oss väldigt nöjda, men om du applicerar samma knep på din WordPress-sida så är sannolikheten att du kan göra ännu större framsteg än så här.

Ifall du tyckte att denna guide var hjälpsam så uppskattar vi om du kunde dela artikeln med andra som du tror skulle ha användning för den.

Ifall du har fler tips på att snabba upp WordPress så får du jättegärna lämna en kommentar här nedanför.

Tack för att du läste!

Hur man tolkar mätresultat från Pingdom & Google PageSpeed Insights

Vi har alla hört hur viktigt det är att ens hemsida laddar snabbt och de flesta har nog använt verktyg så som Pingdom, Google PageSpeed Insights, GTmetrix för att mäta hur snabbt ens sida laddar. Men hur många är det egentligen som förstår mätresultaten som dessa verktyg presenterar?

I detta blogginlägg tänkte jag på ett så pedagogiskt vis som möjligt gå igenom vad de vanligaste förbättringspunkterna egentligen betyder på ren svenska samt vad man kan göra åt dem.

Nu kör vi!

Innehållsförteckning:

Reduce DNS lookups

Varningen ”Reduce DNS lookups” beror på att det hämtas resurser från ett ganska stort antal olika domäner när man laddar en sida. Bakom varje domän finns det en IP-adress och första gången en domän anropas så görs en s.k. DNS lookup så att besökarens dator vet vilken IP-adress som ligger bakom varje domän.

Varje domän kräver en DNS lookup vilket tar lite tid att genomföra. Det man kan göra för att förbättra detta är att gå igenom vilka domäner det hämtas resurser ifrån när ens sida laddas och se om det finns något onödigt som man kan ta bort. Kanske har du något plugin som du inte längre använder som hämtar resurser från en CDN?

Make fewer HTTP requests

Varje gång någon besöker din hemsida så laddas det alltid flera olika filer som exempelvis bilder, JavaScript och CSS-filer. Varje gång en fil hämtas så skickas en s.k. HTTP request från din webbläsare till servern där filernas hämtas ifrån, och ju fler filer som hämtas desto längre tid tar en sida att ladda – därav rådet ”make fewer HTTP requests”.

Medan närapå alla hemsidor kräver ett flertal filer för att ens fungera så är det förstås inte bra om det är för många resurser som behöver hämtas hem. Detta trots det faktum att HTTP2, som är standard hos alla seriösa webbhotell idag, är betydligt effektivare på att hantera många requests.

En vanlig åtgärd för att minska antalet requests, förutom att gå igenom exakt vad som laddas och ta bort ev. resurser som man inte verkligen behöver, är att kombinera CSS och JS-filer med varandra hjälp av plugin så som exempelvis Asset CleanUp, WP Fastest Cache m.m.

Avoid URL redirects

Detta är en varning som visas då adressen som man försöker mäta vidarebefordrar besökaren till en annan adress, eller att resurser som hämtas från tredje part har pekats om.

För att försöka få bort denna varning så bör man först kontrollera att adressen man skrivit in är korrekt och att man inte blandat ihop https:// med http:// eller att man glömt ett ”/” på slutet av adressen. Det är också en bra idé att kontrollera så att kopplingar med trejde part så som t.ex. Google Analytics, supportchatt och andra plugins är uppdaterade och följer utvecklarens senaste anvisningar.

Add expire headers / Leverage browser caching

Expire headers är något som sätts utav en webbserver som talar om för alla besökare hur länge filer som hämtas bör sparas i besökares webbläsare. Om expire headers inte är satta rå riskeras varje fil hämtas på nytt vid varje sidvisning, därav uppmaningen ”add expire headers”.

Hur man åtgärdar detta beror på vilket webbhotell man har och hur deras servermiljö ser ut, men oftast görs det genom att modifiera sin .htaccess-fil eller installera ett plugin som gör jobbet åt en.

Tyvärr så är det inte sällan externa resurser från ex. Google och Facebook som inte cache:as i besökarens webbläsare och som sänker ens mätresultat i detta avseende, och externa resurser har man ingen möjlighet att påverka annat än att överväga att ta bort dem.

Enable gzip compression

Gzip är likt det i folkmun mer välkända zip en kompressionsteknik som gör filer mindre och därmed snabbare att ladda. Gzip-komprimering på en hemsida gör så att istället för att varje fil hämtas i klartext så komprimeras de först till gzip-format vilket gör att mängden data som måste hämtas vid varje besök blir mindre.

Då gzip-komprimering är något som görs på servernivå så är det likt expire headers något som hanteras olika beoroende på ens webbhotell, men oftast med hjälp av plugin eller manuellt ändrade av ens .htaccess-fil.

En cookie ä ren liten fil som hemsidor först skickar till besökarens dator, ofta för att kunna komma ihåg vem besökaren är och för att kunna servera skräddarsytt innehåll för varje besökare. Efter att en cookie har sparats så skickas sedan besökarens alla cookies för den domänen man besöker med vid varje request, något som förstås kräver viss extra bandbredd även om vi cookies vanligen är väldigt små.

Cookies är en nödvändighet för att saker som varukorgar och inloggningar ska kunna fungera, men vad det gäller hämtning av statiska filer så skickas besökarens cookies med helt i onödan och därför kan man snabba upp något genom att servera statiska filer så som bilder, JavaScript och CSS via en CDN med en annan domän som inte sparar några cookies.

Eliminate render-blocking resources / Defer parsing of JavaScript

Varningen “eliminate render-blocking resources” visas när du har JavaScript eller CSS-filer som förhindrar sidan att så snabbt som möjligt bli synlig i besökarens webbläsare. Viss JavaScript och CSS-kod är inte absolut nödvändig för att en hemsida ska kunna visas och därför är det bättre att icke obligatorisk kod laddas på ett sätt som inte blockerar sidan att renderas i en webbläsare.

Man kan göra så att JavaScript laddas på ett sätt som inte är ”render-blocking” genom att använda sig av ”async” eller ”defer”-attribut som talar om för webbläsare att inte vänta på JavaScript-filer innan andra saker kan laddas.

För att få bukt på det här problemet så finns det en mängd plugins till WordPress som kan hjälpa till, men man bör ha i åtanke att det kan krävas en hel del pillande och testande innan man hittat exakt vilka JavaScript man kan mixtra med utan att oväntade problem på hemsidan dyker upp. Så kom ihåg att testa noggrant!

Några plugins som är värda att kolla in är Speed Boster Pack, Autoptimize, Async JavaScript samt Humming Bird.

Serve images in next-gen formats

Sedan en väldigt lång tid tillbaka så har JPG varit det mest populära filformatet för bilder på internet. Det blev snabbt väldigt populärt då det levererade väldigt bra komprimering vilket gjorde bilder mindre i storlek och snabbare att ladda. Men sedan en tid tillbaka så finns det nu en konkurrent till JPG – närmare bestämt WebP.

WebP erbjuder ännu bättre komprimering än JPG och möjlighet att spara 25-35% i storlek med snarlik bildkvalité. Utöver bättre komprimering så har WebP även andra fördelar över JPG så som stöd för animationer och transparens.

Då WordPress (ännu) inte har inbyggt stöd för bilder i WebP-format så kräver det hjälp från plugin och webbserver för att få det att fungera. Vi på Templ.io har hjälpt flera av våra kunder att konfigurera och komma igång med pluginet WebP Express och kan rekommendera det.

Sammanfattning

Med den här artikeln hoppas vi att vi har bringat lite mer klarhet i de mätresultat som de populära verktygen presenterar och gett dig några konkreta lösningar på hur du kan snubba upp din hemsida.

Om ni kommer på flera termer gällande hastighet så tveka inte på att fråga oss i kommentarerna nedan.

Därför stödjer Templ.io QUIC & varför ditt webbhotell också borde göra det

Först så hade vi HTTP.

Sen kom HTTP/2 som innebar nya funktioner och förbättrad hastighet för webben.

Nu finns även QUIC som innebär ytterligare ett jättekliv för både hastighet och säkerhet, och det är en kandidat till att bli HTTP/3 och med tiden ersätta HTTP/2.

QUIC är ett nästa generationens internetprotokoll som är krypterat per default och som kan minska laddtider på internet avsevärt, speciellt för mobila uppkopplingar och för uppkopplingar med dålig bandbredd.

Templ.io har aktiverat QUIC för alla våra kunder

På Templ.io har vi redan aktiverat QUIC för alla våra kunder som använder vår gratis Google Cloud-baserade CDN och vi har har redan sett stora förbättringar på våra kunders hemsidors laddtider.

QUIC är ett initiativ av Google (som HTTP/2 också var) och kommer med flera stora förbättringar:

  • Kraftigt minskad anslutningstid
  • Ökad redundans vid paketförlust
  • Förbättrad överbelastningskontroll
  • Migration av anslutning

Kraftigt minskad anslutningstid

HTTP/2 kräver vanligen 2-3 rundturer av anrop mellan webbläsare och webbserver för varje besök innan en säker anslutning har upprättats.

Med QUIC å andra sidan så kan servern börja skicka data till besökarens webbläsare direkt, utan en enda rundtur ifall de tidigare har kommunicerat med varandra, något som kan kraftigt minska anslutningstiden (även kallad ”time to first byte” eller TTFB) vilket ofta mäts av speedtest-verktyg så som Pingdom och Webpagetest.org.

HTTP/2 jämfört med QUIC. Källa: Google

Ökad redundans vid paketförlust

HTTP/2 möjliggjorde flera strömmar av data i en enda anslutning, men alla dessa strömmar av data kan blockeras samtidigt bara ett enda TCP-paket går förlorat – ett problem som kallas för ”head-of-line blocking”.

QUIC, likt HTTP/2, har också stöd för flera strömmar av data i en anslutning men använder ett mer redundant sätt att överföra data på med hjälp av UDP istället för TCP. Med QUIC så innebär inte längre en förlust av ett enda paket att andra requests saktas ner utan det påverkar enbart just det paketet.

Förbättrad överbelastningskontroll

överbelastningskontroll är ett väldigt komplext ämne i sig och det är inget som jag kommer fördjupa mig i i det här blogginlägget. Så här lyder en kort sammanfattning om QUICs ambitioner gällande överbelastningskontroll, saxat från Wikipedia:

QUIC’s secondary goals include reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion.

Migration av anslutning – Från WiFi to mobildata och vice versa

QUIC skapades med mobila anslutningar i fokus och stödjer nu migration av befintliga anslutningar när man hoppar mellan WiFi och mobilt internet och vice versa.

Tiden då hemsidor helt slutas ladda bara för att din mobiltelefon tappade WiFi-anslutningen för en stund är nu passé!

Hur mycket snabbare är QUIC?

On a well-optimized site like Google Search, connections are often pre-established, so QUIC’s faster connections can only speed up some requests—but QUIC still improves mean page load time by 8% globally, and up to 13% in regions where latency is higher.

Källa: Google

Google menar alltså på att QUIC är 8-13% snabbare än HTTP/2 enligt efter att ha infört QUIC på google.com.

Google Cloud CDN throughput efter att ha aktiverat QUIC. Källa: Google

Hur du kan se ifall din hemsida använder QUIC eller inte

För att kolla ifall din hemsida laddas över QUIC eller inte så kan du öppna Developers Tools i din webbläsare, gå till fliken Network och kolla efter QUIC i kolumnen Protocol.

Ser du ingen kolumn som heter Protocol där så kan man högerklicka på en annan kolumn och där välja att visa den.

Kolla ifall din hemsida använder QUIC eller inte

Om du där kan se flera rader som nämner QUIC så voilà: du använder redan QUIC och är redo att blåsa om dina konkurrenter! ?

Använder du QUIC redan idag eller är du intresserad av att börja använda det?

Låt oss veta i kommentarerna nedan!

Källor:
https://cloud.google.com/blog/products/gcp/introducing-quic-support-https-load-balancing
https://www.litespeedtech.com/products/litespeed-web-server/features/quic-support/why-use-quic
https://blog.cloudflare.com/the-road-to-quic/