Hvorfor er min WordPress-hjemmeside langsom?

Der er ikke én grund til at en WordPress-side er langsom. Der er seks, og de kræver vidt forskellige ting af dig. Nogle koster ti minutter, andre koster en beslutning om at skifte tema. Det værste du kan gøre er at gå i gang med at optimere, før du ved hvilken af de seks der er din — så bruger du en eftermiddag på at komprimere billeder på en side hvor problemet sidder i serveren.

Her er de seks, i den rækkefølge jeg selv tjekker dem. Efter hver står der hvordan du selv afgør om det er den.

1. Der går for lang tid før serveren svarer

Det første tal at kigge på er TTFB — tiden fra browseren beder om siden, til det første byte kommer tilbage. Det er ren ventetid, hvor der ikke er tegnet noget som helst, og den ligger foran alt andet. Grænsen for en god TTFB er 0,8 sekund.

Er din TTFB på flere sekunder, er der ingen grund til at se på billeder eller JavaScript endnu. Du kan ikke tegne dig ud af ventetid der er brugt, før tegningen begynder.

Vær opmærksom på at “serveren” her ikke betyder “hosten”. Dit tema, dine plugins og dine databaseforespørgsler kører på den server ved hver eneste sidevisning, og de tæller med i det samme tal. En høj TTFB kan altså lige så godt pege på punkt 2 og 3 herunder som på din udbyder.

Sådan tjekker du det: kør din forside gennem PageSpeed Insights og find “Reduce initial server response time”. Står tallet over 800 ms, er det her du starter. Læs TTFB: når problemet er serveren.

2. Der er ingen cache — eller der er to

Caching gemmer den færdige side, så serveren ikke skal bygge den op forfra ved hvert besøg. Det er den enkeltændring der flytter mest. På de sider jeg måler, falder TTFB til under 80–150 millisekunder når sidecachen rammer — også på sider hvor den samme URL uden cache tager flere sekunder.

Den modsatte fejl er lige så almindelig: to cache-plugins installeret oven på hinanden. Der bliver sat WP Rocket op, og et halvt år senere kommer der et “speed booster” ovenpå, eller hosten slår sit eget optimeringsplugin til. Så minificerer to plugins hinandens output, og to systemer tror hver især at de ejer cachen. Resultatet er langsommere end ét plugin alene — og fejl der kommer og går.

Sådan tjekker du det: åbn plugin-listen og tæl hvor mange der har med cache, minificering eller “optimize” at gøre. Er der mere end ét, er du der. Læs To cache-plugins er værre end ét.

3. Sidebyggeren leverer mere end designet bruger

Elementor, Divi, WPBakery og Avadas Fusion Builder er de tungeste enkeltdele jeg møder. Ikke fordi de er dårligt lavet, men fordi de er bygget til at kunne alt — og derfor leverer CSS og JavaScript til alt, uanset hvad der rent faktisk står på siden.

I den vægtning jeg bruger i min egen hastighedstest ligger sidebyggerne allerøverst. Elementor Pro og WPBakery vejer 0,50 på en skala hvor et almindeligt SEO-plugin vejer 0,10, og hvor et godt cache-plugin trækker den anden vej med −0,30.

Sådan tjekker du det: kig i PageSpeed Insights under “Reduce unused CSS” og “Reduce unused JavaScript”. Står der 200 kB eller mere ubrugt CSS, er det næsten altid byggeren. Læs Elementor og hastighed.

4. Billederne er for store

Det er den mest almindelige enkeltårsag, og også den letteste at rette. Et hero-billede på 1,5 MB koster sekunder alene på hentetiden, og det er som regel netop det billede der afgør din LCP.

To fejl går igen. Den ene er formatet: JPEG og PNG hvor WebP eller AVIF ville fylde langt mindre ved samme kvalitet. Den anden er størrelsen: et billede på 3000 px bredde, der vises i 600 px, og som browseren skalerer ned efter at have hentet det hele.

Og en tredje, som er selvskade: hero-billedet får loading="lazy" med fra temaet. Så udskyder browseren netop det billede den skulle have hentet først. Se lazy loading.

Sådan tjekker du det: “Properly size images” og “Serve images in next-gen formats” i PageSpeed Insights. Læs Billeder er stadig den største synder.

5. For meget JavaScript holder siden optaget

Når siden ser hurtig ud, men scoren alligevel er 54, er det her det sidder. TBT — Total Blocking Time — måler hvor længe siden er ude af stand til at reagere på et klik, og den vejer 30 procent af din Lighthouse-score. Mere end noget andet enkelttal.

Kilderne er altid de samme: plugins der lægger deres script på alle sider, også hvor de ikke bruges, og tredjeparter — chat, heatmaps, sporingspixels, annoncer. Se Tredjepartsscripts: chat, pixels og analytics.

Sådan tjekker du det: kig på TBT-tallet i mobiltesten. Over 600 millisekunder er dårligt, og der begynder folk at klikke to gange fordi de tror det første klik ikke virkede.

6. Noget blokerer visningen

Browseren tegner ikke noget, før den er igennem den CSS og det JavaScript der står i sidens hoved. På en typisk dansk WordPress-side finder jeg mellem 8 og 20 render-blocking ressourcer — de kommer fra temaet, fra byggeren, og fra hvert plugin der har sin egen CSS-fil med.

Skrifttyper hentet fra et fremmed domæne tæller også med. Browseren skal først slå domænet op og åbne en forbindelse, før den kan hente noget.

Sådan tjekker du det: “Eliminate render-blocking resources” i PageSpeed Insights. Listen viser hver fil og hvor meget tid der er at hente.

Sådan finder du din på ti minutter

1. Kør forsiden gennem PageSpeed Insights — og vælg mobil, ikke computer. Computer-scoren snyder.
2. Kig på serverens svartid først. Over 800 ms? Så er det punkt 1, 2 — og ofte også 3, for temaets og pluginnenes kode kører netop dér.
3. Kig derefter på LCP. Er den høj, mens serveren er hurtig? Så er det punkt 4.
4. Kig på TBT. Er den høj? Så er det punkt 5.
5. Kig på listen over blokerende ressourcer. Lang? Så er det punkt 3 og 6.

Bemærk at scoren i sig selv ikke fortæller dig noget brugbart. Det er tallene under den — LCP, CLS og TBT — der peger på hvad du skal gøre. Se Hvad en hastighedstest IKKE fortæller.

Vil du have det hele gennemgået frem for at gøre det selv, så start med en hastighedsanalyse. Så har vi tallene, inden vi taler sammen.

Ofte stillede spørgsmål

Hvorfor er WordPress langsommere end en almindelig hjemmeside?

Fordi hver eneste sidevisning bygges op forfra: PHP startes, databasen spørges, og hvert aktivt plugin køres igennem. Det er også WordPress’ styrke — men det er derfor sidecache flytter så meget, og det er derfor plugins koster.

Hvor mange plugins er for mange?

Der findes ikke et tal. Tyve lette plugins kan sagtens være hurtigere end fem tunge. Det der tæller er hvad de leverer af CSS og JavaScript på siderne, ikke hvor mange linjer der står i listen. Se Hvad koster hvert plugin dig i hastighed?

Kan et dyrere webhotel løse det?

Det løser punkt 1, hvis det er der problemet sidder — og kun det. Er din side langsom fordi der hentes 900 kB JavaScript, bliver den ikke hurtig af en hurtigere server. Den bliver bare hurtig til at sende de 900 kB.