Trage webapplicatie? Zo verbeter je de prestaties in 7 stappen

Een offerteportaal dat er vijf seconden over doet voordat er iets gebeurt. Een klant die halverwege het afrekenen naar een spinner zit te kijken. Een intern systeem dat op maandagochtend begint te kraken zodra iedereen tegelijk inlogt. Dat zijn geen technische schoonheidsfoutjes. Dat is omzet, productiviteit en geduld dat weglekt.

De oorzaak zit bijna nooit op één plek. Meestal is het een stapeling: een query die met de database is meegegroeid, een koppeling die op een trage externe partij wacht, een scherm dat te veel tegelijk probeert te laden, en hosting die ooit prima paste maar allang niet meer. Een zwaardere server maakt zo'n stapeling een tijdje minder zichtbaar, maar ruimt hem niet op. Meten en prioriteren doet dat wel.

Begin bij het proces dat geld of tijd kost

Niet elke milliseconde is evenveel waard. Een beheerpagina die één keer per week wordt geopend mag rustig twee seconden doen. Een bestelstraat, planningsscherm of klantportaal dat de hele dag onder handen is, niet. Begin dus niet met een technische wensenlijst maar met drie vragen: waar haken gebruikers af, welke handeling kost medewerkers structureel te veel tijd, en op welk moment van de dag of de maand loopt de belasting op?

Kijk daarbij verder dan de homepage. Veel applicaties voelen bij het eerste scherm prima aan en worden pas traag zodra iemand gaat zoeken, filteren, een bestand uploadt of een workflow met meerdere stappen start. Daar zit meestal de echte schade. Tien seconden verlies per handeling klinkt overzichtelijk, maar bij honderd handelingen op een dag is dat bijna zeventien minuten. Vermenigvuldig dat met een team van acht en met een werkjaar en je praat over weken.

1. Meet voordat je iets aanraakt

Zonder cijfers is optimaliseren gokken, en gokken is duur. Meet dus zowel de technische kant als wat gebruikers werkelijk ervaren. Een server die binnen tachtig milliseconden antwoordt zegt weinig als de browser er daarna nog twee seconden over doet om alles op het scherm te krijgen. Andersom staat een strak gebouwde front-end nog steeds stil zolang de database of een externe API niets teruggeeft.

Leg per belangrijk proces vast hoe lang een actie duurt, hoeveel fouten er optreden en waar de tijd precies blijft hangen. Responstijden van schermen en API's, de zwaarste queries, CPU en geheugen, wachttijden bij koppelingen. Zet daarna een rustig uur naast een piekmoment. Iets dat alleen onder druk misgaat vraagt om een andere oplossing dan iets dat altijd traag is.

Spreek meteen af wat goed genoeg is. Voor een eenvoudig scherm is dat een reactie binnen een seconde. Voor een rapportage over een half miljoen regels mag het langer duren, zolang de gebruiker maar ziet dat er iets gebeurt en niet gaat twijfelen of het systeem is vastgelopen. Prestatie gaat net zo goed over voorspelbaarheid als over snelheid.

2. Pak de trage queries aan

De database is meestal de stilste boosdoener in een groeiende applicatie. Een query die bij duizend records niemand opvalt, kan bij honderdduizend records ineens seconden kosten. De klassiekers: een ontbrekende index, een zoekopdracht die veel te breed is, een lijst die per regel opnieuw de database bevraagt, en rapportages die alles live proberen uit te rekenen.

Begin bij de queries die het vaakst draaien of de meeste tijd opsouperen. Controleer of de velden waarop je filtert, sorteert en koppelt geïndexeerd zijn. Haal alleen op wat je nodig hebt. Laad gerelateerde gegevens in één keer in plaats van per rij. En bij echt zware overzichten: reken vooraf uit of zet een export op de achtergrond klaar, in plaats van de gebruiker te laten wachten op een scherm dat alles in één klap wil doen.

3. Maak externe koppelingen minder bepalend

Een API-koppeling met een CRM, betaalprovider, voorraadsysteem of vervoerder is zo een sluipende vertraging, zeker als elke klik van de gebruiker op een antwoord van buiten moet wachten. En over de snelheid van die andere partij heb je nu eenmaal weinig te zeggen.

Loop je koppelingen langs en bepaal per stuk of directe verwerking echt nodig is. Statusupdates, rapportagedata en synchronisaties die niet kritisch zijn kunnen prima via een wachtrij op de achtergrond. De gebruiker gaat verder, de verwerking loopt door. Voor de koppelingen die wél direct moeten reageren regel je time-outs, nette foutafhandeling en een duidelijke melding. Als de betaalprovider er even uit ligt, mag dat niet betekenen dat de hele applicatie stilvalt.

4. Verminder wat de browser moet doen

Een applicatie kan technisch keurig in elkaar zitten en toch stroperig aanvoelen op een laptop van vier jaar oud of een telefoon met een matige verbinding. Grote JavaScript-bundels, ongecomprimeerde afbeeldingen, bibliotheken waarvan je nog twee functies gebruikt en schermen die bij het openen meteen alle data ophalen: het komt allemaal bij de gebruiker terecht.

Laad daarom pas wat nodig is op het moment dat het nodig is. Die uitgebreide grafiek onderaan het dashboard hoeft niet mee te komen als driekwart van de gebruikers er nooit naartoe scrolt. Kies passende afbeeldingsformaten en wees kritisch op scripts van derden. Ook voor interne tools telt dit: niet iedere collega zit op de nieuwste hardware.

Er zit wel een grens aan. Stel je te veel uit, dan krijg je een interface die staat te schokken of waarbij elke klik een nieuw wachtmoment oplevert. Het doel is niet om zo min mogelijk te laden, maar om het juiste op het juiste moment klaar te hebben.

5. Cache, maar met regels

Caching is de goedkoopste snelheidswinst die er is, simpelweg omdat je werk voorkomt dat je al eens gedaan hebt. Productinformatie die iedereen opvraagt, configuraties, veelgebruikte zoekresultaten, het antwoord van een externe API: sla het tijdelijk op en zowel de database als de server krijgt het rustiger.

Alleen vraagt caching wel om afspraken. In een catalogus is informatie van vijf minuten oud geen probleem. Bij voorraad, prijzen, rechten of financiële gegevens is dat het wel degelijk. Leg dus vast wat gecachet mag worden, hoe lang, en wanneer een cache na een wijziging actief ververst moet worden. Zonder die regels ruil je een traag scherm in voor een scherm dat snel het verkeerde laat zien, en dat is een slechtere ruil dan hij lijkt.

6. Stem hosting af op wat er echt gebeurt

Een applicatie heeft hosting nodig die past bij de belasting, de architectuur en de beschikbaarheid die je wilt bieden. Te weinig capaciteit levert wachttijden en storingen op. Te veel capaciteit kost geld en verbergt af en toe een probleem dat gewoon in de code zit. Het is dus geen kwestie van standaard een maatje groter nemen.

Kijk naar piekbelasting, geheugengebruik, de snelheid van je opslag, netwerkverkeer en de manier waarop achtergrondtaken draaien. Een webshop stelt andere eisen dan een intern planningssysteem of een SaaS-platform. Ook waar je database, applicatie en bestanden staan maakt uit. Als die onderdelen onnodig over verschillende omgevingen heen met elkaar praten, telt de vertraging per verzoek op.

Het scheelt bovendien enorm als ontwikkeling en hosting bij hetzelfde technische aanspreekpunt liggen. Bij een storing hoeft niemand dan eerst uit te zoeken of het aan de bouwer, de hoster of de koppeling ligt. Er kan direct gemeten, aangepast en gecontroleerd worden.

7. Test onder piek en houd het daarna bij

Een applicatie die soepel loopt met drie testgebruikers op een dinsdagmiddag is niet automatisch klaar voor een campagne, een maandafsluiting of de eerste maandag na de vakantie. Test dus scenario's die daarop lijken: tientallen gelijktijdige logins, veel zoekopdrachten achter elkaar, een grote import, een piek in bestellingen.

Zo'n test laat vooral zien waar de grens ligt en wat er gebeurt zodra je eroverheen gaat. Blijft de responstijd redelijk stabiel, of loopt de wachtrij binnen een minuut vol? Wordt de database het knelpunt, het geheugen, of toch die ene externe koppeling? Dat weet je liever voordat een gebruiker het meldt.

Daarna is het een kwestie van bijhouden. Nieuwe functies, groeiende tabellen, gewijzigde koppelingen en veranderend gebruikersgedrag schuiven de belasting continu op. Wat een half jaar geleden ruim voldoende was, kan nu een dagelijkse ergernis zijn. Plan periodieke controles op foutmeldingen, trage transacties en capaciteit, en stel waarschuwingen in voordat je tegen een grens aanloopt in plaats van erna.

Combineer die signalen met wat je uit de organisatie hoort. Een dashboard kan volledig groen staan terwijl de planningsafdeling elke ochtend vastloopt in één specifiek scherm dat technisch nooit als storing wordt herkend.

Waar begin je?

Niet met alles tegelijk. Kies één proces waarvan je kunt onderbouwen dat het tijd, omzet of vertrouwen kost. Meet hoe traag het echt is, pak de grootste oorzaak aan en meet daarna opnieuw of het verschil er ook werkelijk is. Dat is minder spectaculair dan een grote optimalisatieronde, maar het levert vrijwel altijd meer op. En het voorkomt dat je maanden werk steekt in een scherm waar niemand op zat te wachten.