Hoppa till innehåll
SilktideHjälp

Sidhastighet och Core Web Vitals

Sidhastighet innebär i modern sökpraxis att få sidor att kännas snabba: huvudinnehållet visas snabbt, layouten förblir stabil och interaktioner svarar utan fördröjning. Googles offentliga namn på de tre fältmått som fångar den känslan är – Largest Contentful Paint (), Interaction to Next Paint () och Cumulative Layout Shift ().

På hela den här sidan utgår vi från att Fernwood behöver få sin prissida, sina jämförelsesidor och sina främsta guider över gränsvärdena för ”bra” på mobila enheter – där de flesta nya besökare och många klick som hänvisats från AI-assistenter kommer från.

Den här tekniken är medvetet inte en fullständig teknisk handbok. web.dev har redan de djupgående instruktionerna. Här följer beslutsramen: vad måtten innebär, hur mycket de spelar roll, hur du prioriterar med Silktide och vart du ska hänvisa utvecklare för åtgärder.

Varför det fungerar (och hur mycket det spelar roll)

Två målgrupper bryr sig:

  • Besökare. Långsam LCP och ryckig CLS gör att besökare lämnar sidan innan de ser svaret eller uppmaningen till handling. Det är ett konverteringsproblem även när rankningen är bra.
  • Sökning. Google anger att Core Web Vitals används av rankningssystem som en del av sidupplevelsen och rekommenderar bra värden för att lyckas i Google Sök (Understanding Core Web Vitals and Google search results; Understanding page experience). Google anger också att Sök fortfarande försöker visa det mest relevanta innehållet även när sidupplevelsen är undermålig – så dessa värden är en verklig signal, inte en magisk rankningsspak. Se dem som grundkrav och en utslagsgivare mellan i övrigt liknande sidor, inte som en ersättning för innehåll där svaret kommer först eller auktoritet.

För AEO specifikt: en snabb sida får inte en AI-assistent att citera dig. Men en långsam sida med layoutförskjutningar förlorar fortfarande de människor som dessa citeringar skickar dit – och tung rendering på klientsidan som försämrar hastigheten försämrar ofta också innehåll som kan läsas utan JavaScript.

De tre mått som spelar roll

Gränsvärdena nedan är Googles mål för ”bra”, utvärderade för verkliga användare vid ungefär den 75:e percentilen (fältdata). Labverktyg diagnostiserar; fältdata är det som Sök bedömer.

MåttVad det mäterBra
LCPNär huvudinnehållet visas≤ 2,5 s
INPHur snabbt sidan svarar på klick/tryck≤ 200 ms
CLSHur mycket layouten hoppar under inläsning≤ 0,1

Information och felsökningsguider: web.dev Vitals, Optimize LCP, Optimize INP, Optimize CLS.

Så arbetar du med problemet (Fernwoods arbetsordning)

1. Välj de sidor som spelar roll

Försök inte göra allt på en gång. Börja med:

  • Landningssidor med hög trafik och startsidan
  • Intäktssidor (prissättning, registrering, viktiga jämförelser)
  • De huvudguider och forskningssidor som du vill ska citeras

Ett mediokert bloggarkiv kan vänta. En långsam prissida kan inte det.

2. Separera labbdiagnos från verkligheten i fältdata

  • Labb (Silktides hastighetstester, Lighthouse, WebPageTest): repeterbara tester som är bra för att hitta orsaker på en specifik URL och enhetsprofil.
  • Fält (Chrome UX Report / Search Console-rapporten Core Web Vitals, RUM som Analytics i Silktide när det är tillgängligt): vad verkliga besökare upplevde.

De kan skilja sig åt utan att någon av dem har fel – enheter, länder och cachetillstånd skiljer sig. Åtgärda labbproblem som tydligt motsvarar fel i fältdata; jaga inte perfekta labbresultat för en URL som redan klarar gränsvärdena i fältdata.

Silktides hastighetsskärm kombinerar labbdiagnostik med mätningar från verkliga besökare där Analytics är anslutet. Kontrollen Web Vitals sammanfattar labbprestandan; Sidor som laddas långsamt och Layoutförskjutningar isolerar LCP respektive CLS.

3. Åtgärda orsaker, inte poäng

När Silktide (eller Lighthouse) pekar på en orsak ska du åtgärda den orsaken:

Vanlig orsakTypiskt måttSilktide / nästa steg
Stor hero-bild, långsam server, renderingsblockerande CSS/JSLCPSidor som laddas långsamt, Förinläs LCP-bild, kontroller för bildoptimering
Bilder/annonser/inbäddat innehåll utan reserverat utrymme; sena teckensnittCLSLayoutförskjutningar, Ange explicita bildstorlekar
Långa JavaScript-uppgifter vid klickINP / TBTMinska JavaScript-körningstiden, Eliminera renderingsblockerande resurser
För många byte totaltAllaGranska bytevikt, moderna bildformat, cachelagring

Utvecklare bör använda web.dev-guiderna ovan för implementeringsdetaljer – ramverksspecifika mönster förändras snabbare än den här sidan bör göra.

4. Testa samma URL:er igen

Efter en åtgärd kör du labbtesterna igen med samma enhetsprofil och väntar sedan på att fältdata ska hinna ikapp (CrUX-perioder omfattar flera veckor). Bedöm resultatet utifrån fältstatusen för de viktiga URL:erna, inte utifrån en Lighthouse-skärmbild av bara startsidan i en presentation.

Ärliga begränsningar

  • Innehållet vinner fortfarande. En snabb tom sida förlorar mot ett långsammare fullständigt svar. Hastighetsarbete på svaga sidor är bara putsning.
  • Tredjeparter. Tagghanterare, chattwidgetar och A/B-verktyg dominerar ofta INP och LCP. Avsätt politiskt kapital för att ta bort eller skjuta upp dem; att förminska din egen CSS räddar dig inte från en synkron tredjepartsbomb.
  • SPA / rendering endast på klientsidan. Om Fernwoods marknadsföringssida levererar ett tomt skal kan du behöva hantera både dessa värden och läsbarhet för AI-crawlare. Föredra SSR/SSG för offentligt innehåll (Innehåll som kan läsas utan JavaScript).
  • Överoptimering som teater. Att kapa 20 ms från LCP i labbet för en URL som redan är grön i fältdata är sällan den bästa användningen av en utvecklares tid medan jämförelsesidor fortfarande saknar bevisblock.

Så hjälper Silktide

Relaterat

Senast uppdaterad

Var den här sidan hjälpsam?

Sidhastighet och Core Web Vitals | Silktide Hjälp