Je voelde het goed aan: het werd langzamer. De oorzaak was niet je code, maar iets wat eronder ontbrak. Hieronder: wat er echt aan de hand was, wat ik heb gefixt, en hoe je het zelf snel houdt terwijl je doorbouwt naar offerte tot facturatie.
1 fix
lost de "wordt steeds trager" klacht direct op: database-indexen
6 fixes
in deze PR, allemaal getest: build groen, 385 tests, 0 lint-errors
ja
je infrastructuur is prima om naar facturatie uit te breiden
De diagnose
Elke zoekopdracht las de hele tabel, regel voor regel.
Een database vindt rijen snel als er een index op staat: een soort register, zoals de inhoudsopgave van een boek. Zonder index moet hij bij elke vraag de hele tabel van boven naar beneden doorlopen. Dat valt niet op bij 50 projecten. Bij 500 of 5000 wordt het merkbaar trager, en precies dat voelde je.
Het bijzondere: je tabellen voor chat, relaties en offertes hadden wel netjes indexen. Alleen de oudste tabellen, lopende_projecten en familie, waren ooit in de Supabase-interface aangemaakt en hebben er nooit een gekregen. Dat is de hele verklaring voor "het werd langzamer".
Zonder index · full table scan
O(n) · de tijd groeit mee met elke rij die je toevoegt. Vandaag traag, morgen trager.
Met index · directe lookup
O(log n) · hij springt direct naar de juiste rij. Blijft snel, ook bij duizenden projecten.
Wat er is gefixt · 1 PR
Zes ingrepen, van zwaarst naar lichtst.
{{ICON_DB}}
Database-indexen op de planning-tabellen
Indexen op werknummer, divisie, deadline, de fase-kolommen en de "nu bezig"-tabel. Eén migratiebestand dat je in Supabase plakt.
dit is de grootste winst en lost letterlijk de "wordt steeds trager"-klacht op.
database
{{ICON_SHIELD}}
Eén gedeelde login-verbinding in plaats van 13
Elk onderdeel opende zijn eigen verbinding naar de inlogstatus. Nu is er één gedeelde, die alle schermen uitlezen.
één token-vernieuwing zette voorheen 13 schermen tegelijk aan het hertekenen.
render
{{ICON_ZAP}}
Tabelcellen hertekenen alleen zichzelf
Bij het typen in één cel werden voorheen alle ~15 cellen van elke zichtbare rij opnieuw getekend. Nu blijft dat netjes bij de cel die je bewerkt.
typen en opslaan in de planning voelt nu direct, niet stroperig.
render
{{ICON_PKG}}
PDF-bibliotheek pas laden bij gebruik
jsPDF (~350 KB) werd op elke projectpagina meegeladen, ook als je nooit een PDF maakt. Nu laadt het pas wanneer je op "Download" klikt.
de projectpagina opent met minder code en is dus sneller in beeld.
bundle
{{ICON_SCISSORS}}
Iconen- en grafiekpakketten uitdunnen
In next.config ingesteld dat alleen de iconen en grafiekdelen die je echt gebruikt in de browser belanden, niet het hele pakket.
kleinere download bij het openen, gratis winst zonder codewijziging.
bundle
{{ICON_TRASH}}
Acht debug-aanroepen verwijderd
Er stonden nog testaanroepen naar een lokaal log-adres (127.0.0.1:7576) in de laadpaden van projecten en offertes. Weggehaald.
opschoning: ze vuurden bij elke laadactie en lekten een sessie-id.
cleanup
Snel blijven · monitoring & QA
Hoe je het zelf snel houdt terwijl je doorbouwt.
Je hoeft geen performance-expert te worden. Met deze paar gewoontes en gratis tools zie je problemen aankomen voordat je ze voelt. Dit is wat ik zou aanzetten.
{{ICON_DB}} Supabase Performance Advisor
Zit al in je Supabase-dashboard. Hij scant je queries en zegt letterlijk welke index ontbreekt.
Database → Advisors → Performance: 1x per maand bekijken
Database → Query Performance: zie je traagste queries
Vuistregel: filter of sorteer je op een kolom? Zet er een index op.
{{ICON_PKG}} Bundle-grootte in de gaten
Voor je een zware bibliotheek toevoegt: kijk wat het kost in de browser.
ANALYZE=true npm run build
Opent een kaart van wat er in de browser-download zit
Zware lib die je zelden gebruikt? Laad hem lazy (zoals de PDF-fix)
{{ICON_GAUGE}} Lighthouse · snelheidscijfer
Zit in Chrome. Geeft een rapportcijfer en concrete tips per pagina.
Doe het opnieuw na grote wijzigingen, vergelijk de score
{{ICON_CHECK}} Check voor elke release
Je hebt dit script al. Eén commando dat alles controleert voor je live gaat.
npm run check:release
Draait lint + tests + build achter elkaar
Groen = veilig om te mergen. Rood = eerst fixen.
REGEL 01
Filter of sorteer je op een kolom? Geef hem een index.
REGEL 02
Haal nooit een hele tabel op als je maar een pagina toont.
REGEL 03
Zware bibliotheek? Laad hem pas op het moment van gebruik.
Voor later · al uitgezocht
Wat ik bewust heb laten liggen.
Niet alles hoort in deze PR. Deze drie zijn de moeite waard zodra je naar facturatie uitbreidt, maar ze raken meer aan en verdienen rustig testen. Ik heb de aanpak alvast voor je uitgezocht.
dashboard
Tellingen in de database doen. Het dashboard haalt nu alle rijen op en rekent in de browser. Met de indexen is dat snel genoeg, maar een database-functie die direct de totalen teruggeeft, blijft snel bij elke schaal.
berichten
Ongelezen-tellers slim ophalen. De chat-indicator haalt nu alle berichten van een project op om te tellen. Een telling in de database is lichter zodra projecten veel berichten krijgen.
offertes
Dezelfde cel-fix op de offertetabel. Exact dezelfde memo-truc als bij de planning, één scherm verder. Klein, maar even los testen.
Wat je hiervan meeneemt
Vier dingen die je nu zelf herkent.
"Wordt steeds trager" = bijna altijd een ontbrekende index.Het eerste wat je checkt als iets langzaam wordt naarmate de data groeit.
Snelheid is meestal niet "slechte code", maar te veel werk op het verkeerde moment.De hele tabel lezen, alles in de browser laden, alles tegelijk hertekenen. Doe minder, op het juiste moment.
Meten voor je optimaliseert.Advisor, Lighthouse en de bundle-analyzer zeggen je waar het zit. Gokken kost tijd.
Je fundament is goed.Paginering, React Query en code-splitting zaten er al in. Je kunt met vertrouwen doorbouwen naar facturatie.