SizeCharts

De aanleiding is banaal en juist daarom interessant. Iemand vindt online een ring, een paar schoenen of een bh uit een ander land en weet niet welk getal daar bij hem hoort. De zoekopdracht die daaruit volgt is kort en letterlijk: ring size chart, US to EU shoe size, bra size calculator. Het is een vraag met een kort antwoord dat je kunt narekenen, want er ligt een fysieke maat onder waar je het aan kunt toetsen.

Wat er in die niche misgaat, is niet de kennis maar de presentatie. De tabel staat als afbeelding op de pagina, dus je kunt er niet in zoeken en een schermlezer kan er weinig mee. Het antwoord ligt onder een laag advertenties en een cookiedialoog. En vaak staat er niet bij waarop de conversie gebaseerd is, waardoor twee sites elkaar kunnen tegenspreken zonder dat je kunt zien wie gelijk heeft.

We zijn SizeCharts begonnen omdat dit een categorie is waar je met een rustige, snelle, eerlijke pagina simpelweg beter kunt zijn dan wat er staat. Niet door meer te bieden, maar door minder in de weg te zetten: de vraag komt binnen, het antwoord staat er, en eronder staat waarom het klopt.

SizeCharts heeft een eigen design-systeem. Geen template, geen CSS-framework, geen componentbibliotheek van de plank. De hele visuele taal staat in één handgeschreven stylesheet, opgebouwd uit designtokens die we per merk opnieuw bepalen. In de kop van dat bestand staat de opdracht aan onszelf samengevat: een warme retail-catalogus-esthetiek met een greige papierachtergrond, één terracotta accent, een meetlint-motief en humanistische typografie. Die regel is er niet voor de sier; hij is de toets waar elke latere toevoeging langs moet.

Die keuze komt voort uit het onderwerp. Maten nemen is fysiek werk. Het hoort bij een meetlint, een papieren strook om je vinger, een catalogus op tafel. Dus is de achtergrond geen wit software-vlak maar warm papier (#f6f1ea), is er één accentkleur (terracotta #c2683f) die we reserveren voor de plekken waar iets gebeurt, en loopt er een meetlint-motief door de interface: een streepje van 1 pixel om de 8 pixels, letterlijk de schaalverdeling van een liniaal. De koppen staan in een serif uit de systeemstack (Iowan Old Style, Palatino Linotype, Georgia), de rest in een humanistische schreefloze. De site haalt geen lettertypen van een externe CDN, dus er is geen extern verzoek nodig voordat de eerste letter goed staat.

Dark mode is geen bijzaak maar een vereiste, opgelost via een data-attribuut op de root met een eigen tokenset: papier wordt #211d1a en terracotta gaat lichter naar #e08b5f, zodat het accent op donker net zo leesbaar blijft als op licht. De kleurcombinaties zijn getoetst op WCAG AA-contrast, en er is een zichtbare toetsenbord-focusring in het accent, zodat wie met tab door een maattabel loopt kan zien waar hij is. Het resultaat is een site die aanvoelt als een naslagwerk in plaats van een dashboard.

De inhoudelijke kern van SizeCharts is een keuze die we vooraf hebben gemaakt: we converteren niet van label naar label, maar via de echte maat eronder. Een ring is een diameter in millimeters, een schoen is een voetlengte in centimeters, een hoed is een hoofdomtrek, een bh is onderbust en bust. De labels van landen zijn verschillende namen voor dezelfde fysieke afmeting. Wie dat als uitgangspunt neemt, houdt elke conversie herleidbaar tot een getal dat je zelf kunt natrekken, in plaats van tabellen aan elkaar te knopen waarvan de herkomst onderweg verdwijnt.

Die maten staan als getypeerde TypeScript-arrays in de repo, getoetst aan gepubliceerde internationale maatstandaarden. Geen database en geen CMS, dus een correctie is één regel in de code met een zichtbare geschiedenis erachter: je kunt zien wanneer een waarde is veranderd en waarom. Dezelfde tabellen voeden drie dingen tegelijk: de pagina's, een gratis statische JSON-API (per categorie een bestand plus een index) en een zelfstandige embed-widget die anderen in een iframe kunnen zetten. Die laatste twee worden bij elke build opnieuw uit de brondata gegenereerd, dus een correctie in de tabel landt in alle drie tegelijk in plaats van dat iemand eraan moet denken.

Waar het kan, maken we het antwoord fysiek. De ringmaatpagina drukt cirkels af op ware grootte, gerekend op 96 CSS-dpi (96 gedeeld door 25,4 is 3,7795 pixels per millimeter). Daarbij staat een kalibratiebalk ter breedte van een bankpas (85,6 mm), zodat je eerst kunt controleren of je printer op 100 procent staat voordat je de meting vertrouwt. Dat balkje is het eerlijkste onderdeel van de pagina: het geeft de bezoeker het gereedschap om ons ongelijk te geven voordat hij op de uitkomst afgaat. Je legt een ring die je al hebt op het papier en leest af. Dat is geen slimme feature, het is gewoon de kortste weg naar een goed antwoord.

Technisch is SizeCharts gebouwd op Next.js 16.2.9 met React 19.2.4 en TypeScript op de App Router. De afhankelijkhedenlijst bestaat uit drie regels: next, react en react-dom. Geen state-library, geen UI-kit, geen analytics-SDK, geen CSS-in-JS. De contentpagina's worden bij de build vooraf gerenderd. Ook de negen routes met een variabel segment, zoals de landenparen en de losse maatpagina's, krijgen hun volledige lijst bij de build mee en staan daarna als kant-en-klare HTML op de schijf; een adres dat niet in die lijst staat bestaat niet. Er is dus geen route die tijdens een bezoek nog iets moet uitrekenen.

Voor de bezoeker betekent dat twee concrete dingen. Het eerste is snelheid: er is niets om op te wachten, geen render-blokkerende bron en geen netwerkverzoek dat tussen jou en de tabel in staat. Het tweede is privacy, en dat is in deze categorie geen detail. Tijdens het gebruik van de tools draait de rekenlogica in de browser, dus je onderbust, je voetlengte of je hoofdomtrek gaat nergens heen. De enige plek waar de site wel een verzoek naar buiten doet is het contactformulier, dat een bericht post naar een extern endpoint, en dat staat volledig los van de maattabellen. In de gepubliceerde build staat verder geen analytics- of advertentiescript; de plekken die we daarvoor gereserveerd hebben renderen niets zolang de bijbehorende omgevingsvariabele niet aan staat, precies zodat er later geen layoutsprong ontstaat als daar ooit een besluit over valt.

Omdat er geen backend is die dingen kan afdwingen, controleren we de site met eigen scripts die we na elke build zelf draaien. Eén script crawlt de gerenderde HTML en eist nul gebroken interne links en nul wezen, dus elke contentpagina moet vanaf de homepage te bereiken zijn. Een tweede script leest de JSON-LD van de pagina's en eist dat die geldig is. Op de meest recente build melden ze 164 gecrawlde contentroutes zonder gebroken links of wezen, en 164 van de 164 pagina's met geldige structured data. Die scripts zijn geen formaliteit: ze staan als npm run crawl en npm run schema in de repo, ze stoppen met een foutcode zodra er iets niet klopt, en ze nemen de plaats in van een testomgeving met een database. Wat er nog niet is, is een hook die ze aan de build of de deploy koppelt. Het is dus een controle die wij bewust uitvoeren, geen poort die vanzelf dichtvalt, en dat is precies het soort automatisering dat hier nog te winnen valt.

Omdat de pagina's statisch zijn, is er niets te optimaliseren aan laadtijd achteraf: de HTML staat er al voordat de eerste bezoeker komt. De contentpagina's zetten hun eigen titel, omschrijving en canonical vanuit het routebestand zelf, dus de metadata zit vast aan de pagina waar hij over gaat in plaats van aan een centrale lijst die kan verlopen. De sitemap wordt niet met de hand bijgehouden maar gegenereerd uit hetzelfde categorie-register dat ook de navigatie en de homepage-grid aanstuurt, met prioriteiten per paginatype. Die sitemap bevat 164 URL's, evenveel als er contentpagina's zijn, en dat is een gevolg van één bron van waarheid.

Structured data ligt op alle 164 contentpagina's: WebApplication op de tools, FAQPage waar echte vragen staan, HowTo op de meetinstructies, en een kruimelpad op de pagina's die ergens in de boom hangen. De homepage draagt in plaats daarvan WebSite, WebApplication en FAQPage, omdat een kruimelpad naar jezelf niets toevoegt, en de internationale gids draagt CollectionPage omdat hij precies dat is: een verzameling die naar de categorieën doorverwijst. De social preview-afbeeldingen worden met next/og bij de build gerenderd, tien stuks, één per categorie plus de homepage en de internationale gids, in dezelfde huisstijl als de site. Er staat ook een llms.txt die de site en de kernreferenties beschrijft voor taalmodellen die hem uitlezen.

De long-tail vullen we programmatisch, maar alleen waar een echte zoekvraag bestaat. Landenparen krijgen een eigen pagina (ring, schoen, hoed, kleding, bh), en waar mensen op een concrete waarde zoeken gaan we een niveau dieper met pagina's per maat: een specifieke schoenmaat van EU naar US, een hoedmaat, een riemmaat, een herenmaat naar damesmaat. Wat we bewust niet doen is die pagina's met een sjabloontekst vullen: de intro's, de FAQ's en de meetstappen zijn per categorie met de hand geschreven op de zoekvraag van die categorie. Waar het antwoord voor een hele categorie hetzelfde is, staat het er ook hetzelfde. Het advies om bij twijfel een halve maat op te ronden geldt voor elke schoenmaat, en dat in tientallen varianten herschrijven zou de tekst slechter maken en de lezer niets opleveren. Uniek per pagina is wat de pagina uniek maakt; de rest mag gewoon het juiste antwoord zijn.

SizeCharts is op 2 juli 2026 begonnen en staat live op mysizecharts.com. Het is geen prototype: acht categorieën zijn af, met per categorie een hub, een meetinstructie, een printbare tabel en waar zinvol extra pagina's zoals een bh-maatcalculator, kindermaten of herenringmaten. De site wordt onderhouden zoals we hem gebouwd hebben, met een changelog-pagina waarop staat wat er is gewijzigd en een datum die bij de data hoort.

Voor ons is deze site vooral een bewijsstuk. Hij laat zien dat we een merk vanaf nul neerzetten (naam, visuele taal, tone of voice), er een eigen design-systeem onder bouwen in plaats van een thema te kopen, de techniek zo kiezen dat de bezoeker er iets aan heeft in plaats van dat het cv er iets aan heeft, en de vindbaarheid inbakken in de architectuur in plaats van er achteraf tags overheen te strooien. Dat zijn dezelfde vier dingen die we voor opdrachtgevers doen.

En het houdt ons scherp. Een site zonder backend, zonder tracking en zonder advertenties heeft nergens iets om zich achter te verstoppen. Als een tabel niet klopt, een link kapot is of een pagina traag voelt, is dat direct zichtbaar. Wat we hier op onszelf uitproberen (statische generatie op schaal, programmatische pagina's die toch met de hand geschreven zijn, controlescripts als vangrail) nemen we mee naar het werk waar het echt om geld gaat.