Mennesker venter irriteret på en langsom side. Agenter venter ikke: de arbejder med korte timeouts, dropper langsomme kilder og vælger den næste på listen. Hastighed er dermed gået fra at være en UX-faktor til at være en API-kontrakt — overholder din server den ikke, bliver du valgt fra, uden at nogen nogensinde fortæller dig det.
Googles Core Web Vitals satte i sin tid tal på brugeroplevelsen: LCP (largest contentful paint) under 2,5 sekunder, INP (interaction to next paint) under 200 millisekunder og CLS (cumulative layout shift) under 0,1. De tærskler gælder stadig i klassisk ranking — men agent-æraen flytter vægten mellem dem og tilføjer nye krav, som denne artikel gennemgår.
- Agenter måler først og fremmest TTFB (time to first byte) — hvor hurtigt serveren svarer, ikke hvor pænt siden animerer.
- Komplet HTML i første svar slår rendering-optimering: en side, der skal samles klientside, er dyrere at bruge.
- Stabilitet under last tæller: agent-trafik kommer i bursts, og en 504 under et crawl-burst koster citater.
Hvorfor flytter prioriteringen sig?
Core Web Vitals blev designet til at måle menneskers oplevelse: hvornår kan jeg se indholdet (LCP), hvor hurtigt reagerer siden (INP), og hopper layoutet rundt (CLS)? En agent har ingen af de bekymringer. Den ser aldrig layoutet, klikker sjældent, og oplever ikke animationer. Dens omkostning er ventetid på serverens svar og arbejdet med at udtrække indholdet af det, der kommer tilbage.
Derfor rykker tre andre egenskaber frem i køen. TTFB bliver det vigtigste enkelttal: en agent med to sekunders budget til fem kilder kan ikke bruge 1,8 sekund på at vente på din server. Rå HTML-læsbarhed bliver næstvigtigst: en side, der er komplet i første svar, er billigere at bruge end en, der skal renderes færdig — sammenhængen med JavaScript er udfoldet i JavaScript-guiden. Og stabilitet under last bliver tredje krav, for agent-trafik opfører sig anderledes end menneskelig trafik: den kommer i bursts, hvor mange sider hentes på kort tid.
Hvad betyder “stabilitet under last” konkret?
En server, der svarer 200 på ét sekund klokken tre om natten, men kaster 504-fejl under et crawl-burst, taber synlighed på to måder. Den mister de sider, der fejlede i situationen — og den lærer crawleren, at kilden er upålidelig, hvilket sænker genbesøgsfrekvensen. Fejlkoder under last er med andre ord ikke bare tabt trafik; de er et signal, der forringer din fremtidige crawl-prioritet.
Overvåg derfor ikke kun gennemsnitstider, men fejlrater pr. user-agent i dine access-logs. Et mønster af 5xx-svar til GPTBot eller PerplexityBot i bestemte tidsrum er et konkret, udbedringsværdigt synlighedsproblem — se metoden i log-casen.
Fejlkoder under last er ikke bare tabt trafik — de sænker din fremtidige crawl-prioritet.
De tre billigste forbedringer
Rækkefølgen herunder er sorteret efter effekt pr. arbejdstime for et typisk indholdssite. De fleste kan gennemføre alle tre på en dag.
- Server-side cachingLiteSpeed, Varnish eller tilsvarende cache foran WordPress/CMS’et bringer TTFB fra hundredvis af millisekunder ned på tocifrede. Husk korrekte undtagelser: API-ruter og fejlsvar må aldrig caches — en cachet fejlside kan forgifte crawlernes billede af sitet længe efter, problemet er løst.
- CDN foran originEt CDN forkorter vejen for både brugere og crawlere og absorberer bursts, før de rammer serveren. Konfigurér det til at cache HTML, ikke kun statiske filer, hvor indholdet tillader det.
- Slank kritisk HTMLKerneindholdet først i dokumentet, tredjepartsscripts udskudt eller fjernet. Hvert marketing-script i
<head>er en afgift, alle betaler — mennesker, Googlebot og agenter.
Glem ikke det klassiske fundament
Core Web Vitals tæller fortsat i klassisk Google-ranking, og klassisk ranking er fortsat fundamentet under AI-synlighed — AI Overviews bygger på Googles indeks, og flere AI-systemer bruger søgeresultater som kildeliste. Hastighedsarbejdet betaler sig altså i alle tre lag af AgenticSEO-pyramiden på én gang: bedre placeringer, flere hentede sider og flere gennemførte agent-opgaver. Få optimeringer i marketing har så bred en effekt.
Sådan måler du TTFB i praksis
Det enkleste værktøj er curl med tidsvariabler: curl -o /dev/null -s -w "%{time_starttransfer}n" https://ditdomæne.dk/ viser tiden til første byte direkte i terminalen. Mål tre ting rigtigt: flere lokationer (agenternes datacentre står i USA og Europa, ikke i København — brug et eksternt måleværktøj eller en VPS i udlandet som supplement), både cachet og ucachet (første kald efter en cache-purge viser den TTFB, crawlere møder på sider uden for cachen), og percentiler frem for gennemsnit — det er de langsomme 10 % af svarene, der rammer timeouts, ikke gennemsnittet.
Sæt derefter overvågning på: en simpel uptime-tjeneste med svartidsalarm fanger de forringelser, der ellers først opdages, når citaterne udebliver. Grænseværdien fra tommelfingerreglen — alarm ved vedvarende TTFB over 500 millisekunder — er et fornuftigt udgangspunkt for indholdssites.
Ofte stillede spørgsmål
Hvad er en god TTFB for AI-crawlere?
Der findes ingen offentliggjort tærskel fra AI-udbyderne. Tommelfingerreglen fra klassisk SEO holder: under 200 millisekunder er godt, under 500 acceptabelt, og over ét sekund er du i farezonen for timeouts hos utålmodige klienter. Mål fra flere geografiske punkter — agenternes datacentre står sjældent i København.
Skal jeg rate-limite AI-crawlere for at beskytte serveren?
Hellere skalere end blokere. Aggressiv rate-limiting giver 429-svar, der ligner ustabilitet og sænker crawl-prioriteten. Kan serveren ikke følge med, er cache og CDN den rigtige løsning — og i yderste tilfælde en crawl-delay-aftale frem for hårde afvisninger.
Betyder INP og CLS så ingenting længere?
De betyder fortsat noget for mennesker og for klassisk ranking — og menneskers adfærdssignaler påvirker stadig din samlede synlighed. Pointen er prioritering: har du begrænset tid, flytter TTFB og komplet HTML mere i AI-søgning end en CLS-forbedring fra 0,08 til 0,05.
Senest revideret 31. august 2026. Artiklen gennemgås løbende, når AI-søgelandskabet flytter sig.