Ydeevnen bliver dårligere. En side, der før indlæstes på to sekunder, bruger nu fire sekunder. Noget har ændret sig.
Fejlfinding svarer på: Hvad har ændret sig? Hvorfor blev ydeevnen dårligere?
Typiske årsager: En ny funktion tilføjede en stor JavaScript-pakke. En databaseforespørgsel blev langsom. Et script fra tredjepart blev tilføjet. Billederne blev større. Serveren blev overbelastet.
Systematisk fejlfinding finder årsagen. Systematisk rettelse fjerner årsagen.
Metode til fejlfinding
Trin ét: Find symptomet. LCP steg fra to til fire sekunder. CLS steg fra 0,05 til 0,2. INP steg fra 100 til 400 millisekunder.
Trin to: Lav en tidslinje. Hvornår begyndte forringelsen? I sidste uge. I går. For en time siden. Tidslinjen snævrer søgningen ind.
Trin tre: Sammenlign med ændringerne. Hvilken kode blev ændret? Hvilke funktioner blev udgivet? Hvad blev ændret i infrastrukturen? Sammenhængen peger på årsagen.
Trin fire: Isolér årsagen. Ydeevnen blev dårligere. Gæt: Den nye JavaScript-pakke. Test: Mål LCP med den nye pakke slået fra. LCP er tilbage på to sekunder. Gættet er bekræftet.
Trin fem: Ret eller rul tilbage. Ret årsagen (optimer pakken) eller rul tilbage (fortryd ændringen). Valget afhænger af, hvor alvorligt det er.
Et ægte eksempel: dårligere ydeevne i en webshop
Symptom: LCP steg fra to sekunder til 3,5 sekunder. Opdaget via en alarm fra overvågningen.
Tidslinje: Forringelsen skete tirsdag morgen. Teamet udgav en ny anbefalingsmotor mandag aften.
Sammenhæng: Sammenfaldet tyder på, at anbefalingsmotoren forårsagede forringelsen.
Test for at isolere årsagen: Slå anbefalingsmotoren fra. LCP er tilbage på to sekunder. Anbefalingsmotoren er bekræftet som årsag.
Undersøgelse: Anbefalingsmotoren indlæser produktbilleder til anbefalingerne. Billederne er ikke optimeret (original størrelse, ingen komprimering). Indlæsning af 50 produktbilleder lægger to megabyte oven i siden.
Rettelse: Optimer anbefalingsmotorens billeder. Komprimer billederne, og brug lazy loading til billeder længere nede. Billedstørrelsen falder til 500 kilobyte. LCP forbedres til 2,2 sekunder.
Udrulning: Fortryd anbefalingsmotoren, og udgiv den optimerede version. LCP er tilbage på 2,2 sekunder.
Almindelige problemer med ydeevne og løsninger
Problem ét: en stor JavaScript-pakke
- Symptom: LCP langsom, INP langsom
- Årsag: En ny funktion tilføjer kode, og pakken vokser
- Løsning: Del funktionens kode op, og brug lazy loading til funktionen
- Forventet forbedring: LCP forbedres med 0,5 sekunder
Problem to: langsomme databaseforespørgsler
- Symptom: TTFB langsom
- Årsag: En databaseforespørgsel bliver langsom (manglende indeks, forespørgslen samler mange tabeller)
- Løsning: Tilføj et indeks i databasen, optimer forespørgslen, gem resultater i cache
- Forventet forbedring: TTFB forbedres med 200 millisekunder
Problem tre: billeder, der ikke er optimeret
- Symptom: LCP langsom, højt forbrug af båndbredde
- Årsag: Billederne er store (ikke komprimeret, forkert format)
- Løsning: Komprimer billederne, konverter til WebP, brug responsive billeder
- Forventet forbedring: LCP forbedres med ét sekund
Problem fire: scripts fra tredjepart
- Symptom: LCP langsom, siden bliver træg
- Årsag: Analyse, sporing og annoncer fra tredjepart gør siden langsom
- Løsning: Brug lazy loading til scripts fra tredjepart, brug en web worker, indlæs asynkront
- Forventet forbedring: LCP forbedres med 0,5 sekunder, INP forbedres med 100 millisekunder
Problem fem: CLS fra annoncer eller indlejret indhold
- Symptom: Layoutet skifter, mens man læser
- Årsag: Annoncer indlæses og fylder, og indholdet skifter
- Løsning: Reserver plads til annoncer, brug lazy loading til annoncer længere nede
- Forventet forbedring: CLS forbedres fra 0,2 til 0,05
Overvågning, så du opdager det tidligt
Alarm ved forringelse: Hvis LCP overstiger 2,5 sekunder, så giv teamet besked.
Alarm ved tilbagegang: Hvis LCP stiger med mere end 0,5 sekunder i forhold til udgangspunktet, så giv teamet besked.
Alarm ved effekt på forretningen: Hvis antallet af fuldførte tilmeldinger falder med én procent, så giv teamet besked (det kan tyde på et problem med ydeevnen).
Et ægte eksempel: alarmer i en SaaS-virksomhed
- Alarm ét: Hvis LCP overstiger 2,5 sekunder
- Alarm to: Hvis der opdages en tilbagegang i ydeevnen (LCP stiger med 50 procent på ét døgn)
- Alarm tre: Hvis Core Web Vitals skifter fra god til skal forbedres for mere end fem procent af brugerne
- Alarm fire: Hvis antallet af fuldførte tilmeldinger falder under målet (det kan tyde på et problem med ydeevnen på betalingssiden)
Når en alarm lyder: Udviklerne undersøger det inden for en time. Årsagen bliver fundet. Rettelsen udgives samme dag.
Et ægte eksempel: problem med ydeevnen ved betaling
Symptom: Andelen af forladte betalinger steg fra 15 procent til 25 procent. Det begyndte om torsdagen.
Undersøgelse: Ydeevnen på betalingssiden blev dårligere. Tiden til svar efter et klik på betalingsknappen steg fra 200 millisekunder til ét sekund.
Tidslinje: Betalingsudbyderen ændrede sin infrastruktur torsdag morgen.
Årsag: Betalingsudbyderen flyttede fra Californien til Europa. Ventetiden på netværket fra brugeren til betalingsudbyderen steg med 200 millisekunder. Den samlede tid til betaling steg til ét sekund.
Løsning: Brug et CDN-punkt tæt på brugeren. Send betalingsanmodningen via det lokale CDN-punkt. CDN-punktet sender den videre til betalingsudbyderen i Europa. Ventetiden på netværket falder. Tiden til betaling er tilbage på 200 millisekunder.
Resultat: Andelen af forladte betalinger er tilbage på 15 procent.
Effekt på forretningen: 5.000 betalinger om måneden med 15 procent forladte er 750 mistede konverteringer. Med en ordreværdi på 100 dollar er det 75.000 dollar tabt om måneden. At rette ventetiden sparede virksomheden 75.000 dollar om måneden.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om et problem med ydeevnen skyldes koden eller infrastrukturen?
Test begge dele. Slå den nye kode fra (rul tilbage). Hvis ydeevnen bliver normal igen, er koden årsagen. Hvis ydeevnen stadig er langsom, er infrastrukturen årsagen. Isolér systematisk. Giv ikke infrastrukturen skylden, hvis koden er årsagen (eller omvendt). Med WEMASY's hjemmesidebygger kan du sætte det op direkte på din hjemmeside.
Skal vi rulle tilbage eller rette, når ydeevnen bliver dårligere?
Alvoren afgør valget. Hvis forringelsen er stor (LCP stiger fra to til fem sekunder), så rul tilbage med det samme. Brugeroplevelsen er ramt. Ret senere. Hvis forringelsen er lille (LCP stiger fra to til 2,3 sekunder), så ret på stedet. Risikoen ved at rulle tilbage er mindre end risikoen ved at udgive en halv rettelse.
Hvordan forhindrer vi, at problemer med ydeevnen når frem til den rigtige hjemmeside?
Test ydeevnen i din CI/CD-pipeline. Mål ydeevnen før hver udgivelse. Hvis grænsen for ydeevne er overskredet, så stop udgivelsen. Forhindr forringelser, før de sker.
Hvad hvis problemet med ydeevnen kommer og går?
Problemer, der kommer og går, er sværere at finde. Indsaml flere data. Overvåg i længere tid. Det kan tyde på: et problem med netværket (sker på langsomme netværk), et problem med trafikken (sker, når der er mest trafik), et problem med browseren (sker i bestemte browsere). Indsnævr feltet. Test gættet på et bestemt netværk, tidspunkt og en bestemt browser.
Hvordan fortæller vi brugerne om problemer med ydeevnen?
Åbenhed skaber tillid. Hvis problemet er kendt, og I arbejder på det, så fortæl det til brugerne. Eksempel: Betalingssiden er langsommere, fordi betalingsudbyderen skifter system. Vi regner med at være færdige i morgen. Vi undersøger sagen. Åbenhed dæmper frustrationen.
Skal vi have en udvikler i bagvagt til ydeevne?
For sider, der er afgørende for forretningen (webshops, SaaS), ja. Udvikleren i bagvagt svarer på alarmer om ydeevne inden for 30 minutter. Undersøger sagen. Udgiver en rettelse eller ruller tilbage. Forhindrer, at problemet med ydeevnen rammer brugerne i længere tid.