Kort svar: APO (Automatic Platform Optimization) får Cloudflare til at cache selve HTML’en fra dit WordPress-site på edge-servere tæt på de besøgende – med automatisk purge, når du opdaterer indhold via det officielle Cloudflare-plugin. Det giver mest, når publikum er spredt over flere lande, eller origin-serveren er langt væk eller langsom. Har du mest danske besøgende og hurtig hosting med servere i Europa og server-cache, er gevinsten typisk lille. Mål TTFB før og efter, og undgå dobbeltarbejde med dit cache-plugin.
Fagligt gennemgået: 2. oktober 2026
APO er Cloudflares svar på et reelt problem: almindelig Cloudflare cacher ikke HTML som standard, så selve siden skal stadig hentes fra din server – uanset hvor godt CSS og billeder ligger på edge. Med APO cacher Cloudflare også HTML’en globalt. Spørgsmålet er ikke, om det virker – det gør det – men om dit site får nok ud af det til at retfærdiggøre pris og ekstra kompleksitet.
Denne guide forklarer, hvad APO gør anderledes, hvornår det betaler sig, hvordan det spiller sammen med dit cache-plugin og WooCommerce, og hvordan du verificerer, at det faktisk virker.
Hvad APO gør anderledes
Uden APO serveres statiske filer fra edge, men HTML hentes fra origin – hver sidevisnings TTFB indeholder altså turen til din server. Med APO serveres hele siden fra den edge-lokation, der er nærmest den besøgende, og det officielle Cloudflare-plugin purger automatisk, når indhold opdateres. Indloggede brugere og besøgende med WooCommerce- eller sessionscookies får bypass, så personligt indhold ikke blandes sammen:
Teknisk er det WordPress-pluginnet, der gør APO muligt: det sender headeren cf-edge-cache, som fortæller Cloudflare, at siden må caches på edge, og det kalder Cloudflares API, når et indlæg, en side eller et tema ændres. Uden pluginnet har Cloudflare hverken tilladelsen til at cache eller besked om, hvornår cachen skal ryddes – og så får du enten ingen effekt eller forældet indhold.
Uden APO, med APO – og alternativerne
APO er ikke den eneste måde at få HTML på edge. Du kan også lave en Cache Rule i Cloudflare, der cacher HTML (“Cache Everything”), eller bruge QUIC.cloud-CDN’et, hvis sitet kører LiteSpeed Cache. Forskellen ligger i, hvem der holder styr på purge og undtagelser:
| Løsning | HTML på edge | Purge ved opdatering | Undtagelser for indloggede og kurv |
|---|---|---|---|
| Cloudflare uden APO | Nej | Ikke relevant | Ikke relevant |
| Cloudflare med APO | Ja | Automatisk via pluginnet | Indbygget for WordPress og WooCommerce |
| Cache Rule med “Cache Everything” | Ja | Du skal selv sørge for den | Du skal selv bygge bypass-reglerne |
| QUIC.cloud CDN med LiteSpeed Cache | Ja | Automatisk via LiteSpeed Cache | Styres af LiteSpeed Cache |
En hjemmelavet Cache Rule kan være gratis, men den er også nemmest at lave forkert: glemmer du bypass for indloggede brugere og kurv, kan besøgende se hinandens indhold. Se guiden til Cache Rules og WooCommerce, før du går den vej.
Hvornår APO giver mening
| Situation | Værdi af APO |
|---|---|
| Internationalt publikum, én origin | Høj – HTML serveres tæt på alle markeder |
| Langsom eller fjern origin-server | Høj – edge skjuler originens TTFB |
| Dansk publikum, hurtig hosting med servere i Europa og server-cache | Lav – origin svarer allerede hurtigt og tæt på |
| Meget dynamisk site (medlemssider, stor webshop med mange indloggede) | Lav – stor del af trafikken bypasser alligevel |
Kort sagt: APO løser afstands- og origin-problemer. Har du ingen af delene – fordi sitet ligger på hurtig LiteSpeed-hosting tæt på dit publikum med velkonfigureret server-cache – er der ikke meget tilbage at løse. Mål din TTFB først med TTFB-guiden: svarer origin allerede på et par hundrede millisekunder for dine besøgende, køber APO dig meget lidt.
Prisen pr. oktober 2026 er ifølge Cloudflares prisside 5 USD om måneden pr. domæne på gratis-planen, mens APO er inkluderet i Pro, Business og Enterprise. Er du allerede på en betalt plan, er spørgsmålet derfor ikke prisen, men om et ekstra cache-lag er værd at vedligeholde.
APO sammen med dit cache-plugin
APO erstatter ikke server-cachen – de arbejder i hver sit lag. Edge-cachen fyldes hurtigere og mere stabilt, når origin svarer fra server-cache, og de sider, der bypasser APO (kurv, checkout, indloggede), er stadig afhængige af en hurtig origin. Men optimeringerne må ikke dobbles: minificering, kritisk CSS og script-håndtering skal ske ét sted (typisk i FlyingPress eller LiteSpeed Cache), og Cloudflares tilsvarende funktioner – inklusive Rocket Loader – skal være slukket.
Bruger du LiteSpeed Cache, så bemærk desuden, at QUIC.cloud-CDN’et og APO løser samme opgave – vælg én edge-løsning til HTML; sammenligningen står i Cloudflare vs. QUIC.cloud-guiden. To edge-lag oven på hinanden giver flere steder, gammelt indhold kan hænge, uden at siden bliver mærkbart hurtigere.
Husk også purge-kæden: når du opdaterer en side, skal server-cachen ryddes først og edge-cachen bagefter. Ellers kan Cloudflare hente den gamle version fra server-cachen og cache den igen. Cloudflare-pluginnet og de fleste cache-plugins håndterer rækkefølgen selv, men opstår der gammelt indhold, er det her, du skal lede – se guiden til purge i Cloudflare.
Opsætning og WooCommerce
Før du ændrer noget: Mål TTFB på 3–5 vigtige sider (forside, kategori, produkt eller artikel) fra dit primære marked, og gem tallene. Uden en før-måling kan du ikke afgøre, om APO er pengene værd. Notér også, hvilke optimeringer der er slået til i Cloudflare og i dit cache-plugin.
1. Installér det officielle Cloudflare-plugin
APO kræver Cloudflares eget WordPress-plugin. Installér det, og forbind det til din zone med en API-token med de nødvendige rettigheder – ikke din globale API-nøgle. Tokenet bruges til automatisk purge, så forbindelsen skal være på plads, før APO slås til.
2. Aktivér APO
APO slås til for zonen i Cloudflare-dashboardet under hastighedsindstillingerne eller fra pluginnets indstillinger. Menuernes placering ændrer sig jævnligt, så søg efter “Automatic Platform Optimization”, hvis du ikke kan finde den. På gratis-planen skal tilkøbet aktiveres først.
3. Tjek indstillingerne for enhed og subdomæner
APO har en mulighed for at cache pr. enhedstype. Den er kun relevant, hvis dit tema sender forskellig HTML til mobil og desktop – et almindeligt responsivt tema har ikke brug for den, og den deler cachen op i flere kopier. Kører WordPress på et subdomæne, skal APO også være sat op til at dække det.
4. Sluk dobbelte optimeringer
Slå Rocket Loader og Cloudflares egne minificerings- og optimeringsfunktioner fra, hvis dit cache-plugin allerede gør arbejdet. Behold billedoptimering ét sted.
5. Test WooCommerce-flowet
På WooCommerce bypasser APO kurv-, checkout- og kontosider samt besøgende med varer i kurven, fordi WooCommerce sætter cookies, som APO genkender. Tjek det alligevel selv efter aktivering med et testkøb i et privat vindue: læg en vare i kurven, skift side, gå til checkout, og kontrollér at kurven og priserne er dine egne. Reglerne for, hvad der aldrig må caches, er de samme som i guiden om kunder, der ser hinandens kurv.
Typiske faldgruber
- Plugins, der sætter egne cookies for alle besøgende: Samtykke-, sprog- eller splittest-plugins kan sætte cookies på første besøg. Rammer en cookie APO’s bypass-liste, bliver alle sider forbigået, og du betaler for en cache, der aldrig rammer.
- Personligt indhold i HTML’en: Viser temaet “Hej, Mette” eller et kurvantal direkte i HTML’en for ikke-indloggede, bliver den første besøgendes version cachet for alle. Hent sådanne stumper via JavaScript i stedet.
- Ændringer uden purge: Ændrer du menuer, widgets eller indhold via et plugin, der ikke udløser WordPress’ normale hooks, purger pluginnet ikke nødvendigvis. Ryd så cachen manuelt for de berørte URL’er.
- Gammel cache efter flytning: Flytter du sitet til ny hosting, så ryd både server-cache og edge-cache, når DNS er skiftet.
Verifikation
APO er i drift, når svarene på gentagne anonyme besøg viser de tre headere, Cloudflare selv dokumenterer: cf-cache-status: HIT, cf-apo-via: tcache og cf-edge-cache: cache,platform=wordpress. Den sidste bekræfter, at pluginnet er installeret og aktivt. Test med en request, der ligner en browser:
curl -sI -H "accept: text/html" https://ditdomæne.dk/ | grep -iE "cf-cache-status|cf-apo-via|cf-edge-cache"Kør kommandoen to gange – første gang kan give MISS, mens cachen fyldes. Kontrollér derefter, at en indholdsopdatering er synlig inden for få sekunder (auto-purge virker), og at et testkøb viser bypass på kurv og checkout. Hvad de forskellige statusværdier betyder, står i guiden til CF-Cache-Status.
Døm derefter på tal: sammenlign TTFB før og efter fra dit primære marked – og fra et udenlandsk målepunkt, hvis I har kunder dér. Følg også feltdata i Core Web Vitals over de næste uger, da lab-målinger kun viser en enkelt request.
Hvornår du skal droppe APO igen
Ingen målbar forskel for jeres faktiske publikum betyder, at du kan opsige tilkøbet igen. Det er en helt fair konklusion. Det samme gælder, hvis APO giver flere problemer med gammelt indhold, end det sparer i svartid, eller hvis det meste af trafikken alligevel bypasser, fordi brugerne er logget ind. Slå APO fra i Cloudflare, ryd edge-cachen, og behold dit cache-plugin – sitet fungerer som før.
Læs også
- Hub: Cloudflare til WordPress
- Cloudflare vs. QUIC.cloud
- CF-Cache-Status forklaret
- Høj TTFB i WordPress
- Cloudflare Cache Rules til WooCommerce
- WordPress hosting hos Hostious – LiteSpeed, NVMe og servere i Europa
Ofte stillede spørgsmål om Cloudflare APO
Erstatter APO mit cache-plugin?
Nej. APO er edge-cache af HTML; server-cachen gør origin hurtig og fylder edge-cachen effektivt. Behold cache-pluginnet – men sluk dobbeltarbejde som minificering i begge lag.
Hvad koster APO?
Pr. oktober 2026 koster APO 5 USD om måneden pr. domæne på Cloudflares gratis-plan og er inkluderet i Pro, Business og Enterprise. Tjek den aktuelle pris hos Cloudflare, og mål værdien med en før/efter-måling, inden du binder dig.
Virker APO med WooCommerce?
Ja – APO genkender WooCommerce-cookies og bypasser kurv, checkout og indloggede kunder. Produktsider og kategorier caches, så katalogdelen bliver hurtigere; selve købsflowet er stadig origin-arbejde.
Hvordan ser jeg, om APO faktisk rammer?
Tjek svarheaderne på en anonym request: cf-cache-status: HIT, cf-apo-via: tcache og cf-edge-cache: cache,platform=wordpress betyder, at siden kom fra edge-cachen, og at pluginnet er aktivt. Mangler cf-edge-cache, er pluginnet ikke forbundet korrekt.
Udgivet 30. august 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026