ClickStorm

Er is een groep zoekopdrachten die al jaren stabiel is en waar het aanbod tekortschiet. Iemand wil weten hoe snel hij klikt, of een specifieke variant meten: tien seconden, één seconde, met de rechtermuisknop, met de spatiebalk, met een jitter- of butterfly-techniek. Het is een simpele vraag met een simpel antwoord, en toch levert de zoekmachine steeds hetzelfde beeld op: een pagina waar het klikvlak ingeklemd zit tussen advertenties, waar de teller pas reageert nadat er scripts zijn geladen, en waar de belofte in de titel niet overeenkomt met wat de tool daadwerkelijk doet.

Dat laatste is het interessantste probleem. Veel concurrenten hebben wel een pagina voor iedere duur, maar daarachter draait één en dezelfde generieke tool. Je landt op "10 second CPS test" en krijgt een keuzemenu waarin tien seconden toevallig ook een optie is. De zoeker heeft een scherpe vraag gesteld en krijgt een vaag antwoord terug. Wij zagen daar de opening: niet harder schreeuwen, maar per zoekintentie leveren wat er gevraagd wordt.

ClickStorm is daarop gebouwd. Vijftien testpagina's, elk met een eigen invalshoek, eigen tekst en een tool die al op de juiste stand staat. De 10-second-pagina biedt alleen tien seconden aan, zonder keuzemenu eromheen; hetzelfde geldt voor de pagina's voor 1, 5, 30, 60 en 100 seconden. De kohi-pagina houdt zich aan de korte bursts van 1, 5 en 10 seconden waar dat format uit voortkomt, en verwijst voor de lange runs door naar de hoofdtest. Dat is geen SEO-trucje maar een inhoudelijke keuze: als de pagina een specifieke vraag beantwoordt, mag de tool ook specifiek zijn.

Vijftien vergelijkbare pagina's is ongeveer het aantal waarbij een site uit elkaar begint te vallen. Je kopieert een bestand, past de titel aan, vergeet de canonical, en drie maanden later staan er vier pagina's met dezelfde meta-description. We hebben dat opgelost door het probleem om te draaien: niet vijftien pagina's die elk hun eigen waarheid bevatten, maar één registry waar die vijftien uit voortkomen.

In die registry staat per route één object met de slug, het pad, de H1, de title en meta-description, de homepagekaart, de categorie, welk testtype de pagina mount, welke duren die test aanbiedt, de introparagraaf, de prose-blokken, de FAQ en de lijst met verwante pagina's. Dat ene object voedt vervolgens de pagina zelf, de homepagekaarten, het interne-linkblok, de sitemap en de gestructureerde data. Volledig automatisch is het niet, en we schrijven dat liever op dan dat we het mooier maken: een route heeft een eigen bestand dat zijn slug hardcodeert, en de header- en footerlinks zijn met de hand gelegd. Een pagina toevoegen betekent dus een object, een routebestand en een footerlink. Vanaf dat punt volgen de metadata, de kaart, de sitemap, de gestructureerde data en de interne links vanzelf.

De teksten zijn daarbij geen bijzaak. Iedere testpagina heeft twee eigen prose-blokken en een eigen FAQ, geschreven vanuit het onderwerp van die pagina in plaats van uit een sjabloon. De 100-seconden-pagina gaat over uithoudingsvermogen en pacing, de jitter-pagina over spierspanning en waarom je moet stoppen bij pijn, de kohi-pagina over de Minecraft-PvP-achtergrond waar de term vandaan komt. Dat is bewust het duurste deel van het werk geweest: de structuur is overal hetzelfde, de inhoud niet, en juist dat verschil is wat een registry je niet cadeau doet.

ClickStorm heeft een eigen design-systeem. Geen template, geen Tailwind, geen componentbibliotheek. De dependency-lijst bestaat uit next, react en react-dom, en verder niets; de opmaak is handgeschreven CSS met een eigen tokenset bovenin, waarin achtergronden, panelen, randen, tekstkleuren, de twee merkaccenten en de statuskleuren voor goed, fout en waarschuwing zijn vastgelegd.

De visuele keuze volgt uit het onderwerp. Dit is een site over reactiesnelheid, arcade-achtige records en gaming, dus we zijn naar een donkere basis gegaan, bijna zwartpaars, met paars en cyaan als accenten en zachte gloed rond de interactieve elementen. De achtergrond is opgebouwd uit radiale verlopen die vanuit de bovenhoeken naar binnen vallen, waardoor het scherm eerder aanvoelt als een speelveld dan als een documentpagina. Voor de typografie combineren we Orbitron voor koppen en cijfers met Rajdhani voor de lopende tekst: het eerste geeft de scores hun display-karakter, het tweede houdt de uitleg leesbaar.

Het merkteken is een bliksemschicht die we als SVG hebben getekend, met een verloop van paars naar cyaan, en die dezelfde twee accentkleuren doortrekt naar het logo, de knoppen en de OG-afbeelding. Dat het geen framework is, merk je vooral aan wat er niet gebeurt: er wordt geen CSS meegestuurd voor componenten die de site nooit gebruikt. Belangrijker is wat het wél mogelijk maakte. Het klikvlak is het onderdeel waar alles om draait, en dat kon precies de vorm en het gedrag krijgen die het nodig had, in plaats van de vorm die een bibliotheek toevallig aanbiedt.

Achter de zeven testtypes zitten vier engines: één voor de klikvarianten, één voor de reactietijd, één voor de aim trainer en één voor de spatiebalk. Alle vier leggen de tijd vast met performance.now(). De klik-engine laat de countdown door requestAnimationFrame lopen in plaats van door een interval-timer die onder belasting achterloopt, en de aim trainer en de spatiebalkteller doen dat op dezelfde manier. De eerste klik start de klok en telt meteen als klik één, dus er gaat geen tijd verloren tussen starten en meten. Zodra de tijd om is springt het vlak op slot, zodat een naklik het resultaat niet meer kan opblazen.

Die zorgvuldigheid zit ook in de andere tests. De reactietijd wordt over vijf pogingen gemiddeld, want één losse meting zegt weinig over een menselijke reflex, en de wachttijd voor het groene signaal is per poging willekeurig tussen 1,2 en 3,5 seconde, zodat je hem niet kunt voorspellen. Die wachttijd loopt als enige via een gewone timer, maar het moment waarop het signaal groen wordt en het moment waarop jij klikt worden allebei met performance.now() vastgelegd, dus de meting zelf hangt niet af van de nauwkeurigheid van die timer. Klik je te vroeg, dan telt dat als valse start en gaat de poging opnieuw. De aim trainer rapporteert bewust twee getallen die tegen elkaar in werken, treffers en nauwkeurigheid, omdat alleen treffers tellen het verkeerde gedrag zou belonen. De rechtermuisknop-test onderdrukt het contextmenu binnen het klikvlak, en alleen daar, zodat de rest van de pagina normaal blijft werken.

Toegankelijkheid hebben we niet als sluitpost behandeld, ook al is dit een muisgedreven site. De klikvlakken zijn met het toetsenbord te bereiken en te bedienen, de statistiekenrij is een live region zodat een schermlezer de tussenstand meekrijgt, en de duurknoppen dragen aria-pressed. Op de CPS- en reactietest telt Enter of spatie als klik; de spatiebalkteller blokkeert Enter juist, omdat spatie daar het onderwerp van de test is en niet de bediening. De klikvlakken van de CPS-test en de reactietest reageren daarnaast op aanraking, en de aim trainer werkt op een tap. De spatiebalkteller vraagt om een fysieke toets en valt op een touch-only apparaat dus af. In plaats van dat te verzwijgen detecteert die pagina zo'n apparaat en wijst hij de bezoeker door naar de CPS-test.

De site draait op Next.js 16 met de App Router, React 19 en TypeScript in strict mode, en is statisch. Er zijn geen API-routes, geen revalidatie en geen dynamische overrides, en next.config.ts is leeg gebleven: de twintig routes worden bij de build gerenderd en daarna als kant-en-klare HTML uitgeleverd. Zodra de pagina geladen is, gaat er tijdens de test niets meer naar een server. De tool die je gebruikt, is de pagina die je al hebt gedownload.

Dat levert twee dingen op die in deze niche zeldzaam zijn. Het eerste is snelheid: bij een tool waar milliseconden het onderwerp zijn, is het niet acceptabel dat je twee seconden op een script staat te wachten voordat je kunt klikken. Het tweede is privacy, en die is hier niet cosmetisch. Er is geen backend om scores naartoe te sturen, dus ze worden ook nergens heen gestuurd. Je persoonlijke records staan in localStorage onder een eigen namespace, per testtype geprefixt en per pagina apart bewaard, en ze blijven op je apparaat. De toegang tot die opslag zit in try/catch, zodat de tests blijven werken als localStorage geblokkeerd is en de bezoeker alleen zijn record mist. Het contactformulier is de enige plek waar iets de deur uit gaat, en dat post rechtstreeks naar een gedeeld endpoint met een honeypot-veld tegen spam, zonder dat deze site daar een eigen server voor nodig heeft.

We hebben de commerciële laag alvast ingebouwd maar bewust uitgezet. De advertentieplek rendert niets zolang de betreffende omgevingsvariabele niet aanstaat, en reserveert vooraf een vaste hoogte, zodat de layout niet gaat schuiven op het moment dat er wel iets in komt. Welk advertentienetwerk het wordt, staat nog niet vast, dus die hoogte is voorlopig een aanname die we bij die keuze opnieuw ijken. De consent-banner is op dezelfde manier voorbereid, inert tot hij nodig is en met de aantekening in de code dat er dan een gecertificeerde CMP in moet voordat er een gepersonaliseerde advertentie laadt. Het alternatief, een advertentiemuur eerst en de gebruikerservaring daarna, is precies wat de rest van de niche doet.

Omdat de site statisch is, staat er volledig gerenderde HTML klaar op het moment dat een crawler langskomt. Elke route heeft een eigen canonical, en de vijftien testpagina's krijgen hun title, meta-description en OpenGraph- en Twitter-blok van één gedeelde metadata-functie. Die functie is er om een reden die makkelijk over het hoofd wordt gezien: een pagina die zelf een openGraph-object zet, vervangt daarmee het hele blok uit de root-layout, inclusief de og:image die daar vandaan zou komen. De testpagina's hebben eigen OG-teksten nodig en lopen daarom door die functie, die de afbeelding er weer in zet. De statische pagina's over, privacy, voorwaarden en contact houden hun og:image juist door er zelf geen te zetten, en de homepage erft titel en omschrijving van de layout. Twee routes naar hetzelfde resultaat, en het is het soort detail dat je één keer goed uitzoekt en daarna vastlegt in een comment. De OG-afbeelding zelf wordt via next/og gegenereerd in de kleuren van het merk, dus een gedeelde link ziet eruit als de site.

Voor de gestructureerde data zetten de testpagina's een JSON-LD-graph met een FAQPage en een BreadcrumbList, gevoed door dezelfde FAQ-items die de bezoeker op de pagina leest, zodat de twee niet uit de pas kunnen lopen zonder dat we het merken. De homepage zet een WebSite en een ItemList met de vijftien tests. In de sitemap zit een keuze die we bewust in een comment hebben vastgelegd: we stempelen geen lastModified. Elke URL bij elke build voorzien van de builddatum leert crawlers alleen maar dat het signaal niets betekent, dus laten we changeFrequency en priority het werk doen. In public staat daarnaast een llms.txt die de kernpagina's en een deel van de tests met een korte omschrijving opsomt, voor de generatieve zoekmachines die inmiddels net zo goed verkeer sturen als de klassieke. Dat bestand staat, net als de footerlinks, buiten de registry en loopt op dit moment achter op de vijftien: vier van de nieuwere testpagina's ontbreken er nog in. Dat is precies het soort onderhoud dat je alleen ziet als je een site blijft beheren in plaats van hem op te leveren, en het staat op de lijst.

Het interne linkwerk is ook handmatig gelegd, maar dan als keuze: een testpagina wijst naar vier tot zeven verwante pagina's die inhoudelijk logisch volgen, de 30-seconden-test naar 10 en 60 seconden, de jitter-test naar butterfly. Een automatisch afgeleide lijst zou hier vooral ruis opleveren. Zo ontstaat er een netwerk dat zowel voor een bezoeker als voor een crawler een begrijpelijke route vormt. Voor ons is ClickStorm het bewijs van iets breders: dat we een merk, een design-systeem, de techniek eronder en de vindbaarheid erboven zelf bouwen en zelf blijven onderhouden, en dat we die keuzes maken op basis van hoe het werk zich over jaren gedraagt in plaats van hoe het er bij oplevering uitziet.