Výkon se zhoršuje. Stránka, která se načítala dvě sekundy, se teď načítá čtyři. Něco se změnilo.
Řešení problémů odpovídá na otázky: co se změnilo. Proč se výkon zhoršil.
Kořenové příčiny: nová funkce přidala velký balíček JavaScriptu. Databázový dotaz zpomalil. Přidal se skript třetí strany. Zvětšily se obrázky. Server se přetížil.
Systematické hledání najde kořenovou příčinu. Systematická oprava ji odstraní.
Postup řešení problémů
Krok jedna: určete příznak. LCP vzrostlo ze dvou na čtyři sekundy. CLS vzrostlo z nuly celá nula pět na nulu celá dvě. INP vzrostlo ze sta na čtyři sta milisekund.
Krok dva: časová osa. Kdy zhoršení začalo. Minulý týden. Včera. Před hodinou. Časová osa zužuje hledání.
Krok tři: propojte to se změnami. Jaký kód se změnil. Jaké funkce se nasadily. Co se změnilo v infrastruktuře. Souvislost odhalí příčinu.
Krok čtyři: izolujte příčinu. Výkon se zhoršil. Hypotéza: nový balíček JavaScriptu. Test: změřte LCP s vypnutým novým balíčkem. LCP se vrátí na dvě sekundy. Hypotéza je potvrzena.
Krok pět: opravte, nebo vraťte zpět. Opravte příčinu (optimalizujte balíček), nebo vraťte změnu zpět. Rozhodnutí závisí na závažnosti.
Reálný příklad: zhoršení výkonu e-shopu
Příznak: LCP vzrostlo ze dvou sekund na tři celé pět sekundy. Odhaleno upozorněním z monitoringu.
Časová osa: zhoršení nastalo v úterý ráno. Tým nasadil nový doporučovací systém v pondělí večer.
Souvislost: shoda okolností naznačuje, že zhoršení způsobil doporučovací systém.
Izolační test: vypněte doporučovací systém. LCP se vrátí na dvě sekundy. Doporučovací systém je potvrzen jako příčina.
Zjištění: doporučovací systém načítá obrázky produktů pro doporučení. Obrázky nejsou optimalizované (původní velikost, bez komprese). Načtení padesáti obrázků produktů přidá ke stránce dva megabajty.
Oprava: optimalizujte obrázky doporučovacího systému. Obrázky zkomprimujte, obrázky pod okrajem obrazovky načítejte líně. Velikost obrázků klesne na pět set kilobajtů. LCP se zlepší na dvě celé dvě sekundy.
Nasazení: vraťte doporučovací systém zpět, nasaďte optimalizovanou verzi. LCP se vrátí na dvě celé dvě sekundy.
Časté problémy s výkonem a jejich řešení
Problém jedna: velký balíček JavaScriptu
- Příznak: pomalé LCP, pomalé INP
- Příčina: nová funkce přidá kód, balíček naroste
- Řešení: funkci rozdělit do samostatného balíčku, načítat líně
- Očekávané zlepšení: LCP se zlepší o nula celá pět sekundy
Problém dva: pomalé databázové dotazy
- Příznak: pomalé TTFB
- Příčina: databázový dotaz zpomalí (chybí index, dotaz spojuje mnoho tabulek)
- Řešení: přidat databázový index, optimalizovat dotaz, výsledky ukládat do mezipaměti
- Očekávané zlepšení: TTFB se zlepší o dvě stě milisekund
Problém tři: neoptimalizované obrázky
- Příznak: pomalé LCP, vysoký přenos dat
- Příčina: obrázky jsou velké (nekomprimované, špatný formát)
- Řešení: obrázky zkomprimovat, převést do WebP, použít responzivní obrázky
- Očekávané zlepšení: LCP se zlepší o jednu sekundu
Problém čtyři: skripty třetích stran
- Příznak: pomalé LCP, stránka přestane reagovat
- Příčina: analytika, sledování a reklamy třetích stran stránku zpomalují
- Řešení: skripty třetích stran načítat líně, použít web worker, načítat asynchronně
- Očekávané zlepšení: LCP se zlepší o nula celá pět sekundy, INP se zlepší o sto milisekund
Problém pět: CLS z reklam nebo vložených prvků
- Příznak: rozvržení se při čtení posouvá
- Příčina: reklamy se načtou, zabírají místo, obsah se posune
- Řešení: vyhradit místo pro reklamy, reklamy pod okrajem obrazovky načítat líně
- Očekávané zlepšení: CLS se zlepší z nuly celá dvě na nulu celá nula pět
Monitoring pro včasné odhalení
Upozornění na zhoršení: pokud LCP překročí dvě a půl sekundy, upozorněte tým.
Upozornění na regresi: pokud LCP vzroste o víc než nula celá pět sekundy oproti výchozímu stavu, upozorněte tým.
Upozornění na dopad na byznys: pokud dokončení registrace klesne o jedno procento, upozorněte tým (může to znamenat problém s výkonem).
Reálný příklad: upozornění ve firmě se SaaS
- Upozornění jedna: pokud LCP překročí dvě a půl sekundy
- Upozornění dvě: pokud je zjištěna regrese výkonu (LCP vzroste za jeden den o padesát procent)
- Upozornění tři: pokud se Core Web Vitals posunou z dobrých na potřebující zlepšení u víc než pěti procent návštěvníků
- Upozornění čtyři: pokud dokončení registrace klesne pod cíl (může to znamenat problém s výkonem stránky pokladny)
Když se upozornění spustí: vývojový tým to prověří do jedné hodiny. Zjistí se kořenová příčina. Oprava se nasadí týž den.
Reálný příklad: problém s výkonem při platbě
Příznak: míra opuštění pokladny vzrostla z patnácti procent na pětadvacet procent. Začalo ve čtvrtek.
Zjištění: výkon stránky pokladny se zhoršil. Doba odezvy tlačítka platby vzrostla ze dvou set milisekund na jednu sekundu.
Časová osa: platební procesor provedl ve čtvrtek ráno změnu v infrastruktuře.
Kořenová příčina: platební procesor se přesunul z Kalifornie do Evropy. Síťová latence od návštěvníka k platebnímu procesoru vzrostla o dvě stě milisekund. Celkový čas zpracování platby vzrostl na jednu sekundu.
Řešení: použijte okrajový uzel CDN blízko návštěvníka. Požadavek na platbu veďte přes místní uzel CDN. Uzel CDN ho předá evropskému platebnímu procesoru. Latence sítě klesne. Čas zpracování platby se vrátí na dvě stě milisekund.
Výsledek: míra opuštění pokladny se vrátí na patnáct procent.
Dopad na byznys: pět tisíc pokladen měsíčně při patnáctiprocentním opuštění je sedm set padesát nedokončených konverzí. Při hodnotě objednávky sto dolarů je to sedmdesát pět tisíc dolarů ztracených měsíčně. Oprava latence ušetřila firmě sedmdesát pět tisíc dolarů měsíčně.
Často kladené otázky
Jak poznáme, zda problém s výkonem způsobuje kód, nebo infrastruktura?
Otestujte obojí. Vypněte nový kód (vraťte zpět). Pokud se výkon vrátí do normálu, příčinou je kód. Pokud zůstane pomalý, příčinou je infrastruktura. Izolujte systematicky. Neviňte infrastrukturu, když je příčinou kód (a naopak). S WEMASY Tvůrcem webů to nastavíte přímo na svém webu.
Máme při zhoršení výkonu vrátit změnu zpět, nebo opravit?
Rozhoduje závažnost. Pokud je zhoršení výkonu vážné (LCP vzroste ze dvou na pět sekund), vraťte změnu zpět hned. Zážitek návštěvníků je ohrožen. Opravte to později. Pokud je zhoršení malé (LCP vzroste ze dvou na dvě celé tři sekundy), opravte to na místě. Riziko návratu zpět je nižší než riziko nasazení neúplné opravy.
Jak zabránit tomu, aby se problémy s výkonem dostaly do ostrého provozu?
Testujte výkon v CI/CD pipeline. Před každým nasazením změřte výkon. Pokud je překročen rozpočet výkonu, nasazení zablokujte. Zabraňte zhoršení dřív, než nastane.
Co když je problém s výkonem občasný?
Občasné problémy se diagnostikují hůř. Sbírejte víc dat. Sledujte déle. Občasný problém může znamenat: problém se sítí (stává se na pomalých sítích), problém s návštěvností (stává se ve špičce), problém s prohlížečem (stává se v konkrétních prohlížečích). Zužte okruh. Hypotézu otestujte na konkrétní síti, v konkrétním čase, v konkrétním prohlížeči.
Jak o problémech s výkonem informovat návštěvníky?
Transparentnost buduje důvěru. Pokud je problém s výkonem znám a řeší se, řekněte to. Příklad: zhoršení výkonu na stránce pokladny kvůli přechodu platebního procesoru. Oprava se čeká zítra. Zjišťujeme příčinu. Transparentnost snižuje frustraci.
Máme mít pohotovostního specialistu na výkon?
U kriticky důležitých webů (e-shop, SaaS) ano. Pohotovostní vývojář reaguje na upozornění na výkon do třiceti minut. Zjistí příčinu. Nasadí opravu, nebo vrátí změnu zpět. Zabrání tomu, aby problém s výkonem dlouhodobě zasáhl návštěvníky.