Slik får du bedre ytelse i WordPress

Hvordan kan du øke WordPress ytelsen? I vårt forrige innlegg skrev vi generelt om trege nettsider – noe som passer for deg som ønsker å forstå litt, uten å gå for mye i det tekniske. Nå derimot er det tid for å bli litt mer teknisk.

Her skal vi skrive om vårt oppsett, samt noen alternative oppsett for å få maks ytelse og raske nettsider med WordPress. Her bør du være over snittet opptatt av WordPress og det tekniske.

Serveren er fundamentalt viktig

En god server er en tvingende nødvendighet om du skal ha nettsider som ikke har en flaskehals allerede på det helt grunnleggende.

Plasseringen av serveren er viktig. Derfor er rimelige amerikanske webhotell fort feil, om kundene dine er i Norge.

Servere som er plassert i Norge eller på det europeiske kontinentet er det beste. Om serveren står i Frankfurt, Stockholm eller Amsterdam eller Bergen har egentlig lite å si – da er ikke avstand og distanse noe problem.

CDN – Content Delivery Network – Skal du ha kunder globalt, så er en CDN løsning nødvendig. Det er ikke nødvendig for god ytelse i Norge mot norske kunder.

Du kan gjerne bruke vårt webmaster betjente webhotell, ferdig oppsatt med WordPress og pro-plugins. Eller om du ønsker å drifte server selv, så benytter vi Digital Ocean via Cloudways – hvor vi også kan velge mellom Vultr, Linode, AWS og Google Cloud Plattform. Det gir oss fleksibilitet til å tilpasse og tweake til optimale resultater. Servere er lokalisert på forskjellige steder, vi er koblet opp på et serversenter i Frankfurt.

Jeg sverger til CloudWays, ProISP (lightspeed) eller for spesielle behov Servebolt.no

DOM-størrelse

Mange selvlærte har ikke fanget opp viktigheten av å holde DOM-størrelsen lav. Når nettsiden lastes inn så bygges en Dokument Objekt Modell – en slags trestruktur av alle HTML elementene i bruk på nettsiden. Lego og tegningen av legosettet er en god sammenligning. Antall legobiter i esken er antall DOM elementer for en nettside.

Bruker du Elementor kan du aktivere flexbox. Det skaper færre DOM-elementer. Det er også en egen innstilling for forbedret DOM ytelse.

OBS! Disse innstillingene i Elementor er eksperimentelle, og her er det en del andre ting du kan forbedre. Men vær klar over risikoen – eksperimentelle funksjoner endrer seg, og det bør ikke utføres på en live kundeside uten at risikoen er forklart. Funksjonene kan endre seg og kreve oppdatering av nettsidene. Det er ofte Beta-funksjoner.

Poenget er at man kan holde DOM-størrelsen lav, helst under 900 – 1500.

Bruk Lighthouse og sjekk.

Det betyr kort og greit at på et eller annet tidspunkt er siden din stor nok, og må evt deles opp i flere deler.

Velg plugins med omhu

Selv med erfarne utviklere ser vi at mange installerer plugins hvor funksjonen allerede finnes i en annen.

Bruk kun det absolutt nødvendige, også i vurdering av gratisversjoner vs pro. Sjekk alltid innstillinger om du kan slå av noe du ikke bruker. For eksempel er det en del add-ons til Elementor som laster inn en bråte med CSS og JS – men du kan i mange velge å aktivere kun de elementene som er i bruk.

Det er også en del plugins som skaper alt for stor DOM-størrelse i sine elementer.

Gode tips når det gjelder Cache

Hvilken Cache som anbefales er avhengig av serveren også. Der er det noen som er litt hånd i hanske.

Lightspeed: Om du bruker ProISP sin lighthspeed-server, så benytter du også Lightspeed cache plugin.

Breeze Cache plugin på Cloudways. For å oppnå 100 % på denne siden testet vi flere plugins. Blant annet W3 Total Cache som vi kommer tilbake til. Etter to dager med testing og tweaking ble konklusjonen at Breeze, på tross av færre tilpasningsmuligheter yter godt nok med bedre brukervennlighet. Breeze er utviklet av Cloudways.

W3 Total Cache plugin. For servere uten egenutviklet cacheplugin, og for mer generisk bruk er W3 Total Cache plugin å anbefale. Denne kan for mange oppleves som kompleks, da det er mange innstillinger å ta høyde for, som krever en viss teknisk forståelse. Vi brukte W3 Total Cache helt til topps, men timevis med testing og tilpasninger gjør at Breeze ble riktig valg for denne siden.

WP Rocket – En mer brukervennlig Cacheplugin, som du ikke får i gratisversjon. Denne har også målgruppen sin blant de som synes slike innstillinger er litt herk.

Server-side Cache. Flere serverløsninger har også mulighet for å sette opp cacheløsning på serveren. Dette kan fungere veldig bra, men det kan også være en kilde til forsinkelse, siden serveren hele tiden vil sjekke om det finnes en mellomlagret versjon. Vi anbefaler å teste med og uten. Og gjerne slå det på til slutt, når resten er optimalisert.

Slik optimaliserer du med Cache og Asset CleanUp.

Cache er det siste du skal tenke på. Rekkefølgen du gjør ting i, er også viktig. For eksempel er det greit å optimalisere både CSS og Javascript i forkant av aktivering av cache. Start alltid med Asset CleanUp før Cache – Mer om Asset CleanUp og Perfmatters nedenfor.

Gzip – De fleste webhotell kan aktivere Gzip på serveren. Det er best.

Minify & Combine på CSS og JS

Bruk Minify (komprimer) før du kjører Combine (slå sammen). Minify fjerner unødig kode og mellomrom og gjør filstørrelsen mindre.

Combine er ikke alltid lurt. WordPress og en rekke plugins for WP leverer egne CSS og JS filer, i sum får du fort 15-20 forskjellige filer som lastes inn. I stedet for at henvendelsen går frem og tilbake en rekke ganger, kan man altså kombinere disse filene til 1 fil, og hente den en gang. Filen blir større, antall henvendelser til serveren blir færre.

Ulempen er at en del filer har lurt av å bli utsatt (defer) til nettsiden har fått lastet seg inn. Mens noen bør lastes inn tidlig. Så om du kombinerer, vil du raskt oppleve problemer som skaper forsinkelse.

Ta backup, test og vurder. Bruk alltid backup. Om du slår dette på og av, så kan du oppleve at ikke alt er helt som det skal etterpå. Det kan være at en kombinert fil «henger seg opp» i cacheminnet eller andre uforutsette problemer. Ta derfor backup og kjør tilbake til utgangspunktet i stedet.

Asset CleanUp & Perfmatters

Dette er to plugin som gjør det samme. AssetCleanUp er mer kompleks og Perfmatters har bedre brukergrensesnitt (UI) – Ut over det gjør de akkurat det samme. Hvilken du velger henger litt sammen med hva din cacheplugin allerede gjør. Bruker du for eksempel WP Rocket, så er det ikke sikkert du trenger AssetCleanUp Pro for inline JS og render-blocking CSS.

Vi bruker Asset CleanUp på denne siden. For mange kan det bare bli et valg på hvilken de liker best.

Start med Asset CleanUp (FØR du begynner med Cache) og fjern ubrukt CSS filer og JS – det kan du gjøre sitewide eller per side. Med Pro-versjonen vil du også få mer kontroll over utsatt levering. Det er ikke sikkert det er nødvendig. Vi har ikke gått for Pro på denne siden – selv om det er enkelte punkt hvor det kunne utgjort en forskjell – men det er minimalt, og i akkurat dette tilfellet ikke verd prisen.

Gå over innstillingene og les hva de gjør. Du kan blant annet fjerne XML-RPC protokollen og mye mer – om du ikke bruker det.

VIKTIG: Backup alltid og test løpende. Kjør inn gammel backup fremfor å stille frem og tilbake.

Starter du med Cache og kjører kombiner, så tar du med filer du skulle ha fjernet først.

PS! I Asset CleanUp er det en innstilling som gjør at du kan fjerne kjernefiler fra WordPress. Bruker du en sidebygger som f.eks Elementor så kan du slå av Gutenberg Blocks – som default laster inn en CSS fil på alt, selv om du ikke bruker Gutenberg.

Sider som ikke skal bruke cache eller minify/combine.

Det er ikke alle sider som skal mellomlagres. Om du har nettbutikk så skal følgende sider ikke caches:

Handlevogn
Betaling (Checkout)
Min konto/kontosider
Produkter (Endrer du pris, så er det greit at ny pris vises)

I tillegg bør du hindre Sitemap-filer fra mellomlagring og minify. Vi anbefaler RankMath for SEO, og her er det en god guide til akkurat det.

Om du mellomlagrer sitemap, vil du oppleve at Google ikke oppdager nye sider for indeksering. Her kan du få den beste SEO hjelp du kan få, om trenger det.

Lazy Load av elementer og smarte innlastingstriks

Å laste inn bilder som er utenfor den første skjermen, først når noen scroller til dem er en fin måte å hindre at alt må lastes inn før noe vises.

Har du video? Bruk et bilde med lenke til en videoside eller youtube. Evt lag en 2-3 sekunders loop som video for siden med en egen videoside for å laste inn videoen uforstyrret av andre elementer. Da trenger du ikke laste inn så mye data på siden, med mer ytelse som resultat.

Du kan også velge å laste fontene lokalt. Eller et annet triks som de fleste designere misliker. Bruk systemfonter som finnes i de fleste operativsystemer. Da lastes fonten fra leserens nettleser.

De mest populære google-fontene, finnes ofte allerede på en lokal maskin nær deg. Et lurt triks kan derfor være å bruke en av dem. Da trenger du strengt tatt ikke å laste den lokalt. For om du har vært på en nettside som allerede har brukt en font, så lastes ikke den fra serveren neste gang, selv på en ny nettside.

Bruker du mer unike fonter så kan du undersøke både lokal lasting og preloading som gode muligheter for å hindre Cumulative Layout Shift (CLS) når fontene bytter. (om du bruker font swap)

Font swap er en metode hvor du bruker systemfonter frem til fonten du ønsker er lastet inn, så byttes fontene etterpå. Du kan ofte se at det er et lite hopp når det skjer. Du får mer fart av det, men kan få dårligere score på CLS.

Oppdater bilder til WebP

Bildekomprimering er viktig. Skaler dem ned til riktig størrelse og komprimer. Om du ikke har noen verktøy til dette, så kan du bruke dette online bilderedigeringsprogrammet gratis.

Dette bør være et kjent punkt for deg allerede, så jeg går ikke mer i dybden her.

Alt er en avveiing - Ytelse er ikke alt

Godt nok – er bra nok. Besettelse over ytelse er sjeldent lønnsomt og kost/nytte går fort i minus for de siste to prosentene.

Av og til trenger du en større nettside, av og til er det årsaker til at ting må laste sakte (store filer av video eller høyoppløselige bilder) – Det viktigste er at du har tatt et aktivt valg på det.

Opplevd ytelse er viktigere enn målevertkøyene. Føles siden rask, er den rask.

Om du skal ha fokus på noe, som du bør få inn i det grønne, så er det primært Core Web Vitals, samt luke ut direkte feilmeldinger.

Ut over det, er en score på 90+ ofte godt nok. For de aller fleste norske nettsider som har alt fra noen hundre til noen tusen besøkende, så har ikke et millisekund her og der så mye å si. Den slags ytelse er først viktig når vi snakker millioner av besøk og gigantiske nettsider, som det er få av her i landet.

Trenger du WordPress hjelp til bedre ytelse, så tar du kontakt. Vi kan alltid ta en gratis evaluering og vurdere hva som må til – før du bestemmer deg.