Gå til indhold
SilktideHjælp

Sidehastighed og Core Web Vitals

Sidehastighed betyder i moderne søgepraksis at få sider til at føles hurtige: Hovedindholdet vises hurtigt, layoutet forbliver stabilt, og interaktioner reagerer uden forsinkelse. Googles offentlige navn for de tre feltmålinger, der indfanger denne oplevelse, er – Largest Contentful Paint (), Interaction to Next Paint () og Cumulative Layout Shift ().

På denne side antager vi, at Fernwood skal have sin prisside, sine sammenligningssider og sine vigtigste vejledninger over "god"-tærsklerne på mobil, hvor de fleste nye besøgende og mange klik henvist af AI-assistenten kommer fra.

Denne teknik er bevidst ikke en komplet teknisk manual. web.dev dækker allerede den dybdegående vejledning. Det følgende er beslutningsrammen: Hvad målingerne betyder, hvor meget de betyder, hvordan du prioriterer med Silktide, og hvor du kan sende udviklere hen for at få rettelser.

Hvorfor det virker (og hvor meget)

To målgrupper bekymrer sig om det:

  • Besøgende. Langsom LCP og ujævn CLS får dem til at forlade siden, før de ser svaret eller CTA'en. Det er et konverteringsproblem, selv når placeringerne er fine.
  • Søgning. Google oplyser, at Core Web Vitals bruges af rangordningssystemer som en del af sideoplevelsen, og anbefaler gode webmålinger for at få succes i Søgning (Understanding Core Web Vitals and Google search results; Understanding page experience). Google oplyser også, at Søgning fortsat søger at vise det mest relevante indhold, selv når sideoplevelsen er under niveau – så webmålinger er et reelt signal, ikke en magisk løftestang for rangordning. Betragt dem som et grundkrav og en afgørende faktor mellem ellers lignende sider, ikke som en erstatning for indhold med svaret først eller autoritet.

Specifikt for AEO: En hurtig side får ikke en AI-assistent til at citere dig. Men en langsom side, hvor layoutet flytter sig, mister stadig de mennesker, som disse citationer sender – og tung klientbaseret rendering, der skader hastigheden, skader ofte også indhold, der kan læses uden JavaScript.

De tre målinger, der betyder noget

Tærsklerne nedenfor er Googles "gode" mål, vurderet for rigtige brugere omkring den 75. percentil (feltdata). Labværktøjer diagnosticerer; feltdata er det, Søgning vurderer.

MålingHvad den målerGod
LCPHvornår hovedindholdet vises≤ 2,5 s
INPHvor hurtigt siden reagerer på klik/tryk≤ 200 ms
CLSHvor meget layoutet flytter sig under indlæsning≤ 0,1

Detaljer og fejlfindingsvejledninger: web.dev Vitals, Optimize LCP, Optimize INP, Optimize CLS.

Sådan arbejder du med problemet (Fernwoods rækkefølge)

1. Vælg de sider, der betyder noget

Forsøg ikke at løse alt på én gang. Start med:

  • Landingssider med høj trafik og forsiden
  • Sider, der skaber indtægt (priser, tilmelding, vigtige sammenligninger)
  • De centrale vejledninger og forskningssider, du ønsker citeret

Et middelmådigt blogarkiv kan vente. En langsom prisside kan ikke.

2. Adskil laboratoriediagnose fra feltsandhed

  • Lab (Silktide-hastighedstests, Lighthouse, WebPageTest): Gentagelige tests, gode til at finde årsager på en specifik URL og enhedsprofil.
  • Felt (Chrome UX Report / Search Console-rapporten Core Web Vitals, RUM såsom Analytics i Silktide, når det er tilgængeligt): Hvad rigtige besøgende oplevede.

De kan være uenige, uden at nogen af dem tager fejl – der er forskellige enheder, lande og cachetilstande. Ret labproblemer, der tydeligt svarer til fejl i feltdata; jagt ikke laboratorieperfektion på en URL, der allerede klarer felttærsklerne.

Silktides hastighedsskærm kombinerer laboratoriediagnostik med målinger fra rigtige besøgende, hvor Analytics er tilsluttet. Tjekket Web Vitals opsummerer laboratorieydelsen; Sider med langsom indlæsning og Layoutskift isolerer LCP og CLS.

3. Ret årsager, ikke scorer

Når Silktide (eller Lighthouse) peger på en årsag, skal du rette den årsag:

Almindelig årsagTypisk målingSilktide / næste trin
Meget stort hero-billede, langsom server, renderingsblokerende CSS/JSLCPSider med langsom indlæsning, Forudindlæs LCP-billede, tjek af billedoptimering
Billeder/annoncer/indlejringer uden reserveret plads; sene skrifttyperCLSLayoutskift, Angiv eksplicitte billedstørrelser
Lange JavaScript-opgaver ved klikINP / TBTReducer JavaScript-eksekveringstid, Eliminer renderingsblokerende ressourcer
For mange byte samlet setAlleGennemgå bytevægt, moderne billedformater, caching

Udviklere bør bruge web.dev-vejledningerne ovenfor til implementeringsdetaljer – frameworkspecificerede mønstre ændrer sig hurtigere, end denne side bør.

4. Test de samme URL'er igen

Efter en rettelse skal du køre labtests igen med den samme enhedsprofil og derefter vente på, at feltdata indhenter det (CrUX-vinduer strækker sig over flere uger). Vurder succes ud fra feltstatus for de vigtige URL'er, ikke ud fra et Lighthouse-skærmbillede kun af forsiden i et slide deck.

Ærlige begrænsninger

  • Indhold vinder stadig. En hurtig tom side taber til et langsommere, komplet svar. Hastighedsarbejde på svage sider er blot polering.
  • Tredjeparter. Tag managers, chatwidgets og A/B-værktøjer dominerer ofte INP og LCP. Afsæt politisk kapital til at fjerne eller udskyde dem; minificering af din egen CSS redder dig ikke fra en synkron tredjepartsbombe.
  • SPA / rendering kun på klienten. Hvis Fernwoods marketingsite leverer en tom skal, kæmper du muligvis både med webmålinger og læsbarhed for AI-crawlere. Foretræk SSR/SSG til offentligt indhold (Indhold, der kan læses uden JavaScript).
  • Teater med overoptimering. At barbere 20 ms af laboratorie-LCP på en URL, der allerede er grøn i feltdata, er sjældent den bedste anvendelse af en udviklers tid, mens sammenligningssider stadig mangler dokumentationsblokke.

Sådan hjælper Silktide

Relateret

Sidst opdateret

Var denne side nyttig?

Sidehastighed og Core Web Vitals | Silktide Hjælp