Elke milliseconde is een keuze.

Performance is geen fase aan het eind van een project. Het is een ontwerpbeslissing die je vanaf dag één maakt, of achteraf duur betaalt.

Je gebruikers wachten niet. Google rankt je lager. Je serverkosten lopen op. En je developers worden gek van een codebase die bij elke feature trager wordt.

De meeste performance-problemen beginnen hier. Queries zonder index, N+1 problemen, of een datamodel dat niet ontworpen is voor de hoeveelheid data die het nu moet verwerken.

Ongeoptimaliseerde afbeeldingen, JavaScript-bundles van meerdere megabytes, layout shifts die je pagina laten springen. De gebruiker merkt het direct — en vertrekt.

Een server die te klein is voor je traffic. Geen caching. Geen CDN. Of juist: te veel lagen en services die latency toevoegen in plaats van wegnemen.

Wij gokken niet.

Voordat we één regel code aanraken, meten we waar de tijd zit. Server response times, database query logs, front-end waterfalls, Core Web Vitals.

Dan prioriteren we. Een query die 200ms duurt maar twee keer per dag draait? Laat maar. Een API-call die 800ms duurt op elke pageview? Die pakken we eerst aan.

Bij nict is performance geen apart traject dat je erbij boekt. Het zit in hoe we bouwen.

We houden bundle-sizes klein en laden alleen in wat nodig is. Server-side rendering waar het telt voor een snelle first paint. Lean API's die niet meer data sturen dan de front-end nodig heeft.

Het datamodel staat voordat de eerste feature wordt gebouwd. En we testen met duizenden records, niet met vijf.