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 (23)

[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.

[cdwave]

Ik verbaas mij al jaren over de "constantheid" van performance.

Voor de eeuwwisseling duurde het doorgaans ongeveer een seconde om een webpagina te laden. Een beetje op het randje, het voelde niet snel, maar was niet irritant genoeg om er iets aan te doen.

Ruim een kwart eeuw later zijn de verbindingen van kilobits naar gigabits gegaan, hebben we multicore CPUs met 1000x de performance, en dikke GPUs om de pixels naar het scherm te pompen. Je zou verwachten dat een paginaatje met breipatronen sneller zou laden dan de refreshrate van je monitor, maar niets is minder waar.

Er zit "iets" in de ontwikkeling die ervoor zorgt dat webpagina's (en ook veel andere producten) altijd en eeuwig maar "net acceptabel" presteren, ze zijn zo traag dat je je eraan stoort, maar ook net snel genoeg dat men er niks aan gaat doen om dat te verbeteren. Dat de hardware zoveel sneller is geworden heeft blijkbaar geen enkel effect, die wordt alleen maar ingezet om nog zwaardere frameworks te kunnen supporten.

Ooit was een web frontend een "light weight" client. Tegenwoordig is een browser zo ongeveer de zwaarste applicatie die je maar kunt draaien op een general purpose machine.

[Tk55]

Webpagina’s (of webapplicaties!) kunnen natuurlijk steeds meer. Maar ik denk dat de echte reden is dat snelheid blijkbaar geen onderscheidende factor is. Anders gebruikten we met z’n allen de snelste websites en niet degene met de “beste” inhoud.

[Navi]

Meer features, meer tracking, meer reclame, meer AI, meer abstractie in frameworks, etc.

Net als met bv Windows, zelfs het start menu openen kan tegenwoordig lang duren...

[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)

[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.

[KarlijnL]

Haha nee, wij hebben er wel vrede mee hoor We waren tot denk ik 9 maanden terug wel vrij sceptisch, maar de waarde die het inmiddels biedt is vele malen hoger dan ik had gedacht, juist om saai manueel werk weg te nemen. Het is zelfs super handig!

Maar - zo weet ik ook van andere developer summits, er wordt vaak achterdochtig gekeken naar AI, en soms ook zeer terecht. Om op AI te kunnen vertrouwen heb je wel guardrails nodig en sturing, nog los van de grotere impact die het kan/ zal hebben op de samenleving. En soms denk ik wel, ai, we gaan te snel (no pun intended). En wij hebben de technische fundering, maar wat nou als je nu start als developer? Lijkt me lastig.

En overigens - dankjewel voor het warme welkom!

[NetAmp]

ai / AI, we gaan te snel

offtopic:
🤭 Als woordgrappen-'connaisseur' en Evert Kwok liefhebber, vind ik deze woordspeling leuk.

Lijkt me inderdaad lastig nu, als beginnende/junior developer. Direct krachtige tools tot je beschikking, maar waarschijnlijk nog amper ervaring opgedaan. Alsof je vorige week je rijbewijs behaalde en direct in een Ford Mustang (zo'n 315 tot 486 pk) stapt; op volle snelheid wegrijdend. 🏎️🏁 🫣 (Ter vergelijking bijv. een Volkswagen Polo met circa 95 pk).

[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.

[DaKluit]

Die groep is geïnteresseerd in een goede gebruikerservaring. Vandaar die ad-blocker. En nee, die willen inderdaad juist niet getracked worden. Ook daarom die ad-blocker.

[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

[The Zep Man]

"Baseer webperformance op de ervaring van echte gebruikers"

Maar ga het niet overdenken. Neem de snelheid van animaties in Android. Open de ontwikkelaarinstellingen en zet die op 0.5x i.p.v. 1x. Zie hoe je "ervaring" in het gebruik van Android verandert. "Meer snelheid" door bottlenecks weg te halen is beter.

Snelheid is vaak niet het probleem dat ik ondervind. Wel dat sites niet gericht zijn op het vlot vindbaar maken van de juiste informatie of het uitzetten van de juiste actie. Ik was laatst naar hotelwebsites aan het kijken. Het valt soms tegen hoe erg je moet graven om achter het adres van een hotel te komen. Staat bijvoorbeeld niet in de footer of op de "over ons" pagina of bij de contactgegevens.

[Reactie gewijzigd door The Zep Man op 7 oktober 2026 13:08]

[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!

[lenwar]

content die tijdens het lezen verspringt

Dit is mijn persoonlijke frustratie voor mobiele sites. Dan wil je klikken op een knop, en dan verspringt hij ineens, en klik je, in het slechtste geval op het verkeerde, of helemaal nergens op, of juist wel.

Een gouden voorbeeld is de KPN Captive Portal bij de Albert Heijn.
Ik vind het fijn om met m'n telefoon met de AH-app te zelfscannen, waarvoor je de Wifi van het filiaal moet zitten. Dat gaat blijkbaar via een KPN-dienst, en krijg je dus die KPN Captive Portal. Die begint heel clean, en als je dan op 'Inloggen' wil klikken, dan bedenkt die site ineens dat 'ie' een grote foto wil plaatsen (alles om maar bandbreedte te verspillen omdat de marketingafdeling dat nodig acht?) waardoor die knop ineens omlaag schiet. Super-irritant. (en een typisch eerstewereldprobleem )

Een uitgever wil dat bezoekers blijven lezen en dat advertenties op tijd, maar zonder hinder worden geladen.

Dit gevoel heb ik niet. Ik krijg bij menig (niet alle) site (ongeacht wat voor site het is), het gevoel dat de site het liefst zo vol mogelijk staat met advertenties. (dus artikelen tussen de advertenties door.)

Al-met-met-al heb ik zelf het gevoel dat de (verkoop)marketingafdelingen van webdiensten de webdiensten zelf per definitive slechter maken voor de gebruiker. Veel websites lijken als doel te hebben om advertenties/marketing te laten zien (van welke aard dan ook) in plaats van content waar de gebruikers voor naar die website komen.
Iedereen snapt dat er slechts een paar manieren zijn om met een webdienst geld te verdienen valt. (advertenties (in de breedste zin), abonnementen, eenmalige aanschaf (van bijvoorbeeld een nieuwsartikel of zo), vrijwillige donaties of sponsoren (of anders zelf bekostigen (volgens mij zijn dit de 4/5 methoden))
We zien dit gedrag op veel sites, door webpagina's onnodig lang te maken (zodat er meer ruimte is voor advertenties) met veel lucht schrijven. (bijvoorbeeld een webpagina die gaat over 'hoe doe je xyz op abc'. Dan krijg je eerst een complete introductie product abc. Daarna een inleidend verhaal over wat xyz is, en waarom je het al dan niet zou moeten willen, om daarna in drie alinas's te schrijven dat het niet kan , of nog erger, dat ze doen alsof het kan, maar eigenlijk niet antwoord geven op de 'echte vraag'. Zoals deze lap tekst over manieren om de kleur van het accu-icoontje op iOS te veranderen. tldr: de kleuren omdraaien in je instellingen, je telefoon op 'energiebesparende stand' zetten, je telefoon aan de lader leggen of je accu leeg laten lopen. Ofwel Het kan niet, maar dan uitgekauwd in een lap tekst waar je gek van wordt , maar de pagina heeft wel lekker veel advertenties.

[Navi]

Het verspringen is ook een veelgebruikte truc om ad clicks te krijgen. Er springt altijd net een advertentie onder de muis..