Hopp til innhold
SilktideHjelp

Sidehastighet og Core Web Vitals

Sidehastighet, i moderne søkepraksis, betyr å få sider til å føles raske: Hovedinnholdet vises raskt, oppsettet forblir stabilt, og interaksjoner svarer uten forsinkelse. Googles offentlige navn på de tre feltmålingene som fanger denne opplevelsen, er – Largest Contentful Paint (), Interaction to Next Paint () og Cumulative Layout Shift ().

På denne siden antar vi at Fernwood trenger at prissiden, sammenligningssidene og de viktigste veiledningene oppfyller tersklene for «bra» på mobil – der de fleste nye besøkende og mange klikk henvist fra assistenter kommer fra.

Denne teknikken er med hensikt ikke en komplett teknisk håndbok. web.dev dekker allerede de detaljerte fremgangsmåtene. Det som følger, er rammeverket for beslutninger: hva målingene betyr, hvor mye de betyr, hvordan du prioriterer med Silktide, og hvor du kan sende utviklere for å rette opp problemer.

Hvorfor det fungerer (og hvor mye det betyr)

To målgrupper bryr seg:

  • Besøkende. Treg LCP og hakkete CLS fører til at brukere forlater siden før de ser svaret eller handlingsoppfordringen. Det er et konverteringsproblem, selv når rangeringene er gode.
  • Søk. Google oppgir at Core Web Vitals brukes av rangeringssystemene som en del av sideopplevelsen, og anbefaler gode målinger for å lykkes i Søk (Understanding Core Web Vitals and Google search results; Understanding page experience). Google oppgir også at Søk fortsatt prøver å vise det mest relevante innholdet selv når sideopplevelsen er under pari – derfor er målingene et reelt signal, ikke en magisk spak for rangering. Behandle dem som et grunnkrav og en utslagsfaktor mellom ellers lignende sider, ikke som en erstatning for innhold som svarer først eller autoritet.

Spesielt for AEO: En rask side får ikke en assistent til å sitere deg. Men en treg side med oppsett som flytter på seg, mister fortsatt menneskene som disse sitatene sender – og tung klientbasert gjengivelse som skader hastigheten, skader ofte også innhold som er lesbart uten JavaScript.

De tre målingene som betyr noe

Tersklene nedenfor er Googles mål for «bra», vurdert for ekte brukere omtrent ved 75. persentil (feltdata). Laboratorieverktøy brukes til diagnostikk; feltdata er det Søk vurderer.

MålingHva den målerBra
LCPNår hovedinnholdet vises≤ 2,5 s
INPHvor raskt siden svarer på klikk/trykk≤ 200 ms
CLSHvor mye oppsettet hopper under innlasting≤ 0,1

Detaljer og veiledninger for feilsøking: web.dev Vitals, Optimize LCP, Optimize INP, Optimize CLS.

Slik arbeider du med problemet (Fernwoods rekkefølge)

1. Velg sidene som betyr noe

Ikke prøv å løse alt på én gang. Begynn med:

  • Landingssider med høy trafikk og forsiden
  • Sider som genererer inntekter (priser, registrering, viktige sammenligninger)
  • Hovedveiledningene og forskningssidene du vil at andre skal sitere

Et middelmådig blogarkiv kan vente. En treg prisside kan ikke det.

2. Skill mellom laboratoriediagnose og feltsannhet

  • Laboratorium (Silktides hastighetstester, Lighthouse, WebPageTest): repeterbart og godt for å finne årsaker på en bestemt URL og enhetsprofil.
  • Felt (Chrome UX Report / Search Console-rapporten om Core Web Vitals, RUM som Analytics i Silktide, når det er tilgjengelig): det faktiske besøkende opplevde.

De kan være uenige uten at noen av dem tar feil – det er forskjellige enheter, land og hurtigbufferstatuser. Løs laboratorieproblemer som tydelig samsvarer med feil i feltdata; ikke jag laboratorieperfeksjon på en URL som allerede oppfyller felttersklene.

Silktides Hastighetsside kombinerer laboratoriediagnostikk med målinger fra ekte besøkende når Analytics er tilkoblet. Kontrollen Web Vitals oppsummerer laboratorieytelsen; Sider med treg innlasting og Oppsettsforskyvninger isolerer LCP og CLS.

3. Løs årsakene, ikke poengsummene

Når Silktide (eller Lighthouse) peker på en årsak, løser du den årsaken:

Vanlig årsakTypisk målingSilktide / neste steg
Svært stort heltebilde, treg server, CSS/JS som blokkerer gjengivelseLCPSider med treg innlasting, Forhåndslast LCP-bilde, kontroller for bildeoptimalisering
Bilder/annonser/innbygginger uten reservert plass; sene skrifttyperCLSOppsettsforskyvninger, Angi eksplisitte bildestørrelser
Lange JavaScript-oppgaver ved klikkINP / TBTReduser kjøringstiden for JavaScript, Fjern ressurser som blokkerer gjengivelse
For mange byte totaltAlleGå gjennom bytevekten, moderne bildeformater, hurtigbufring

Utviklere bør bruke veiledningene på web.dev som er lenket til ovenfor, for detaljer om implementering – rammeverksspesifikke mønstre endrer seg raskere enn denne siden bør gjøre.

4. Test de samme URL-ene på nytt

Etter en retting kjører du laboratorietester på nytt med den samme enhetsprofilen, og venter deretter på at feltdataene skal oppdateres (CrUX-vinduer går over flere uker). Vurder resultatet ut fra feltstatusen for de viktige URL-ene, ikke ut fra et Lighthouse-skjermbilde av bare forsiden i en presentasjon.

Ærlige begrensninger

  • Innhold vinner fortsatt. En rask, tom side taper mot et langsommere, fullstendig svar. Hastighetsarbeid på svake sider er bare finpuss.
  • Tredjeparter. Taggadministratorer, chatwidgeter og A/B-verktøy dominerer ofte INP og LCP. Sett av politisk kapital til å fjerne eller utsette dem; minifisering av egen CSS redder deg ikke fra en synkron tredjepartsbombe.
  • SPA / kun klientbasert gjengivelse. Hvis Fernwoods markedsføringsnettsted leverer et tomt skall, kan dere kjempe mot både målinger og lesbarhet for AI-crawlere. Foretrekk SSR/SSG for offentlig innhold (Innhold som er lesbart uten JavaScript).
  • Teater rundt overoptimalisering. Å redusere laboratorie-LCP med 20 ms på en URL som allerede har grønne feltdata, er sjelden den beste bruken av en utvikler når sammenligningssider fortsatt mangler bevisblokker.

Slik hjelper Silktide

Relatert

Sist oppdatert

Var denne siden nyttig?