Prestaties worden slechter. Een pagina die in twee seconden laadde, laadt nu in vier. Er is iets veranderd.
Probleemoplossing beantwoordt: wat is er veranderd? Waarom werden de prestaties slechter?
Oorzaken: een nieuwe functie voegde een grote JavaScript-bundel toe. Een databasequery werd traag. Er kwam een script van derden bij. Afbeeldingen werden groter. De server raakte overbelast.
Een vaste aanpak vindt de oorzaak. Een vaste aanpak voor herstel haalt de oorzaak weg.
Stappenplan voor probleemoplossing
Stap één: bepaal het symptoom. LCP steeg van twee naar vier seconden. CLS steeg van 0,05 naar 0,2. INP steeg van 100 naar 400 milliseconden.
Stap twee: tijdlijn. Wanneer begon de achteruitgang? Vorige week. Gisteren. Een uur geleden. De tijdlijn beperkt je zoekgebied.
Stap drie: koppel aan wijzigingen. Welke code is veranderd? Welke functies zijn live gegaan? Wat is er in de infrastructuur veranderd? Samenhang wijst de oorzaak aan.
Stap vier: isoleer de oorzaak. De prestaties werden slechter. Hypothese: de nieuwe JavaScript-bundel. Test: meet de LCP met de nieuwe bundel uitgeschakeld. De LCP is weer twee seconden. Hypothese bevestigd.
Stap vijf: herstellen of terugdraaien. Los de oorzaak op (optimaliseer de bundel) of draai terug (maak de wijziging ongedaan). De keuze hangt af van de ernst.
Een voorbeeld uit de praktijk: achteruitgang in prestaties van een webshop
Symptoom: LCP steeg van twee seconden naar 3,5 seconden. Ontdekt via een melding van de monitoring.
Tijdlijn: de achteruitgang begon dinsdagochtend. Het team had maandagavond een nieuwe aanbevelingsmodule live gezet.
Samenhang: het toeval wijst erop dat de aanbevelingsmodule de achteruitgang veroorzaakte.
Isolatietest: schakel de aanbevelingsmodule uit. De LCP is weer twee seconden. De aanbevelingsmodule is bevestigd als oorzaak.
Onderzoek: de aanbevelingsmodule laadt productafbeeldingen voor de aanbevelingen. De afbeeldingen zijn niet geoptimaliseerd (oorspronkelijke grootte, geen compressie). Vijftig productafbeeldingen laden voegt twee megabyte toe aan de pagina.
Oplossing: optimaliseer de afbeeldingen van de aanbevelingsmodule. Comprimeer de afbeeldingen en gebruik lazy loading voor afbeeldingen onder de vouw. De afbeeldingsgrootte daalt naar 500 kilobyte. De LCP verbetert naar 2,2 seconden.
Uitrol: draai de aanbevelingsmodule terug en zet de geoptimaliseerde versie live. De LCP is weer 2,2 seconden.
Veelvoorkomende prestatieproblemen en oplossingen
Probleem één: grote JavaScript-bundel
- Symptoom: trage LCP, trage INP
- Oorzaak: een nieuwe functie voegt code toe, de bundel groeit
- Oplossing: splits de code van de functie af, lazy load de functie
- Verwachte verbetering: LCP verbetert met 0,5 seconde
Probleem twee: trage databasequery's
- Symptoom: trage TTFB
- Oorzaak: een databasequery wordt traag (ontbrekende index, query koppelt veel tabellen)
- Oplossing: voeg een database-index toe, optimaliseer de query, cache de resultaten
- Verwachte verbetering: TTFB verbetert met 200 milliseconden
Probleem drie: niet-geoptimaliseerde afbeeldingen
- Symptoom: trage LCP, hoog bandbreedtegebruik
- Oorzaak: afbeeldingen zijn groot (niet gecomprimeerd, verkeerd formaat)
- Oplossing: comprimeer afbeeldingen, zet om naar WebP, gebruik responsive afbeeldingen
- Verwachte verbetering: LCP verbetert met één seconde
Probleem vier: scripts van derden
- Symptoom: trage LCP, pagina reageert niet meer
- Oorzaak: analytics, tracking of advertenties van derden vertragen de pagina
- Oplossing: lazy load scripts van derden, gebruik een web worker, laad asynchroon
- Verwachte verbetering: LCP verbetert met 0,5 seconde, INP verbetert met 100 milliseconden
Probleem vijf: CLS door advertenties of embeds
- Symptoom: layoutverschuivingen tijdens het lezen
- Oorzaak: advertenties laden en nemen ruimte in, inhoud verschuift
- Oplossing: reserveer ruimte voor advertenties, lazy load advertenties onder de vouw
- Verwachte verbetering: CLS verbetert van 0,2 naar 0,05
Monitoren om problemen vroeg te zien
Melding bij achteruitgang: komt de LCP boven 2,5 seconden, dan krijgt het team een melding.
Melding bij terugval: stijgt de LCP met meer dan 0,5 seconde ten opzichte van de uitgangswaarde, dan krijgt het team een melding.
Melding bij zakelijk effect: daalt het afronden van aanmeldingen met één procent, dan krijgt het team een melding (kan wijzen op een prestatieprobleem).
Een voorbeeld uit de praktijk: meldingen bij een SaaS-bedrijf
- Melding één: als de LCP boven 2,5 seconden komt
- Melding twee: als een terugval in prestaties wordt gezien (LCP stijgt 50 procent in één dag)
- Melding drie: als de Core Web Vitals voor meer dan 5 procent van de gebruikers van goed naar moet beter gaan
- Melding vier: als het afronden van aanmeldingen onder het doel zakt (kan wijzen op een prestatieprobleem op de afrekenpagina)
Gaat er een melding af, dan onderzoekt het techteam het binnen een uur. De oorzaak wordt gevonden. De oplossing staat dezelfde dag live.
Een voorbeeld uit de praktijk: prestatieprobleem bij betalingen
Symptoom: het percentage afgebroken afrekenprocessen steeg van 15 procent naar 25 procent. Het begon op donderdag.
Onderzoek: de prestaties van de afrekenpagina werden slechter. De reactietijd van de betaalknop steeg van 200 milliseconden naar één seconde.
Tijdlijn: de betaalprovider voerde donderdagochtend een wijziging door in de infrastructuur.
Oorzaak: de betaalprovider verhuisde van Californië naar Europa. De netwerkvertraging van gebruiker naar betaalprovider steeg met 200 milliseconden. De totale verwerkingstijd van de betaling steeg naar één seconde.
Oplossing: gebruik een CDN-edgelocatie dicht bij de gebruiker. Stuur het betaalverzoek via de lokale CDN-edge. De CDN-edge stuurt het door naar de Europese betaalprovider. De netwerkvertraging daalt. De verwerkingstijd van de betaling is weer 200 milliseconden.
Resultaat: het percentage afgebroken afrekenprocessen is weer 15 procent.
Zakelijk effect: 5000 afrekenprocessen per maand bij 15 procent afbreken zijn 750 gemiste conversies. Bij een bestelwaarde van 100 dollar is dat 75.000 dollar per maand die je misloopt. Het oplossen van de vertraging bespaarde het bedrijf 75.000 dollar per maand.
Veelgestelde vragen
Hoe stellen we vast of een prestatieprobleem door code of door infrastructuur komt?
Test beide. Schakel de nieuwe code uit (terugdraaien). Zijn de prestaties weer normaal, dan is de code de oorzaak. Blijven de prestaties traag, dan is de infrastructuur de oorzaak. Isoleer stap voor stap. Geef de infrastructuur niet de schuld als de code de oorzaak is (of andersom). Met de websitebouwer van WEMASY kun je dit direct op je website instellen.
Moeten we terugdraaien of oplossen als prestaties slechter worden?
De ernst bepaalt de keuze. Is de achteruitgang groot (LCP stijgt van twee naar vijf seconden), draai dan direct terug. De gebruikerservaring lijdt eronder. Los het later op. Is de achteruitgang klein (LCP stijgt van twee naar 2,3 seconden), los het dan ter plekke op. Het risico van terugdraaien is dan lager dan het risico van een onvolledige oplossing uitrollen.
Hoe voorkomen we dat prestatieproblemen in productie komen?
Test prestaties in de CI/CD-pipeline. Meet de prestaties vóór elke uitrol. Wordt het prestatiebudget overschreden, blokkeer dan de uitrol. Voorkom terugval voordat het gebeurt.
Wat als het prestatieprobleem af en toe optreedt?
Af en toe optredende problemen zijn lastiger te vinden. Verzamel meer data. Monitor langer. Het kan wijzen op een netwerkprobleem (gebeurt op trage netwerken), een verkeersprobleem (gebeurt bij piekverkeer) of een browserprobleem (gebeurt in bepaalde browsers). Beperk het zoekgebied. Test je hypothese op een bepaald netwerk, tijdstip of bepaalde browser.
Hoe vertellen we gebruikers over prestatieproblemen?
Openheid schept vertrouwen. Is een prestatieprobleem bekend en wordt het opgelost, vertel het gebruikers dan. Bijvoorbeeld: de afrekenpagina is trager door de migratie van de betaalprovider. We verwachten morgen een oplossing. We zoeken het uit. Openheid vermindert frustratie.
Moeten we een prestatie-engineer in bereikbaarheidsdienst hebben?
Voor sites die cruciaal zijn (webshops, SaaS) wel. De engineer in dienst reageert binnen dertig minuten op prestatiemeldingen. Onderzoekt het probleem. Zet een oplossing live of draait terug. Zo houden prestatieproblemen geen lange tijd invloed op gebruikers.