Dev Summit 2026: "Baseer webperformance op de ervaring van echte gebruikers"

Een hoge Lighthouse-score staat mooi in een rapport, maar vertelt nog niet of een website voor echte bezoekers prettig werkt. Karlijn Löwik, ceo en medeoprichter van RUMvision, wil webperformance daarom uit de frontendniche halen en begrijpelijk maken voor het hele ontwikkelteam. Tijdens de Tweakers Developers Summit laat ze in haar talk Code, RUM, fix, repeat: Core Web Vitals op autopilot zien hoe Real User Monitoring en AI samen kunnen helpen om vertragingen sneller te vinden en op te lossen. De AI mag daarbij speurwerk overnemen, maar de developer blijft aan de knoppen.

Karlijn woont in Groningen met haar man, webperformance consultant Erwin (en voormalig Dev Summit-spreker), en hun vijfjarige dochter. Haar loopbaan begon met een juridische studie, maar de dagelijkse praktijk bleek minder goed bij haar te passen. "Ik heb een hekel aan conflict. Ik help liever mensen, leg dingen graag uit en zorg liever voor oplossingen."

Via haar man en een tijdelijke klus belandde ze alsnog in de IT. Wat begon als ondersteuning bij de bedrijfsvoering, groeide uit tot een vaste rol binnen een webbureau. Daar ontdekte Karlijn dat ze technische onderwerpen goed kon vertalen en complexe discussies kon terugbrengen tot de kern. Haar loopbaan laat volgens haar zien dat ook een niet-technische achtergrond waardevol kan zijn in de IT.

RUMvision ontstond bijna vijf jaar geleden uit een praktisch dataprobleem. Het webbureau was gespecialiseerd in websitesnelheid, maar miste gebruikersdata waarmee het verbeteringen kon koppelen aan conversie. Karlijn was toen negen maanden zwanger en kan de startdatum daardoor nog precies terughalen. Lachend: "Mijn dochter en het bedrijf groeien min of meer tegelijk op." Als co-chair van de W3C RUM Community Group spreekt ze inmiddels met partijen als Google, Mozilla, Cloudflare en Akamai over meetmethoden, webstandaarden en Real User Monitoring.

Performance is meer dan een snelle pagina

Wie over webperformance praat, komt al snel uit bij laadtijden en technische scores. Karlijn gebruikt liever een bredere term: Sitespeed User Experience, afgekort SUX. "Snelheid is pas relevant wanneer die wordt gekoppeld aan wat een gebruiker daadwerkelijk ervaart. Een knop die niet reageert, content die tijdens het lezen verspringt of een advertentie die plotseling de halve pagina inneemt, voelt voor een bezoeker simpelweg alsof de site niet goed werkt."

Ook het woord performance is volgens haar op zichzelf te vaag. "XXL Nutrition denkt ook dat het in de performance zit. En de formule 1 ook." Bij websites draait het uiteindelijk om een veel concretere vraag: kunnen bezoekers zonder onnodige vertraging of frustratie doen waarvoor ze kwamen?

Dat doel verschilt per organisatie. Voor een webwinkel kan een snellere ervaring direct effect hebben op conversie. Een uitgever wil dat bezoekers blijven lezen en dat advertenties op tijd, maar zonder hinder worden geladen. Voor een overheidswebsite telt vooral dat belangrijke informatie bereikbaar blijft, ook via een slechte verbinding of tijdens een calamiteit. Seo kan een extra reden zijn om naar Core Web Vitals te kijken, maar mag volgens Karlijn nooit het vertrekpunt worden. De echte gebruiker moet centraal blijven staan.

Toch krijgt performance in veel organisaties vooral aandacht tijdens de bouw van een nieuwe website. Daarna stapelen de toevoegingen zich op: chatwidgets, heatmaps, consenttools, marketingpixels en losse scripts van externe partijen. Afzonderlijk lijken die ingrepen vaak beperkt, maar samen kunnen ze de ervaring flink vertragen. Vooral Google Tag Manager verandert geregeld in een ongecontroleerde verzamelplaats. "Elke marketeer heeft gratis toegang tot Google Tag Manager en pleurt er al die meuk in."

De snelle laptop van de developer is niet de norm

Een tweede valkuil is de aanname dat een gekozen platform of framework vanzelf snel is. Single-page applications (SPA's) kunnen voor developers prettig werken en na de eerste pageview vlot aanvoelen, maar de eerste laadbeurt kan zwaar zijn. Zeker wanneer veel JavaScript moet worden gedownload, geparset en uitgevoerd.

Op een recente MacBook en een snelle telefoon valt die belasting niet altijd op. Veel bezoekers gebruiken echter een goedkoper of ouder toestel. Juist daar kan zware JavaScript-code merkbaar ten koste gaan van interactiviteit. Karlijn: "Iedere developer heeft een mooie nieuwe shiny MacBook en een mooie snelle telefoon. Maar niet elke gebruiker heeft dat natuurlijk."

Dat betekent niet dat een SPA of JavaScript-framework per definitie verkeerd is. Het betekent wel dat teams moeten meten welke prijs hun technische keuzes hebben bij echte gebruikers. Een labtest op één krachtige machine is daarvoor onvoldoende.

Waarom één groene score niet genoeg is

De hoeveelheid tools en metrics maakt webperformance onnodig onoverzichtelijk, vindt Karlijn. Lighthouse levert een herkenbare cirkel met een score op, maar blijft een labtest. De test simuleert één situatie, kan niet als een echte bezoeker door de site klikken en stopt op een bepaald moment tijdens het laden. Alles wat daarna gebeurt door advertenties, interacties of dynamische content blijft grotendeels buiten beeld.

"Fantastische visual. Die wil iedereen", zegt Karlijn over het bekende rondje met een cijfer. Precies daardoor krijgt de score soms meer betekenis dan hij verdient. Teams optimaliseren dan voor het cijfer in plaats van voor hun bezoekers. "Je doet het uitstekend op LinkedIn, maar het levert geen geld op."

Core Web Vitals zijn een stap vooruit, omdat ze gegevens van echte Chrome-gebruikers bevatten. Maar ook deze openbare dataset heeft beperkingen. De cijfers worden over 28 dagen verzameld en laten vooral zien dát gebruikers een bepaalde ervaring hadden. Ze vertellen een developer niet automatisch welk script, element of deployment de verslechtering veroorzaakte.

Real User Monitoring vult dat gat. RUM verzamelt gegevens uit de browsers van daadwerkelijke bezoekers en laat veel sneller zien wat er na een wijziging gebeurt. Een team dat deployt, hoeft daardoor geen weken te wachten voordat een trend zichtbaar wordt. Soms is binnen een halfuur al duidelijk of de ervaring verbetert of juist achteruitgaat. De relevante vraag is dus niet welke dataset de mooiste score oplevert, maar welke informatie een team nodig heeft om een probleem echt op te lossen.

Code, RUM, fix, repeat

Tijdens haar talk introduceert Karlijn daarvoor de workflow Code, RUM, fix, repeat. Een team brengt een wijziging uit, volgt via echte gebruikersdata wat die wijziging doet, zoekt de oorzaak van een regressie, past de code aan en meet opnieuw. Bekende boosdoeners zijn zware scripts van externe partijen, verkeerd toegepaste lazy loading, cache-instellingen die onbedoeld blokkeren en hero-images die pas laat worden geladen.

De technische basis verandert minder snel dan soms wordt gedacht. Minder onnodig JavaScript versturen, afbeeldingen verstandig laden en goed cachen blijven relevante principes. Tegelijk nemen browsers steeds meer werk over dat vroeger via losse library's werd opgelost, zoals lazy loading. Developers moeten dus de basis blijven begrijpen, maar ook weten wat de browser inmiddels zelf kan.

Het probleem is dat RUM-data uit veel dimensies en uitsplitsingen bestaat. Voorheen konden vooral ervaren performanceconsultants daar snel de juiste conclusies uit trekken. AI maakt die kennis volgens Karlijn toegankelijker. RUMvision bouwde daarom een koppeling via het Model Context Protocol (MCP) waarmee developers RUM-data direct binnen hun eigen AI-workflow en codebase kunnen gebruiken. Het protocol geeft de assistent gecontroleerde toegang tot de relevante meetgegevens en context.

"Iedereen had ineens een MCP, dus wij hadden er blijkbaar ook één nodig."Karlijn geeft eerlijk toe dat het team aanvankelijk sceptisch was. "Iedereen had ineens een MCP, dus wij hadden er blijkbaar ook één nodig." De meerwaarde werd duidelijk toen de assistent analyses kon reproduceren waarvoor een consultant normaal uren door data en code zoekt. Een handmatige analyse van twee tot drie uur leverde in een test vrijwel hetzelfde advies op als een vraag aan de gekoppelde AI, maar dan binnen enkele minuten.

Een developer kan daardoor in gewone taal vragen waar een regressie vandaan komt. De AI gebruikt gegevens van echte bezoekers, zoekt een waarschijnlijke bottleneck in de code en kan een concrete aanpassing voorstellen. De kennis zit daarmee niet langer alleen in het hoofd van een kleine groep specialisten. Met gevoel voor understatement merkt ze op: "Dat is voor mijn Erwin niet zo goed nieuws. Maar voor veel developers en tweakers wel."

Autopilot betekent niet zonder piloot

AI neemt het denkwerk niet volledig over. Developers moeten beoordelen of een analyse klopt, een voorgestelde wijziging veilig is en welke gevolgen die elders heeft. Daarvoor blijft technische basiskennis nodig. Karlijn: "Wie niet begrijpt waarom grote hoeveelheden JavaScript problematisch kunnen zijn, kan ook moeilijk beoordelen of een gegenereerde oplossing logisch is."

Vooral junior developers lopen volgens haar risico. Zij beschikken over krachtige"Als organisaties over twee jaar besluiten dat AI niet meer mag worden gebruikt, kunnen developers hun systemen dan nog begrijpen en onderhouden?" hulpmiddelen, maar hebben nog weinig ervaring om fouten te herkennen. Teams mogen bovendien niet volledig afhankelijk worden van één assistent. "Als organisaties over twee jaar besluiten dat AI niet meer mag worden gebruikt, kunnen developers hun systemen dan nog begrijpen en onderhouden?"

De automatische piloot uit de titel van haar talk heeft dus nog altijd een menselijke gezagvoerder nodig. AI kan monitoring volgen, regressies aanwijzen en fixes voorbereiden; de developer bepaalt wat uiteindelijk naar productie gaat.

Zo wil Karlijn webperformance behapbaar maken voor teams waarin het onderwerp nu vaak tussen verschillende datasets en prioriteiten verdwijnt. Haar uitnodiging is direct: "Webperformance was altijd een ratjetoe aan data. Iedereen vond het belangrijk, maar niemand prioriteerde het. Ik ga vertellen hoe je dat wél doet, terwijl AI een deel van het werk overneemt."

Dev Summit 2026: Koop nu je kaartje voor de Tweakers Dev Summit 2026 en verdiep je in het complete programma!

Enthousiast geworden om Karlijns talk bij te wonen? Koop dan hier een kaartje. De verkoop van de kaarten gaat hard, dus wacht niet te lang. Meer informatie over het programma, workshops en de andere sprekers vind je op de aparte Dev Summit-website. We zien je heel graag eind oktober!

Reacties (14)

[Skyaero]

RUMvision, een website dat - om de eerste pagina te laden - 80 request doet, 4.7 MB gecomprimeerde data laad, een javascript error heeft en 8,5 seconden erover doet om alles te laden. En dat voor een generieke 13-in-dozijn bedrijfspagina.

"Do as I say, not as I do" is hier wel heel toepasselijk.

[KarlijnL]

Ah, maar er is een twist! Want juist als je denkt dat het aantal request een rol gaan spelen in echte gebruikerservaring, is dit een leuke talk om bij te wonen. Want we gaan dit soort percepties tackelen.

(ben overigens wel benieuwd naar de JS error, dus als je die hebt, graag!)

Karlijn (die net een account heeft aangemaakt hier op Tweakers)

[locke960]

Real User Monitoring vult dat gat. RUM verzamelt gegevens uit de browsers van daadwerkelijke bezoekers en laat veel sneller zien wat er na een wijziging gebeurt.

Werkt dit ook als er een adblocker geïnstalleerd is?
Dat aantal wordt steeds groter en juist dat deel van de bevolking is geïnteresseerd in de gebruikservaring.

[KarlijnL]

We kunnen het tracken, maar doen dat niet by default (ook om onze JS impact te beperken). Wel een interessante hoek om het zo te bekijken, jij denkt dat juist die groep gemeten wil worden? Ik heb ook wel discussies de andere kant op gevoerd namelijk.

[david-v]

Ik heb altijd een dubbel gevoel bij dit soort metingen. De zwakste schakel in het geheel bepaald de performance. Zeer oude en langzame computer/laptop, netwerk bottlenecks zoals slechte verbinding in huis of onderweg in de trein.

Er zijn nogal wat factoren die buiten de invloedssfeer liggen van de ontwikkelaar en dan moet je wel goed kijken waar je tijd in gaat steken. Voor mij is de performance van de backend cruciaal. Als dat al slecht is dan heb je een probleem. Dit is heel goed te meten en valt ook volledig onder jouw controle.

Aan de gebruikerskant valt er weinig te veranderen, behalve zo weinig mogelijke data over de lijn heen sturen, dus geen grote MB plaatjes maar zo klein mogelijk zonder verlies van kwaliteit en geen enorme datasets ophalen maar paginering, en geen zware grafische elementen gebruiken op je website.

[KarlijnL]

" De zwakste schakel in het geheel bepaald de performance. Zeer oude en langzame computer/laptop, netwerk bottlenecks zoals slechte verbinding in huis of onderweg in de trein. "

Dat is waar - dat is ook waarom binnen RUM performance over percentielen wordt gemeten. In de meeste gevallen zullen deze gevallen binnen de slechtste percentielen vallen (P95+), en is het de vraag hoever je wilt gaan hun ervaring te optimaliseren. Hangt er natuurlijk ook vanaf met welke insteek je dat doet - ben je bijvoorbeeld overheid en moet je juist de mensen helpen met het minste te besteden (data/ devices), dan kan het nog steeds een afweging zijn.

Maar die andere punten zijn leuk, want waar ga je tijd in steken? Ja, de backend is belangrijk, maar je zou verbaasd zijn hoe vaak die doorklinkt in de frontend, of dat die frontend juist geheel nieuwe issues veroorzaakt waar de backend niks mee te maken heeft.

Een layout shift. Een query string in ads die de cache mist. Een bfcache die (per ongeluk) geblokkeerd wordt, of een image die boven de vouw staat, maar wordt gelazyload.

Dat valt allemaal te veranderen. En als je weet hoeveel van je bezoekers wáár last van hebben, weet je precies waar je die tijd in moet steken om de meesten het snelst te helpen.

Overigens de Nederlandse gebruiker kan best wat hebben hoor, helemaal in Nederland (goed internet, goede devices - de grote image is met http2/3 niet vaak meer de grootste bottleneck)

Dus al met al - kom langs op Tweakers Developer Summit, lijkt me leuk hier verder over te praten

[NetAmp]

"Als organisaties over twee jaar besluiten dat AI niet meer mag worden gebruikt ..."

Is dat nog een optie? 🤔 Nu big tech ervoor zorgt dat AI (LLM) zowat overal in verweven wordt?

[KarlijnL]

Ik denk dat je gelijk hebt... Maar hey, hypothetisch kan men altijd filosoferen.

[NetAmp]

Welkom in de Tweakers community, Karlijn. Zou jij of Erwin nog terug willen, naar de werkwijze zonder AI ? Of zien jullie meer de voordelen ervan, dat:

"... AI een deel van het [speur]werk overneemt"

"...waarvoor een consultant normaal uren door data en code zoekt."

En dat het werk inhoudelijk verschuift naar andere (misschien wel leukere) taken, die AI (nog?) niet kan doen.

[kuurtjes]

Waarom SUX wanneer dit ook gewoon onder de UX valt?

[KarlijnL]

Weet je hoeveel slechte grappen ik kan maken met SUX? Waarom zou je me die lol ontnemen? Good SUX sells, bad SUX sucks. Een talk in New York: "SUX and the City". In Marbella: SUX on the beach. De grappen zijn eindeloos

Maar in alle eerlijkheid: omdat als we het over UX gaan hebben de meerderheid denkt dat het voornamelijk een CRO issue is. En CRO teams zijn dan weer een andere niche dan web performance optimalisatie. SUX is een onderdeel van UX, maar wel heel specifiek het stuk rond snelheid en laden.

[nachtnet]

Waarom moet er genoemd worden dat deze spreker een dochter van 5 heeft? Bij naam en toenaam? Heeft genoemde dochter niet ook gewoon recht om niet via een tweakers artikel voor altijd gekoppeld te zijn aan het werk van haar moeder en tweakers?
@Tweakers Partners

[Reactie gewijzigd door nachtnet op 7 oktober 2026 10:13]

[KarlijnL]

Goed punt. Ben er normaal aardig scherp op, zeker met foto's, maar in dit geval is dit even langs me gegaan in de revisie rondes. Mag van mij aangepast! Dank!

[Blitskikkert]

Aangepast!