Hur gör man WooCommerce snabbare?


Artikel av Thomas Audunhus. Published on mars 28, 2018

Allt fler kämpar med hastigheten i WooCommerce, vilket inte är konstigt då antalet e-handelssidor med WooCommerce ökar varje dag. Samtidigt ser jag allt fler dåliga förslag på hur man kan göra WooCommerce snabbare. På Servebolt arbetar vi dagligen med optimering av prestanda för WordPress och WooCommerce. Här är mina bästa tips på hur man bygger en så snabb WooCommerce-sida som möjligt.

Grundläggande principer för en snabb WooCommerce

Det finns några principer du bör följa för att säkerställa prestandan i WooCommerce. I grund och botten är WooCommerce snabbt – det är allt du lägger till som kan göra det långsamt.

Kör så lite kod som möjligt

All kod som läggs in har, vid någon tidpunkt, en inverkan på hur snabbt webbplatsen laddar. Att köra mindre kod är alltid bra för hastigheten i WooCommerce. Om du själv skriver koden bör du kontrollera att den verkligen behövs. Kod som t ex bara ska köras på produktsidor behöver inte finnas med på kategorisidor.

Tillägg – Avinstallera alla tillägg du inte behöver

Ett stort problem i WooCommerce, samt WordPress rent allmänt, är dåliga tillägg. Tillägg är ett enkelt sätt att utöka funktionaliteten i WooCommerce, men de innehåller många gånger onödig kod. Om du har kört samma butik en längre tid är chansen stor att du har tillägg installerade som inte längre uppdateras och innehåller både buggar och säkerhetshål.

Vår lista med tillägg att undvika

  • WordFence
  • iThemes Security
  • WP Optimize
  • WP Super cache
  • WP Rocket
  • W3 Total Cache

Dessa tillägg har enligt vår erfarenhet en negativ inverkan på antingen hastighet eller säkerhet (vilket är ironiskt, då detta är säkerhets- och prestandatillägg). Vi vill starkt avråda er från att använda dessa tillägg.

Tillägg du bör vara försiktig med

  • Visual Composer
  • Beaver Builder

Dessa tillägg kan likaså ha en negativ inverkan på din webbplats prestanda och bör användas försiktigt (testa gärna hastigheten både före och efter du använder dessa tillägg).

Buggar – fixa alla fel du vet om

Alla webbservar har en fellogg (error log) och det är ett av dina viktigaste verktyg för en så väl fungerande och snabb WooCommerce-sida som möjligt. Alla PHP-fel registreras i felloggen och om något finns med där så bör du åtgärda det.

Det finns två orsaker till detta; först och främst så är det omöjligt att få översikt och testa alla sidor i WooCommerce. Det kan vara tusentals enkla sidor, där olika fel kan visas för olika besökare (och sökmotorspindlar).

För det andra så handlar det om prestanda. Det är lätt för utvecklare att tänka ”det är bara en varning” eller ”det ger inget synligt fel”, men alla fel (och varningar samt notiser) tar tid att behandla. Det är lätt att underskatta hur mycket resurser detta tar.

Förra veckan hjälpte jag till att felsöka en webbplats, där de hade uppdaterat till WooCommerce 3 utan att kontrollera felloggen. Efter några timmars intensivt buggfixande tystnade felloggen – och webbplatsen var då hela 60 % snabbare (!).

Sedan är det inte bara PHP-fel som orsakar långsamma hemsidor. Även fel i HTML, CSS och JavaScript bör rättas omgående, innan de får saker och ting att gå långsamt.

Validera HTML på de viktigaste sidorna med W3 Validator

Korrekt strukturerad och formatterad HTML är viktigt för en smidig rendering av webbsidor. För att kontrollera detta kan du använda W3C Validator. När korrekt formaterad HTML används behöver webbläsaren inte arbeta lika hårt för att presentera sidan, vilket då gör den snabbare.

Databasmotor och tabell-index

För att WooCommerce ska fungera så bra som möjligt så krävs en bra och snabb databasmotor, såsom InnoDB. Utöver detta finns det många tillägg som ställer frågor på dåliga eller felaktiga sätt, vilket inte kan hanteras så bra av databasen. Grundregeln är att alla frågor ska använda index. Detta kan vara lite överkurs, men med vårt tillägg Servebolt Optimizer är det enkelt att sätta rätt tabeller och index, för både WordPress och WooCommerce. Detta tillägg gör de flesta webbutiker 20-30 % snabbare hos oss.

Ladda ner Servebolt Optimizer

Håll nere storleken på .htaccess

.htaccess är en konfigurationsfil för Apache, som bl a används för standardomskrivningar i WordPRess. Denna fil kan användas för olika konfigurationer av undermappar. Vid ett besök läser webbservern varje .htaccess-fil i mappstrukturen, vilket orsakar extra väntetid.

Det finns även många tillägg, särskilt för cache och liknande, som lägger in extra konfigurationer i .htaccess. Detta orsakar ytterligare onödig väntan. Vi rekommenderar att man använder en så enkel/standardiserad version som möjligt av .htaccess. Om man behöver ordna särskilda omskrivningar så är det bäst att göra det via tillägg som Redirection.

Kombinera inte filer i PHP – byt till HTTP/2

Förklaring av HTTP/2 från Cloudflare

Med den nya nätverksstandarden HTTP/2 medföljer en teknik som heter ”multiplexing”. Den gör det möjligt att ta emot fler samtidiga filer via en anslutning till servern. Detta innebär att det inte längre är nödvändigt att kombinera filer (t ex stilmallar eller script).

Alla servrar/webbhotell har inte stöd för HTTP/2 än, men Servebolt har haft HTTP/2 (och dess föregångare SPDY) sedan vi startade 2013.

Optimera bilder och använd rätt storlek

Moderna e-handelssidor har många bilder. WooCommerce använder WordPress inbyggda mediafunktion för sin bildhantering, vilket gör att alla bilder som laddas upp även skapas i flera anpassade storlekar. Även om det är ett rätt gammaldags sätt att hantera bilder så fungerar det bra – om man ser till att använda rätt storlek.

Anpassa bildstorlekar för WooCommerce

I WordPress adminpanel (med WooCommerce 3.3 samt att ditt tema har stöd för det), under Utseende -> Anpassa -> WooCommerce och Product Images kan man anpassa de tre olika bildstorlekar som WooCommerce använder. För äldre versioner av WooCommerce kan man ställa in detta under WooCommerce inställningar -> Produkter -> Visa.

Anpassa bildstorlekarna så att de är exakt vad som krävs för ditt tema. Då slipper besökarnas webbläsare ändra storleken på bilderna när hemsidan laddas in. Ju mer exakta bildstorlekarna är desto bättre.

Optimera alla bilder

Bilder innehåller mycket data inte används när de visas på en hemsida. Om du optimerar dina bilder så kan du minska storleken på din e-handel, vilket gör att den laddar snabbare. Jag brukar rekommendera ett tillägg som heter Resize Image After Upload, som både ändrar storleken på bilder som laddas upp samt komprimerar dem.

Ovanstående tillägg hjälper för nya bilder som laddas upp. Om man vill komprimera bilder som redan är uppladdade kan vi rekommendera ett av följande tillägg:

Notera även att WordPress som standard komprimerar bilder med JPEG-komprimeringsnivå 82 %.

Välj en snabb leverantör

Oavsett hur mycket du gör för att snabba upp WooCommerce så begränsas du i slutändan ändå av din leverantör av server eller webbhotell. Därför måste du välja en så snabb levantör som möjligt.

Våra tjänster är bevisat snabbast och vi arbetar oavbrutet med att optimera vår tekniska plattform, till våra kunders nytta. Vi har byggt vår plattform på rätt sätt från start, med fokus på prestanda i alla led. Det är både enklare att utveckla hemsidor hos oss, samt att hemsidorna blir garanterat snabbare här. Om du har en långsam WooCommerce, kika närmare på vår hantering av WooCommerce.

När du väljer leverantör för WooCommerce, tänk även på att hastigheten på databasen är viktig. E-handelssidor är väldigt beroende av databaser, så en snabb databas ger en snabb webbshop.

Hastigheten hos leverantören får heller inte bero på cachelösningar – det ger i slutändan sämre prestanda, då det är omöjligt att lagra allt i en cache (samt att cachen behöver laddas om). Ett bra exempel på detta är varukorgen. Den kan och får inte cacheas. Är varukorgen långsam kan det ha en stor negativ inverkan på din försäljning.

Använd cache på rätt sätt

Jag har tidigare skrivit om hur cache fungerar i WordPress och cache är viktigt att tänka på när det gäller hastighet i WordPress. Men det gäller att använda det rätt. Du ska inte använda helsidescache (W3 Total Cache, Varnish etc) för hastighetsförbättring i WooCommerce. Det kommer orsaka problem, för eller senare. Det du istället ska göra är att använda objektcache och transienter på rätt sätt.

Objektcache är en mekanism som lagrar resultatet av en databasfråga tillfälligt i minnet (RAM), så att resultat kan återanvändas blixtrande snabbt vid samma sidladdning. Det rekommenderas när samma fråga upprepas, t ex vid visning av produkter. Så för att undvika onödiga/dubbla databasfrågor, använd objektcache.

Transienter är en liknande typ av cache, där resultaten lagras i databasen. Det innebär att resultatet kan sparas mellan olika sidladdningar. En transient kan innehålla vad som helst, men bör användas för komplicerade eller långsamma databasfrågor, eller där resultatet sällan ändras. Tänk på att sätta en lämplig utgångstid, baserat på när datan förväntas ändras.

För att identifiera långsamma databasfrågor och hitta de frågor som lämpar sig för cache med transienter, använd Query Monitor från John Blackburn. Du kan även läsa mer om objektcache och transienter i mitt inlägg om hur cache fungerar i WordPress.

Om du utvecklar eller utökar WooCommerce

Använd actions vid utökning av WooCommerce

WordPress har ett Action API som gör det möjligt att att lägga in funktioner i olika delar av WordPress och WooCommerce. Enkelt förklarat är en action en position i koden. Det gör det enkelt att lägga element på specifika platser i front-end, eller köra funktioner enbart när WooCommerce laddas. Utöver WordPress inbyggda actioner så har även WooCommerce en motsvarande lista.

För att lägga till en funktion till en action, skapa en add_action() på detta sätt:

<?php

add_action('action_tag', 'navnet_til_funksjonen', PRIORITET);

?>

action_tag = Alla inbyggda actions har en tag som anges för att WordPress ska veta vilken action som funktionen ska köras med.
name_of_your_function = Alla funktioner måste ha globalt unika namn. Namnet läggs in i add_action funktionen för att WordPress ska veta vilken funktion som ska läggas till action angivet i action_tag.
PRIORITET = Den prioritet som funktionen har, om flera funktioner är kopplade till samma action. Detta påverkar t ex i vilken ordning kod körs i front-end. 1 körs först, högre nummer kör senare.

Undvik att använda init

init är en action som körs väldigt tidigt i WordPress. Den körs på alla sidor, hela tiden. Funktioner som läggs in under denna action kör då varje gång som WordPress laddas, vilket påverkar hastigheten. Både i front-end och adminpanelen. Man bör därför undvika att koppla funktioner till init, om det inte verkligen behövs.

Så lägger du till egna actions, som andra kan utöka

Du kan enkelt skapa egna actions, t ex för att köra specifika funktioner på produktsidor.

do_action('din_egen_action_tag');

När du har skapat din egen action tag, antingen i en mallfil eller någon annanstans i koden, så kan du använda ovanstående exempel för att lägga till en funktion till din egendefinierade action.

Använd inte Visual Composer eller andra sidbyggare

Visual Composer och andra sidbyggare inkluderas ofta i teman som man köper. Det beror på att sidbyggarna har många funktioner, som gör dessa teman enklare att konfigurera och sälja. Men som vi nämnt tidigare, mer kod (eller fler funktioner) gör det alltid mer långsamt.

För att få full flexibilitet i sidbyggarna krävs en hel del variabler i databasen, samt en massa PHP. Hur mycket padding ska ett element ha, vilken färg ska det ha, ska det vara en ram runt innehållet, ska en bild vara rund eller fyrkanting osv. Allt detta kräver att PHP-kod körs samt att databasen tillfrågas, vilket ger en långsam sida. Därför bör du undvika sidbyggare, särskilt om du bygger WooCommerce från grunden och upp.

Det finns ingen anledning att köra en sidbyggare som Visual Composer om du kan skriva PHP-kod.

Du kan få flexibilitet även utan att använda sidbyggare

Jag är ingen motståndare till flexibilitet, men jag är en motståndare till onödig flexibilitet, som inte används, samt har en negativ inverkan på prestanda. Därför rekommenderar jag ACF Flexible Content Fields för att bygga en egen sidbyggare. Detta ger dig möjlighet att definiera de fält som du verkligen behöver till din sida. Det kräver grundläggande kunskap om PHP, HTML och CSS, men bygger du en webbshop från grunden är ACF oslagbart.

När du skapar en sidbyggare med ACF Flexible Content Fields använder du mallfiler med PHP. Tänk att varje mallfil är en del av din sida, som du kan upprepa hur många gånger som helst. Och du bestämmer själv ordningen på dessa mallar när du skapar en sida. Det är så vår hemsida är uppbyggd (ja, denna här).

Men Gutenberg då?

Med Gutenberg bygger man sidor på liknande sätt som ACF Flexible Content Fields. Du staplar helt enkelt block på över och under varandra. Gutenberg är framtidens redigerare i WordPRess och det är värt att redan nu börja testa och använda den.

Läs mer om Gutenberg här.

En kort sammanfattning

  1. Välj Servebolt som leverantör
  2. Kör så lite kod som möjligt
  3. Ta bort tillägg du inte behöver och använd tillägg som gör en sak (istället för många saker)
  4. Använd cache på rätt sätt
  5. Fixa alla buggar, håll felloggen ren
  6. Validera de viktigaste sidorna med W3 Validator
  7. Använd HTTP/2
  8. Utöka WooCommerce med actions där du kontrollerar koden och kör den rätt
  9. Använd inte Visual Composer

Var detta självklart och enkelt för dig? I sådana fall får du gärna läsa mer om våra lediga tjänster, för dig vill vi gärna höra mer från!