AI-latentie temmen met SSE
Ik heb een AI-autocompletefunctie gebouwd. Gebruikers haatten het.
Elke toetsaanslag triggerde een AI-verzoek. Gebruikers moesten 2 tot 3 seconden wachten op een volledige JSON-respons. De UI voelde kapot aan. Ik heb debouncing en caching geprobeerd. Niets werkte. Het kernprobleem bleef hetzelfde: gebruikers zagen niets totdat het volledige antwoord binnen was.
Ik heb dit opgelost door Server-Sent Events (SSE) te gebruiken om responsen stukje bij beetje te streamen.
De oude workflow zag er zo uit:
- Gebruiker typt
- 300ms debounce
- HTTP POST-verzoek
- AI verwerkt (1-2 seconden)
- Server stuurt volledige respons terug
- Client rendert
Gebruikers zagen secondenlang een leeg scherm. Zelfs met een loading spinner voelde het traag aan.
Ik overwoog polling of WebSockets. Polling zorgt voor te veel overhead. WebSockets zijn te zwaar voor een eenrichtingsstroom.
Ik koos voor SSE omdat:
- Het werkt via eenrichtingsverkeer van server naar client
- Het eenvoudige tekst en JSON-chunks gebruikt
- Het automatisch opnieuw verbinding maakt als de verbinding wegvalt
- Het geen extra bibliotheken op je server vereist
De resultaten veranderden alles:
- Tijd tot de eerste visuele respons: van 2,1s naar 0,3s
- Gebruikersbetrokkenheid: 40% hoger
- Gebruikersklachten: nul
Streamen gaat over perceptie. Een progressieve UI voelt sneller aan dan een statische. Gebruikers geven er de voorkeur aan om woorden één voor één te zien verschijnen, in plaats van te wachten op een blok tekst.
Als je AI-responsen erg kort zijn, houd dan vast aan standaard verzoeken. Als je tweerichtingsverkeer nodig hebt, gebruik dan WebSockets. Maar voor de meeste AI-streamingbehoeften is SSE de beste keuze.
Hoe ga jij om met AI-latentie in je apps? Stream je, of wacht je op volledige responsen?