14 jul 2025·6 min
Meten vóór optimaliseren: de workflow van Paul Irish voor snelheid
Gebruik 'meten vóór optimaliseren' als een eenvoudige cyclus: baseline, profileren, één wijziging, impact verifiëren en een rustigere performance‑gewoonte opbouwen.
Gebruik 'meten vóór optimaliseren' als een eenvoudige cyclus: baseline, profileren, één wijziging, impact verifiëren en een rustigere performance‑gewoonte opbouwen.
Performancewerk voelt willekeurig als je begint met fixes. De ene dag minificeer je bestanden, de volgende dag tweak je caching en daarna verwijder je een bibliotheek. Soms helpt het. Soms verandert er niks, en weet je niet waarom.
Het grootste risico is dat je het verkeerde optimaliseert. Als de pagina traag is omdat de main thread wordt geblokkeerd door JavaScript, levert urenlang afbeeldingen comprimeren misschien nauwelijks winst op. Of je versnelt iets wat gebruikers niet opmerken terwijl de echte vertraging een lange API-call is, een layout die blijft reflowen, of een enkele blocking script.
Er zit ook een valkuil in oordelen op gevoel. “Voelt sneller” kan voortkomen uit placebo‑veranderingen (zoals een spinner) of omdat je op een ander netwerk, apparaat of tijdstip testte. “Is sneller” betekent dat dezelfde actie, onder dezelfde omstandigheden, betere cijfers opleverde.
Een simpele belofte verhelpt dit grotendeels: meet vóór je optimaliseert, en beslis daarna. Als je performance als een meetprobleem behandelt, stop je met gokken en begin je te leren.
Een praktische lus ziet er zo uit: kies één gebruikersactie om te verbeteren, neem een baseline op onder herhaalbare omstandigheden, maak één wijziging die je kunt verklaren, meet opnieuw en behoud de wijziging alleen als de cijfers verbeteren.
Paul Irish is een van de bekendste stemmen in webperformance. Via zijn werk aan browser tooling en performance‑advies hielp hij een eenvoudig idee populair te maken: je eerste taak is niet raden wat traag is, maar het bewijzen.
Die mindset verandert teamdynamiek. In plaats van discussies vanuit gewoontes zoals “afbeeldingen zijn altijd het probleem” of “het zal wel het framework zijn”, begin je met bewijs. Als je naar een timeline, een trage query of een lange task kunt wijzen, verschuift het gesprek van schuld naar oplossingen.
"Meten vóór optimaliseren" koelt performance‑discussies ook af omdat het gedeelde regels creëert: wees het eens over wat je meet, wees het eens over wat “beter” betekent, en vier het alleen als de cijfers bewegen.
Dit werkt op kleine sites en grote apps. Een enkele baseline kan willekeurige micro‑optimalisaties op een marketingpagina stoppen. In een groot product houden consistente metingen performance uit de neerwaartse spiraal van onafgemaakte taken.
Een eenvoudige manier om dit concreet te maken is performance behandelen als een bugrapport: duidelijke reproduceerbare stappen, de metric die je zag, en één wijziging gekoppeld aan één resultaat. Als twee mensen het oneens zijn, voer je de meting opnieuw uit en laat je de data beslissen.
Zie performance eerst als een instrumentatieprobleem: voeg manieren toe om te observeren wat gebruikers echt ervaren. Als je het niet kunt zien, eindig je in meningsdiscussies in plaats van bewijs. Dat is de kern van eerst meten.
Instrumentatie hoeft niet ingewikkeld te zijn. Het is consistent een paar signalen verzamelen, op dezelfde plekken, zodat je basisvragen kunt beantwoorden:
Gewoonlijk wil je twee soorten data.
Labdata wordt vastgelegd in een gecontroleerde setup: een specifieke laptop of testapparaat, een stabiel netwerkprofiel, steeds dezelfde stappen. Het is geweldig voor debuggen omdat je de slow‑down op aanvraag kunt reproduceren.
Real user data is wat mensen in het wild ervaren: verschillende apparaten, locaties en verbindingskwaliteiten. Het is ideaal om te prioriteren omdat het laat zien wat echte gebruikers schaadt, niet alleen één testrun.
Zelfs zonder expert te zijn kun je pagina‑laadmijlpalen meten (zoals eerste content zichtbaar), long tasks en main‑thread blocking, trage netwerkrequests, dure renderingtaken (layout, style, paint) en serverresponstijd.
Die signalen leven meestal op een paar plekken: browser developer tools voor labprofiling, serverlogs en traces voor backend‑timing, en analytics of RUM‑dashboards voor real user data. Bijvoorbeeld: als checkout traag aanvoelt, kunnen DevTools laten zien dat de browser druk is met het renderen van een enorme cart UI, terwijl serverlogs laten zien dat de API snel is. Zonder instrumentatie optimaliseer je misschien de backend en los je het echte probleem nooit op.
Om te meten vóór optimaliseren heb je een beginpunt nodig waarop je kunt vertrouwen. Een baseline is dezelfde actie, op dezelfde manier gemeten, onder dezelfde omstandigheden.
Begin met één echte gebruikersreis, niet “de hele site.” Kies iets dat je in één zin kunt beschrijven, zoals “open de homepage en scroll naar het eerste productgrid” of “log in en bereik het dashboard.” Smal houden maakt de cijfers stabieler en de volgende stappen duidelijker.
Kies vervolgens 1–3 metrics die bij de reis passen. Voor een paginaview is een veelgebruikt paar LCP (hoe snel de hoofdinhoud verschijnt) en TTFB (hoe snel de server reageert). Voor een flow als checkout volg je misschien de tijd om stap 1 te voltooien plus de API‑responstijd voor de betaalcall. Te veel metrics maakt het makkelijk om selectief te kiezen.
Schrijf de testsetup op zodat iemand anders het later kan reproduceren. Kleine verschillen kunnen resultaten sterk beïnvloeden:
Definieer tenslotte wat “goed genoeg” is voor je publiek. Bijvoorbeeld: “LCP onder 2,5s op een mid‑range telefoon, op 4G.” Als je Koder.ai gebruikt, helpt een snapshot vóór het testen om je baseline aan één bekende versie te koppelen.
Voordat je iets profileert, laat het probleem opnieuw gebeuren op aanvraag. Als je het niet kunt herhalen, kun je het resultaat niet vertrouwen.
Begin bij wat mensen voelen, niet bij wat je aanneemt. Is het een trage eerste render? Een klik die vastloopt voordat er iets verandert? Een lange wachttijd na het verzenden van een formulier? Kies het ene moment waar gebruikers over klagen en focus daar.
Doe een korte run om te bevestigen dat de slow‑down echt en herhaalbaar is. Houd verder alles hetzelfde: dezelfde pagina, hetzelfde apparaat, hetzelfde netwerk indien mogelijk. Schrijf dan de trigger en het exacte moment op waarop het traag voelt, zoals “na klikken op Betalen bevriest de knop een seconde” of “scrollen hapert wanneer de productlijst verschijnt.”
Een simpele manier om het herhaalbaar te houden is een klein script: open de pagina vanuit een nieuw tabblad, voer de trage actie uit, noteer het exacte punt waar het vertraagt, en herhaal eenmaal om te bevestigen.
Maak één of twee baseline‑opnames, niet tientallen. Je wilt net genoeg bewijs om te zeggen: “Ja, de slow‑down gebeurt, en het gebeurt precies hier.”
Als je de slow‑down kunt reproduceren: stop met raden. Open een profiler (voor de meeste mensen het Performance‑paneel van de browser) en neem één run van de trage interactie op. Het doel is niet elk mogelijk probleem te vinden. Het doel is begrijpen waar de tijd naartoe gaat.
Begin bij de grootste tijdblokken. Kleine spikes kunnen echt zijn, maar ze verklaren zelden op zichzelf een merkbare vertraging.
Een nuttige manier om een opname te lezen is tijd in een paar bakken te groeperen: netwerk en laden (wachten op requests), main‑thread scripting (lange JavaScript‑taken), rendering en paint (layout en stylewerk), idle gaps (wachten op iets anders), en herhaald werk (dezelfde dure stap die steeds terugkeert).
Een veelgemaakte fout is een trage serverreactie verwarren met traag clientwerk. Als de timeline lange gaps toont terwijl requests in flight zijn, kan je bottleneck netwerk of backend zijn. Als het lange tasks op de main thread toont, heb je een frontendprobleem, ook al is het netwerk snel.
Schrijf voordat je iets verandert een korte, toetsbare hypothese op basis van wat je zag. Bijvoorbeeld: “De pagina voelt traag omdat de main thread wordt geblokkeerd door JSON‑parsing direct nadat de API‑response binnenkomt.” Die zin zet de volgende stap klaar.
Nadat je de waarschijnlijke bottleneck hebt geïdentificeerd, weersta de neiging om "alles" te repareren. Verander één variabele zodat je oorzaak en gevolg kunt koppelen.
Houd de wijziging klein en makkelijk terug te draaien. Grote rewrites vervagen het resultaat: verbetert performance, dan weet je niet waarom. Wordt het slechter, dan is rollback risicovol.
Goede één‑ding wijzigingen zijn specifiek en toetsbaar. Voorbeelden: een enkele third‑party script uitstellen of verwijderen dat rendering blokkeert, één te grote afbeelding op de trage pagina comprimeren, caching toevoegen aan één dure databasequery, één zwaar UI‑component opsplitsen zodat het minder werk up‑front rendert, of werk verminderen in één hot loop die je in de profiler zag.
Schrijf voordat je code aanraakt op wat je wijzigde, waarom je het koos, en wat je verwacht te verbeteren (bijv. “main‑thread tijd verminderen” of “DB‑tijd halveren”).
Als je team een platform gebruikt met snapshots en rollback (zoals Koder.ai), maak dan een snapshot vlak voor de wijziging zodat “klein en omkeerbaar” echt is, niet aspirational.
Je hebt één ding veranderd. Bewijs nu dat het geholpen heeft.
Voer exact dezelfde testsetup opnieuw uit als voor de baseline: dezelfde apparaat, dezelfde browserversion, dezelfde route en flow, en hetzelfde aantal runs. Vergelijk voor en na met dezelfde metrics. Voeg niet halverwege nieuwe metrics toe alleen omdat die beter lijken.
Ruis is de meest voorkomende reden dat teams over performance ruzie maken. Let op warm vs cold cache, extensies of achtergrondprocessen, verschillende netwerkcondities of VPN‑instellingen, servervariatie (rustige minuut vs drukke minuut) en het verschil tussen “direct na deploy” en steadystate.
Als de mediaan verbetert maar de worst‑case verslechtert, is dat een echte afweging. Bepaal wat belangrijk is voor je gebruikers en documenteer de beslissing: behoud de wijziging, draai hem terug, of schrijf een nieuwe hypothese en test opnieuw.
Performancewerk wordt verwarrend als je het verkeerde meet of te veel tegelijk verandert. Je kunt veel moeite verspillen zonder duidelijke winst, zelfs als je app verbetert.
Een veelgemaakte fout is één score als doel zien. Scores kunnen handig zijn, maar gebruikers ervaren geen “een 92.” Ze ervaren “de pagina toont content in 2 seconden” of “op Buy drukken reageert meteen.” Kies één gebruikerszichtbaar resultaat en meet dat consequent.
Een andere val is alleen testen op een krachtig laptop. Veel vertragingen verschijnen op mid‑range telefoons, slechte netwerken of wanneer de CPU bezig is. Als je alleen op je beste apparaat profileert, mis je mogelijk de bottleneck.
Verwarring ontstaat vaak door patronen als verbeteren wat het makkelijkst is in plaats van wat het meeste tijd kost, meerdere tweaks in één wijziging bundelen, elke keer van testpad wisselen, een retest overslaan omdat het “sneller voelt”, of overwinning verklaren zonder dezelfde baseline opnieuw te draaien.
Als je de app bouwt met een chat‑gedreven platform zoals Koder.ai, blijft dezelfde discipline gelden: één wijziging, daarna verifiëren op exact dezelfde flow zodat je het resultaat vertrouwt.
Als je één gewoonte behoudt, behoud dan deze: meet vóór je optimaliseert. Het doel is niet eindeloos data vergaren, maar een herhaalbare lus waarop je kunt vertrouwen.
Noem de exacte gebruikersreis die je belangrijk vindt. “Homepage is traag” is vaag. “Van productpagina naar klikken op Buy naar de bevestiging zien” geeft je een klikpad dat je kunt herhalen.
Gebruik deze checklist:
De kalme versie van performancewerk is simpel: één pad, één setup, één wijziging, één geverifieerd resultaat.
Een veelvoorkomende klacht: checkout voelt traag direct nadat een klant op “Pay” klikt. Mensen beginnen te raden (afbeeldingen, fonts, de knop). Behandel het in plaats daarvan als een test die je kunt herhalen.
Stel een baseline vast die je opnieuw kunt draaien. Kies één apparaat en één pad (cart → checkout → Pay → confirmation). Zet netwerkthrottling aan (bijv. Fast 3G) en houd het elke run hetzelfde. Meet één eenvoudig getal: tijd van klikken op “Pay” tot het bevestigingsscherm zichtbaar is.
Profileer datzelfde moment en kijk waar de tijd naartoe gaat. Meestal beslis je tussen drie bakken: netwerk (een lange request of te veel requests), server (de betaalcall is traag terwijl de browser idle is) of main thread (de browser is druk met JavaScript en kan de UI niet updaten).
Stel je voor dat de profile laat zien dat na klikken op “Pay” de browser een analytics‑request en een fraud‑check script verstuurt, en de betaalrequest blijft daarachter wachten. Dat is geen “maak alles sneller” probleem. Het is één blocking stap.
Maak één doelbewuste wijziging. Bijvoorbeeld: laat de betaalrequest direct starten en stuur analytics pas nadat het bevestigingsscherm is getoond.
Verifieer met dezelfde setup: dezelfde throttling, dezelfde stappen, meerdere runs. Als de bevestigingstijd daalt en errors niet toenemen, heb je een echte winst. Controleer ook dat je geen refunds, retries of dubbele submits hebt gebroken.
Performance blijft beheersbaar als het een routine is, niet een reddingsmissie. Maak meten de standaardactie, zelfs als alles goed lijkt.
Kies een kleine set metrics die je team altijd volgt. Houd het consistent zodat trends makkelijk te zien zijn:
Bouw een lus rond die metrics. Een wekelijkse baseline‑controle is vaak voldoende. Wanneer een metric afwijkt, is dat je trigger om de slow‑down te reproduceren, te profileren, één wijziging te maken en de impact te verifiëren.
Houd een eenvoudig performance‑log bij in het formaat dat je team daadwerkelijk gebruikt. Noteer wat je gemeten hebt (inclusief apparaat, netwerk en build), wat je veranderd hebt en wat de cijfers daarna deden.
Als je met Koder.ai bouwt, kan Planning Mode je helpen de gebruikersreis en de metric op te schrijven voordat je iets verandert. Gebruik snapshots en rollback om experimenten veilig te houden: snapshot, pas één wijziging toe, test opnieuw en draai terug als het resultaat te veel ruis heeft of slechter is.
Bij planning of review houdt één vraag de cultuur gezond: “Wat hebben we gemeten, en wat veranderde er?”
Omdat je makkelijk uren kunt besteden aan iets verbeteren dat niet de vertraging veroorzaakt. Begin met vaststellen waar de tijd naartoe gaat (netwerk, server, main thread, rendering) en richt je dan op de grootste bottleneck.
Schrijf één specifieke actie en de exacte omstandigheden op, en herhaal die:\n\n- Zelfde apparaat + browserversie\n- Zelfde netwerkprofiel (of throttling)\n- Zelfde cachestatus (cold of warm)\n- Zelfde testdata (account, winkelwagengrootte, regio)\n- Meerdere runs (gebruik de mediaan)\n\nAls je het niet kunt herhalen, kun je het niet vertrouwen.
Kies 1–3 metrics die passen bij wat gebruikers opmerken:\n\n- Pagina laden: LCP (hoelang tot de hoofdinhoud zichtbaar is), TTFB (hoe snel de server reageert)\n- Interactie: INP (hoe responsief het voelt)\n- Stabiliteit: CLS (layoutverschuivingen)\n- Backend: p95 responstijd voor de specifieke API waar je op wacht\n\nVermijd te veel cijfers tegelijk, anders ga je cherry-picken.
Labdata wordt vastgelegd in een gecontroleerde opstelling (ideaal voor debuggen). Realtime gebruikersdata is wat echte gebruikers ervaren (handig om te prioriteren).\n\nEen goed uitgangspunt: gebruik real user data om de slechtste journeys te vinden, en labprofiling om waarom ze langzaam zijn te verklaren en fixes veilig te testen.
Behandel het als een bugrapport:\n\n- Exacte stappen om het te reproduceren\n- Welk moment traag aanvoelt\n- Wat je gemeten hebt (metric + waarde)\n- Eén opname (profiel of trace) die laat zien waar de tijd naartoe gaat\n\nDan verschuift het gesprek van meningen (“het zijn vast de afbeeldingen”) naar bewijs.
Neem de trage interactie op in een profiler en zoek het grootste blok tijd:\n\n- Lange gaps tijdens requests → waarschijnlijk netwerk/backend\n- Lange main-thread taken → JavaScript of zware UI-taken\n- Veel layout/style/paint → renderingproblemen\n- Herhaald dure werk → onnodige re-renders of loops\n\nSchrijf daarna één-zoenige hypothese die je kunt testen.
Het houdt oorzaak en gevolg helder. Verander je vijf dingen en het wordt sneller, dan weet je niet wat hielp. Als het langzamer wordt, is rollback gevaarlijk.\n\nEen praktische regel: één wijziging die je kunt uitleggen, één metric waarvan je verwacht dat die beweegt, en dan opnieuw meten.
Voer dezelfde testsetup uit en vergelijk voor/na met precies dezelfde metrics.\n\nOm ruis te verminderen:\n\n- Doe meerdere runs en gebruik de mediaan\n- Houd cachestatus hetzelfde\n- Schakel extensies/achtergrondtaken uit indien mogelijk\n- Test bij vergelijkbare serverbelasting (vergelijk geen rustige minuut met een drukke minuut)\n\nBehoud de wijziging alleen als de cijfers verbeteren onder dezelfde condities.
Veelvoorkomende valkuilen:\n\n- Optimaliseren wat het makkelijkst is, niet wat het meeste tijd kost\n- Alleen testen op een krachtige laptop\n- De gebruikersroute bij elke run veranderen\n- Een score vieren in plaats van een gebruikerszichtbaar resultaat\n- Re-tests overslaan omdat het “sneller voelt”\n\nBlijf bij één journey, één setup en één geverifieerd resultaat.
Gebruik ze om experimenten veilig en vergelijkbaar te maken:\n\n- Maak een snapshot vlak voor een performance-change zodat je snel kunt terugdraaien\n- Gebruik Planning Mode om de journey, baseline en success-metric op te schrijven voordat je iets wijzigt\n- Code exporteren of deployen is prima—maar houd hetzelfde testscript zodat resultaten vergelijkbaar blijven\n\nDe tools helpen, maar de echte winst is de herhaalbare lus: baseline → profile → één wijziging → verifiëren.