Kort svar: Start med en baseline, backup og kun ét aktivt fuld-side-cachelag. Bekræft derefter servercache med to anonyme requests: først forventes normalt
miss, derefterhit. Bevar dynamiske sider som checkout og kontoområder uden fuld sidecache. Lad avanceret CSS-, JavaScript-, Guest Mode- og crawleroptimering være slået fra, indtil basis-cachen er målt og stabil. En PageSpeed-score er ikke bevis for korrekt funktion.
Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, LiteSpeed Cache 7.9, PHP 8.4.23 og Chrome 151 på isoleret staging. QUIC.cloud-integration og quota er ikke aktiveret eller verificeret; de dele af forløbet skal derfor bekræftes i din egen konto.
LiteSpeed Cache for WordPress rummer flere produkter i én menu: serverbaseret page cache, browsercache, database-/object-cacheintegration, CSS/JavaScript-optimering, medieoptimering, crawler og QUIC.cloud-tjenester. De skal ikke aktiveres som en samlet “hurtig” profil uden test. En stabil opsætning bygges lag for lag, så du ved, hvilken indstilling der ændrer hvad.
På denne side
Den tidligere version af denne artikel lovede “100% PageSpeed og GTmetrix” og universelle indstillinger. Det er ikke en faglig målsætning. Resultater afhænger af tema, scripts, billeder, server, trafik, samtykke og den konkrete testsituation. Målet er korrekt cacheadfærd, intakte funktioner og dokumenteret forbedring på de sider, brugerne faktisk besøger.
| Symptom eller mål | Sandsynlig risiko | Kontrol | Sikkert næste skridt |
|---|---|---|---|
| Page cache skal aktiveres | Server/CDN understøtter den ikke | Anonyme headers på cachebar URL | Aktivér kun ved dokumenteret miss → hit |
| Indloggede sider skal være hurtige | Privat indhold kan blive delt | To isolerede brugerstates | Bevar logged-in cache fra som udgangspunkt |
| Indhold skal opdateres hurtigt | TTL bruges som eneste ugyldiggørelse | Gem post og følg purge/header | Start med defaults og ret purge-eventet |
| Arkiv viser gammel post | Relateret cachetag purges ikke | Post, arkiv og forside før/efter | Bevar smarte purge-regler og ret integrationen |
| Dynamisk side får hit | Exclude eller cookie-vary mangler | Kurv/login/konto i privat session | Tilføj kun den dokumenterede dynamiske undtagelse |
| Layout eller knap bryder | CSS/JS blev aktiveret i en samlet batch | Funktion-for-funktion-test på staging | Slå basisoptimering fra og aktivér ét lag ad gangen |
| Første besøg viser forkert state | Guest Mode ignorerer nødvendig vary | Ny gæst, sprog, pris og consent | Bevar Guest Mode fra indtil matrixen består |
| Crawler presser sitet | Serverfeature/kapacitet er ikke afklaret | Miss→hit plus CPU/PHP-baseline | Bevar crawler fra og aftal grænser med hosting |
Aktivering i WordPress beviser ikke, at webserveren cacher. Test som anonym bruger uden en cache-bypass-cookie. Første request til en ren URL er normalt X-LiteSpeed-Cache: miss; gentagelsen skal blive hit. QUIC.cloud kan i stedet tilføje X-QC-Cache og X-QC-Pop.
Et no-cache i X-LiteSpeed-Cache-Control kan være tilsigtet for login, POST, søgning, checkout eller en ekskluderet cookie. Tving ikke disse sider i cache for at få et hit.
Hvis headeren mangler på en almindelig offentlig artikel, brug guiden om LiteSpeed Cache, der ikke cacher.
To page-cachelag kan fungere, men kun med et dokumenteret purge- og bypassdesign. Et optimeringsplugin, host-cache og CDN-page-cache kan ellers levere tre forskellige HTML-versioner. Slå overlappende funktioner fra på staging, og tilslut dem igen én ad gangen med headerbevis.
Object cache er ikke det samme som page cache. Redis/Memcached kan reducere databasearbejde, men gør ikke automatisk en HTML-side til et cache-hit. Aktiver kun persistent object cache, hvis hostingmiljøet leverer og overvåger den.
Login, wp-admin, formularresultater, konto-, kurv- og checkoutflows samt sider med brugerafhængige priser/sprog kræver korrekt bypass eller cache vary. Test mindst to isolerede browsere. De må ikke se hinandens personlige indhold.
Brug specifikke URI-/cookie-/rolleundtagelser. En bred regel som at cache alt eller aldrig cache hele sitet er sjældent den rigtige løsning.
TTL bestemmer, hvor længe en cachepost kan leve. Den bør ikke være den eneste måde, nyt indhold bliver synligt. Ved publicering og redigering skal LiteSpeed normalt purge posten og relaterede arkiver via tags/hooks. Test dette med en unik, ufølsom markør.
Hvis du konstant må Purge All, mangler der sandsynligvis en integration eller purge-event. Brug guiden om gammelt indhold i stedet for at forkorte alle TTL'er.
Mål først uden page optimization. Aktivér derefter én funktion, purge det relevante lag, og test desktop, mobil, menu, formular, login og købsflow. Kombinér ikke minify, combine, defer, delay, UCSS og async CSS i én gemning; så kan fejlen ikke tilskrives.
Ved layoutproblemer bruges UCSS/CCSS-guiden. Ved døde knapper eller formularer bruges JavaScript-guiden.
I LiteSpeed Cache v7 er det gamle Domain Key-felt udfaset. Forbindelsen sker via LiteSpeed Cache → General → Online Services → Enable QUIC.cloud Services. Online Services og CDN er to forskellige valg; du behøver ikke flytte DNS for blot at bruge billed-/sideoptimering.
Se den samlede QUIC.cloud-opsætningsguide før DNS-ændringer.
Guest Mode kan vise en standardcache til første request og derefter hente den korrekte variant. Det kan give et kort glimt af forkert sprog, pris eller indhold. Crawleren kan bygge flere varianter og belaste serveren. De er optimeringsvalg, ikke krav for at page cache virker.
Aktiver dem kun med en testmatrix og kapacitetsmåling. Separate fejlguides dækker Guest Mode og crawleren.
En enkel informationsside kan ofte bruge konservativ page cache, browsercache og billedoptimering uden mange undtagelser. En medlemsportal har derimod login, roller og personligt indhold; her er beviset for korrekt bypass vigtigere end maksimal hitrate. En WooCommerce-butik tilføjer kurv, checkout, konto, valuta og lager, som skal testes i to isolerede sessioner.
Det betyder, at en settingsprofil fra et andet site ikke er et facit. Kopiér i stedet rækkefølgen: baseline, én funktion, purge af det relevante lag, samme funktionsmatrix og rollback ved afvigelse. Selve værdierne skal følge sidens states og serverens kapacitet.
Du aktiverer JavaScript Delay og ser en bedre laboratoriemåling. Forsiden ser rigtig ud, men samtykkebannerets acceptknap og kontaktformularens validering reagerer først ved andet klik. Det er en funktionsregression, selv om cacheheaderen og scoren er fine. Slå kun Delay tilbage, purge page optimization og gentag præcis de to interaktioner. Hvis de virker, bruges JavaScript-guiden til at finde den mindste exclusion; resten af basis-cachen kan blive stående.
Når en post gemmes, bør den relevante cachepost blive ugyldiggjort. Den første anonyme request efter gemningen kan derfor være miss, og den næste hit. Fejlen er ikke første miss, men hvis alle requests bliver miss, hvis arkivet aldrig får den nye post, eller hvis en dynamisk side pludselig bliver hit. Mål sekvensen i stedet for at læse ét header isoleret.
For hver fase noteres dato, URL-type, indstilling, cacheheader, synligt resultat og rollback. Det gør opgraderinger håndterbare: hvis LiteSpeed Cache, tema eller builder ændrer adfærd, kan du genkøre de samme fem URL'er uden at genopfinde opsætningen. Opdater journalen efter større pluginændringer, ikke kun når noget allerede er gået galt.
Eksporter eller screenshot indstillingerne før hver fase. Gendan kun den senest ændrede funktion, purge dens relevante cache og gentag samme test. En profilimport med mange ændringer kræver fuld konfigurationsbackup; brug ikke “Reset All” som første rollback.
Hosting skal bekræfte serverstøtte, cacheheader, cache-root/rettigheder og eventuel crawleradgang. Tema-/pluginudvikleren skal have den ene indstilling og URL, der reproducerer fejlen. Se LiteSpeed hosting hos Hostious ved serverrelateret driftshjælp.
Lav to anonyme requests mod samme side, og læs x-litespeed-cache-headeren: første svar må gerne være miss, det næste skal være hit. Får du aldrig hit, cacher serveren ikke – så skal de grundlæggende LiteSpeed Cache indstillinger efterses, før du optimerer videre.
Kurv, checkout, login og kontosider skal forblive dynamiske. LiteSpeed undtager dem som regel selv på WooCommerce, men verificér med en no-cache-header på netop de URL’er.
Nej. Få basiscachen stabil først, og mål effekten. UCSS, kritisk CSS og Guest Mode kan give reelle gevinster, men de kan også ødelægge layout og funktioner, hvis de aktiveres uden eftertest.
Gem en baseline med de aktive cachelag, LiteSpeed-indstillinger og headers for en offentlig artikel, login, konto og eventuel checkout. Beskær domæne, bruger og cookies fra billeder, men bevar versionsnumre og de felter, der faktisk blev ændret. Skriv én linje pr. ændring med førværdi, efterværdi, purge og resultat.
En god kontrol viser både cacheadfærd og funktion: anonym miss → hit på en cachebar side, bevidst no-cache på dynamiske sider og en konkret prøve af menu, formular eller købsflow. Hvis QUIC.cloud senere aktiveres, så dokumentér integrationsstatus og quota separat i dit eget dashboard.
