Waarom ik met de frontend begin
Als je een nieuwe site bouwt, kun je allerlei kanten op. Ik heb er bewust voor gekozen om te beginnen bij de voorkant. Niet meteen allemaal losse pagina’s pixel voor pixel afwerken, maar eerst een fundament leggen dat overal hetzelfde werkt. Dat geeft rust in het ontwerp, snelheid in de uitvoering en minder gedoe als er later iets moet veranderen.
Waarom ik met de frontend begin
We zijn gestart met een klein, praktisch stijlkader. Denk aan keuzes voor lettergroottes, koppen, witruimte, knoppen en kaarten. Geen dikke brandguide, maar genoeg houvast om op elke pagina hetzelfde gevoel neer te zetten. Vanuit dat kader heb ik componenten gemaakt die steeds terugkomen: hero’s, kaarten, knoppen, lijstjes, tabbladen, CTA-secties. Door die onderdelen consequent te gebruiken, voelt de site meteen vertrouwd, ook als je er voor het eerst komt.
Tailwind zonder rommel
In de code draait alles op een strakke Tailwind-setup. We werken met één centrale input.css, zonder rommel. Regels op één lijn, geen commentaarblokken, en als een utility niet bestaat, fix ik dat direct. Secties krijgen altijd een eigen scope, zodat stijlen niet gaan rondzweven en elders problemen veroorzaken. Voor HTML die uit page builders komt, heb ik een aanpak waarbij de buitenste sectie de stijl draagt en ik binnenin nette, geneste selectors gebruik. Zo blijft de markup schoon en is het later eenvoudiger om dingen te verplaatsen of uit te breiden.
Snelheid als eis: WebP, afmetingen en lazy loading
Snelheid was vanaf het begin een harde eis. Grote afbeeldingen heb ik omgezet naar WebP en we letten op afmetingen, lazy loading en vaste breedte- en hoogte-attributen. Dat scheelt echt. In onze testcases ging een hero-beeld naar ongeveer twee tiende megabyte per stuk. Dat is prima voor pagespeed, zolang je de rest ook licht houdt. Verder geen overbodige JavaScript libraries. Als iets in HTML of CSS kan, dan doe ik dat. Daardoor blijven belangrijke metingen zoals LCP en CLS lekker stabiel.
Toegankelijkheid die je merkt in gebruik
Toegankelijkheid is geen extra laagje achteraf. Het zit in de keuzes die we steeds maken. Koppen volgen een logische volgorde, links hebben duidelijke hover- en focus-staten, en het kleurcontrast is op orde. Formulieren hebben labels die je met een schermlezer kunt begrijpen. Dit soort dingen zie je niet altijd direct, maar je merkt het wel in gebruiksgemak en uiteindelijk ook in SEO.
Responsive zonder gedoe
Responsiveness heb ik getest op verschillende schermformaten en apparaten. Nederlandse koppen kunnen lang zijn, dus ik zorg voor genoeg ruimte en nette afbreking. Beelden snijden mooi bij op mobiel, knoppen blijven groot genoeg om te tikken en kaarten behouden hun ritme. Het resultaat is geen spektakel, maar wel een site die gewoon klopt en rustig oogt op elk scherm.
Subtiele interacties, geen fratsen
Animatie doe ik alleen als het helpt. Een subtiele schaduw op een kaart bij hover, een korte overgang bij een knop, of een zachte fade wanneer je een tab wisselt. Geen flitsende fratsen die de boel trager maken. De bedoeling is dat de site snel en betrouwbaar voelt, niet dat hij probeert te imponeren.
Klaar voor WordPress en groei
Het fijne van deze aanpak is dat alles klaarstaat voor WordPress. Omdat elk onderdeel al een duidelijke HTML-structuur heeft, kan ik het zonder gedoe omzetten naar Gutenberg-blokken. Dat lees je in deel twee. Ben je vooral op zoek naar hulp bij de voorkant, kijk dan bij frontend development en als snelheid jouw grootste zorg is, begin dan bij website snelheid optimaliseren. Wil je dat de site ook na livegang vlot en veilig blijft, dan past WordPress onderhoud daar mooi bij. En wie alles in één keer goed wil neerzetten, komt vaak uit bij een maatwerk WordPress thema.
De kern is simpel. Een nette frontend bespaart later tijd en frustratie. Pagina’s worden sneller, consistenter en makkelijker te beheren. En als er iets verandert in je bedrijf of aanbod, dan hoef je niet overal te sleutelen. Je bouwt het één keer goed, en plukt daar elke dag de vruchten van.