14 aug 2025·4 min
Compiler-benadering van webprestaties: Rich Harris' visie
Een praktische blik op de compiler-benadering voor webprestaties: hoe compile-time output runtime-zware frameworks kan verslaan en een eenvoudig beslismodel.
Een praktische blik op de compiler-benadering voor webprestaties: hoe compile-time output runtime-zware frameworks kan verslaan en een eenvoudig beslismodel.
Gebruikers beschrijven prestaties zelden in technische termen. Ze zeggen dat de app zwaar aanvoelt. Pagina's doen er te lang over om iets te tonen, knoppen reageren laat en simpele acties zoals het openen van een menu, typen in een zoekveld of het wisselen van tabbladen haperen.
De symptomen zijn bekend: een trage eerste load (lege of halfgebouwde UI), trage interacties (klikken die pas na een pauze landen, haperend scrollen) en lange spinners na acties die direct zouden moeten voelen, zoals het opslaan van een formulier of het filteren van een lijst.
Veel daarvan is runtime-kost. In eenvoudige termen is het het werk dat de browser moet doen nadat de pagina is geladen om de app bruikbaar te maken: meer JavaScript downloaden, het parsen, uitvoeren, de UI bouwen, handlers koppelen en daarna extra werk bij elke update blijven doen. Zelfs op snelle apparaten is er een grens aan hoeveel JavaScript je door de browser kunt duwen voordat de ervaring begint te vertragen.
Prestatieproblemen sluipen er ook later in. Eerst is de app klein: een paar schermen, lichte data, simpele UI. Dan groeit het product. Marketing voegt trackers toe, design voegt rijkere componenten toe, teams voegen state, features, afhankelijkheden en personalisatie toe. Elke verandering lijkt op zichzelf onschuldig, maar het totaalwerk telt op.
Daarom gaan teams letten op compiler-first performance-ideeën. Het doel is meestal niet perfecte scores, maar blijven uitbrengen zonder dat de app elke maand trager wordt.
De meeste frontendframeworks helpen je twee dingen te doen: een app bouwen en de UI synchroon houden met data. Het belangrijkste verschil is wanneer dat tweede deel plaatsvindt.
Bij een runtime-zwaar framework gebeurt meer werk in de browser nadat de pagina is geladen. Je verstuurt een general-purpose runtime die veel gevallen aankan: veranderingen volgen, beslissen wat moet updaten en die updates toepassen. Die flexibiliteit is fijn voor ontwikkeling, maar het betekent vaak meer JavaScript om te downloaden, te parsen en uit te voeren voordat de UI klaar aanvoelt.
Bij compile-time optimalisatie verhuist meer van dat werk naar de buildstap. In plaats van de browser een grote set regels te sturen, analyseert de buildtool je componenten en genereert directere, app-specifieke code.
Een nuttig mentaal model:
De meeste echte producten zitten ergens in het midden. Compiler-first benaderingen sturen nog steeds wat runtime-code (routing, data fetching, animaties, error handling). Runtime-zware frameworks gebruiken ook build-time technieken (minificatie, code-splitting, server rendering) om het clientwerk te verkleinen. De praktische vraag is niet welk kamp “juist” is, maar welke mix bij je product past.
Rich Harris is een van de duidelijkste stemmen achter compiler-first frontendgedachten. Zijn argument is eenvoudig: doe meer werk vooraf zodat gebruikers minder code downloaden en de browser minder hoeft te doen.
De motivatie is praktisch. Veel runtime-zware frameworks sturen een general-purpose engine: componentlogica, reactiviteit, diffing, scheduling en helpers die voor elke mogelijke app moeten werken. Die flexibiliteit kost bytes en CPU. Zelfs als je UI klein is, kun je nog steeds betalen voor een grote runtime.
Een compiler-aanpak draait het model om. Tijdens buildtijd kijkt de compiler naar je daadwerkelijke componenten en genereert de specifieke DOM-updatecode die ze nodig hebben. Als een label nooit verandert, wordt het gewone HTML. Als maar één waarde verandert, wordt alleen het updatepad voor die waarde gegenereerd. In plaats van een generieke UI-machine te sturen, lever je output die op je product is toegesneden.
Dat leidt vaak tot een eenvoudig resultaat: minder framework-code naar gebruikers en minder werk bij elke interactie. Het is vooral merkbaar op low-end apparaten, waar extra runtime-overhead snel zichtbaar wordt.
Toch blijven er trade-offs:
Een praktische vuistregel: als je UI grotendeels op voorhand bekend is, kan een compiler strakke output genereren. Is je UI erg dynamisch of plugin-gedreven, dan kan een zwaardere runtime makkelijker zijn.
Compile-time optimalisatie verplaatst waar het werk gebeurt. Meer beslissingen worden tijdens de build genomen en minder werk blijft voor de browser.
Een zichtbaar resultaat is minder JavaScript dat je verzendt. Kleinere bundles verkorten netwerktijd, parsetijd en de vertraging voordat de pagina reageert op een tik of klik. Op mid-range telefoons doet dat er meer toe dan veel teams denken.
Compilers kunnen ook directere DOM-updates genereren. Wanneer de buildstap de structuur van een component kan zien, kan hij updatecode produceren die alleen de DOM-nodes aanraakt die echt veranderen, zonder zoveel lagen van abstractie bij elke interactie. Dit kan frequente updates sneller laten voelen, vooral in lijsten, tabellen en formulieren.
Build-time analyse kan ook tree-shaking en dead-codeverwijdering versterken. De winst is niet alleen kleinere bestanden, maar ook minder codepaden die de browser moet laden en uitvoeren.
Hydration is een ander gebied waar build-keuzes helpen. Hydration is de stap waarbij een server-gerenderde pagina interactief wordt door event handlers te koppelen en voldoende state in de browser te reconstrueren. Als de build kan markeren wat interactiviteit nodig heeft en wat niet, kun je het eerste-laadwerk verminderen.
Als bijeffect verbetert compilatie vaak CSS-scoping. De build kan klassen hernoemen, ongebruikte stijlen verwijderen en style-lekkage tussen componenten verminderen. Dat voorkomt onverwachte kosten naarmate de UI groeit.
Stel je een dashboard voor met filters en een grote datatabel. Een compiler-first aanpak kan de initiële load lichter houden, alleen de cellen updaten die na een filterklik veranderden en delen van de pagina vermijden te hydrateren die nooit interactief worden.
Een grotere runtime is niet per definitie slecht. Het koopt vaak flexibiliteit: patronen die pas tijdens runtime beslist worden, veel third-party componenten en werkwijzen die door de jaren heen zijn getest.
Runtime-zware frameworks blinken uit wanneer de UI-regels vaak veranderen. Heb je complexe routing, geneste layouts, rijke formulieren en een diepe state-modellen, dan voelt een volwassen runtime als een vangnet.
Een runtime helpt wanneer je wilt dat het framework veel afhandelt terwijl de app draait, niet alleen tijdens het bouwen. Dat kan teams dag na dag sneller maken, ook al voegt het overhead toe.
Veelvoorkomende voordelen zijn een groot ecosysteem, bekende patronen voor state en data fetching, sterke devtools, makkelijker plugin-achtige extensies en soepeler onboarding als je mensen uit de gebruikelijke talentpool aanneemt.
Teambekendheid is een echte kostenpost en een echte winst. Een iets langzamer framework waar je team vertrouwen in heeft kan beter presteren dan een snellere aanpak die retraining, striktere discipline of custom tooling vereist om valkuilen te vermijden.
Veel klachten over een “trage app” worden niet veroorzaakt door de framework-runtime. Als je pagina wacht op een trage API, zware afbeeldingen, te veel fonts of third-party scripts, lost een frameworkwissel het kernprobleem niet op.
Een intern admin-dashboard achter login voelt vaak prima aan met een grotere runtime, omdat gebruikers krachtige apparaten hebben en het werk wordt gedomineerd door tabellen, permissies en backend-queries.
“Voldoende snel” kan vroeg het juiste doel zijn. Als je nog productwaarde aan het bewijzen bent, houd de iteratiesnelheid hoog, stel basale budgetten en neem compiler-first complexiteit alleen aan als je bewijs hebt dat het verschil maakt.
Iteratiesnelheid is time-to-feedback: hoe snel kan iemand een scherm aanpassen, draaien, zien wat er kapot is en het repareren. Teams met een korte loop leveren vaker en leren sneller. Daarom voelen runtime-zware frameworks vroeg productief: bekende patronen, snelle resultaten, veel ingebouwde gedrag.
Prestatiewerk vertraagt die loop als het te vroeg of te breed wordt ingezet. Als elke pull request verandert in micro-optimalisatie-discussies, stopt het team met risico’s nemen. Als je een complex pipeline bouwt voordat je weet wat het product wordt, besteden mensen tijd aan tooling in plaats van aan gebruikers.
De truc is overeenstemming over wat “goed genoeg” betekent en binnen die grenzen itereren. Een performancebudget geeft je die grenzen. Het gaat niet om perfecte scores, maar om limieten die de ervaring beschermen en tegelijk ontwikkeling mogelijk houden.
Een praktisch budget kan omvatten:
Als je performance negeert, betaal je meestal later. Zodra een product groeit, wordt traagheid gekoppeld aan architectuurbeslissingen, niet alleen aan kleine tweaks. Een late rewrite betekent vaak features bevriezen, het team hertrainen en bestaande workflows breken.
Compiler-first tooling kan deze ruil verschuiven. Je accepteert mogelijk iets langere builds, maar vermindert het werk dat op elk apparaat bij elk bezoek gedaan moet worden.
Herzie budgetten naarmate het product zich bewijst. Bescherm vroeg de basis. Naarmate verkeer en omzet groeien, verscherp je de budgetten en investeer je waar veranderingen echte metrics beïnvloeden, niet ego.
Meestal is het niet alleen het netwerk—het is runtime-kost: de browser die JavaScript downloadt, parseert en uitvoert, de UI opbouwt en extra werk doet bij elke update.
Daarom kan een app op een krachtige laptop toch “zwaar” aanvoelen zodra de JavaScript-werkload groot wordt.
Ze hebben hetzelfde doel (minder werk op de client), maar het mechanisme verschilt.
Het betekent dat het framework je componenten tijdens buildtijd analyseert en code genereert die op jouw app is afgestemd, in plaats van een grote generieke UI-engine te versturen.
Het praktische voordeel is meestal kleinere bundles en minder CPU-werk tijdens interacties (klikken, typen, scrollen).
Begin met:
Meet altijd op representatieve apparaten en voer telkens hetzelfde gebruikerspad uit zodat je builds kunt vergelijken.
Ja, maar alleen als het knelpunt daadwerkelijk in het framework zit. Als je app wacht op trage API's, grote afbeeldingen, te veel lettertypen of externe scripts, lost een nieuw framework die problemen niet op.
Behandel frameworkkeuze als één van de hefbomen: verifieer eerst waar de tijd naartoe gaat—netwerk, JavaScript CPU, rendering of backend.
Kies runtime-zwaar wanneer je flexibiliteit en iteratiesnelheid nodig hebt:
Als de runtime niet jouw beperkende factor is, is het gemak vaak de extra bytes waard.
Een eenvoudige vuistregel:
Hybride werkt vaak het beste—leg de grenzen vast zodat de app geen verwarrende mix van aannames wordt.
Gebruik een budget dat het gevoel van de gebruiker beschermt zonder het uitbrengen te blokkeren. Bijvoorbeeld:
Budgetten zijn richtlijnen, geen wedstrijd om perfecte scores.
Hydration is het werk waarbij een server-gerenderde pagina interactief wordt door event handlers te koppelen en genoeg client-state op te bouwen.
Als je te veel hydrateert, kan de eerste laadtijd traag aanvoelen hoewel de HTML snel zichtbaar is. Build-time tooling kan soms verminderen wat echt interactief hoeft te zijn, zodat je minder hydrateert.
Een goede "thin slice" bevat de reële rommel:
Voor snelle prototyping kan Koder.ai helpen om web + backend-flow via chat te bouwen en de bron te exporteren, zodat je vroeg kunt meten zonder je aan een volledige rewrite te verbinden.