Varm din website-cache op på Mac: Mål kold vs. cachet svartid

Driver du et website – WordPress, TYPO3, Drupal, Shopify eller et andet CMS – har du sikkert bemærket, at det første besøg efter en tømning af cachen eller en deploy føles pinefuldt langsomt, mens alle efterfølgende besøg er hurtige. Det er din cache, der gør sit arbejde. Spørgsmålet er: Hvad sker der med den besøgende, der kommer først?

I de fleste opsætninger betaler den besøgende den fulde pris. Vedkommende venter på, at serveren renderer siden fra bunden, spørger databasen, kører hvert eneste plugin og først derefter sender et svar. Den anden besøgende, som nu får siden fra cachen, får den hurtige version. Cache warming lukker det hul ved at lade som om, den er den første besøgende – på hver eneste side – så de rigtige brugere slipper.

Dette indlæg gennemgår, hvad cache warming faktisk gør, hvorfor naive tilgange som wget --recursive ikke slår til, og hvordan du måler, om din cache virker. Til sidst ser vi på et native macOS-værktøj, der er bygget specifikt til formålet.

Hvad er cache warming egentlig?

En cache warmer er en crawler med en snæver opgave: at besøge alle URL’er på dit website, så serveren gemmer det renderede svar i cachen. Næste gang en rigtig bruger beder om siden, leveres den fra cachen – fra Nginx FastCGI, Varnish, LiteSpeed, Redis, et WordPress-plugin som WP Rocket eller W3 Total Cache eller en CDN-edge-node som Cloudflare eller Fastly.

En god cache warmer gør tre ting:

1. Udløser cachegenerering på hver side (det kolde gennemløb).
2. Kontrollerer, at cachen faktisk bliver fyldt op og brugt (det varme gennemløb).
3. Måler forskellen, så du ved, at din cachekonfiguration virker.

Det tredje punkt er dér, hvor de fleste værktøjer kommer til kort. Masser af scripts kan crawle et website. Meget få fortæller dig, om crawlet gjorde noget nyttigt.

Hvornår cache warming betyder noget

Du behøver ikke altid at varme din cache op. For en lille blog med stabil trafik og lang TTL i cachen varmer dagens første besøgende siden op helt naturligt. Men der er situationer, hvor opvarmning ikke er valgfri:

• Efter en deploy. De fleste cache-backends ugyldiggør posterne, når applikationen ændres. Det første besøg på hver side efter en deploy er en kold rendering. Har du 500 produktsider og deployer to gange om dagen, er det 1.000 langsomme førstebesøg om dagen – mange af dem fra bots, crawlere eller marketinglinks.
• Efter en tømning af cachen. Planlagte tømninger (natlige rydninger, genindlæsning af konfiguration, indholdsimport) sletter hele cachen. Uden opvarmning bliver den næste times trafik et stormløb mod din origin-server.
• Med kort TTL. Udløber din cache hvert 15. minut, er hver side uden cache 96 gange om dagen. Opvarmning holder alt konstant varmt.
• For SEO og Core Web Vitals. Googlebot straffer langsomme første svar. Hvis Googlebot tilfældigvis crawler en kold side, lider dine LCP- og TTFB-værdier – og botten kommer ikke tilbage fem minutter senere for at se den hurtige version.
• Ved annoncekampagner og store e-mailudsendelser. Når du sender 50.000 nyhedsbrevsmodtagere til en landingsside på samme tid, vil du ikke have, at de første 500 besøgende får serveren i knæ, før cachen er fyldt.

Derfor er wget --mirror ikke nok

Den klassiske udviklerrefleks er at gribe til wget eller curl i en løkke:

wget --recursive --no-directories --delete-after https://example.com

Det virker sådan set. Det besøger siderne, hvilket udløser rendering, hvilket fylder cachen op. Men det giver dig nul indsigt i, hvad der skete. Du kan ikke svare på nogen af de spørgsmål, der betyder noget:

• Slog cachen faktisk til? Måske sætter din Cache-Control: no-cache-header i det stille hele opsætningen ud af spil.
• Leverer Cloudflare fra edge, eller sender den hver gang videre til origin? CF-Cache-Status-headeren ved det, men wget viser dig det ikke.
• Hvor meget hurtigere er et cachet svar end et koldt? Er det 80 ms mod 2.000 ms (fremragende) eller 800 ms mod 900 ms (din cache gør næsten ingenting)?
• Hvilke sider mangler i sitemappet? Hvilke returnerer 404? Hvilke har cache-headers, der aldrig vil lade dem blive cachet?

wget dumper HTML’en og går videre. Du skal selv gennemgå logs, tilføje --server-response, sende det gennem awk, og når du endelig har en brugbar rapport, har du genopfundet et halvt værktøj til cacheanalyse.

Hvad en god cache warmer måler

Den egentlige opgave er ikke bare at besøge sider. Det er at kunne svare på disse spørgsmål efter en kørsel:

• Cache hit rate. Hvor mange af N sider blev leveret fra cachen i det andet gennemløb?
• Kold vs. varm svartid. Hvad var svartiden ved første besøg i forhold til andet besøg for hver URL?
• Forbedring i procent. Hvor meget hurtigere svarede de cachede sider i gennemsnit?
• Oversigt over cache-headers. Hvilke sider sender Cache-Control: public, max-age=..., hvilke sender no-store, hvilke returnerer X-Cache: HIT eller CF-Cache-Status: DYNAMIC? Det viser dig med ét blik, hvor din konfiguration er i stykker.
• Fejl. Hvilke URL’er giver 404? Hvilke får timeout? Hvilke returnerer 500 under crawlbelastning?

Uden det varmer du op i blinde. Du kører måske et cronjob hver time, der belaster din origin-server uden at fylde en eneste post i cachen – og det ville du ikke vide.

Find cachen bag kulisserne

Moderne websites kører på en stak af caches. Et typisk WordPress-website hos en administreret hostingudbyder kan have:

• Cloudflare i kanten (CF-Cache-Status, Age)
• LiteSpeed- eller Nginx FastCGI-cache på webserveren (X-LiteSpeed-Cache, X-Cache)
• Varnish foran applikationen (X-Varnish, Age)
• WP Rocket eller W3 Total Cache inde i WordPress (HTML-kommentarer, egne headers)
• Objektcache (Redis, Memcached) til databaseforespørgsler – usynlig i HTTP-headerne

Når en side er langsom, betyder det noget at vide, hvilket lag der ikke ramte. Er Cloudflare HIT, men svartiden stadig 800 ms, er dit problem, at Cloudflare leverer et forældet, men langsomt cachet svar. Er Cloudflare MISS, men LiteSpeed HIT, er din edge-konfiguration forkert. En cache warmer, der undersøger svar-headerne, giver dig et overblik lag for lag.

På samme måde betyder det noget at kende dit CMS. WordPress, TYPO3, Drupal, Shopify, Magento, Ghost og statiske sitegeneratorer har hver deres konventioner for caching. En warmer, der genkender dit CMS, kan vise relevante standardindstillinger og tips om plugins – wp-super-cache opfører sig anderledes end Drupal med Varnish, som igen opfører sig anderledes end et statisk eksporteret Hugo-website.

Find sider via sitemap – gå ikke glip af halvdelen

Link-crawling alene overser sider, der ikke er linket fra forsiden. Forældreløse landingssider, arkiverede blogindlæg, produktvarianter, paginerede arkiver, tag-sider – de står i sitemappet, men ikke i hovednavigationen. Crawler du ikke sitemappet, forbliver de sider kolde, og det er ofte netop dem, der får organisk søgetrafik.

En ordentlig warmer henter robots.txt, læser Sitemap:-direktiverne og gennemgår hele sitemap-træet – inklusive sitemap-indekser, der henviser til flere underordnede sitemaps. Kombineret med link-crawling dækker det både de strukturelle sider og long tail-indholdet.

Den native macOS-løsning: WebCacheWarmer

Vil du have alt det uden selv at sætte det sammen, er det præcis, hvad WebCacheWarmer er bygget til. Det er en native macOS-app, der kører et crawl i to gennemløb:

• Gennemløb 1 (koldt): besøg alle fundne URL’er, udløs cachegenerering, og mål den kolde svartid.
• Gennemløb 2 (varmt): besøg hver URL igen, mål den cachede svartid, og beregn forbedringen.

Til sidst får du en klar rapport: crawlede sider, fejl, gennemsnitlig kold tid, gennemsnitlig varm tid, forbedring i procent og cache hit rate. Du kan se præcis, hvilke sider der bliver cachet, og hvilke der ikke gør – og inspektøren for cache-headers viser hvorfor.

Et par detaljer, der betyder noget i den daglige brug:

• Find sitemaps via robots.txt, med indbygget fremviser og eksport til XML.
• Genkendelse af CMS for WordPress, Drupal, Shopify, TYPO3, Magento, Joomla, Wix, Squarespace, Ghost, Hugo, Jekyll og flere.
• Analyse af cache-headers på tværs af Cache-Control, X-Cache, CF-Cache-Status, Age, ETag, Varnish- og LiteSpeed-headers.
• Eksport til CSV, Excel eller JSON med alle header-detaljer, så du kan følge cachens tilstand over tid eller give en rapport til din hostingudbyder.
• Indbygget download af statiske websites, med genoptagelse, inkrementel tilstand og lokal forhåndsvisning – nyttigt til at arkivere et website før en migrering.
• Planlagte nye crawls med intervaller på 1, 4, 12 eller 24 timer, så sider med meget trafik konstant holdes varme.
• Overholdelse af robots.txt med longest-path-match-semantik, så du ikke crawler stier, du ikke bør.

Alt kører lokalt på din Mac. Der sendes ingen data nogen steder hen, bortset fra HTTP-forespørgslerne til det website, du varmer op – hvilket betyder noget, når du crawler testmiljøer med adgangsbeskyttet indhold.

En typisk arbejdsgang

1. Efter en deploy kører du WebCacheWarmer mod din produktions-URL. Tjek cache hit rate i det varme gennemløb – over 90 % er sundt, under 50 % betyder, at noget er forkert konfigureret.
2. Undersøg cache-headerne for de sider, der stadig var kolde i det varme gennemløb. Som regel er det en af tre ting: en manglende Cache-Control-header, en cookie, der sætter cachen ud af spil, eller en URL-parameter, som cachen behandler som unik.
3. Eksporter resultaterne til CSV, hvis du skal dele dem med et bureau, en hostingudbyder eller en kollega, der vil se de rå tal.
4. Planlæg et nyt crawl med få timers mellemrum, hvis din TTL er kort. Så holder warmeren de varme sider varme uden manuel indgriben.

Konklusionen

Cache warming er en af de driftsvaner, der betaler sig med det samme, men som sjældent bliver talt om. Er dine svartider ved første besøg langsomme og din cache hit rate middelmådig, lukker en opvarmning efter hver deploy hullet – og de rigtige brugere får den hurtige version, som din cache skulle have leveret fra starten.

Det er målingerne, der gør det umagen værd. En cache, du ikke har målt, er en cache, du gætter på. WebCacheWarmer giver dig tallene, live, i en native Mac-app, der respekterer din tid og dine data.

Sætter du pris på friktionsfri Mac-værktøjer, der gør én ting godt, følger Konverter CSV til Excel på Mac samme filosofi for arbejdet med regneark.