Een performance-budget dat het jaar overleeft

Bijna elke website is snel op de dag van oplevering. Een jaar later niet meer. Er is een meetscript bijgekomen, een chatwidget, een derde lettertype en een carrousel met ongecomprimeerde foto's. Niemand heeft één grote fout gemaakt; iedereen heeft een kleine gemaakt.

Een performance-budget is het gereedschap dat dat patroon doorbreekt. Het is geen meting achteraf, maar een afspraak vooraf: dit zijn de grenzen, en een wijziging die eroverheen gaat komt er niet in. Hieronder staat hoe u zo'n budget vastlegt, waarom het meestal alsnog verwatert, en wat er nodig is om het wel te laten houden.

Wat een performance-budget precies is

Een budget is een klein aantal getallen waar iedereen op het project van weet. Niet twintig metrics uit een rapport, maar de handvol die het verschil maken tussen een pagina die reageert en een pagina die traag aanvoelt. In de regel leggen we er vier vast:

• Largest Contentful Paint onder 2,5 seconden, gemeten op een middenklasse telefoon over 4G — niet op de glasvezelverbinding van kantoor.
• Interaction to Next Paint onder 200 milliseconden, gemeten op de zwaarste pagina van de site. Dat is meestal een overzicht met filters, niet de homepage.
• Cumulative Layout Shift onder 0,1. In de praktijk betekent dat: elke afbeelding, banner en ingesloten component krijgt vooraf gereserveerde ruimte.
• Een harde bovengrens voor JavaScript per pagina, in gecomprimeerde kilobytes. Dit is het getal dat het vaakst ongemerkt oploopt.

De precieze getallen zijn minder belangrijk dan het feit dat ze bestaan en ergens staan opgeschreven. Een budget dat alleen in het hoofd van één ontwikkelaar zit, is geen budget.

Waarom het budget alsnog verwatert

Performance verslechtert zelden door één beslissing. Het gebeurt door twintig redelijke beslissingen die stuk voor stuk verdedigbaar waren. Marketing wil een heatmap. Sales wil een chatwidget. Een ontwikkelaar pakt een bibliotheek van 90 kB voor een datumkiezer die met 3 kB ook had gekund.

Het punt is niet dat die keuzes verkeerd zijn. Het punt is dat niemand op het moment van kiezen de optelsom zag. Zonder meting op het moment van wijzigen blijft de rekening onzichtbaar tot de site merkbaar traag is — en dan is terugdraaien duur geworden.

Een budget dat zichzelf bewaakt

Een budget werkt alleen als overschrijden gevolgen heeft. Niet een waarschuwing die iedereen wegklikt, maar een build die faalt. Vier stappen zijn genoeg:

1. Meet bij elke wijziging, niet één keer per kwartaal. Een geautomatiseerde meting op een vast toestelprofiel is betrouwbaarder dan een handmatige test op een willekeurige laptop.
2. Laat de build falen bij overschrijding. Een grens zonder consequentie is een advies, en adviezen verliezen het van deadlines.
3. Laat zien welke wijziging het verschil veroorzaakte. 'De bundel is 40 kB gegroeid' helpt niemand; 'deze bibliotheek voegde 38 kB toe' is direct op te lossen.
4. Verhoog grenzen bewust, niet stilletjes. Een budget mag omhoog als daar een reden voor is — maar dan als besluit, met een naam eronder.

Deze vier stappen kosten samen minder dan een dag inrichten. Het rendement is dat een probleem zichtbaar wordt op het moment dat het ontstaat, in plaats van maanden later in een rapportage.

Wanneer u het budget mag overschrijden

Een budget dat nooit mag wijken, wordt op een gegeven moment genegeerd. Er zijn functies die hun gewicht waard zijn: een kaart, een editor, een videospeler. De vraag is niet of iets zwaar mag zijn, maar of het zwaar moet zijn op elke pagina, voor elke bezoeker, meteen bij het laden.

De juiste vraag is zelden 'is dit te zwaar', maar 'wie betaalt hiervoor, en wanneer'.

Meestal is het antwoord dat de functie pas geladen hoeft te worden wanneer iemand hem gebruikt. Een kaart die pas laadt bij het openen van dat tabblad kost de overige bezoekers niets. Zo blijft het budget intact zonder dat er functionaliteit sneuvelt.

Kort samengevat

Leg vier getallen vast, meet ze bij elke wijziging, laat de build falen bij overschrijding en verhoog de grenzen alleen bewust. Dat is het hele mechanisme. Het moeilijke eraan is niet technisch — het is de afspraak volhouden op de dag dat er haast is.