Waarom je met AI gebouwde app traag aanvoelt (en wat je eraan doet)

Je met AI gebouwde app werkt. De knoppen gaan waar ze horen, de schermen lijnen op, de data slaat op. Maar er voelt iets niet goed. Pagina’s doen er net iets te lang over om te laden. Een lijst van vijftig items hangt een seconde. Op “opslaan” klikken laat je wachten, dan nog wat wachten, dan je afvragen of je opnieuw moet klikken. Er is niets kapot — het voelt gewoon traag.

Als je een niet-technische oprichter bent die lanceert met een AI-appbouwer, is dit een van de meest voorkomende “ik weet niet wat er mis is”-momenten. Het goede nieuws is dat 80% van de trage met AI gebouwde apps traag is om dezelfde handvol redenen. Geen ervan vereist dat je leert hoe databases werken. Ze hebben allemaal fixes die je in gewone taal aan je AI-bouwer kunt vragen.

Deze post is het spiekbriefje.

Waarom “traag” meestal vier dingen is

Wanneer gebruikers zeggen dat een app traag aanvoelt, bedoelen ze bijna nooit “de server is te zwak”. Ze bedoelen een van vier dingen:

1. De eerste weergave is traag — ze klikken op een link en staren twee seconden naar een blanco scherm voordat er iets verschijnt.
2. Een lange lijst is sloom — scrollen, filteren, of “al mijn projecten” laden duurt langer dan door Instagram scrollen.
3. Een actie duurt te lang zonder ze te vertellen wat er gebeurt — ze klikken op “opslaan” of “versturen” en er reageert niets zichtbaars.
4. De database krijgt te veel vragen — pagina’s die data uit meerdere plekken tonen, halen elk stuk apart op en stapelen de wachttijden op.

Dat is het. Bijna elke trage met AI gebouwde app die ik heb bekeken, is traag om een van die vier redenen. Hier is hoe je elke herkent en wat je je bouwer moet vragen eraan te doen.

Trage reden #1: de eerste weergave

Hoe het eruitziet: je klikt op een link naar je app, de URL-balk is klaar met laden, maar de pagina is een seconde of twee wit voordat er iets verschijnt.

Wat het meestal veroorzaakt: de app laadt elk stuk JavaScript dat hij misschien nodig heeft voordat hij je iets toont. AI-appbouwers neigen ertoe royaal te bundelen — beter iets opnemen dan missen — en die bundel wordt groter naarmate je meer functies toevoegt.

Wat je je AI-bouwer moet vragen: “De eerste pagina-lading voelt traag. Kun je de JavaScript-bundels splitsen per route zodat de homepage niet de hele beheerderssectie hoeft te downloaden?” Of, simpeler: “Voeg lazy loading toe voor routes die niet de homepage zijn.” De meeste moderne frameworks ondersteunen dit in een of twee regels config. De AI weet hoe — je moet er gewoon om vragen.

Terwijl je toch bezig bent: “Zijn er grote afbeeldingen op de landingspagina die we kunnen optimaliseren?” Een hero-foto van 4 MB tankt waargenomen snelheid meer dan welk codeprobleem dan ook.

Trage reden #2: de lange lijst

Hoe het eruitziet: je hebt een lijst — projecten, contacten, posts, wat dan ook — en zodra hij voorbij de veertig of vijftig items komt, hapert scrollen of duurt filteren een merkbare beat.

Wat het meestal veroorzaakt: de app rendert elk afzonderlijk item op de pagina tegelijk, zelfs degene die je niet kunt zien. Met tien items is dat prima. Met vijfhonderd verslikt de browser zich.

Wat je je AI-bouwer moet vragen: “De projectenlijst is traag wanneer er veel items zijn. Kunnen we paginering toevoegen, of de lijst virtualiseren zodat alleen de zichtbare rijen worden gerenderd?” Paginering (“toon er 20 per pagina, met volgende/vorige-knoppen”) is de makkelijkste fix. Virtualisatie (“render alleen wat op het scherm is terwijl de gebruiker scrolt”) voelt vlotter maar is iets meer werk. Beide is prima.

Als de lijst ook zoeken of filteren heeft: “Kan het zoekfilter op de server gebeuren in plaats van in de browser?” Server-side filteren betekent dat de browser alleen ooit de overeenkomende rijen vasthoudt, niet de hele dataset.

Trage reden #3: de stille wacht

Hoe het eruitziet: je klikt op “opslaan” of “versturen” of “genereren”. Er gebeurt niets zichtbaars. Twee seconden later werkt het scherm bij en besef je dat het de hele tijd werkte.

Wat het meestal veroorzaakt: de app doet echt werk — opslaan in een database, een API aanroepen — maar de AI-bouwer voegde geen laadstaat toe. Dus vanuit jouw oogpunt deed de klik niets.

Dit is eigenlijk geen prestatieprobleem. Het is een waargenomen prestatieprobleem, en die zijn vaak pijnlijker dan echte. Een actie van 200 milliseconden zonder feedback voelt trager dan een actie van 2 seconden met een spinner, want het brein van de gebruiker tast in het duister.

Wat je je AI-bouwer moet vragen: “Voeg een laadstaat toe aan elke knop die een actie in gang zet. Toon een spinner of ‘Opslaan…’-tekst terwijl hij werkt, en schakel de knop uit zodat gebruikers niet dubbel kunnen klikken.” Dit is de prestatiefix met het hoogste rendement in elke app en het kost vrijwel niets.

Terwijl je toch bezig bent: “Voor acties waarvan we weten wat het resultaat zal zijn, kunnen we de UI optimistisch bijwerken — de verandering meteen tonen en terugdraaien als de server hem weigert?” Optimistische updates zijn waarom de “like”-knop op sociale apps direct aanvoelt, zelfs wanneer je telefoon vreselijke ontvangst heeft.

Trage reden #4: de babbelzieke database

Hoe het eruitziet: een pagina die een lijst met items toont, elk met extra info — zoals een lijst met projecten met het aantal taken in elk — duurt veel langer om te laden dan een gewone lijst zou doen.

Wat het meestal veroorzaakt: de pagina laadt de projecten in één query, laadt dan het taakaantal voor elk project in een aparte query. Tien projecten? Elf queries. Honderd projecten? Honderdeneen. Dit heet een “N+1-query”, en het is de meest voorkomende databaseprestatiebug in met AI gebouwde apps, want de AI optimaliseert voor code die helder leest, niet voor code die efficiënt draait.

Wat je je AI-bouwer moet vragen: “Deze pagina maakt één query per item. Kunnen we alle gerelateerde data in één query ophalen — een join of een aggregaat?” Je hoeft niet te weten wat een van beide woorden betekent. De AI wel. De trage pagina laten zien en zeggen “ik denk dat dit een N+1-probleem heeft” is meestal genoeg.

Je kunt N+1-problemen zonder enige tool herkennen: open de pagina, tel hoe lang hij erover doet, voeg dan tien keer zoveel items toe aan de onderliggende lijst. Als de pagina nu tien keer trager is, heb je een N+1. Als hij maar een tikje trager is, niet.

Een woord over voortijdige optimalisatie

Een valkuil waar nieuwe bouwers in trappen: proberen elke pagina snel te maken voordat iemand de app gebruikt. Doe het niet.

Prestatiewerk heeft echte kosten. Paginering toevoegen aan een lijst die alleen ooit twintig rijen zal hebben, is verspilde moeite. Een pagina optimaliseren die twee keer per dag laadt, is verspilde moeite. Bundels splitsen voor een interne tool met drie gebruikers is verspilde moeite. Het juiste moment om een trage pagina te repareren, is wanneer je de pagina, de actie en een persoon die erdoor geïrriteerd was kunt noemen.

Dus bouw hem eerst normaal. Lanceer hem. Kijk hoe hij wordt gebruikt. Wanneer iets traag aanvoelt voor een echt persoon — inclusief jij — match het symptoom aan een van de vier categorieën hierboven en vraag om die specifieke fix. Je krijgt een snellere app zonder een week te besteden aan infrastructuur die je gebruikers nooit zullen opmerken.

Hoe je met je AI-bouwer over snelheid praat

Een patroon dat werkt: beschrijf het symptoom, niet de oplossing. De AI is veel beter in het kiezen van de juiste fix dan je zou verwachten, zolang hij weet wat er echt mis is.

Goede prompts om te kopiëren:

• “Wanneer ik de instellingenpagina open, is er een vertraging van een seconde voordat er iets verschijnt. Kunnen we uitvogelen wat de eerste weergave blokkeert?”
• “Het dashboard duurt langer om te laden dan de homepage, ook al toont het minder data. Kunnen we kijken naar hoe het zijn data ophaalt?”
• “Wanneer ik op de profielpagina op ‘wijzigingen opslaan’ klik, gebeurt er twee seconden niets. Voeg een laadstaat toe en zorg dat de knop niet dubbel kan worden geklikt.”
• “Test deze lijst met 500 nepitems en vertel me waar de vertragingen zitten.”

De laatste is ondergewaardeerd. De AI vragen om testdata te genereren en de pagina zelf te proberen, is een van de nuttigste dingen die je kunt doen. Het vindt vaak de trage plekken voordat je gebruikers dat doen — en stelt de fix voor in hetzelfde antwoord.

Snelheid in met AI gebouwde apps draait niet om magie. Het draait om weten in welke van de vier bakken je probleem valt, en vragen om de juiste fix in heldere woorden. Doe dat, en “voelt traag” wordt “voelt prima” met een handvol kleine, gerichte wijzigingen — geen herschrijving.