Prestandamått utvecklas. Core Web Vitals infördes 2020. De ersatte äldre mått (FCP, FID). Om fem år ersätts Core Web Vitals av nya mått.
Framtidens mått kommer att mäta: AI-laddning (hur lång tid det tar tills AI-funktioner svarar), respons i realtid (hur lång tid det tar tills strömmande svar syns) och upplevd prestanda (hur sidan känns, inte bara tekniska mått).
Frågan just nu: hur förbereder vi oss för framtida mått utan att veta vilka de blir? Svaret: mät det som spelar roll för din verksamhet. Core Web Vitals mäter den allmänna användarupplevelsen. Egna mått mäter resultat som är specifika för din verksamhet. Förbered dig på framtiden genom att bygga in flexibilitet i mätsystemen.
Så utvecklas måtten
Core Web Vitals är dagens standard. Men de är inte permanenta.
Tidslinje:
- 2020: Core Web Vitals infördes (LCP, CLS, FID)
- 2022: FID ersattes av INP (responsmåttet förfinades)
- 2024: diskussion om nästa mått (väntetid för interaktion, svarstid för strömmande svar)
- Framtiden: nya mått dyker upp
Mönster: när tekniken förändras förändras måtten. När sidor blev interaktiva blev interaktiva mått (INP) viktiga. När AI blir vanligt kan AI-svarstid bli ett viktigt mått.
Lärdom: fokusera på principerna (användaren upplever en snabb, responsiv och stabil sida), inte på själva måtten. Principerna består även när måtten byts ut.
AI och prestanda i realtid
AI-funktioner blir vanliga. En chattbot på en webbplats tar två sekunder på sig att svara. Användaren förväntar sig snabbare.
Nytt mått: AI-svarstid (tiden från användarens fråga till AI-svarets första token).
Exempel: en chattbot för kundtjänst på supportsidan. Användaren ställer en fråga. Chattbotten tar två sekunder på sig att leverera första svarstoken. Användarens uppfattning: chattbotten är långsam och trög.
Optimering: strömmande svar. Skicka första token inom femhundra millisekunder och strömma resten av svaret. Användaren upplever svaret som omedelbart, även om hela svaret tar två sekunder.
Framtida mått: mät tiden till första token (TTF), inte total svarstid. TTF under femhundra millisekunder är bra.
Verkligt exempel: SaaS med inbyggd AI-assistent.
Dagens användarupplevelse:
- Användaren klickar på assistentikonen
- Assistenten tar en komma fem sekunder på sig att visas
- Användaren väntar och upplever långsamhet
- Chattupplevelsen känns långsam
Framtida optimering:
- Användaren klickar på assistentikonen
- Ikonen animeras direkt (omedelbar återkoppling, hundra millisekunder)
- Chattfönstret öppnas (tvåhundra millisekunder)
- Första AI-svaret visas (femhundra millisekunder)
- Resten av AI-svaret strömmas (en till två sekunder)
Användarens uppfattning: omedelbart svar (animationen och det öppna fönstret syns direkt).
Edge computing och distribuerad prestanda
Edge computing flyttar beräkningar närmare användarna. Servern flyttas från New York till en nod i Los Angeles. TTFB förbättras dramatiskt.
Framtiden: beräkningar sker vid kanten av nätverket. HTML genereras vid kanten. JavaScript körs vid kanten. Databasfrågor fördelas ut till kanten.
Effekt på måtten: TTFB blir försumbar (nätverkslatensen närmar sig noll). LCP beror på renderingen, inte på serverns svar.
Framtida fokus för optimering: renderingsprestanda, inte serverprestanda.
Exempel: en framtida startsida driven från kanten.
Nuläge:
- TTFB: tvåhundra millisekunder (server i New York, användare i Los Angeles)
- LCP: två sekunder (LCP = TTFB + renderingstid)
Framtida läge (edge computing):
- TTFB: tjugo millisekunder (server i noden i Los Angeles)
- LCP: en komma fem sekunder (renderingstiden är flaskhalsen, inte serverns svar)
Optimering: att förbättra renderingsprestandan (CSS, JavaScript) blir viktigare än att förbättra serverns svarstid.
Upplevd prestanda och subjektiva mått
Objektiva mått: LCP är två sekunder (mätbart, objektivt).
Subjektiva mått: sidan känns responsiv (subjektivt, upplevt).
Forskning visar: en sida som känns responsiv kan ha samma tekniska mått som en sida som känns långsam. Skillnaden är animation, visuell återkoppling och upplevd laddning.
Framtida mått: upplevd respons. Mät användarens upplevelse, inte bara det tekniska måttet.
Exempel: två sidor med samma LCP (två sekunder).
Sida ett: laddas direkt till en tom sida, sedan visas innehållet efter två sekunder. Användaren upplever långsamhet.
Sida två: visar en skelettskärm direkt (tvåhundra millisekunder) och fyller gradvis på innehåll fram till två sekunder. Användaren upplever den som snabbare (skelettskärmen ger en illusion av snabbare laddning).
Tekniska mått (LCP): samma för båda (två sekunder).
Användarens uppfattning: sida två känns snabbare.
Framtida mått: upplevelsepoäng (mät den subjektiva upplevelsen vid sidan av de tekniska måtten).
Strömning och progressiv rendering
Dagens metod: rendera hela sidan och skicka den till klienten. Klienten renderar sidan. Sidan är interaktiv.
Strömmande metod: skicka sidans delar när de är renderade. Klienten tar emot och renderar delarna stegvis. Sidan är delvis interaktiv innan den är helt laddad.
Effekt: en sida som tar två sekunder att ladda helt kan vara interaktiv efter noll komma fem sekunder om den strömmas.
Framtida mått: time to interactive (TTI). Hur lång tid det tar tills användaren kan interagera med sidan.
Exempel: en produktsida med rekommendationer.
Dagens metod:
- HTML laddas (noll komma fem sekunder)
- CSS laddas (noll komma tre sekunder)
- JavaScript laddas (noll komma fem sekunder)
- API-anrop för rekommendationer (en sekund)
- Sidan är interaktiv efter två komma tre sekunder
Strömmande metod:
- HTML strömmas (noll komma en sekund) - sidans struktur syns
- CSS strömmas (noll komma två sekunder) - sidan får sin stil
- JavaScript strömmas (noll komma tre sekunder) - sidan är interaktiv
- API-anropet för rekommendationer fortsätter i bakgrunden
- Sidan är interaktiv efter noll komma fem sekunder
- Rekommendationerna visas efter en sekund och framåt
Användaren kan interagera (lägga i varukorgen, klicka på knappar) efter noll komma fem sekunder. Allt innehåll visas efter en sekund och framåt.
Framtida mått (TTI): noll komma fem sekunder (från två komma tre sekunder). Enorm förbättring av användarens upplevelse.
Vanliga frågor
Ska vi börja mäta AI-svarstid redan nu?
Ja, om din sajt har AI-funktioner. Mät tiden till första token. Följ den dagligen. Sätt mål (under femhundra millisekunder är bra). Förbered dig på en framtid där det blir ett standardmått. Även om det inte är ett officiellt mått ännu förbereder du dig genom att mäta det som spelar roll för dina användare. Med WEMASY webbplatsbyggare kan du ställa in det direkt på din webbplats.
Hur förbereder vi oss för framtida prestandamått som vi inte känner till ännu?
Bygg ett flexibelt mätsystem. Mät Core Web Vitals (dagens standard). Mät också egna mått (det som spelar roll för din verksamhet). När nya mått dyker upp kan du lägga till dem vid sidan av de befintliga. Flexibilitet är nyckeln.
Ska vi investera i edge computing för prestanda?
Ja, om du har användare över hela världen. Edge computing minskar TTFB dramatiskt (nätverkslatensen försvinner). Värt investeringen. Om dina användare finns i ett geografiskt område räcker ett CDN. En global publik får nytta av edge computing.
Hur mäter vi upplevd prestanda?
Fråga användarna. Fråga: känns sidan snabb, responsiv och stabil? Jämför enkätsvaren med de tekniska måtten. Du kan se att användarna upplever sidan som snabbare trots samma tekniska mått. Använd svaren i designen (lägg till skelettskärmar, animationer och visuell återkoppling).
Blir time to interactive (TTI) det nya standardmåttet?
Möjligen. TTI säger mer än LCP för interaktiva sidor (användaren kan agera innan sidan har laddats helt). Men just nu är Core Web Vitals (LCP, CLS, INP) standard. TTI är på väg upp men ännu inte officiellt. Följ båda.
Hur håller vi oss uppdaterade om nya prestandamått och standarder?
Följ officiella källor: Googles prestandauppdateringar, bloggen på web.dev och W3C:s standardgrupper. Följ branschen: webbutvecklingsmagasin, bloggar om prestandatestning och föredrag på tekniska konferenser. Nya mått dyker upp genom de kanalerna. Håll dig informerad. Börja tidigt när en ny standard blir relevant för din sajt.