Prestandan försämras. En sida som laddades på två sekunder laddas nu på fyra. Något har ändrats.
Felsökning svarar på: vad har ändrats? Varför försämrades prestandan?
Grundorsaker: en ny funktion lade till ett stort JavaScript-paket. En databasfråga blev långsam. Ett tredjepartsskript lades till. Bildstorleken ökade. Servern blev överbelastad.
Systematisk felsökning hittar grundorsaken. Systematisk åtgärd tar bort den.
Ramverk för felsökning
Steg ett: identifiera symtomet. LCP ökade från två till fyra sekunder. CLS ökade från noll komma noll fem till noll komma två. INP ökade från hundra till fyrahundra millisekunder.
Steg två: tidslinje. När började försämringen? Förra veckan. Igår. För en timme sedan. Tidslinjen snävar in sökandet.
Steg tre: koppla till ändringar. Vilken kod ändrades? Vilka funktioner släpptes? Vad ändrades i infrastrukturen? Sambandet pekar ut orsaken.
Steg fyra: isolera orsaken. Prestandan försämrades. Hypotes: det nya JavaScript-paketet. Test: mät LCP med det nya paketet avstängt. LCP går tillbaka till två sekunder. Hypotesen är bekräftad.
Steg fem: åtgärda eller ångra. Åtgärda orsaken (optimera paketet) eller ångra (återställ ändringen). Beslutet beror på hur allvarligt det är.
Verkligt exempel: prestandaförsämring i en webbutik
Symtom: LCP ökade från två sekunder till tre komma fem sekunder. Upptäcktes via en övervakningsavisering.
Tidslinje: försämringen skedde på tisdagsmorgonen. Teamet släppte en ny rekommendationsmotor på måndagskvällen.
Samband: sammanträffandet tyder på att rekommendationsmotorn orsakade försämringen.
Isoleringstest: stäng av rekommendationsmotorn. LCP går tillbaka till två sekunder. Rekommendationsmotorn är bekräftad som orsak.
Undersökning: rekommendationsmotorn laddar produktbilder för rekommendationerna. Bilderna är inte optimerade (originalstorlek, ingen komprimering). Att ladda femtio produktbilder lägger två megabyte på sidan.
Åtgärd: optimera bilderna i rekommendationsmotorn. Komprimera bilderna, använd lazy loading för bilder under vikningen. Bildstorleken minskar till femhundra kilobyte. LCP förbättras till två komma två sekunder.
Utrullning: återställ rekommendationsmotorn, släpp den optimerade versionen. LCP går tillbaka till två komma två sekunder.
Vanliga prestandaproblem och lösningar
Problem ett: stort JavaScript-paket
- Symtom: LCP långsam, INP långsam
- Orsak: en ny funktion lägger till kod, paketet växer
- Lösning: dela upp koden för funktionen, använd lazy loading för funktionen
- Förväntad förbättring: LCP förbättras med noll komma fem sekunder
Problem två: långsamma databasfrågor
- Symtom: TTFB långsam
- Orsak: databasfrågan blir långsam (saknat index, frågan kopplar ihop många tabeller)
- Lösning: lägg till databasindex, optimera frågan, cacha resultaten
- Förväntad förbättring: TTFB förbättras med tvåhundra millisekunder
Problem tre: ooptimerade bilder
- Symtom: LCP långsam, hög bandbredd
- Orsak: bilderna är stora (okomprimerade, fel format)
- Lösning: komprimera bilder, konvertera till WebP, använd responsiva bilder
- Förväntad förbättring: LCP förbättras med en sekund
Problem fyra: tredjepartsskript
- Symtom: LCP långsam, sidan blir trög
- Orsak: tredjepartsanalys, spårning och annonser bromsar sidan
- Lösning: använd lazy loading för tredjepartsskript, använd en web worker, ladda asynkront
- Förväntad förbättring: LCP förbättras med noll komma fem sekunder, INP förbättras med hundra millisekunder
Problem fem: CLS från annonser eller inbäddningar
- Symtom: layouten skiftar under läsning
- Orsak: annonser laddas och tar plats, innehållet flyttar sig
- Lösning: reservera plats för annonser, använd lazy loading för annonser under vikningen
- Förväntad förbättring: CLS förbättras från noll komma två till noll komma noll fem
Övervakning för tidig upptäckt
Avisering vid försämring: om LCP överstiger två komma fem sekunder, varna teamet.
Avisering vid regression: om LCP ökar med mer än noll komma fem sekunder från utgångsvärdet, varna teamet.
Avisering vid affärseffekt: om genomförda registreringar minskar med en procent, varna teamet (kan tyda på ett prestandaproblem).
Verkligt exempel: aviseringar hos ett SaaS-företag
- Avisering ett: om LCP överstiger två komma fem sekunder
- Avisering två: om en prestandaregression upptäcks (LCP ökar femtio procent under en dag)
- Avisering tre: om Core Web Vitals går från bra till behöver förbättras för mer än fem procent av användarna
- Avisering fyra: om genomförda registreringar sjunker under målet (kan tyda på prestandaproblem på kassasidan)
När en avisering utlöses: utvecklingsteamet undersöker inom en timme. Grundorsaken identifieras. Åtgärden släpps samma dag.
Verkligt exempel: prestandaproblem i betalningsflödet
Symtom: andelen övergivna kassor ökade från femton procent till tjugofem procent. Började på torsdagen.
Undersökning: kassasidans prestanda försämrades. Tiden för interaktion med betalknappen ökade från tvåhundra millisekunder till en sekund.
Tidslinje: betalningsleverantören gjorde en ändring i sin infrastruktur på torsdagsmorgonen.
Grundorsak: betalningsleverantören flyttade från Kalifornien till Europa. Nätverkslatensen från användaren till betalningsleverantören ökade med tvåhundra millisekunder. Den totala betalningstiden ökade till en sekund.
Lösning: använd en CDN-nod nära användaren. Skicka betalningsbegäran via den lokala CDN-noden. CDN-noden vidarebefordrar till betalningsleverantören i Europa. Nätverkslatensen minskar. Betalningstiden går tillbaka till tvåhundra millisekunder.
Resultat: andelen övergivna kassor går tillbaka till femton procent.
Affärseffekt: femtusen kassor i månaden med femton procent övergivna är sjuhundrafemtio missade konverteringar. Med ett ordervärde på hundra dollar är det sjuttiofemtusen dollar i förlorad intäkt varje månad. Att åtgärda latensproblemet sparade företaget sjuttiofemtusen dollar i månaden.
Vanliga frågor
Hur avgör vi om ett prestandaproblem beror på koden eller infrastrukturen?
Testa båda. Stäng av den nya koden (återställ). Om prestandan blir normal igen är koden orsaken. Om prestandan förblir långsam är infrastrukturen orsaken. Isolera systematiskt. Skylla inte på infrastrukturen om koden är orsaken (eller tvärtom). Med WEMASY webbplatsbyggare kan du ställa in det direkt på din webbplats.
Ska vi återställa eller åtgärda när prestandan försämras?
Hur allvarligt det är avgör. Är försämringen svår (LCP ökar från två till fem sekunder), återställ direkt. Användarupplevelsen påverkas. Åtgärda senare. Är försämringen liten (LCP ökar från två till två komma tre sekunder), åtgärda på plats. Risken med en återställning är lägre än risken med att släppa en ofullständig åtgärd.
Hur förhindrar vi att prestandaproblem når produktion?
Prestandatester i CI/CD-flödet. Mät prestandan före varje release. Om prestandabudgeten överskrids, blockera releasen. Förhindra försämringar innan de sker.
Vad gör vi om prestandaproblemet kommer och går?
Problem som kommer och går är svårare att diagnostisera. Samla mer data. Övervaka längre. Det kan bero på: nätverket (händer på långsamma nätverk), trafiken (händer vid trafiktoppar) eller webbläsaren (händer i vissa webbläsare). Snäva in. Testa hypotesen på ett visst nätverk, en viss tid eller en viss webbläsare.
Hur kommunicerar vi prestandaproblem till användarna?
Öppenhet skapar förtroende. Om ett prestandaproblem är känt och håller på att åtgärdas, berätta det för användarna. Exempel: prestandaförsämring på kassasidan på grund av byte av betalningsleverantör. Åtgärd väntas i morgon. Vi undersöker saken. Öppenhet minskar frustrationen.
Ska vi ha en prestandaingenjör i beredskap?
För verksamhetskritiska webbplatser (webbutiker, SaaS) ja. Ingenjören i beredskap svarar på prestandaaviseringar inom trettio minuter. Undersöker. Släpper en åtgärd eller återställer. Förhindrar att prestandaproblem påverkar användarna på lång sikt.