LiteSpeed Cache sammen med andre optimeringsplugins

Kort svar: Hver optimeringsopgave må kun løses ét sted. To page caches, dobbelt minificering, to lazy loads eller to billedoptimeringer giver ikke dobbelt fart – de giver fejl, der er svære at spore. Kører du LiteSpeed Cache på en LiteSpeed-server, bør den være dit ene lag; slå overlappende funktioner fra i andre plugins (eller fjern pluginnet), og lad kun specialiserede værktøjer uden overlap køre ved siden af.

Fagligt gennemgået: 2. oktober 2026

„Jo flere hastighedsplugins, jo hurtigere site“ er en af de dyreste misforståelser i WordPress-drift. Optimeringsplugins arbejder på de samme filer og de samme mekanismer – og når to systemer omskriver hinandens output, opstår netop de fejl, der fylder i fejlfindingsguiderne: ødelagte layouts, død JavaScript og cache, der aldrig rammer.

Her får du reglen, en oversigt over de farlige overlap, en metode til at finde dem på dit eget site og en sikker fremgangsmåde, når du skifter fra ét plugin til et andet.

Før du ændrer noget: Tag en backup, og tag skærmbilleder af de nuværende plugin-indstillinger. Arbejd helst på en staging-kopi, og ændr én ting ad gangen, så du ved, hvilken ændring der gjorde forskellen.

Reglen: én opgave, ét værktøj

Optimering består af afgrænsede opgaver: page cache, object cache, minificering og sammenlægning, kritisk CSS, script-udskydelse, lazy load, billedoptimering og CDN. Hver opgave må have præcis én ejer. Problemet med to ejere er ikke kun spildt arbejde – det er, at lag to arbejder på lag ets omskrevne output: minificeret CSS minificeres igen, udskudte scripts udskydes igen, og cache-lag ét gør lag to blindt for opdateringer:

De farlige overlap

Overlap	Typisk symptom
To page caches (fx LiteSpeed Cache + WP Super Cache)	Gammelt indhold, purge der „ikke virker“, dobbelte cache-filer
To object cache-plugins (fx LiteSpeeds object cache + Redis Object Cache)	Det ene plugin overskriver det andets object-cache.php; fejl i wp-admin eller ingen effekt
Dobbelt minificering og sammenlægning	Ødelagt CSS eller JavaScript – fejl, der kun ses hos besøgende
To script-udskydere (delay/defer + Rocket Loader)	Menuer og formularer dør uforudsigeligt
To lazy loads	Billeder, der aldrig loader, dobbelte pladsholdere
To billedoptimeringer	Dobbelt komprimering – synligt kvalitetstab og spildt diskplads

Kombinationen LiteSpeed Cache + FlyingPress eller WP Rocket er det klassiske eksempel: stærke værktøjer hver for sig, men med næsten fuldt overlap. Vælg ét som primært – hvilket afhænger af server og behov, og det valg er hele emnet i sammenligningsguiden. På en LiteSpeed-server er LiteSpeed Cache det naturlige valg til page cache, fordi kun den kan bruge serverens indbyggede cache-motor, ESI og privat cache.

Hvorfor overlap giver tekniske konflikter

Mange konflikter skyldes, at WordPress kun har plads til ét plugin på bestemte nøglepunkter. To filer i wp-content er særligt vigtige:

• advanced-cache.php indlæses tidligt, når konstanten WP_CACHE er sat til true i wp-config.php. Page cache-plugins lægger deres egen version her. Der kan kun være én fil – det sidst aktiverede plugin vinder, og det andet tror måske stadig, at det kører.
• object-cache.php er drop-in’en til object cache (Redis eller Memcached). Også her kan kun ét plugin eje filen. To object cache-plugins giver i bedste fald ingen effekt og i værste fald forældede data i wp-admin.

Dertil kommer .htaccess: både LiteSpeed Cache og andre cache-plugins skriver regler ind i filen. Efterladte sektioner fra et afinstalleret plugin kan blive ved med at påvirke cache og omskrivninger. Se guiden om reglerne, LiteSpeed skriver i .htaccess.

1. Kortlæg, hvem der ejer hvad

Start med en liste over aktive plugins. Med SSH og WP-CLI får du den hurtigt, sammen med en kontrol af drop-in-filerne:

wp plugin list --status=active
wp plugin list --status=dropin
wp config get WP_CACHE
head -n 5 wp-content/advanced-cache.php

Toppen af advanced-cache.php afslører typisk, hvilket plugin der har skrevet filen. Lav derefter en enkel tabel: én række pr. opgave (page cache, object cache, minificering, kritisk CSS, script-udskydelse, lazy load, billeder, CDN) og én kolonne pr. plugin. Står der mere end ét kryds i en række, har du et overlap. Husk også temaer og sidebyggere – nogle har deres egen lazy load eller CSS-optimering.

2. Bekræft overlap i sidekilden og headerne

Åbn sidekilden i et privat vindue. Minificerede og sammenlagte filer bærer typisk deres ophav i stien – fx /wp-content/litespeed/ eller et andet plugins cache-mappe. Ser du to forskellige cache-stier til CSS eller JavaScript på samme side, laver to plugins det samme arbejde. Det samme gælder lazy load: to forskellige klasser eller attributter på de samme billeder betyder to mekanismer.

Tjek derefter cache-headerne:

curl -sI https://dit-domæne.dk/ | grep -i -E "x-litespeed-cache|cf-cache-status|x-cache"

x-litespeed-cache: hit viser, at LiteSpeeds page cache svarer. Se guiden om LiteSpeed-cache-headere, hvis du får miss eller slet ingen header.

3. Hvad der gerne må køre ved siden af

Ingen overlap, ingen konflikt. Disse kombinationer er typisk fine:

• Et rent billedoptimeringsplugin, hvis LiteSpeeds egen billedoptimering er slået fra (og omvendt).
• Cloudflare som DNS, sikkerhed og statisk cache foran LiteSpeed, så længe Cloudflares omskrivende funktioner som Rocket Loader er slukkede. Cloudflares gamle Auto Minify-funktion er udfaset, så den skal du ikke længere tage stilling til.
• Værktøjer uden frontend-omskrivning: backup-, sikkerheds- og SEO-plugins blander sig ikke i optimeringen.
• LiteSpeed Cache kun som page cache og et andet plugin til frontend-optimering – men kun hvis hver overlappende funktion er slået fra det ene sted, og du vedligeholder opdelingen ved hver opdatering.

Tommelfingerregel: hvis to plugins har en indstillingsside med de samme ord (minify, defer, delay, lazy load, cache), skal funktionen være slukket i det ene.

4. Skift rigtigt fra ét plugin til et andet

1. Notér det gamle plugins aktive funktioner (skærmbillede af indstillingerne), så intet går tabt i skiftet.
2. Deaktivér og afinstallér det gamle plugin – og tjek, at det rydder op efter sig i .htaccess, advanced-cache.php og object-cache.php. Fjern efterladte sektioner og filer manuelt.
3. Sæt det nye op fra en dokumenteret basisopsætning – for LiteSpeed: indstillingsguiden – og slå avancerede funktioner til én ad gangen.
4. Ryd al cache (server, plugin og CDN), og test i et privat vindue: forside, menu, formular, søgning – og købsflowet på webshops.

Går layoutet i stykker efter et skift, er det oftest kritisk CSS eller UCSS, der skal genereres på ny. Se guiden om ødelagt layout efter UCSS eller Critical CSS.

5. Verificér resultatet

Opsætningen er ren, når:

• kun ét plugin ejer hver opgave i din tabel;
• sidekilden kun viser ét systems signaturer (én minificering, én lazy load-mekanisme);
• cache-headerne viser HIT fra det rigtige lag;
• browserkonsollen ikke viser nye JavaScript-fejl;
• en hastighedsmåling før og efter oprydningen viser samme eller bedre tal med færre plugins.

Det sidste er pointen: overlap gav aldrig fart – kun risiko. Er du i tvivl om, hvad der overlapper på dit site, kigger Hostious-supporten gerne plugin-listen igennem.

Læs også

• Hub: QUIC.cloud og LiteSpeed Cache
• WP Rocket vs. FlyingPress vs. LiteSpeed Cache
• Rocket Loader ødelægger JavaScript
• Object cache med Redis eller Memcached i LiteSpeed Cache
• WordPress hosting hos Hostious – LiteSpeed-hosting med Redis object cache fra WP StartUp

Ofte stillede spørgsmål om plugin-kombinationer

Må jeg bruge LiteSpeed Cache sammen med FlyingPress?

Det frarådes som standard, fordi overlappet er næsten totalt. Avancerede opsætninger kan dele opgaverne (fx LiteSpeed kun som page cache og FlyingPress til frontend-optimering), men så skal hver overlappende funktion slås fra manuelt – og opdelingen vedligeholdes ved hver opdatering.

Hvordan ser jeg, om to plugins begge minificerer?

Kig i sidekilden: minificerede filer bærer typisk deres ophav i stien (fx /litespeed/ eller pluginnets cache-mappe). To forskellige cache-stier til CSS eller JavaScript på samme side betyder dobbeltarbejde.

Gælder reglen også Cloudflare?

Ja. Cloudflare som DNS, sikkerhed og statisk cache er fint oven på LiteSpeed – men omskrivende funktioner som Rocket Loader tæller som endnu en ejer af script-opgaven og skal være slukkede.

Kan to plugins dele object cache?

Nej. Object cache styres af én drop-in-fil, object-cache.php, og kun ét plugin kan eje den. Vælg enten LiteSpeed Caches object cache eller et dedikeret Redis-plugin, og slå funktionen fra i det andet.