Performancemål udvikler sig. Core Web Vitals kom i 2020. De afløste ældre mål (FCP, FID). Om fem år afløser nye mål Core Web Vitals.
Fremtidens mål vil måle: indlæsning af AI (hvor lang tid der går, før AI-funktioner svarer), respons i realtid (hvor lang tid der går, før streamede svar dukker op) og oplevet performance (hvordan siden føles, ikke kun de tekniske tal).
Spørgsmålet nu: Hvordan forbereder vi os på fremtidens mål, når vi ikke kender dem? Svaret: Mål det, der betyder noget for din virksomhed. Core Web Vitals måler den generelle brugeroplevelse. Egne mål viser, hvad der betyder noget for netop din forretning. Forbered dig ved at gøre dine målinger fleksible.
Følg udviklingen i målene
Core Web Vitals er standarden i dag. Men de er ikke permanente.
Tidslinje:
- 2020: Core Web Vitals kommer (LCP, CLS, FID)
- 2022: FID erstattes af INP (målet for respons bliver forbedret)
- 2024: der tales om næste mål (ventetid på interaktion, svartid ved streaming)
- Fremtiden: nye mål dukker op
Mønstret er: Når teknologien ændrer sig, ændrer målene sig. Da sider blev interaktive, blev mål for interaktion (INP) vigtige. Når AI bliver almindeligt, kan AI-svartid blive et vigtigt mål.
Lærdommen: Hold dig til principperne (brugeren oplever en hurtig, responsiv og stabil side), ikke til selve målene. Principperne består, selv om målene ændrer sig.
AI og performance i realtid
AI-funktioner bliver almindelige. En chatbot på hjemmesiden bruger 2 sekunder på at svare. Brugeren forventer hurtigere svar.
Nyt mål: AI-svartid (tiden fra brugerens spørgsmål til det første token i AI-svaret).
Eksempel: en chatbot til kundeservice på supportsiden. Brugeren stiller et spørgsmål. Chatbotten bruger 2 sekunder på at give det første token. Brugeren oplever, at chatbotten er langsom og træg.
Optimering: streamet svar. Giv det første token på 500 millisekunder, og stream resten af svaret. Brugeren oplever svaret som øjeblikkeligt, selv om hele svaret tager 2 sekunder.
Fremtidigt mål: mål tiden til første token (TTF), ikke den samlede svartid. TTF under 500 millisekunder er godt.
Eksempel: SaaS med indbygget AI-assistent.
Brugeroplevelse i dag:
- Brugeren klikker på assistentens ikon
- Assistenten bruger 1,5 sekunder på at dukke op
- Brugeren venter og oplever langsomhed
- Chatten føles langsom
Optimering i fremtiden:
- Brugeren klikker på assistentens ikon
- Ikonet reagerer med det samme (hurtig tilbagemelding, 100 millisekunder)
- Chatvinduet åbner (200 millisekunder)
- Det første AI-svar vises (500 millisekunder)
- Resten af AI-svaret streames (1 til 2 sekunder)
Brugerens oplevelse: øjeblikkeligt svar (animationen og det åbne vindue ses med det samme).
Edge computing og distribueret performance
Edge computing flytter beregningerne tættere på brugerne. Serveren flyttes fra New York til en edge-server i Los Angeles. TTFB bliver markant bedre.
I fremtiden foregår beregningerne ved kanten af nettet. HTML bliver lavet ved kanten. JavaScript bliver kørt ved kanten. Databaseforespørgsler bliver fordelt ud til kanten.
Effekt på målene: TTFB bliver ubetydelig (netværksforsinkelsen går mod nul). LCP afhænger af visningen, ikke af serverens svar.
Fremtidigt fokus for optimering: performance i visningen, ikke serverens svartid.
Eksempel: en forside i fremtiden med edge computing.
Status i dag:
- TTFB: 200 millisekunder (server i New York, bruger i Los Angeles)
- LCP: 2 sekunder (LCP = TTFB + tid til visning)
Fremtiden (edge computing):
- TTFB: 20 millisekunder (server ved edge i Los Angeles)
- LCP: 1,5 sekunder (visningen er flaskehalsen, ikke serverens svar)
Optimering: Det bliver vigtigere at forbedre performance i visningen (CSS, JavaScript) end at forbedre serverens svartid.
Oplevet performance og subjektive mål
Objektive mål: LCP er 2 sekunder (kan måles, objektivt).
Subjektive mål: siden føles responsiv (subjektivt, oplevet).
Forskning viser: En side, der føles responsiv, kan have de samme tekniske tal som en side, der føles langsom. Forskellen ligger i animation, visuel tilbagemelding og oplevet indlæsning.
Fremtidigt mål: oplevet responsivitet. Mål brugerens oplevelse, ikke kun det tekniske tal.
Eksempel: to sider med samme LCP (2 sekunder).
Side 1: Viser en tom side med det samme, og indholdet dukker op efter 2 sekunder. Brugeren oplever langsomhed.
Side 2: Viser en skeletskærm med det samme (200 millisekunder) og fylder gradvist indhold på, indtil der er gået 2 sekunder. Brugeren oplever den som hurtigere (skeletskærmen giver en følelse af hurtigere indlæsning).
Tekniske mål (LCP): ens for begge (2 sekunder).
Brugerens oplevelse: side 2 føles hurtigere.
Fremtidigt mål: en score for brugerens oplevelse (mål den subjektive oplevelse sammen med de tekniske tal).
Streaming og gradvis visning
Nuværende metode: Lav hele siden, og send den til browseren. Browseren viser siden. Siden kan bruges.
Streaming: Send siden i dele, efterhånden som de er klar. Browseren modtager og viser delene gradvist. Siden kan delvist bruges, før den er fuldt indlæst.
Effekt: En side, der bruger 2 sekunder på at indlæse fuldt ud, kan bruges efter 0,5 sekunder, hvis den streames.
Fremtidigt mål: tid til interaktiv (TTI). Hvor lang tid går der, før brugeren kan bruge siden?
Eksempel: produktside med anbefalinger.
Nuværende metode:
- HTML indlæses (0,5 sekunder)
- CSS indlæses (0,3 sekunder)
- JavaScript indlæses (0,5 sekunder)
- API-kald til anbefalinger (1 sekund)
- Siden kan bruges efter 2,3 sekunder
Streaming:
- HTML streames (0,1 sekunder), sidens opbygning er synlig
- CSS streames (0,2 sekunder), siden har sit design
- JavaScript streames (0,3 sekunder), siden kan bruges
- API-kaldet til anbefalinger kører videre i baggrunden
- Siden kan bruges efter 0,5 sekunder
- Anbefalingerne vises efter 1 sekund eller senere
Brugeren kan bruge siden (lægge i kurv, klikke på knapper) efter 0,5 sekunder. Alt indhold vises efter 1 sekund eller senere.
Fremtidigt mål (TTI): 0,5 sekunder (ned fra 2,3 sekunder). En kæmpe forbedring i brugerens oplevelse.
Ofte stillede spørgsmål
Skal vi begynde at måle AI-svartid nu?
Ja, hvis din hjemmeside har AI-funktioner. Mål tiden til første token. Følg den dagligt. Sæt mål (under 500 millisekunder er godt). Forbered dig på en fremtid, hvor det bliver et standardmål. Selv om det endnu ikke er et officielt mål, forbereder du dig ved at måle det, der betyder noget for dine brugere. Med WEMASY's hjemmesidebygger kan du sætte det op direkte på din hjemmeside.
Hvordan forbereder vi os på fremtidige performancemål, vi ikke kender endnu?
Byg et fleksibelt målesystem. Mål Core Web Vitals (dagens standard). Mål også egne mål (det, der betyder noget for din forretning). Når nye mål dukker op, kan du føje dem til de eksisterende. Fleksibilitet er nøglen.
Skal vi investere i edge computing for at få bedre performance?
Ja, hvis du har brugere over hele verden. Edge computing sænker TTFB markant (netværksforsinkelsen forsvinder). Det er investeringen værd. Hvis dine brugere er samlet i ét område, er et CDN nok. Et globalt publikum har glæde af edge computing.
Hvordan måler vi oplevet performance?
Spørg brugerne. Spørg: Føles siden hurtig, responsiv og stabil? Sammenlign svarene med de tekniske tal. Du kan opleve, at brugerne synes, siden er hurtigere, selv om de tekniske tal er de samme. Brug svarene i designet (tilføj skeletskærme, animationer og visuel tilbagemelding).
Er tid til interaktiv (TTI) ved at blive det nye standardmål?
Måske. TTI siger mere end LCP om interaktive sider (brugeren kan handle, før siden er fuldt indlæst). Men lige nu er Core Web Vitals (LCP, CLS, INP) standarden. TTI er på vej frem, men ikke officiel endnu. Følg begge.
Hvordan holder vi os opdaterede om nye performancemål og standarder?
Følg de officielle kilder: Googles opdateringer om performance, bloggen på Web.dev og W3C's arbejdsgrupper. Følg også branchen: fagblogs om webudvikling og oplæg fra konferencer for udviklere. Nye mål dukker op gennem disse kanaler. Hold dig orienteret. Tag nye standarder i brug tidligt, når de bliver relevante for din hjemmeside.