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

Vi har under årens gång 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 din hemsida snabbare.

Snabba upp WordPress

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!

Kommentera

Din e-postadress kommer inte offentliggöras. Obligatoriska fält markerade med *