Slik sjekker du Core Web Vitals i AmICited

Raske, stabile sider betyr noe for AI-synlighet også — svarmotorer foretrekker kilder som laster raskt. Før du går løs på revisjonen i AmICited, hjelper det å forstå hva Core Web Vitals faktisk måler, og hvorfor et problem med sidehastighet stille og rolig kan bli et problem for AI-siteringer.

Hva er Core Web Vitals?

Core Web Vitals er et sett med standardiserte målinger Google har utviklet for å tallfeste den reelle sideopplevelsen : hvor raskt hovedinnholdet på en side vises, hvor raskt siden svarer på interaksjon, og hvor visuelt stabil den forblir mens den laster. De ble utformet for å erstatte vage inntrykk av at “nettstedet føles tregt” med tall du kan spore, sammenligne og holde utviklingsteam ansvarlige for. Google innlemmet dem i sine rangeringssignaler for flere år siden, og det samme underliggende datagrunnlaget — samlet inn fra reelle Chrome-brukere via Chrome UX Report (CrUX) — påvirker i stadig større grad hvilke kilder svarmotorer er villige til å hente, rendre og sitere.

De tre kjernemålingene er Largest Contentful Paint (LCP), Interaction to Next Paint (INP) og Cumulative Layout Shift (CLS), hver med en bestått/ikke-bestått-terskel som Google publiserer og oppdaterer med jevne mellomrom. To støttemålinger, First Contentful Paint (FCP) og Time to First Byte (TTFB), fullender bildet av sidehastighet ved å isolere hvor raskt serveren svarer og hvor raskt noe som helst vises på skjermen, selv før hovedinnholdet er klart. Fordi CrUX er bygget på anonymiserte felt-data — faktiske besøk fra faktiske Chrome-brukere — reflekterer tallene reelle forhold (enhetsmiks, nettverkskvalitet, geografi) i stedet for en enkelt labtest kjørt på en rask kontorforbindelse.

Hvorfor betyr dette noe spesifikt for generative engine optimization ? AI-crawlere og gjenfinningssystemene bak AI Overviews, ChatGPT-søk og Perplexity må hente og tolke siden din før de kan sitere den. En side som tidsavbrytes, laster tregt eller flytter på innhold mens den laster, er dyrere å crawle i stor skala og mindre pålitelig å hente rent innhold fra. Særlig treg TTFB kan føre til at en crawler gir opp henting før hovedinnholdet ditt i det hele tatt kommer frem. Ingenting av dette er den avgjørende faktoren for om du blir sitert — innholdets relevans, autoritet og struktur betyr langt mer — men en kronisk treg eller ustabil hjemmeside er en friksjon svarmotorer ikke har noen grunn til å tolerere når en raskere konkurrent tilbyr den samme informasjonen.

Dette er også et område hvor teknisk SEO og answer engine optimization overlapper nesten fullstendig: de samme tekniske forbedringene som styrker Google-rangeringene dine — bildestørrelse, serverresponstid, layoutstabilitet — er de som holder sidene dine tilgjengelige og siterbare for AI-systemer. Dette overlappet er nøyaktig hvorfor AmICited viser Core Web Vitals som en del av en bredere AI-synlighetsrevisjon i stedet for som et frittstående SEO-verktøy: det er én av flere faktorer som avgjør om AI-motorer opplever nettstedet ditt som pålitelig og enkelt å jobbe med.

Hvor du finner det

Åpne Audit → Web Vitals fra venstremenyen. Siden forklarer det slik: “Core Web Vitals for domenets hjemmeside… sidehastighet er en Google-rangeringsfaktor og AI-svarmotorer foretrekker raskt lastende sider.” AmICited henter disse dataene automatisk for domenet du sporer og for hver konkurrent du overvåker, slik at du slipper å bruke et separat verktøy eller lime inn URL-er manuelt — det er det samme konkurrentsettet du allerede bruker til å spore share of voice og siteringsrangering andre steder i plattformen.

Fordi CrUX krever et minimumsvolum av reell Chrome-trafikk før det kan publisere stabile tall for en URL, vil domener med lav trafikk — inkludert mange B2B- og nisjenettsteder — noen ganger vise tomme verdier i en periode. Det er forventet oppførsel, ikke en feil: det betyr at Google ennå ikke har samlet nok feltdata til å rapportere med sikkerhet, og verdiene fylles ut etter hvert som trafikk (eller tid) tilkommer.

Hva målingene betyr

Konkurrentsammenligningstabellen viser hvert domene med:

• Score — en samlet Core Web Vitals bestått/ikke-bestått-oppsummering, som gir deg et raskt overblikk over om et domene klarer Googles terskler over hele linjen.
• LCP (Largest Contentful Paint) — hvor raskt hovedinnholdet laster, som regel det største bildet eller tekstblokken i den synlige delen av skjermen. Dette er målingen som er mest direkte knyttet til en besøkendes — eller en crawlers — opplevelse av “er denne siden klar ennå”.
• INP (Interaction to Next Paint) — hvor responsiv siden føles når en bruker faktisk samhandler med den (klikker, trykker, skriver). Den erstattet den eldre First Input Delay-målingen fordi den fanger opp responsivitet gjennom hele sidebesøket, ikke bare ved den første interaksjonen.
• CLS (Cumulative Layout Shift) — hvor visuelt stabil siden er mens den laster. Høy CLS betyr at elementer hopper rundt etter hvert som bilder, annonser eller skrifttyper lastes inn, noe som er forstyrrende for besøkende og kan gjøre det vanskeligere for automatiserte systemer å tolke innholdet konsekvent.
• FCP (First Contentful Paint) — hvor raskt noe som helst først vises på skjermen, selv før hovedinnholdet er klart. Det er et tidlig signal på at siden faktisk laster, i stedet for å vise en blank skjerm.
• TTFB (Time to First Byte) — serverens responshastighet: tiden mellom forespørselen om siden og mottak av den første byten. Dette er nesten utelukkende en backend-/infrastrukturmåling, og ofte den enkleste å fikse med endringer i hosting, caching eller CDN.

Ditt eget domene er merket Du, med dine sporede konkurrenters hjemmesider under, slik at hver måling umiddelbart blir sammenlignet i stedet for vurdert isolert.

Slik bruker du det

1. Sammenlign med konkurrenter. Hvis konkurrentenes sider er raskere, er det nok et fortrinn de har både i søk og AI-svar — og et gap som er billig å lukke sammenlignet med arbeid med innhold eller autoritet.
2. Fiks de røde. En mislykket LCP eller CLS peker på konkret teknisk arbeid: overdimensjonerte hero-bilder, manglende bredde/høyde-attributter, render-blokkerende skript eller uoptimaliserte webfonter er de vanlige syndebukkene.
3. Prioriter TTFB hvis den er treg. Fordi den ligger oppstrøms for alle andre målinger, drar en treg TTFB også ned LCP, og det er ofte den raskeste målingen å forbedre — gjerne gjennom caching, en CDN eller en hostingoppgradering fremfor en omskriving av innhold.
4. Sjekk på nytt etter endringer. Etter hvert som feltdata oppdateres, kom tilbake for å bekrefte at forbedringene har slått inn. CrUX-data er et rullerende 28-dagers vindu, så endringer tar tid å vise seg — ikke forvent at tallene beveger seg dagen etter en utrulling.
5. Behandle TTFB som et tidlig varselsignal. En server som jevnlig bruker over ett sekund på å returnere den første byten, er en sterk kandidat for crawl- og renderingsproblemer som strekker seg langt utover denne ene revisjonen — det er verdt å lese om hvorfor crawler-ingeniører i økende grad behandler rask TTFB som en terskel for pålitelig suksess med AI-crawlere fremfor noe man bare kan ha godt av.

Ingen av disse fire målingene fungerer isolert fra resten av det tekniske fotavtrykket ditt. En hjemmeside som scorer bra på Core Web Vitals, men blokkerer AI-crawlere i robots.txt, eller serverer en stort sett tom side til klienter uten JavaScript, blir fortsatt ikke sitert — hastighet hjelper først når en crawler faktisk slipper inn og kan tolke det som finnes der. Derfor er det verdt å behandle denne revisjonen som ett sjekkpunkt i en bredere rutine snarere enn en engangsfiks: kjør den sammen med de andre AmICited-revisjonene dine med jevne mellomrom, på samme måte som du periodisk bør gå gjennom en bredere teknisk sjekkliste som dekker crawlbarhet, strukturerte data og hvor lett innholdet lar seg hente ut.

Web Vitals vinner ikke siteringer alene, men trege, ustabile sider kan holde deg tilbake — denne revisjonen forteller deg hvor du står sammenlignet med nettstedene AI-motorene velger mellom. Hvis du vil ha den dypere forskningen bak anbefalingen, kan du lese om hvorvidt sidehastighet faktisk påvirker AI-søkesynlighet , og kombinere denne sjekken med en bredere AI-tilgjengelighetsrevisjon av nettstedet ditt for å dekke crawlbarhets-siden av ligningen. Derfra er det naturlige neste steget å innlemme Web Vitals i din faste overvåkingsrutine sammen med AmICiteds AI-rangeringssporing og siteringssporing, slik at en ytelsesregresjon fanges opp samtidig som du ville lagt merke til en nedgang i omtaler — i stedet for å bli oppdaget separat, uker senere, når den allerede har kostet deg synlighet.