Wanneer een digitaal product te langzaam laadt, zoeken mensen een andere weg. Dat is geen technisch probleem, het is een ontwerpprobleem. En het begint bij de brief.
Bij Livewall zien we het steeds opnieuw: prestatiedoelstellingen worden pas laat ingebracht, vaak als een dev-ticket in sprint drie, nadat de architectuur al is vastgelegd en de animaties zijn goedgekeurd. Op dat moment is terugdraaien duur. Soms onmogelijk.
Een prestatiebudget is simpelweg een afgesproken grens: maximale laadtijd, maximale paginagrootte, een doelscore voor Core Web Vitals. De meeste teams begrijpen dat concept pas als het product al in productie is. De slimme aanpak is dit al bij de eerste briefing op tafel leggen.
Waarom het zo laat komt
Presteren wordt te vaak beschouwd als een technische verantwoordelijkheid, niet als een producteigenschap. Product owners beschrijven functies. Designers beschrijven beelden en beweging. Developers bouwen wat er staat. Niemand vraagt vroeg genoeg: hoe snel moet dit werken voor iemand met een gemiddelde verbinding op een middenklasse telefoon?
Dat is een UX/UI-ontwerpbeslissing, geen optimalisatietaak achteraf.
Wat een prestatiebudget in een brief doet
Als je een laadtijdlimiet van twee seconden vastlegt in de brief, veranderen er dingen. Designers wegen de impact van zware animaties. Contentteams denken na over videoformaten. Developers kiezen een renderingsstrategie die bij die grens past in plaats van er achteraf op te optimaliseren.
Het verplaatst de discussie van "kunnen we dit versnellen?" naar "wat nemen we mee binnen dit budget?" Dat is een fundamenteel andere mindset, en die is veel goedkoper.
Bij de bouw van de KLM Scalable Growth Case was schaalbaarheid en technische prestatie al in de productstrategie verankerd. Niet als eis aan het eind, maar als ontwerpbeginsel van het begin af aan. Dat maakte snellere iteraties en betere resultaten over meerdere markten mogelijk.
