Onze eigen website, eindelijk live

Snel laden én makkelijk publiceren

We begonnen met twee wensen. De site moest razendsnel worden, met vier keer honderd in LighthouseWoordenboek · In het kortLighthouseLighthouse is een open-source tool van Google die webpagina's automatisch controleert op onder meer prestaties, toegankelijkheid, best practices en SEO.Lees meer⁠ als doel. Die tool van Google beoordeelt websites op snelheid, toegankelijkheid, best practices en SEO. Tegelijk wilden we de menu's, filters, carousels en formulieren die de website prettig maken om te gebruiken. Snelheid moest dus in de techniek zitten, door de hele site heen.

Daarnaast wilden we van het CMSWoordenboek · In het kortCMSEen CMS is software waarmee gebruikers digitale content kunnen aanmaken, ordenen, wijzigen en publiceren, meestal via een beheeromgeving.Lees meer⁠ af. We gebruikten Contentful en wilden onze pagina's vrij kunnen opbouwen. De ene keer een tekst met een foto, dan een rij kaarten, ergens een citaat; iedere pagina moest zijn eigen volgorde kunnen krijgen. Dat kun je prima modelleren in Contentful. Alleen was het invullen van al die blokken vervolgens zoveel werk dat het ons tegenhield om nieuwe content te publiceren.

Als softwarebureau brengen we een groot deel van de dag door in een teksteditor. Daar wilden we ook onze verhalen schrijven, met de vrijheid om blokken te verplaatsen of er eentje tussen te voegen. Kopiëren, plakken, aanpassen. Zo ontstond het idee om de pagina's als MarkdownWoordenboek · In het kortMarkdownMarkdown is een tekstnotatie waarmee je gewone tekst structuur geeft, bijvoorbeeld met koppen, lijsten, nadruk en links.Lees meer⁠ op te slaan en de website zelf de opmaak te laten verzorgen.

Waarom we graag in tekst werken

Het prettige van tekstbestanden merk je vooral als je iets wilt veranderen. We kunnen door alle pagina's zoeken, een term overal aanpassen of twee versies naast elkaar leggen. GitWoordenboek · In het kortversiebeheerVersiebeheer legt wijzigingen in code vast, inclusief wie wat heeft aangepast en wanneer. Zo kunnen ontwikkelaars samenwerken, veranderingen vergelijken en teruggaan naar een eerdere versie.Lees meer⁠ laat precies zien welke zinnen zijn gewijzigd. Een collega kan daarop reageren voordat de wijziging live gaat, en een eerdere versie is terug te halen. We kunnen in de editor blijven waarin we toch al werken.

Diezelfde bestanden zijn ook goed te gebruiken door scripts en AI-agents. Een agent kan de bestaande pagina's, onze schrijfafspraken en de componenten samen bekijken. Daarvoor hoeft hij geen CMS te bedienen of te raden welk invoerveld bij welk stukje van een pagina hoort. Het resultaat blijft een wijziging aan een leesbaar bestand, die we gewoon kunnen beoordelen.

Dat past bij iets waar we binnen 10KB breder mee bezig zijn: company as code. Onze website staat in 42KB, de repository waarin ook bedrijfskennis, handleidingen, werkwijzen en infrastructuur worden beheerd. We gebruiken versiebeheer en automatische controles dus ook voor werk dat je misschien eerder in een losse documentmap zou verwachten. Zo wordt kennis makkelijker terug te vinden en te gebruiken bij de volgende klus. Over 42KB en company as code vertellen we binnenkort meer in een reeks blogposts.

Van aanwijzing naar pagina

Hieronder kun je een ingekorte versie van het MDX-bestand vergelijken met de volledige dienstenpagina. Wijs een onderdeel aan om te zien welke regels erbij horen; dat werkt ook andersom. Met Tab ga je naar het volgende blok en met Shift+Tab naar het vorige. Het blok dat de focus krijgt, licht meteen op. Escape wist de markering; op een touchscreen tik je op een blok.

De plugins lezen de Markdown als een syntaxboom: ze weten welk stukje een kop is, welk stukje een alinea en waar een afbeelding staat. Daardoor kunnen ze bijvoorbeeld de kop en tekst onder een side-by-side-aanwijzing verzamelen en aan het juiste component meegeven. Een auteur schrijft de inhoud en kiest het patroon. De plugin regelt de vertaling naar de website.

Bovenaan het bestand, tussen de streepjes, staat de frontmatterWoordenboek · In het kortfrontmatterFrontmatter is een blok metadata aan het begin van een contentbestand, meestal met waarden die de gebruikte tool uitleest.Lees meer⁠, met bijvoorbeeld de titel, omschrijving en hoofdafbeelding. Ook daar hebben we werk uit handen gehaald. Onze frontmatterplugins koppelen taalversies, bouwen het kruimelpad en de SEO-gegevens, berekenen leestijd en zoeken gerelateerde artikelen. Ze bekijken daarvoor ook de andere pagina's. Via een centrale lijst met cases vullen ze bijvoorbeeld de casecarousels, zodat we op al die plekken niet steeds dezelfde kaart hoeven in te voeren. Ook de volgorde waarin de plugins hun werk doen ligt vast: eerst de taal en tags bepalen, daarna pas gerelateerde artikelen zoeken.

Een pagina hervatten, zonder hydration

Veel frameworks leveren eerst HTML en voeren daarna in de browser opnieuw de componentcode uit om de pagina interactief te maken. Ze herstellen onder meer welke knop bij welke functie hoort en wat de toestand van de applicatie is. Dat heet hydrationWoordenboek · In het korthydrationHydration is het proces waarbij een framework server-gerenderde HTML in de browser koppelt aan code en applicatiestatus om de pagina interactief te maken.Lees meer⁠. De pagina kan er dan al zijn, terwijl de browser nog bezig is haar klaar te maken voor gebruik.

Qwik bewaart die informatie bij de HTML. Een knop bevat als het ware al het adres van de code die bij die knop hoort. Het framework hoeft daarom bij binnenkomst niet eerst alle componenten opnieuw langs. Die aanpak heet resumability: hervatten. Vergelijk het met een opgeslagen spelletje; je gaat verder waar je gebleven was, met de benodigde toestand al vastgelegd.

Dat betekent niet dat er geen JavaScript meer is. Het menu moet nog steeds kunnen openen en het formulier moet reageren. Het verschil zit in wanneer de code nodig is. We kunnen die opdelen en gericht laden, zodat een bezoeker niet eerst de werking van de hele pagina hoeft binnen te halen om de eerste alinea te lezen.

Een foto krijgt meer dan één bestand

Voor afbeeldingen doen we veel werk tijdens de build, het moment waarop de bronbestanden in de publiceerbare website worden omgezet. Een grote foto wordt dan verkleind en gecomprimeerd tot verschillende varianten. Die berekening doen we bij het publiceren; bezoekers krijgen de bestanden die al klaarliggen.

De juiste variant hangt af van de ruimte die het beeld op de pagina krijgt én van het scherm. Een telefoon heeft meestal minder pixels nodig dan een groot beeldscherm, maar een scherp telefoonscherm kan wel een hogere pixeldichtheid hebben. Onze afbeeldingspipeline rekent daarom met de werkelijke breedtes van de componenten en maakt varianten voor meerdere schermgroottes en pixeldichtheden.

Met srcset geven we de browser een keuzelijst van die bestanden. Met sizes vertellen we hoeveel ruimte de afbeelding in de opmaak krijgt. Dat tweede detail bleek belangrijk: als de browser denkt dat een beeld breder wordt dan het werkelijk is, kiest hij alsnog een te groot bestand. Voor mobiele hero's hebben we daarom de opgegeven breedtes aangescherpt en een kleinere variant van 384 pixels toegevoegd. De hoofdafbeelding heeft bovendien een eigen mobiele uitsnede.

Eerst wat je meteen ziet

Ook een klein bestand kan te laat komen. De grote afbeelding bovenaan de pagina moet snel in beeld zijn; een foto helemaal onderaan kan best even wachten. We geven het eerste scherm daarom voorrang. Met een preload kondigen we de hero-afbeelding vroeg aan, zodat de browser die al kan ophalen voordat hij bij het beeld zelf aankomt. Die aankondiging gebruikt dezelfde afbeeldingsvarianten als de hero, anders zou een telefoon onbedoeld twee bestanden kunnen downloaden.

Beelden verder naar beneden gebruiken lazy loading: de browser haalt ze op wanneer ze in de buurt van het zichtbare deel komen. De afmetingen staan alvast in de HTML, zodat hij ruimte kan vrijhouden. Dat voorkomt dat tekst tijdens het laden ineens naar beneden springt.

Naast de beelden hebben we de opmaak aangepakt. CSS bepaalt hoe de pagina eruitziet. Het deel dat voor de eerste weergave nodig is, komt direct mee in de HTML. De overige styles kunnen daarna volgen. Vanilla Extract maakt die CSS tijdens de build, en de lettertypes serveren we als lokale, compacte WOFF2-bestanden. Met font-display: optional mag de browser bij een trage verbinding het beschikbare lettertype blijven gebruiken. Zo hoeft hij de tekst niet later alsnog te verschuiven om ons font in te passen.

Minder laden is niet altijd sneller

Tijdens het optimaliseren vonden we ook verrassingen. Onze algemene paginaroute importeerde aanvankelijk alle MDX-pagina's tegelijk. Dat was handig om mee te beginnen, maar een bezoeker kwam natuurlijk voor één pagina. We hebben de metadata voor de server en de laders voor de pagina-inhoud daarom gescheiden. Ook iconen importeren we nu expliciet, zodat een klein icoontje niet onbedoeld een hele verzameling code meetrekt. En hulpfuncties die alleen nodig zijn om stylesheets te bouwen, hebben we losgemaakt van de code die naar de browser gaat.

Bij Qwiks preloader namen we eerst een verkeerde afslag. Die haalt alvast code op die straks nodig kan zijn. Uitzetten scheelde downloads bij binnenkomst, maar bij het doorklikken moest de browser vervolgens bestanden na elkaar ophalen. De navigatie voelde daardoor trager. De preloader staat inmiddels weer aan; we hebben de indeling van de JavaScript-bundels verbeterd.

Dat is waarom we verder kijken dan het eerste laadmoment. De volgende klik, het openen van een menu en het invullen van een formulier horen net zo goed bij een snelle website.

Wat er uit de meting komt

Het Lighthouse-rapport laat 98 voor performance en 100 voor toegankelijkheid, best practices en SEO zien. Deze test simuleert een trage telefoon met een trage internetverbinding. In die meting verschijnt de eerste inhoud na 1,5 seconde en staat het grootste zichtbare element na 2,4 seconden op zijn plek. De gemeten blokkeertijd is 60 milliseconden, de layoutverschuiving 0. De pagina laat dus al inhoud zien terwijl de rest binnenkomt, met nauwelijks blokkerend rekenwerk en zonder verschuivingen in deze meting.

Die laatste twee punten zijn minstens zo prettig als een hoog cijfer. Een pagina die snel lijkt te laden maar niet op een tik reageert, voelt alsnog traag. En niemand vindt het fijn als een knop verspringt op het moment dat je erop wilt drukken. Daarom controleren we ook zelf of het menu meteen reageert en je vlot naar de volgende pagina kunt.

We kunnen weer verder schrijven

We hebben er lang over gedaan, maar de manier waarop we de site nu kunnen bijhouden past bij ons. Tekst, componenten en publicatie horen bij dezelfde werkwijze. Een verbetering aan een component komt op meerdere pagina's terug, en bij een nieuw verhaal kunnen we de blokken in de volgorde zetten die daarbij past. Precies waar we ooit tegenaan liepen in Contentful.

Helemaal klaar zal onze eigen website vast nooit zijn. Er is altijd nog een detail om mooier te maken of een download die kleiner kan. Maar de volgende keer dat we iets willen vertellen, staat de techniek ons in ieder geval een stuk minder in de weg.