Tilbage til Forsiden
Tips og tricks· 20. juli 2026 ·Opdateret 24. aug. 2026 ·6 min læsetid

Sådan fremskynder du et langsomt WordPress-websted (uden et enkelt plugin)

WordPress ud af boksen er langsom af kedelige, fikserbare grunde. Her er rækkefølgen for at rette dem – først med størst effekt – ved at flytte arbejdet til kanten i stedet for at stable flere plugins ovenpå.

Mads Edelskjold
Mads Edelskjold
Grundlægger, XprotectTerm0X ex-datacenter CTO
Sådan fremskynder du et langsomt WordPress-websted (uden et enkelt plugin)

Det sædvanlige råd til et langsomt WordPress-websted er en liste over tyve ting, der præsenteres, som om de alle er lige vigtige. Det gør de ikke. To af dem tegner sig for de fleste forbedringer på de fleste websteder, og resten er afrundingsfejl, du kan komme til senere.

Så dette er en rangeret liste. Gør dem i orden, mål efter hver gang, og stop, når webstedet er hurtigt nok – hvilket sandsynligvis vil være hurtigere, end du forventer.

Trin 0: Find ud af, hvad der faktisk er langsomt

At springe over dette er, hvordan folk bruger en weekend på at minificere CSS på et websted, hvis virkelige problem er et 4 MB-hovedbillede.

Åbn dit websted i et inkognitovindue med DevTools på fanen Netværk. Se på tre tal: hvor længe indtil den første byte af HTML ankommer, hvad den største fil på siden er, og hvor mange anmodninger siden gør. Det er nok til at fortælle dig, hvilket af afsnittene nedenfor der gælder for dig.

  • Første byte over 600ms - dit problem er serversiden. Afsnit 1.
  • Første byte fin, siden stadig langsom - dit problem er aktiver. Afsnit 2.
  • Hurtigt for dig, langsomt for kunder andre steder – dit problem er afstand. Afsnit 3.

1. Stop med at genopbygge sider, der ikke er ændret

Det her er det store. For hvert besøg, WordPress vækker PHP, indlæser dit tema og hver aktiv plugin, kører en bunke af database forespørgsler, samler HTML, og først derefter sender det. Det samme gælder for den tusinde besøgende på et indlæg udgivet i marts.

Visitor PHP runsevery time DB queries HTML, finally
De røde trin gentages ved hvert enkelt besøg – også selvom siden aldrig ændres.

Cachelagring af hele sider gemmer den færdige HTML og serverer denne kopi direkte. PHP og databasen får fri. Udført ved kanten i stedet for på serveren, betyder det også, at den cachelagrede kopi sidder tæt på dine besøgende i stedet for i ét datacenter.

Indvendingen er altid "men mit websted har dynamiske dele". Det gør det, og det håndteres ved at omgå cachen præcis, hvor det er nødvendigt, snarere end at opgive caching helt.

Cache disse – identiske for alle

  • Indlæg og sider
  • Hjemmeside og arkiv
  • Kategori og tag lister
  • Statiske aktiver, naturligvis

Omgå disse – personlige

  • wp-admin og indloggede sessioner
  • Indkøbskurv og betaling
  • Alt bag et login
  • Eksempelvisning og tilpasning af WordPress

Mekanismen er cookies. WordPress sætter genkendelige cookies, når nogen logger ind eller lægger noget i en indkøbskurv, og cachen omgår deres tilstedeværelse. En udlogget besøgende har ingen af dem og får den cachede kopi; du, logget ind som editor, få en live side og aldrig mærke cache eksisterer.

Flere caching-plugins er ikke svaret, når caching-plugins er problemet. At køre to eller tre samtidig skaber konflikter, forældede sider og en eftermiddag fyldt med forvirring snarere end fart. At flytte cachen væk fra serveren er helt uden betydning for hele kategorien.

2. Fix billederne, fordi de er siden vægt

På et typisk WordPress-websted er billeder 60 til 80 procent af bytene på siden. Mediebiblioteket er fyldt med billeder, der uploades direkte fra en telefon i fuld opløsning, og som vises i en kolonne med 600 pixel.

To ændringer i denne rækkefølge: størrelsesændring til de dimensioner, der faktisk vises, og derefter konvertere til WebP eller AVIF. Udført på kanten, begge sker automatisk på vej ud og cachelagres bagefter - ingen re-uploading, ingen regenererende miniaturebilleder, ingen plugin omskrivning af dit mediebibliotek og bryde noget.

Mens du er der: Sørg for, at billedet i din sidehoved ikke er dovent. WordPress tilføjer loading="lazy" Det skader din største indholdsrige maling, når du anvender det på det største billede ovenover. Denne enkelt attribut har kostet flere websteder deres LCP-score end næsten alt andet.

3. Server den fra tæt på dine besøgende

Hvis din vært er i Frankfurt, og en fjerdedel af dine kunder er i USA, betaler de 100 til 150 millisekunders ventetid på hver rundtur, før din server har gjort noget overhovedet. Cachelagrede sider serveret fra en nærliggende kant fjerne det helt, og det er den løsning, som din egen test aldrig vil afsløre - webstedet er hurtigt fra dit skrivebord, fordi dit skrivebord er i nærheden af serveren.

4. Kun nu, de små ting

Når de første tre er færdige, er disse en time værd:

  • Revision af dine plugins ærligt

    Deaktiver alting, og genaktiver én ad gangen, så du kan kontrollere indlæsningstiden undervejs. De fleste websteder har to eller tre plugins, som ingen har brugt siden 2022, hver med scripts på hver side.

  • Komprimer og minify tekstaktiver

    Brotli til CSS, JS og HTML. Virkeligt, hvis det er beskedent, og det koster ikke noget at tænde.

  • Skær ned på alle sider

    Et skyderbibliotek, der er indlæst på hele webstedet, giver én skyder på startsiden, hvilket er meget almindeligt og nemt at rette.

  • Rengør databasen

    Efter revisioner, udløbne transienter og forældreløse metadata ophobes i årevis. Kun værd at gøre efter ovenstående; det sjældent bevæger nålen på egen hånd.

  • Ofte stillede spørgsmål

    Hvorfor er mit WordPress-websted så langsomt?

    Oftest fordi WordPress genopbygger hver side fra PHP og databasen ved hvert besøg, selv for sider, der ikke har ændret sig i måneder, og fordi billederne er langt større end det rum, de vises i. Mellem dem disse to tegner sig for størstedelen af problemet på typiske websteder. Plugin opblussen og uoptimerede aktiver sagen, men normalt mindre end folk antager.

    Kan jeg fremskynde WordPress uden plugins?

    Ja, og det er ofte bedre. Fuldsides caching, billedændring og formatkonvertering og komprimering kan alle håndteres på CDN-kanten i stedet for ved plugins, der kører inde i WordPress. Det fjerner PHP-arbejdet helt i stedet for at optimere det og undgår de konflikter, der opstår, når flere caching-plugins kører på én gang.

    Vil caching ødelægge min WooCommerce-kurv eller sider, der er logget ind?

    Ikke hvis cache bypass er konfigureret korrekt. WordPress og WooCommerce sætter identificerbare cookies, når en besøgende logger ind eller tilføjer noget til en indkøbskurv, og cachen omgås, når disse cookies er til stede. Udloggede besøgende, der søger i kataloget, får cachelagrede sider; alle med en session får en liveside genereret normalt.

    Hvor meget hurtigere gør fuldside caching WordPress?

    Besparelsen er hele serversiden, som på en typisk delt hosting WordPress-installation er flere hundrede millisekunder til et par sekunder pr. Side. En cachelagret side serveret fra en nærliggende kant ankommer normalt på under 50 millisekunder sammenlignet med 800 millisekunder eller mere ucachelagret. Kløften udvides under belastning, fordi cachelagrede svar ikke forbruger oprindelseskapacitet.

    Hjælper eller skader det ydeevnen med at lægge billeder i doven tilstand?

    Begge dele afhængigt af billedet. Du slipper for at indlæse billeder under folden, hvilket sparer båndbredde og øger den indledende belastning. Det største billede over skillelinjen – ofte overskriften eller helten – forsinker det og forværrer direkte den største indholdsrige maling. WordPress anvender loading="lazy" bredt, så det er værd at kontrollere, at dit heltebillede er udelukket.

    Læg listen ned, og stop, når du er tilfreds. De fleste websteder får størstedelen af den tilgængelige forbedring fra trin 1 og 2, som mellem dem tager en eftermiddag og kræver installation af noget.

    #wordpress #præstation #caching #speed
    Sæt det i praksis

    Se, hvordan NordicCDN gør dette for dit websted:

    Mads Edelskjold
    Skrevet af
    Mads Edelskjold Grundlægger, NordicCDN ex-datacenter CTO

    Mads har arbejdet med IT – mest som vært – siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig og sikker infrastruktur enkel at bruge.

    Få dit websted til at indlæses øjeblikkeligt

    Start gratis på to minutter – intet kort påkrævet.

    Start gratis