Suorituskyky heikkenee. Sivu, joka latautui kahdessa sekunnissa, latautuu nyt neljässä. Jokin on muuttunut.
Vianmääritys vastaa kysymyksiin: mikä muuttui ja miksi suorituskyky heikkeni.
Perimmäiset syyt: uusi ominaisuus toi mukanaan ison JavaScript-paketin. Tietokantakysely hidastui. Mukaan tuli kolmannen osapuolen skripti. Kuvan koko kasvoi. Palvelin ylikuormittui.
Järjestelmällinen vianmääritys löytää perimmäisen syyn. Järjestelmällinen korjaus poistaa sen.
Vianmäärityksen viitekehys
Vaihe yksi: tunnista oire. LCP kasvoi kahdesta neljään sekuntiin. CLS kasvoi 0,05:stä 0,2:een. INP kasvoi 100:sta 400 millisekuntiin.
Vaihe kaksi: aikajana. Milloin heikkeneminen alkoi? Viime viikolla. Eilen. Tunti sitten. Aikajana rajaa etsintää.
Vaihe kolme: yhdistä muutoksiin. Mikä koodi muuttui? Mitä ominaisuuksia julkaistiin? Mikä infrastruktuurissa muuttui? Yhteys paljastaa syyn.
Vaihe neljä: eristä syy. Suorituskyky heikkeni. Hypoteesi: uusi JavaScript-paketti. Testi: mittaa LCP uusi paketti pois päältä. LCP palaa kahteen sekuntiin. Hypoteesi vahvistui.
Vaihe viisi: korjaa tai palauta. Korjaa syy (optimoi paketti) tai palauta edellinen versio (peruuta muutos). Päätös riippuu vakavuudesta.
Käytännön esimerkki: verkkokaupan suorituskyvyn heikkeneminen
Oire: LCP kasvoi kahdesta sekunnista 3,5 sekuntiin. Havaittiin seurannan hälytyksestä.
Aikajana: heikkeneminen tapahtui tiistaiaamuna. Tiimi julkaisi uuden suosittelumoottorin maanantai-iltana.
Yhteys: ajoitus viittaa siihen, että suosittelumoottori aiheutti heikkenemisen.
Eristystesti: poista suosittelumoottori käytöstä. LCP palaa kahteen sekuntiin. Suosittelumoottori vahvistui syyksi.
Selvitys: suosittelumoottori lataa tuotekuvia suosituksia varten. Kuvia ei ole optimoitu (alkuperäinen koko, ei pakkausta). Viidenkymmenen tuotekuvan lataaminen lisää sivulle kaksi megatavua.
Korjaus: optimoi suosittelumoottorin kuvat. Pakkaa kuvat ja lataa ruudun alaosan kuvat vasta tarvittaessa. Kuvien koko pienenee viiteensataan kilotavuun. LCP paranee 2,2 sekuntiin.
Käyttöönotto: palauta suosittelumoottorin edellinen versio ja julkaise optimoitu versio. LCP palaa 2,2 sekuntiin.
Yleisiä suorituskykyongelmia ja ratkaisuja
Ongelma yksi: iso JavaScript-paketti
- Oire: LCP hidas, INP hidas
- Syy: uusi ominaisuus lisää koodia, paketti kasvaa
- Ratkaisu: jaa ominaisuus omaan koodipakettiinsa (code split) ja lataa se vasta tarvittaessa
- Odotettu parannus: LCP paranee 0,5 sekuntia
Ongelma kaksi: hitaat tietokantakyselyt
- Oire: TTFB hidas
- Syy: tietokantakysely hidastuu (puuttuva indeksi, kysely yhdistää monta taulua)
- Ratkaisu: lisää tietokantaindeksi, optimoi kysely, tallenna tulokset välimuistiin
- Odotettu parannus: TTFB paranee 200 millisekuntia
Ongelma kolme: optimoimattomat kuvat
- Oire: LCP hidas, kaistanleveyden käyttö suuri
- Syy: kuvat ovat suuria (pakkaamattomia, väärä formaatti)
- Ratkaisu: pakkaa kuvat, muunna WebP-formaattiin, käytä responsiivisia kuvia
- Odotettu parannus: LCP paranee sekunnin
Ongelma neljä: kolmannen osapuolen skriptit
- Oire: LCP hidas, sivu muuttuu jähmeäksi
- Syy: kolmannen osapuolen analytiikka, seuranta ja mainokset hidastavat sivua
- Ratkaisu: lataa kolmannen osapuolen skriptit vasta tarvittaessa, käytä web workeria, lataa asynkronisesti
- Odotettu parannus: LCP paranee 0,5 sekuntia, INP paranee 100 millisekuntia
Ongelma viisi: mainosten tai upotusten aiheuttama CLS
- Oire: asettelu siirtyy luettaessa
- Syy: mainokset latautuvat ja vievät tilaa, sisältö siirtyy
- Ratkaisu: varaa tila mainoksille, lataa ruudun alaosan mainokset vasta tarvittaessa
- Odotettu parannus: CLS paranee 0,2:sta 0,05:een
Seuranta varhaista havaitsemista varten
Hälytys heikkenemisestä: jos LCP ylittää 2,5 sekuntia, hälytä tiimiä.
Hälytys taantumasta: jos LCP kasvaa yli 0,5 sekuntia lähtötilanteesta, hälytä tiimiä.
Hälytys liiketoimintavaikutuksesta: jos rekisteröitymisen valmistuminen laskee yhdellä prosentilla, hälytä tiimiä (voi viitata suorituskykyongelmaan).
Esimerkki: hälytykset SaaS-yrityksessä
- Hälytys yksi: jos LCP ylittää 2,5 sekuntia
- Hälytys kaksi: jos havaitaan suorituskyvyn taantuma (LCP kasvaa viisikymmentä prosenttia vuorokaudessa)
- Hälytys kolme: jos Core Web Vitals siirtyvät hyvästä tilaan "kaipaa parannusta" yli viidellä prosentilla käyttäjistä
- Hälytys neljä: jos rekisteröitymisen valmistuminen laskee tavoitteen alle (voi viitata kassasivun suorituskykyongelmaan)
Kun hälytys laukeaa: tekninen tiimi selvittää asian tunnin sisällä. Perimmäinen syy tunnistetaan. Korjaus julkaistaan samana päivänä.
Käytännön esimerkki: maksunkäsittelyn suorituskykyongelma
Oire: kassalta poistumisprosentti nousi viidestätoista prosentista kahteenkymmeneenviiteen. Alkoi torstaina.
Selvitys: kassasivun suorituskyky heikkeni. Maksupainikkeen vuorovaikutusaika kasvoi 200 millisekunnista yhteen sekuntiin.
Aikajana: maksunvälittäjä teki infrastruktuurimuutoksen torstaiaamuna.
Perimmäinen syy: maksunvälittäjä siirtyi Kaliforniasta Eurooppaan. Verkon viive käyttäjältä maksunvälittäjälle kasvoi 200 millisekuntia. Maksunkäsittelyn kokonaisaika kasvoi yhteen sekuntiin.
Ratkaisu: käytä käyttäjän lähellä olevaa CDN-reunasolmua. Reititä maksupyyntö paikallisen CDN-reunasolmun kautta. CDN-reunasolmu välittää pyynnön eurooppalaiselle maksunvälittäjälle. Verkon viive pienenee. Maksunkäsittelyn aika palaa 200 millisekuntiin.
Tulos: kassalta poistumisprosentti palaa viiteentoista prosenttiin.
Liiketoimintavaikutus: viisi tuhatta kuukausittaista kassalle siirtymistä viidentoista prosentin poistumisella on 750 epäonnistunutta konversiota. Sadan dollarin tilausarvolla se on 75 000 dollaria menetettyä kuukaudessa. Viiveongelman korjaaminen säästi yritykselle 75 000 dollaria kuukaudessa.
Usein kysytyt kysymykset
Miten selvitämme, johtuuko suorituskykyongelma koodista vai infrastruktuurista?
Testaa molemmat. Poista uusi koodi käytöstä (palauta edellinen versio). Jos suorituskyky palaa normaaliksi, syy on koodi. Jos suorituskyky pysyy hitaana, syy on infrastruktuuri. Eristä järjestelmällisesti. Älä syytä infrastruktuuria, jos syy on koodi (tai päinvastoin). Rakenna tämä suoraan verkkosivustollesi WEMASY-sivustonrakentajalla.
Pitäisikö suorituskyvyn heiketessä palauttaa edellinen versio vai korjata?
Vakavuus ratkaisee. Jos suorituskyvyn heikkeneminen on vakavaa (LCP kasvaa kahdesta viiteen sekuntiin), palauta edellinen versio heti. Käyttökokemus kärsii. Korjaa myöhemmin. Jos heikkeneminen on vähäistä (LCP kasvaa kahdesta 2,3 sekuntiin), korjaa paikan päällä. Palautuksen riski on pienempi kuin keskeneräisen korjauksen julkaisun riski.
Miten estämme suorituskykyongelmien päätymisen tuotantoon?
Suorituskykytestaus CI/CD-putkessa. Mittaa suorituskyky ennen jokaista julkaisua. Jos suorituskykybudjetti ylittyy, estä julkaisu. Estä taantumat ennen kuin ne tapahtuvat.
Entä jos suorituskykyongelma on ajoittainen?
Ajoittaisia ongelmia on vaikeampi diagnosoida. Kerää lisää dataa. Seuraa pidempään. Ajoittainen ongelma voi viitata: verkko-ongelmaan (esiintyy hitailla verkoilla), liikenneongelmaan (esiintyy ruuhkahuippujen aikana) tai selainongelmaan (esiintyy tietyillä selaimilla). Rajaa aluetta. Testaa hypoteesi tietyllä verkolla, ajankohdalla ja selaimella.
Miten kerromme suorituskykyongelmista käyttäjille?
Avoimuus rakentaa luottamusta. Jos suorituskykyongelma tiedetään ja sitä korjataan, kerro siitä käyttäjille. Esimerkki: kassasivun suorituskyky on heikentynyt maksunvälittäjän siirron vuoksi. Korjauksen odotetaan valmistuvan huomiseen mennessä. Selvitämme asiaa. Avoimuus vähentää turhautumista.
Tarvitaanko päivystävä suorituskykyasiantuntija?
Liiketoiminnan kannalta kriittisille sivustoille (verkkokauppa, SaaS) kyllä. Päivystävä asiantuntija reagoi suorituskykyhälytyksiin 30 minuutissa. Selvittää asian. Julkaisee korjauksen tai palauttaa edellisen version. Estää suorituskykyongelmaa vaikuttamasta käyttäjiin pitkään.