Hastighedsoptimering uden plugins-overload: Metoder der virker

Hastighed på jeres WordPress-hjemmeside handler sjældent om at jagte et enkelt tal i et værktøj. Det handler om ro i driften, et brand der fremstår professionelt, og en oplevelse der ikke står i vejen for jeres budskaber.

Som marketingansvarlig i en B2B-virksomhed har du ofte brug for, at hjemmesiden bare fungerer. Den skal være hurtig på mobil, stabil på tværs af kampagner og nem at videreudvikle uden, at hver forbedring kræver fem nye plugins og en ny risiko.

Her får du en metode til hastighedsoptimering i WordPress, hvor fokus er på de ting, der giver mest effekt, og hvor I holder plugin-listen nede.

Før du optimerer: afklar hvad “hurtigt nok” betyder for jer

En hjemmeside kan føles hurtig, selv om den ikke får topkarakter i alle tests. Omvendt kan en side score pænt og stadig virke tung, hvis den hakker på mobil eller loader elementer i en uheldig rækkefølge.

Jeg plejer at afklare tre ting internt, før man begynder:

• Hvilke sider er vigtigst for jeres marketing og salg (typisk forside, ydelser, cases og kontakt)?
• Hvilke device-typer betyder mest (B2B er ofte mobil + desktop i blandet forhold)?
• Hvad er “godkendt” i praksis (fx at siden kan bruges uden ventetid og uden hoppende layout)?

Det gør det lettere at prioritere de rigtige tiltag og undgå optimering, der kun giver ro i et værktøj.

Trin 1: Mål rigtigt og skriv jeres baseline ned

Start med én repræsentativ side og én vigtig landingsside. Kør dem igennem PageSpeed Insights eller Lighthouse. Gentag gerne testen et par gange og notér gennemsnittet, så I ikke reagerer på tilfældige udsving.

Det du primært vil holde øje med, er:

• LCP (hvor hurtigt hovedindholdet er synligt)
• CLS (om layoutet hopper)
• INP (om siden føles responsiv, når man klikker)

Nedenfor er en enkel “oversætter”, der gør det nemmere at koble tal til konkrete handlinger.

Når baseline er skrevet ned, kan I ændre én ting ad gangen og se, hvad der faktisk flytter noget.

Trin 2: Start med det, der vejer mest: billeder og video

På mange B2B-hjemmesider er billeder den største post. Og her kan man få store gevinster uden at installere en “alt-i-en” optimeringspakke.

WordPress understøtter WebP (og håndterer responsive billedstørrelser), men det kræver stadig disciplin i jeres arbejdsgang: rigtige dimensioner, fornuftig kvalitet og en konsekvent praksis, når marketing uploader nyt indhold.

En simpel intern standard kan være:

• WebP som udgangspunkt
• Maks bredde pr. brugssituation (fx 1600 px til hero, 900 px til indhold)
• Samme billedformat-stil på tværs af sider, så brandet hænger sammen

Når det er på plads, undgår I, at “hurtighed” bliver et projekt, der starter forfra hver gang nogen uploader en ny case.

Hvis I bruger indlejrede videoer, så kig også på, om de loader for tidligt. En YouTube-embed kan nemt trække mange requests med sig, selv før brugeren trykker play.

Trin 3: Brug WordPress’ indbyggede lazy load, og udvid kun hvor det giver mening

WordPress lazy-loader allerede billeder i mange tilfælde, hvis billederne er indsat korrekt og har dimensioner. Det hjælper både hastighed og stabilitet (CLS).

Udfordringen opstår typisk ved iframes, embeds og elementer fra sidebyggere. Her kan en lille, kontrolleret kodeændring være bedre end et plugin, der forsøger at “fikse alt”.

Eksempel på at tilføje loading="lazy" til iframes via et filter:

function ew_lazyload_iframes($html) {
    return str_replace('<iframe', '<iframe loading="lazy"', $html);
}
add_filter('embed_oembed_html', 'ew_lazyload_iframes');
add_filter('video_embed_html', 'ew_lazyload_iframes');

Hold det enkelt. Test én side. Tjek at embeds stadig virker, og at der ikke opstår uventede visuelle skift.

Trin 4: Fjern blokering i toppen: CSS, fonte og JavaScript

Her er det let at ende i plugin-overload, fordi mange performance-plugins lover at håndtere minificering, kritisk CSS, defer, delay, preload og alt muligt andet på én gang.

Mit råd er at arbejde trin for trin og holde jer til de mest stabile greb først.

Kritisk CSS, men kun når det giver ro

Kritisk CSS kan være effektivt, men det kan også skabe vedligeholdelsesarbejde, hvis designet ofte ændres. Brug det på sider, der er centrale for jeres marketing, og hvor I kan holde stilen relativt stabil (fx forside eller en kerne-landingpage).

En klassisk metode er:

1. Inline en lille mængde CSS til header og hero.
2. Load resten af CSS normalt, men uden at blokere første rendering.

Det kræver lidt håndarbejde, men det er til at styre, hvis I dokumenterer det.

Defer scripts og ryd op i det, der ikke er kritisk

Mange WordPress-installationer ender med scripts, der kører på alle sider, selv om de kun er nødvendige på få.

I WordPress kan du tilføje defer til udvalgte scripts:

add_filter('script_loader_tag', function($tag, $handle) {
    $defer = ['custom-main-js'];
    if (in_array($handle, $defer, true)) {
        return str_replace(' src', ' defer src', $tag);
    }
    return $tag;
}, 10, 2);

Gør det med omtanke. Nogle scripts kræver rækkefølge. Når du ændrer loading, så test både navigation, formularer og eventuelle tracking-events, så I ikke får fejl i jeres målinger.

Fonte: færre varianter og tydelig fallback

Fonte kan give både langsommere rendering og layout-hop. Her er de to typiske greb:

• Brug færre weights (ofte rækker normal og bold langt i B2B).
• Sørg for font-display: swap; så tekst vises med det samme og skifter font, når den er hentet.

Det er sjældent en god ide at hente fem forskellige fonte for at “se lidt mere designet ud”. Det skaber uro og er ikke nødvendigt for et professionelt udtryk.

Trin 5: Server og caching: vælg en stabil løsning frem for mange små

Hvis TTFB er høj, kan du optimere billeder og CSS længe uden at få den ro, du ønsker. WordPress skal stadig generere siden, og det koster tid.

Her er de server-ting, jeg typisk kigger efter:

• PHP 8.x
• OPcache slået til
• HTTP/2 eller HTTP/3 aktivt
• Komprimering (gzip eller Brotli)
• Cache headers på statiske filer

Cache headers kan ofte sættes i serverkonfigurationen. På Apache kan det fx ske i .htaccess, hvis hosten tillader det.

Når det gælder caching, giver det ofte mest ro, hvis caching ligger på serverniveau. En sidecache, der serverer HTML hurtigt, reducerer belastning og gør svartider mere stabile.

Objektcache (fx Redis) er næste skridt, hvis I har mange dynamiske opslag eller travl admin, men det er ikke altid nødvendigt på mindre B2B-sites.

Trin 6: Database og WordPress-hygiejne, der holder over tid

Hastighed falder ofte gradvist. Ikke fordi nogen gør noget “forkert”, men fordi hjemmesiden får flere sider, flere billeder, flere integrationer og flere plugins.

Her kan en fast rytme give ro:

• Ryd op i plugins, I ikke bruger.
• Fjern gamle temaer og unødvendige skabeloner.
• Kig på autoloaded data i wp_options, hvis admin føles tung.
• Flyt tunge planlagte opgaver væk fra “kør ved besøg”, så de ikke rammer brugerne.

Det her er ikke glamourøst, men det er driftssikkert. Og det er typisk her, en B2B-hjemmeside vinder stabilitet.

Når du arbejder med oprydning, så gør det altid på staging først og tag backup. Marketing har brug for forudsigelighed.

En lille styringsmodel, der forebygger plugin-overload

Plugin-overload opstår sjældent på én dag. Det kommer, når små behov løses med små plugins, og ingen har overblikket efter et halvt år.

En enkel model er at aftale, hvad der udløser et plugin, og hvad der udløser en kodeændring eller en ændring i arbejdsgang.

Det kan være så konkret som:

• Nyt plugin: kræver formål, ejer og plan for vedligehold
• Tredjepart-script: kræver vurdering af effekt på hastighed og samtykkeopsætning
• Nyt design-element: kræver tjek af billedstørrelser, fonte og mobilvisning
• Ny integration: kræver test af TTFB og fejl i konsol

Det skaber ro, fordi du kan sige ja eller nej på et fagligt grundlag, uden at det bliver en smagssag.

Tjekliste til næste sprint, uden at gøre det større end det er

Hvis du vil i gang uden at åbne en stor teknisk opgave, så brug denne rækkefølge. Den giver typisk tydelige forbedringer uden at introducere fem nye afhængigheder.

1. Mål to vigtige sider og skriv baseline ned.
2. Optimer hero-billeder og de største billeder i mediebiblioteket.
3. Sikr width/height på billeder og tjek CLS igen.
4. Defer et par ikke-kritiske scripts og test formularer og tracking.
5. Kontrollér PHP-version, OPcache og komprimering på serveren.
6. Aftal en intern regel for nye plugins og nye scripts, så hastigheden holder.

Det er sjældent nødvendigt at gøre alt på én gang. Det vigtigste er, at forbedringerne kan forklares, gentages og holdes stabile, når hjemmesiden vokser.