ReadMyBrowser

"Wat is mijn user agent." "Wat is mijn IP-adres." "Wat is mijn schermresolutie." Het zijn vragen die mensen dagelijks intypen, vaak omdat ze een formulier moeten invullen, een bug moeten melden of gewoon willen weten wat een site eigenlijk van ze ziet. De antwoorden liggen al jaren klaar op pagina's die één waarde tonen, met daaromheen advertentieblokken en een cookiemuur. Je krijgt een string te zien, en verder niets.

Dat vonden we een gemiste kans, want de interessante vraag begint pas na het antwoord. Wat betekent die string. Waarom leest een website hem uit. Hoe uniek maakt hij je. En kun je er iets aan veranderen. Dat is het deel dat op de meeste van die pagina's ontbreekt, terwijl het het deel is dat iemand echt verder helpt.

ReadMyBrowser is daarom niet opgezet als een losse checktool, maar als een dashboard met een naslagwerk eronder. De homepage toont in één keer wat een site over je kan aflezen, verdeeld over zes categorieën: Browser, Network, Location, Display, Device en Privacy. Wie dieper wil, klikt door naar de pagina van dat ene signaal en krijgt daar het volledige verhaal.

De kern van de site is een catalogus van 32 eigenschappen in lib/properties.ts. Een eigenschap heeft daar niet alleen een label en een detector-id, maar ook een eigen inleiding van twee tot drie alinea's, een uitleg waarom sites het signaal verzamelen, een privacy-paragraaf, een sectie over wat je er zelf aan kunt doen en een eigen set veelgestelde vragen.

Die prose is per eigenschap geschreven, niet gegenereerd uit een sjabloon waarin alleen het onderwerp wisselt. Dat is een bewuste keuze en meteen de duurste: batterijstatus vraagt een ander verhaal dan WebGL-renderer of Do Not Track. De categorie-inleidingen gaan net zo ver. Op de Device-pagina staat bijvoorbeeld dat Firefox en Safari geheugen- en batterijgegevens expres achterhouden om een bekende trackingroute te blokkeren, en dat een lege kaart daar dus een privacyfunctie is en geen fout in de tool. Dat is precies het soort uitleg dat je op een pagina met alleen een waarde nooit krijgt, want daar ziet een lege kaart eruit als een kapotte kaart.

Dezelfde catalogus voedt allebei de verschijningsvormen. De homepage krijgt er een lichte kaartlijst uit, de 32 verdiepingspagina's en de zes categoriepagina's krijgen het volledige verhaal. Het prose-gedeelte blijft daarbij server-side, zodat de dashboardkaarten niet de hele tekstcatalogus meeslepen in de JavaScript-bundel. Eén bron van waarheid betekent hier vooral dat een correctie op een uitleg op één plek gebeurt en overal doorwerkt.

Bij dit onderwerp ligt één visuele richting voor de hand: zwart scherm, groene letters, terminalsfeer. Wij hebben daar bewust niet voor gekozen. Iemand die opzoekt wat een website van hem afleest, is meestal niet op zoek naar spanning maar naar geruststelling en duidelijkheid. Een alarmerend ontwerp zou de tool minder betrouwbaar maken, niet betrouwbaarder.

Het designsysteem staat daarom in een eigen stylesheet op CSS-variabelen, zonder framework en zonder template. De richting is die van een kalm productdashboard: koel leisteengrijs als basis, één zelfverzekerd blauw als accent, kaarten met ruime radius, veel witruimte, en monospace alleen waar het echt hoort, namelijk bij de ruwe waarden zelf. Licht is de standaard, met een uitgewerkt donker thema ernaast. In de header van het bestand staat de opdracht aan onszelf genoteerd, inclusief het punt dat de site zich moet onderscheiden van de andere sites in het netwerk. Die notitie staat er niet voor de sier: ze is het ijkpunt waar een latere wijziging aan getoetst wordt.

De typografie komt uit de systeemfont-stack. Geen externe fontloader, geen CDN, geen render-blocking resources. Dat is deels een prestatiekeuze, maar het past ook bij het onderwerp: als je pagina uitlegt hoeveel een website ongemerkt van je opvangt, is een fontverzoek naar een ander domein een vervelende tegenspraak. De Open Graph-kaarten volgen dezelfde taal, met een donkere navy achtergrond en dezelfde blauwe accentbalk, gerenderd als PNG omdat sociale platforms geen SVG tonen.

Technisch staat de site op Next.js 16 met de App Router, React 19 en TypeScript in strict mode. Er is geen database, en de inhoudspagina's worden bij de build vooraf gerenderd; de dynamische routes gebruiken generateStaticParams. Eén route valt buiten die regel: de iframe-widget leest de themakeuze uit een query-parameter en wordt daarom op verzoek gerenderd. De detectie zelf zit in lib/detect.ts en leest de standaard Web API's uit: navigator, screen, Intl, WebGL, de Network Information API en de rest.

Dat client-side model is hier geen technische voorkeur maar het hele punt. De site kan alleen geloofwaardig uitleggen wat websites over je te weten komen als hij zelf zo min mogelijk doorstuurt. Voor het merendeel van de kaarten lukt dat: de browser leest ze uit en er gaat niets de deur uit. Twee groepen kaarten kunnen dat niet, en daar zijn twee eigen routes op de edge runtime voor. De ene kaatst je publieke adres terug met de grove stadsindicatie die het hostingplatform er zelf al uit afleidt, zodat we geen extern keyless dienstje nodig hebben dat bij groei gaat rate-limiten. De andere zet coördinaten om naar een leesbaar adres, en draait alleen op de vijf kaarten die om je locatie vragen, nadat je daar expliciet toestemming voor hebt gegeven.

Die tweede route verdient een eerlijke voetnoot, en de site geeft hem ook. Een adres uit coördinaten halen kan de browser niet zelf; daarvoor gaan je coördinaten via onze route naar de publieke Nominatim-dienst van OpenStreetMap. Je locatie verlaat op dat moment dus wel je apparaat, en dat staat met zoveel woorden in de inleiding van de Location-categorie. Onze eigen routes loggen of bewaren niets, maar wat een derde partij met een verzoek doet, ligt buiten ons bereik, en dan is het netter om dat te zeggen dan om het weg te laten. Daarbuiten staat alleen nog het contactformulier, dat naar een endpoint elders in ons netwerk post en losstaat van de tool.

De sitemap bevat 49 inhoudelijke URL's: elf vaste pagina's, zes categoriepagina's en de 32 signaalpagina's. Pagina's krijgen een eigen title, meta description en canonical, opgebouwd uit dezelfde catalogus die ook de teksten levert, zodat de metadata niet apart onderhouden hoeft te worden. Een detail waar we bewust tijd in hebben gestoken is de datumstempel. Standaard zet je daar new Date() neer, waarna elke rebuild alle URL's als gewijzigd markeert, ook de pagina's waar niets aan veranderd is. Daar staat nu één centrale CONTENT_DATE die we alleen bijwerken als er echt inhoud verandert, zodat de signalen naar zoekmachines kloppen.

De gestructureerde data wordt gecontroleerd in plaats van gehoopt. De site gebruikt onder meer BreadcrumbList, FAQPage, WebApplication, ItemList, CollectionPage en Organization. Twee eigen scripts bewaken dat: crawl.mjs loopt de gebouwde site af en faalt bij een gebroken interne link of een pagina waar niets naartoe linkt, check-schema.mjs parseert de JSON-LD en faalt als een verplicht veld ontbreekt. Beide draaien op de build-output, dus een fout komt aan het licht voordat hij live staat en niet pas als een zoekmachine erover klaagt.

Daarnaast schrijft de build een llms.txt volgens de opkomende conventie, zodat taalmodellen een compacte kaart van de site krijgen. De uitbreiding is programmatisch van opzet: het patroon /what-is-my/[slug] en het UA-datamodel maken een volgende reeks pagina's een kwestie van data toevoegen, niet van pagina's naprogrammeren. Het groeipad staat uitgeschreven in post-launch.md en loopt van de huidige omvang naar tweehonderd-plus pagina's, met autoriteit eerst en verkeer als gevolg, niet andersom.

ReadMyBrowser is eigen werk. Niemand heeft het besteld, wij hebben de niche gekozen, het merk bedacht, het ontwerpsysteem geschreven, de 32 verhalen zelf getypt en de site live gezet. Dat maakt hem tot een eerlijke steekproef van hoe we werken als er geen briefing is om ons achter te verschuilen: welke keuzes maken we dan, en waar leggen we de lat.

De site geeft ook zonder verkeerscijfers antwoord op de vraag of zoiets goed in elkaar zit. Er staan controles op de build die falen als de interne linkstructuur wegzakt of als de gestructureerde data stukgaat. De inhoudscatalogus is één bestand waar dashboard, categoriepagina's en verdiepingspagina's uit lopen, dus onderhoud is één plek. De JSON-API onder public/api bestaat uit echte statische bestanden die de build genereert, dus die valt niet om als er ineens veel meer mensen langskomen dan verwacht. De embeddable widget is dat niet, omdat hij de themakeuze uit de URL leest, maar het blijft een lichte route zonder database erachter.

Diezelfde toon zit in de fingerprint-test, het scherpste voorbeeld van hoe we de uitleg en de tool aan elkaar knopen. Hij verzamelt elf signalen, waaronder een canvas-hash, de WebGL-renderer, tijdzone, kernen en geheugen, rekent er een stabiele hash uit en schat hoe uniek je bent. In de code staat er meteen bij dat de entropiecijfers illustratieve schattingen zijn voor educatief gebruik en geen precieze populatiemeting. Een tool die overdrijft over hoe uniek je bent, is zelf ook een vorm van misleiding, en dat is precies het gedrag waar deze site tegen bedoeld is. Wat een opdrachtgever hieraan heeft, is vooral het bewijs dat de positionering, het merk, de interface, de code en de vindbaarheid bij ons uit dezelfde hand komen, samen ontworpen in plaats van achteraf op elkaar gepast.