Vi ansetter!

Hvordan gjør du WooCommerce rask?


Artikkel av Thomas Audunhus. Published on mars 25, 2018

Fler og fler sliter med hastigheten i WooCommerce, og det er ikke så rart ettersom antallet butikker bygget på WooCommerce øker dag for dag. Og samtidig ser jeg fler og fler dårlige forslag på hvordan man får opp hastigheten i WooCommerce. I Servebolt jobber vi hver dag med hastighet i WordPress og WooCommerce, uten snarveier. Her er mine beste tips for å øke hastigheten i WooCommerce.

Det grunnleggende for en rask WooCommerce

Det er noen grunnleggende prinsipper du må følge for å sikre at du har en rask WooCommerce, og når man jobber med WooCommerce er det viktig å huske én ting – WooCommerce er raskt, det er alt du gjør med WooCommerce som kan gjøre det tregt.

Kjør så lite kode som mulig

All kode du implementerer har på et eller annet tidspunkt en påvirkning på hvor raskt en side laster. Å kjøre mindre kode er alltid en god idé for å få opp hastigheten i WooCommerce. Skriver du koden selv burde du lage gode regler som sjekker om en spesifikk blokk med kode trenger å kjøres eller ikke. Eksempelvis er det viktig at ikke kode som kun skal kjøres på produktsider ikke kjøres på kategorisider.

Plugins – Avinstaller og slett alle plugins du ikke trenger

Et stort problem i WooCommerce, og WordPress forøvrig, er bruken av plugins. Plugins er en fin måte å utvide WooCommerce med avansert funksjonalitet, men mange plugins inneholder unødvendig kode. Har du hatt samme butikk i mange år er sjansen også stor for at du har plugins som ikke lenger vedlikeholdes installert.

Vår liste med ikke-anbefalte plugins

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

Disse har etter vår erfaring en negativ påvirkning på enten hastighet eller sikkerhet, og er ikke anbefalt. Selv om noen av de er laget for å forbedre sikkerhet eller hastighet har de altså motsatt effekt. Disse har såpass negativ effekt at vi vurderer å forby disse fra å brukes på Servebolt.

Plugins du burde være obs på

  • Visual Composer
  • Beaver Builder

Bugs – Fiks alle feil du vet om

Alle webservere har en error-log, og den er et av dine viktigste verktøy for å få en velfungerende og rask WooCommerce. Alle PHP-feil blir logget til error-loggen, og hvis det er meldinger om feil i loggen, så bør du fikse de. Det er to årsaker til det; for det første er det umulig å holde oversikt og teste alle sider i en WooCommerce. Det er ofte tusenvis av enkeltsider, og sære situasjoner kan lage sære feil.

Den andre grunnen har med ytelse å gjøre. Det er lett for utviklere å tenke at «det er jo bare en Warning» eller «den lager ikke noen synlig feil». Men alle feil tar tid. Og hvor mye tid de tar, blir alltid undervudert. Jeg hjalp nylig til med å fikse bugs på en side som var oppgradert til WooCommerce 3, uten at de hadde sjekket error-loggen. Etter noen timers intensiv bug-fixing, så sluttet errorloggen å skrive nye linjer – og hastigheten på siden hadde økt med 60% – ja du leste riktig – seksti prosent!

Det er ikke bare PHP-bugs som sinker siden din. Du bør også fikse alle feil i HTML, CSS og Javascriptene som er i bruk – for alle feil gjør at ting går mye saktere enn det trenger å gjøre.

Valider HTML på de viktigste sidene med W3 Validator

For å sikre en rask og god rendering er det viktig å bruke korrekt struktur og format på HTML, og for å sjekke dette kan du bruke W3C Validator. Ved å bruke korrekt formatert HTML slipper browseren å jobbe like mye for å avgjøre hvordan en side skal se ut, og derfor blir den raskere.

Database-tabelltyper og Indexer

For at WooCommerce skal fungere bra er det viktig at man bruker moderne tabelltyper til lagring av data, som InnoDB. I tillegg er det mange utvidelser i WooCommerce som spør etter data på måter som ikke kan håndteres bra av databasen. Vi har laget vår plugin Servebolt Optimizer som fikser tabelltyper og legger til noen indexer som burde vært i WordPress og WooCommerce som standard. Forbedringene vår plugin gjør gir deg i snitt 20-30% raskere nettbutikk.

Last ned Servebolt Optimizer

Hold .htaccess liten

Htaccess er en konfigurasjonsfil for Apache, hvor du kan sette opp videresendinger(redirects), og andre regler for Apache. Det kan ligge en htaccess i hver mappe, og serveren vil lese og kjøre disse filene hver gang. Det vil si at alt du legger i htaccess potensielt kan gjøre WooCommerce tregere. Vi anbefaler å holde htaccess ren og til WordPress standard, og bruke plugins som Redirection for å håndtere videresendinger.

Ikke kombiner filer i PHP – bytt til HTTP/2

Forklaring av HTTP/2 av Cloudflare

Med HTTP/2 kommer også en teknologi kalt multiplexing. Det betyr at man kan motta flere filer gjennom samme tilkobling til serveren via HTTP når en side lastes. Det betyr at kombinering av filer, som tidligere kunne bidra til raskere rendering, ikke lenger er nødvendig i samme grad. Dersom du utvikler på egenhånd må du gjerne kombinere filer ved å bruke en compiler som feks grunt eller gulp, men det er ikke anbefalt å kombinere filer i PHP. Det betyr altså at du ikke burde kombinere filer ved bruk av plugins som feks Autoptimize eller liknende.

Optimaliser bildene og bruk riktig størrelse

Dagens nettbutikker har mange bilder. WooCommerce bruker WordPress sin mediafunksjon for bildehåndtering, som betyr at alle bilder som lastes opp blir lagret i en hel rekke ulike bildestørrelser. Selv om dette er en noe gammeldags måte å gjøre skalering av bilder på så fungerer den overraskende greit. Men, du må huske å bruke riktig bildestørrelse.

Juster WooCommerce bildestørrelser

Under WooCommerce innstillinger -> Produkter -> Vis finner du WooCommerce sine tre standard bildestørrelser. Juster disse til å være eksakt den størrelsen du bruker i butikken. Da slipper browseren å endre størrelsen på bildet før det vises, samt at du vil kunne spare en del tid ved å ha et så lite bilde som mulig.

Optimaliser alle bilder

Bilder inneholder mye data som ved visning på web ikke benyttes. Så ved å optimalisere bildene kan du med andre ord slanke sidestørrelsene i nettbutikken din, og derfor også få en raskere side. På Servebolt bruker vi en plugin som heter Resize Image After Upload, som endrer størrelse på den fulle versjonen av et bilde så du ikke lagrer størrel bilder enn du trenger. I tillegg kan den komprimere bildene. Denne utvidelsen gjør jobben når du laster opp et bilde, og vil derfor ikke fungere på eksisterende bilder i bildebanken din. For å optimalisere eksisterende bilder i bildebanken kan du bruke en av disse:

 

Velg rask hosting

Uansett hvor mye og hardt du jobber med å gjøre WooCommerce rask vil du alltid begrenses av hastigheten på hostingen. Derfor burde du velge en så rask hosting som mulig. Vår hosting er bevist raskest, og våre kontinuerlige hastighetsoptimaliseringer sikrer at du til en hver tid har rask hosting. Vi har verdens raskeste hosting gjennom å løse problemene der de er, fremfor å legge til mer teknologi. Dette gjør det enklere å utvikle løsninger på Servebolt hosting, men også vesentlig raskere enn alle andre alternativer. Sliter du med treg WooCommerce burde du ta en titt på vår hosting for WooCommerce.

Når du skal velge hosting er det spesielt hastighet på databasen som er viktig. En rask WooCommerce krever en rask database. I tillegg er det viktig å velge en hosting som ikke avhenger av caching for å være rask. Hosting som avhenger av caching vil på et eller annet tidspunkt oppleves som tregt for noen, fordi du vil ikke klare å cache alt. Eksempel er handlekurven. Den kan ikke og skal ikke caches, og er en ekstremt viktig del av butikken din. En treg handlekurv og kasse kan ha stor betydning for konverteringsraten din.

Bruk Cache riktig

Jeg har tidligere skrevet om hvordan caching fungerer i WordPress, og caching er en viktig del når man skal tenke hastighet i WordPress. Men det er viktig å bruke det riktig. Du skal ikke bruke full page caching (W3 Total Cache, Varnish etc) som en hastighetsforbedring i WooCommerce. Det vil gi deg hodebry enten nå eller senere. Det du derimot skal gjøre er å bruke object cache og transients der det hører hjemme.

Object Cache er en mekanisme som lagrer resultatet av en spørring til databasen midlertidig i minnet(RAM) slik at du lynraskt kan bruke resultatet på nytt på samme sidevisning. Dette burde du bruke når du benytter samme spørring flere ganger på siden. Eksempelvis kan det være ved visning av produkter, så henter du all produktinformasjon før du deretter begynner å bruke informasjonen. For å unngå unødvendige og doble spørringer til databasen kan du derfor bruke object cache.

Transients er en liknende type cache, men hvor man lagrer data i databasen. Du kan fylle en transient med hva som helst, men skal du bruke transients riktig så burde transients brukes til å lagre resultatet av spørringer som er trege, store eller krever mye datakraft, og som sjeldent endrer seg. Husk å sette en fornuftig utløpstid basert på hvor ofte dataene er forventet å endre seg. For å avgjøre hvilke spørringer du burde kjøre inn i en transient kan du bruke Query Monitor fra John Blackbourn, og se etter trege databasekall.

Du kan lese mer om hvordan object cache og transients fungerer i min artikkel om Caching i WordPress.

Om du bygger eller utvider WooCommerce

Bruk actions for å utvide WooCommerce

WordPress har et Action API som gjør det mulig å legge funksjoner til ulike deler av WordPress og WooCommerce. Enkelt forklart er en action en posisjon i koden. Dette gjør det enkelt å legge til elementer som skal vises på gitte steder i frontend, eller funksjoner som skal kjøres når WordPress eller WooCommerce laster etc. I tillegg til WordPress sine innebygde actions har også WooCommerce en helt rekke innebydge actions, og gjør det derfor enkelt å utvide WooCommerce.

For å legge din funksjon til en action må du lage en add_action(), og den bygges opp slik:

<?php

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

?>

 

action_tag = Alle innebygde actions har en tag, og denne må du legge inn for at WordPress skal vite hvilken action funksjonen skal kjøres med.
navnet_til_funksjonen = Alle funksjoner må ha et unikt navn. Dette unike navnet legger du inn i add_action funksjonen for at WordPress skal vite hvilken funksjon som skal legges til action angitt i action_tag.
PRIORITET = Prioriteten funksjonen har dersom det er flere funksjoner som er lagt til samme action. Eksempelvis vil derre påvirke rekkefølgen en funksjon vises i frontend. 1 er høyeste prioritet, og vil kjøres først.

Unngå å bruke init

init er en action som kjøres etter det meste av WordPress er lastet, hver gang. Funksjoner du legger til denne action vil kjøres hver gang WordPress laster, og vil derfor påvirke hastigheten på hver sidevisning. Både i front og backend. Derfor burde du unngå å bruke init med mindre du må, og heller bruke mer actions som gir mer kontroll og sikrer at din funksjon kun kjøres når den trengs.

Slik legger du til egne actions

I din egen kode kan du legge til egne actions, slik at du enkelt kan legge til funksjoner til for eksempel produktsidene.

do_action('din_egne_action_tag');

Når du har laget en action tag, enten i template filer eller andre steder i koden kan du bruke eksempelet over for å legge til en funksjon til din egendefinert action.

Ikke bruk Visual Composer eller andre sidebyggere

Visual Composer og andre sidebyggere er ofte inkludert i themes du kjøper. Det er fordi sidebyggere gjerne inneholder masse funksjoner, og gjør temaene enklere å selge og enklere å sette opp. Som tidligere nevnt betyr mer kode(les flere funksjoner) i de aller fleste tilfeller også en tregere side. For å ha full fleksibilitet i sidebyggerne trengs det en hel del variabler i databasen og en hel masse PHP. Hvor mye padding skal et element ha, hvilken farge skal det ha, skal det være en border på innholdet, skal et bilde være rundt eller firkantet osv. Alt dette betyr PHP som skal kjøres og oppslag til databasen når en side skal lastes, og vil resultere i en treg side. Derfor burde du unngå å bruke sidebyggere, spesielt om du bygger WooCommerce butikker fra bunnen av.

Om du kan PHP er det ingen grunn til å bruke sidebyggere som Visual Composer.

Du kan ha fleksibilitet uten å bruke sidebyggere som Visual Composer

Jeg er ikke motstander av fleksibilitet, men jeg er motstander av fleksibilitet som ikke brukes eller som kan løses bedre på andre måter. Derfor anbefaler vi i Servebolt å bruke ACF Flexible Content Fields til å lage din egen sidebygger. Dette gjør at du selv kan definere hvilke felter som skal kunne settes når en side bygges, og du kan lage den fleksibiliteten du trenger selv. Dette krever dog grunnleggende kunnskap om PHP, HTML og CSS. Men bygger du en butikk fra bunnen av er det uproblematisk.

Når du lager en sidebygger med ACF Flexible Content Fields er det PHP template filer som brukes. Du kan tenke på hver template fil som en rad på siden din, som kan gjentas så mange ganger du selv vil. Og du kan bestemme rekkefølgen disse template filene skal brukes når du lager en ny side. Vi bruker selv denne metoden på vår nettside.

Men hva med Gutenberg?

Med Gutenberg vil du kunne bygge sider, artikler og annet innhold på samme måte som med ACF Flex Fields. Denne fungerer litt på samme måte som Flex Fields i form at at det er blokker du setter under hverandre. Gutenberg er fremtidens innholdsredigerer i WordPress, og det er verdt å begynne å bruke den allerede nå.

Les mer om Gutenberg her.

Kort oppsummert

  1. Bytt til Servebolt hosting
  2. Kjør så lite kode som mulig
  3. Slett plugins du ikke treger, og ikke bruk en stor plugin for å løse en liten oppgave
  4. Bruk caching riktig
  5. Fiks alle kjente bugs, og hold errorloggen ren
  6. Valider de viktigste sidene med W3 Validator
  7. Bytt til HTTP/2
  8. Utvid WooCommerce ved bruk av actions for å ha best mulig kontroll og sikre at koden kjøres på riktig sted
  9. Ikke bruk Visual Composer

Virket alt dette som plankekjøring? Da burde du ta en titt på våre ledige stillinger! Da vil vi mest sannsynlig veldig gjerne prate med deg.

 

 

More about Thomas Audunhus

Thomas leder satsningen i vårt hjemland, Norge, og er ekspert på WordPress og WooCommerce. Thomas har bygget noen av de raskeste WordPress og WooCommerce sidene i Norge, og vet derfor nøyaktig hvordan man skal få WordPress og WooCommerce så rask som mulig. I tillegg til å arbeide hos oss er Thomas sentral i det norske WordPress og WooCommerce miljøet. Han er en av organisatorene av Oslo WordPress meetup, og ikke minst lead organizer av WordCamp Oslo 2018.