WordPress-ytelse
Vi gjør WordPress-nettsider raskere og viser hva hvert tiltak endret.
kunde.noMobil- LCP
- 0,8 s
- fra 3,2 s
- TTFB
- 0,18 s
- fra 1,2 s
- Sidevekt
- 1,1 MB
- fra 4,1 MB
- Redis foran databasen−640 ms svartid
- Plugins fra 19 til 4−410 KB JavaScript
- Bilder i WebP og AVIF−2,6 MB
- Ferdige sider i sidebuffer−230 ms svartid
Lastetiden påvirkerbesøkende og plassering i Google
Google bruker Core Web Vitals, et sett måltall for hastighet og stabilitet, når sider rangeres. En treg side kan derfor miste plasseringer. Lastetiden påvirker også de besøkende: ifølge Googles egne tall øker sjansen for at noen forlater siden med 32 % når lastetiden går fra ett til tre sekunder.
kunde.noHenter målingerIkke bestått- LCPHovedinnholdet vises3,2 sGrense 2,5 s22 %20 %58 %
- INPSvar på klikk280 msGrense 200 ms41 %45 %14 %
- CLSInnhold som flytter seg0,15Grense 0,148 %39 %13 %
En typisk WordPress-side på delt webhotell bruker 2–5 sekunder på å laste. Pluginene sender JavaScript til besøkende som aldri bruker det, og temaet gjør oppslag i databasen som ikke trengs. I tillegg starter serveren hele WordPress på nytt for hver sidevisning.
Hvilke av disse som betyr mest, varierer fra side til side, og det må måles. Ofte gir et nytt serveroppsett størst gevinst, sammen med opprydding i pluginene.
- Svartid etter ombyggingen i et av kundeprosjektene våre, ned fra 4,2 s
- 180ms
- Hastighetsscore i Googles Lighthouse på sidene vi drifter
- 98/100
- Flere forlater siden når lastetiden går fra 1 til 3 sekunder
- 32%
- Tid siden ikke svarer på klikk, etter forbedringene
- 0ms
Vanlige årsaker til at WordPress-siden er treg
WordPress i seg selv er sjelden problemet. Oftere ligger årsaken i hostingen og i plugins som har samlet seg opp over flere år.
For mange plugins
Hver plugin legger til egen JavaScript, CSS og flere databasespørringer. 20 plugins kan fort gi 400 KB ekstra skript og over 50 oppslag i databasen, og serveren må gjøre den jobben på nytt for hver sidevisning.
En database som gjør samme jobb om igjen
Måten WordPress lagrer data på, er fleksibel, men blir treg når datamengden vokser. Uten mellomlagring gjør databasen nøyaktig de samme oppslagene for hver besøkende.
Andre nettsteder på samme webhotell
På et delt webhotell deler du server med hundrevis av andre nettsteder. Får en av dem mye trafikk, blir din side tregere. Du bestemmer heller ikke selv hvilken PHP-versjon siden kjører på.
Mellomlagring i en plugin
En plugin for mellomlagring demper symptomene, men årsaken blir liggende. Mellomlagring virker bedre når den er en del av serveroppsettet, med Redis foran databasen og ferdige sider som ligger klare.
En ytelsesgjennomgang viser hva som gjør siden treg og hva hvert tiltak vil gi.
En ytelsesanalyse viserhvor tiden går
Før vi endrer noe, måler vi hvor tiden går på en vanlig sidevisning. Vi ser hvor lenge serveren bruker på å bygge siden, hvor mange databasespørringer hver plugin står for, og hvor mye JavaScript og CSS som sendes til nettleseren.
kunde.no/tjenester/Måler1 840 ms- Slider-pluginLaster på alle sider
- Databasen · 112 spørringer48 like spørringer
- WooCommerce
- WordPress-kjernen
- Tema
Som regel står noen få ting for det meste av tiden: en plugin som gjør de samme oppslagene for hver besøkende, en slider som laster et stort skript på alle sider, eller bilder som er mange ganger større enn de vises. Der begynner vi.
Etter hvert tiltak måler vi på nytt med de samme verktøyene, så du ser hva hver endring ga.
Dette gjør vi for å få opp farten
Mellomlagring med Redis
Svar fra databasen ligger klare i minnet. Handlekurver og midlertidige data hentes også fra Redis, så databasen får mye mindre å gjøre.
Bilder i riktig format
Bildene lages automatisk i formatene WebP og AVIF, som gir mindre filer, og i riktig størrelse for hver skjerm. Da slipper mobilbrukere å laste ned en JPEG på 4 MB over mobilnettet.
Det viktigste lastes først
Utseendet til den delen av siden som vises først, legger vi rett inn i siden. Resten lastes etterpå, så innholdet kommer raskere fram.
Bilder lastes når de trengs
Bilder, innebygde videoer og andre tunge elementer lastes først når de nærmer seg skjermen. Den første sidelastingen blir lettere, og siden blir raskere klar til bruk.
Filer fra nærmeste server
Bilder, skript og stilark sendes fra serveren som ligger nærmest den besøkende. Når vi publiserer endringer, oppdateres bare filene som er endret.
Databaseoptimalisering
Først finner vi de trege oppslagene i databasen. Så legger vi til indekser som mangler og rydder bort gamle midlertidige data, og vi måler effekten av hvert tiltak før vi går videre.
Samme nettside, to målinger
Begge målingene er gjort med samme innhold og samme verktøy. Mellom dem ble antallet plugins redusert fra 19 til 4, og siden ble flyttet til FrankenPHP og Redis. Google har målt at lengre lastetid gir færre konverteringer [1].
Core Web Vitals side om side
| Vanlig WordPress | Bygget av PXLGoogles terskel | |
|---|---|---|
| LCP | 3,2 s (dårlig) | 0,8 s (bra) |
| INP | 280 ms (trenger forbedring) | 12 ms (bra) |
| CLS | 0,15 (trenger forbedring) | 0,01 (bra) |
| TTFB | 1,2 s | 0,18 s |
| FCP | 2,8 s | 0,6 s |
| Total Blocking Time | 450 ms | 0 ms |
| Lighthouse-score | 45–65 | 95–100 |
Slik måler vi WordPress-ytelse
Før vi begynner, setter vi konkrete måltall. Etterpå dokumenterer vi hva hvert tiltak endret i de samme tallene.
Automatisk måling før publisering
Lighthouse er Googles verktøy for å måle ytelse. Vi kjører det automatisk hver gang ny kode skal publiseres. Faller scoren under grensen vi har satt, stopper publiseringen før endringen når nettsiden.
Målinger fra ekte besøk
Målinger i testmiljø viser ikke hvordan siden oppleves på ekte mobiler og nettverk. Derfor henter vi Core Web Vitals fra virkelige besøk og ser hvor mobil, desktop og besøkende fra utlandet skiller seg fra hverandre.
Faste målinger døgnet rundt
Vi kjører faste ytelsestester fra flere steder hele døgnet. Trendene viser om siden gradvis blir tregere, lenge før noen merker det i nettleseren.
Analyse av hver sidevisning
Vi ser på databaseoppslag og minnebruk for hver sidevisning. Da kan vi peke på nøyaktig hvilken fil og linje som gjør siden treg.
Tegn på at det er verdt å se på ytelsen
Hvert punkt kan ha flere forklaringer, men sammen tyder de på at siden er for treg:
Kjenner du igjen tre eller flere av punktene, bør du se på serveroppsettet før du installerer enda en plugin.
- Lastetiden er over 2 sekunder, selv med en plugin for mellomlagring
- Googles Lighthouse gir siden under 70 poeng på hastighet
- Google Search Console melder om problemer med Core Web Vitals
- Besøkende gir opp før siden har vist innhold
- Siden er merkbart tregere på mobil enn på PC
- Siden blir tregere under kampanjer og trafikktopper
Send oss adressen til nettsiden, så gir vi deg en første vurdering av hva som gjør den treg.
Spørsmål vi ofte får
Hva er Core Web Vitals?
Core Web Vitals er tre måltall Google bruker for å måle hvordan en side oppleves for besøkende. LCP (Largest Contentful Paint) måler hvor raskt hovedinnholdet vises. INP (Interaction to Next Paint) måler hvor raskt siden reagerer når noen klikker eller skriver. CLS (Cumulative Layout Shift) måler om innholdet flytter seg mens siden laster. Google bruker alle tre i rangeringen.
Hjelper det med en plugin for mellomlagring?
Den hjelper litt, særlig for besøkende som kommer tilbake til en side de har lastet før. Men en plugin oppå WordPress når ikke ned til det som gjør siden treg. Det er som regel for mange plugins, en database som gjør samme jobb om igjen, en gammel PHP-versjon og et webhotell du deler med hundrevis av andre. Pluginen demper symptomene en stund, men årsaken er der fortsatt.
Hva gjør Redis for WordPress?
Redis er en database som holder data i minnet. WordPress spør databasen om de samme tingene mange ganger på hver sidevisning, for eksempel innstillinger, menyer og produktdata. Med Redis som mellomlager hentes svarene fra minnet i stedet for fra MySQL, og databasen får mye mindre å gjøre. Det merkes mest på sider som må bygges for hver besøkende, som handlekurven og sider for innloggede brukere.
Hvor mye raskere kan WordPress bli?
For sider som kommer fra delt webhotell, ser vi som regel 10–20 ganger raskere svartid etter en ombygging. I ett av kundeprosjektene våre tok en side 4,2 sekunder på det gamle oppsettet, og nå svarer den på rundt 180 millisekunder. Core Web Vitals gikk samtidig fra rødt til grønt. Hvor stor forbedringen blir hos deg, kommer an på utgangspunktet.
Påvirker ytelse SEO-rangeringer?
Ja, men det er ett av mange signaler. Google har bekreftet at Core Web Vitals er en del av rangeringen, så måltallene teller direkte. I tillegg oppfører folk seg annerledes på en treg side: de gir opp tidligere, blir kortere og åpner færre sider. Google sier ikke nøyaktig hvordan slik atferd brukes, men en side folk forlater raskt, gir uansett færre henvendelser og salg.
Kan dere optimalisere en eksisterende WordPress-side?
Ja. Vi starter med en ytelsesanalyse som finner flaskehalsene, og tar tiltakene i prioritert rekkefølge. Noen sider trenger bare opprydding i pluginene og fornuftig mellomlagring, mens andre trenger et nytt serveroppsett. Du får vite hva siden din trenger, og en plan som starter med tiltakene som gir mest effekt.
Hva koster ytelsesoptimalisering?
En ytelsesgjennomgang med konkrete anbefalinger koster fra 10 000 kr. Hva selve arbeidet koster, avhenger av hvor mye som må gjøres, og en enkel opprydding koster mindre enn å bygge om infrastrukturen. Har du en driftsavtale med oss, følger vi med på hastigheten hele tiden. Da fanger vi opp at siden blir tregere lenge før det blir et problem.
Hva er forskjellen på TTFB, FCP og LCP?
De måler tre punkter på samme tidslinje, fra forespørselen sendes til siden er ferdig. TTFB (Time to First Byte) viser når serveren begynner å svare. FCP (First Contentful Paint) er når det første innholdet vises på skjermen. LCP (Largest Contentful Paint) er når hovedinnholdet er på plass og siden oppleves som ferdig. Alle tre påvirker opplevelsen, men Google legger mest vekt på LCP.
Ytelsesgjennomgang av WordPress-siden
Fortell litt om nettsiden, så svarer vi med hva vi mener kan forbedres og hva det vil koste.