A teljesítmény romlik. Az az oldal, amely 2 másodperc alatt betöltődött, most 4 másodperc alatt töltődik be. Valami megváltozott.
A hibaelhárítás arra ad választ: mi változott. Miért romlott a teljesítmény.
Kiváltó okok: egy új funkció nagy JavaScript csomagot adott hozzá. Egy adatbázis-lekérdezés lelassult. Hozzáadtak egy harmadik féltől származó szkriptet. Megnőtt a képek mérete. A szerver túlterhelődött.
A rendszerezett hibaelhárítás megtalálja a kiváltó okot. A rendszerezett javítás megszünteti.
Hibaelhárítási keretrendszer
Első lépés: azonosítsd a tünetet. Az LCP 2 másodpercről 4-re nőtt. A CLS 0,05-ről 0,2-re nőtt. Az INP 100 ezredmásodpercről 400-ra nőtt.
Második lépés: idővonal. Mikor kezdődött a romlás. Múlt héten. Tegnap. Egy órája. Az idővonal szűkíti a keresést.
Harmadik lépés: kapcsold össze a változásokkal. Milyen kód változott. Milyen funkciók kerültek élesbe. Milyen infrastruktúra változott. Az összefüggés kiadja az okot.
Negyedik lépés: különítsd el az okot. A teljesítmény romlott. Hipotézis: az új JavaScript csomag. Teszt: mérd meg az LCP-t kikapcsolt új csomaggal. Az LCP visszatér 2 másodpercre. A hipotézis beigazolódott.
Ötödik lépés: javítás vagy visszaállítás. Javítsd az okot (optimalizáld a csomagot), vagy állítsd vissza (vond vissza a változtatást). A döntés a súlyosságtól függ.
Valós példa: webshop teljesítményromlása
Tünet: az LCP 2 másodpercről 3,5 másodpercre nőtt. A monitorozási riasztás jelezte.
Idővonal: a romlás kedd reggel történt. A csapat hétfő este élesítette az új ajánlómotort.
Összefüggés: az egybeesés arra utal, hogy az ajánlómotor okozta a romlást.
Elkülönítési teszt: kapcsold ki az ajánlómotort. Az LCP visszatér 2 másodpercre. Az ajánlómotor igazolt ok.
Vizsgálat: az ajánlómotor az ajánlatokhoz termékképeket tölt be. A képek nincsenek optimalizálva (eredeti méret, tömörítés nélkül). Ötven termékkép betöltése 2 megabájttal növeli az oldalt.
Javítás: optimalizáld az ajánlómotor képeit. Tömörítsd a képeket, a látható rész alatti képeket késleltetve töltsd be. A képméret 500 kilobájtra csökken. Az LCP 2,2 másodpercre javul.
Kivezetés: állítsd vissza az ajánlómotort, élesítsd az optimalizált verziót. Az LCP visszatér 2,2 másodpercre.
Gyakori teljesítményproblémák és megoldásaik
Első probléma: nagy JavaScript csomag
- Tünet: lassú LCP, lassú INP
- Ok: az új funkció kódot ad hozzá, a csomag megnő
- Megoldás: a funkció kódjának szétbontása, a funkció késleltetett betöltése
- Várt javulás: az LCP 0,5 másodperccel javul
Második probléma: lassú adatbázis-lekérdezések
- Tünet: lassú TTFB
- Ok: az adatbázis-lekérdezés lelassul (hiányzó index, a lekérdezés sok táblát kapcsol össze)
- Megoldás: adatbázis-index hozzáadása, a lekérdezés optimalizálása, az eredmények gyorsítótárazása
- Várt javulás: a TTFB 200 ezredmásodperccel javul
Harmadik probléma: optimalizálatlan képek
- Tünet: lassú LCP, nagy sávszélesség-használat
- Ok: a képek nagyok (tömörítetlenek, rossz formátumúak)
- Megoldás: képek tömörítése, átalakítás WebP-re, reszponzív képek használata
- Várt javulás: az LCP 1 másodperccel javul
Negyedik probléma: harmadik féltől származó szkriptek
- Tünet: lassú LCP, az oldal akadozik
- Ok: a harmadik féltől származó analitika, követés és hirdetések lelassítják az oldalt
- Megoldás: a harmadik féltől származó szkriptek késleltetett betöltése, web worker használata, aszinkron betöltés
- Várt javulás: az LCP 0,5 másodperccel, az INP 100 ezredmásodperccel javul
Ötödik probléma: CLS hirdetésektől vagy beágyazott elemektől
- Tünet: az elrendezés olvasás közben eltolódik
- Ok: a hirdetések betöltődnek és helyet foglalnak, a tartalom elmozdul
- Megoldás: hely foglalása a hirdetéseknek, a látható rész alatti hirdetések késleltetett betöltése
- Várt javulás: a CLS 0,2-ről 0,05-re javul
Figyelés a korai észleléshez
Riasztás romláskor: ha az LCP meghaladja a 2,5 másodpercet, riaszd a csapatot.
Riasztás visszaesésnél: ha az LCP a kiindulási értékhez képest több mint 0,5 másodperccel nő, riaszd a csapatot.
Riasztás üzleti hatásnál: ha a regisztrációk befejezése 1 százalékkal csökken, riaszd a csapatot (teljesítményproblémára utalhat).
Valós példa: riasztások egy SaaS cégnél
- Első riasztás: ha az LCP meghaladja a 2,5 másodpercet
- Második riasztás: ha teljesítményromlást észlel a rendszer (az LCP egy nap alatt 50 százalékkal nő)
- Harmadik riasztás: ha a Core Web Vitals a felhasználók több mint 5 százalékánál jóról fejlesztésre szorulóra vált
- Negyedik riasztás: ha a regisztrációk befejezése a cél alá csökken (a pénztár oldal teljesítményproblémájára utalhat)
Riasztáskor: a fejlesztőcsapat egy órán belül vizsgálja. Megvan a kiváltó ok. A javítás még aznap élesedik.
Valós példa: fizetésfeldolgozási teljesítményprobléma
Tünet: a pénztári lemorzsolódás aránya 15 százalékról 25 százalékra nőtt. Csütörtökön kezdődött.
Vizsgálat: a pénztár oldal teljesítménye romlott. A fizetési gomb interakciós ideje 200 ezredmásodpercről 1 másodpercre nőtt.
Idővonal: a fizetésfeldolgozó csütörtök reggel infrastruktúra-változtatást hajtott végre.
Kiváltó ok: a fizetésfeldolgozó Kaliforniából Európába költözött. A felhasználó és a fizetésfeldolgozó közötti hálózati késleltetés 200 ezredmásodperccel nőtt. A teljes fizetésfeldolgozási idő 1 másodpercre nőtt.
Megoldás: használj a felhasználóhoz közeli CDN peremszervert. Irányítsd a fizetési kérést a helyi CDN peremszerveren át. A CDN peremszerver továbbítja az európai fizetésfeldolgozónak. A hálózati késleltetés csökken. A fizetésfeldolgozási idő visszatér 200 ezredmásodpercre.
Eredmény: a pénztári lemorzsolódás aránya visszatér 15 százalékra.
Üzleti hatás: havi 5000 pénztári vásárlás 15 százalékos lemorzsolódás mellett 750 meghiúsult konverziót jelent. 100 dolláros rendelési értéknél ez havi 75 000 dollár veszteség. A késleltetési probléma javítása havi 75 000 dollárt spórolt a cégnek.
Gyakran ismételt kérdések
Hogyan derítjük ki, hogy a teljesítményprobléma kód vagy infrastruktúra miatt van?
Teszteld mindkettőt. Kapcsold ki az új kódot (visszaállítás). Ha a teljesítmény visszatér a normálisra, a kód az ok. Ha lassú marad, az infrastruktúra az ok. Különítsd el rendszerezetten. Ne az infrastruktúrát hibáztasd, ha a kód az ok (és fordítva). A WEMASY weboldalépítőjével ezt közvetlenül a saját weboldaladon beállíthatod.
Visszaállítsunk vagy javítsunk, ha romlik a teljesítmény?
A súlyosság dönt. Ha a romlás súlyos (az LCP 2 másodpercről 5-re nő), azonnal állíts vissza. A felhasználói élmény sérül. A javítás később jön. Ha a romlás csekély (az LCP 2 másodpercről 2,3-ra nő), javíts a helyén. A visszaállítás kockázata kisebb, mint a befejezetlen javítás élesítésének kockázata.
Hogyan akadályozzuk meg, hogy a teljesítményproblémák élesbe kerüljenek?
Teljesítményteszt a CI/CD folyamatban. Minden élesítés előtt mérd meg a teljesítményt. Ha túllépted a teljesítménykeretet, állítsd le az élesítést. Előzd meg a visszaeséseket, mielőtt megtörténnek.
Mi van, ha a teljesítményprobléma időszakos?
Az időszakos problémákat nehezebb diagnosztizálni. Gyűjts több adatot. Figyelj tovább. Az időszakos probléma utalhat: hálózati hibára (lassú hálózaton fordul elő), forgalmi problémára (csúcsforgalomban fordul elő), böngészőproblémára (bizonyos böngészőkben fordul elő). Szűkítsd a kört. Teszteld a hipotézist egy adott hálózaton, időpontban, böngészőben.
Hogyan kommunikáljuk a teljesítményproblémákat a felhasználóknak?
Az átláthatóság bizalmat épít. Ha a teljesítményprobléma ismert, és javítják, mondd el a felhasználóknak. Példa: a pénztár oldal teljesítménye romlott egy fizetésfeldolgozó-váltás miatt. A javítás holnapra várható. Vizsgáljuk a problémát. Az átláthatóság csökkenti a bosszúságot.
Legyen ügyeletes teljesítménymérnökünk?
Üzletkritikus oldalaknál (webshop, SaaS) igen. Az ügyeletes mérnök 30 percen belül reagál a teljesítményriasztásokra. Kivizsgálja. Javítást élesít vagy visszaállít. Megakadályozza, hogy a teljesítményprobléma hosszú távon hasson a felhasználókra.