Alle AI SEO Marketing Design Code Wordpress Woocommerce HTML/CSS

Laadtoestanden en skeleton screens: zo maak je wachten draaglijk

Vertrekbord met treintijden in een stationshal

Je kunt een website tot op de milliseconde optimaliseren en toch de indruk wekken dat hij traag is. Andersom kan ook: een pagina die technisch niet sneller is dan die van de concurrent, maar die vlot áánvoelt. Het verschil zit zelden in de meting en bijna altijd in wat de bezoeker te zien krijgt terwijl hij wacht. Wachten is namelijk geen getal, het is een ervaring — en die kun je ontwerpen.

Wachten is een gevoel, geen meetwaarde

Uit gebruikersonderzoek komt steeds hetzelfde beeld: een wachttijd waarin iets zichtbaar gebeurt, wordt korter geschat dan een even lange wachttijd waarin het scherm stil blijft. Een leeg wit vlak dwingt de bezoeker zelf te bedenken wat er aan de hand is, en mensen vullen dat consequent negatief in: is er iets kapot, ben ik verkeerd geklikt, doet mijn verbinding het nog? Elke seconde onzekerheid weegt zwaarder dan een seconde waarin duidelijk is dat er gewerkt wordt.

Dat is meteen de kern van het ontwerpvraagstuk. Je hoeft de wachttijd niet altijd te verkorten. Je moet hem verklaarbaar maken.

Spinner, skeleton of helemaal niets

Onder ongeveer een kwart seconde: niets. Een draaiend icoontje dat even opflikkert en meteen weer verdwijnt, maakt de website juist onrustig. Laat de overgang gewoon gebeuren.
Tot ongeveer een seconde: een subtiele indicatie. Een knop die kort inactief wordt of een dunne voortgangsbalk bovenaan de pagina is genoeg. De bezoeker weet dat zijn klik is aangekomen.
Langer dan een seconde: een skeleton screen. Toon de vorm van de inhoud die eraan komt: grijze blokken op de plek van de afbeelding, streepjes op de plek van de tekst. De bezoeker ziet dan al hoe de pagina eruit gaat zien.
Langer dan ongeveer tien seconden: benoem de voortgang. Bij een upload of een zware berekening wil iemand weten hoever het is en hoelang het nog duurt. Een oneindig draaiend icoontje wekt hier de indruk dat het is vastgelopen.
Bij een fout: zeg wat er misging. De vervelendste laadtoestand is degene die eeuwig doorgaat omdat de achterliggende aanvraag stilletjes is mislukt.

Waarom een skeleton beter werkt dan een spinner

Een draaiend icoontje zegt alleen “wacht”. Een skeleton zegt “hier komt een afbeelding, daar drie regels tekst en onderaan een knop”. Dat verschil is groter dan het lijkt. De bezoeker kan tijdens het wachten al beginnen met kijken waar hij straks moet zijn, en als de echte inhoud verschijnt, komt die op de plek waar hij hem verwachtte. Er is geen moment van heroriëntatie.

Daar zit ook meteen de belangrijkste voorwaarde: het skelet moet dezelfde afmetingen hebben als de inhoud die erin komt. Klopt dat niet, dan springt de pagina alsnog op het moment van laden. Zo’n sprong is niet alleen irritant — als iemand net wilde klikken, klikt hij op iets anders — maar telt ook mee in de Core Web Vitals waar Google op let. Een slecht gemaakt skeleton screen is dus erger dan geen.

De valkuilen

Drie fouten kom je in de praktijk het vaakst tegen. De eerste is het skelet dat blijft staan omdat er geen maximale wachttijd is ingebouwd; na tien seconden grijze blokken denkt iedereen dat de site stuk is. De tweede is het skelet dat wordt getoond bij inhoud die al gecachet is en dus direct beschikbaar — dan bouw je een wachtmoment dat er niet hoefde te zijn. De derde is de bewegende glans die over veel skeletten heen loopt: subtiel is prima, maar een felle animatie die over het halve scherm pulseert, is precies zo vermoeiend als het klinkt. Houd er bovendien rekening mee dat een deel van je bezoekers in het besturingssysteem heeft aangegeven minder beweging te willen zien; die voorkeur kun je respecteren met één regel CSS.

Nog een stap verder: doen alsof het al klaar is

Bij handelingen die vrijwel altijd slagen, kun je het resultaat direct tonen en de verwerking op de achtergrond laten plaatsvinden. Denk aan een product dat meteen in de winkelwagen verschijnt of een hartje dat direct inkleurt. De bezoeker wacht dan nergens op. Voorwaarde is wel dat je netjes terugdraait en dat ook laat zien wanneer het achteraf tóch misgaat. Zonder die afhandeling verkoop je je bezoeker een resultaat dat er niet is — en dat is een duurdere fout dan een seconde extra wachten.

Conclusie

Laadtoestanden zijn geen technisch detail maar onderdeel van je ontwerp. Toon niets bij een korte wachttijd, een subtiele indicatie bij een middellange, en een skeleton screen zodra het langer duurt — met exact de afmetingen van de inhoud die komt. Bouw altijd een grens en een foutmelding in, en gebruik beweging met mate. Zo blijft dezelfde laadtijd hetzelfde aantal seconden, maar voelt je website merkbaar sneller.

Filters en paginering in je webshop: voorkom dat Google verdwaalt

Doolhof van groene heggen van bovenaf gezien

Filters zijn een zegen voor je bezoekers. Kleur, maat, merk, prijs: met een paar klikken staat precies het juiste rijtje producten in beeld. Maar wat voor een bezoeker één handige knop is, is voor Google een compleet nieuwe webpagina met een eigen adres. En omdat filters te combineren zijn, groeit dat aantal niet lineair maar explosief. Een webshop met zeven filters kan zonder het te merken tienduizenden adressen aanbieden — voor een paar honderd producten.

Hoe filters ongemerkt duizenden URL’s maken

Elke filterkeuze komt meestal als parameter achter je adres te staan. Kies je twee filters, dan ontstaat er een adres met twee parameters. Kies je ze in een andere volgorde, dan ontstaat er nóg een adres met exact dezelfde producten erop. Voeg sorteervolgorde, het aantal producten per pagina en paginering toe, en het aantal unieke adressen loopt hard op. Zoekmachines volgen die links gewoon, want ze staan als klikbare verwijzingen in je pagina.

Waarom dat een probleem is

Er zijn drie afzonderlijke problemen, en ze versterken elkaar. Ten eerste je crawlbudget: Google besteedt per website een beperkte hoeveelheid tijd aan het ophalen van pagina’s. Gaat die op aan filtercombinaties, dan blijven je nieuwe producten en je echte categoriepagina’s langer onopgemerkt. Ten tweede duplicate content: tientallen adressen met vrijwel dezelfde inhoud, waardoor Google zelf maar moet raden welke de belangrijkste is. En ten derde dunne pagina’s: een filtercombinatie die twee producten oplevert, is geen pagina waarmee je in de zoekresultaten wilt staan.

Zo pak je het aan

Zet een canonical naar de schone categoriepagina. Op elke gefilterde weergave geef je aan dat de ongefilterde categorie de hoofdversie is. Daarmee vertel je Google waar de waarde thuishoort.
Gebruik noindex met follow op filtercombinaties. De pagina hoeft niet in de zoekresultaten, maar de links naar je producten mogen wél gevolgd worden. Dat is de combinatie die je wilt.
Maak filterlinks onvindbaar voor crawlers waar dat kan. Filters die via JavaScript werken zonder een gewone link in de broncode, worden simpelweg niet als aparte pagina opgepikt.
Blokkeer sorteer- en weergaveparameters in robots.txt. Volgorde en aantal per pagina leveren nooit een pagina op die je geïndexeerd wilt hebben. Let op: blokkeer nooit een adres waar je een canonical of noindex op wilt laten werken, want dan leest Google die instructie niet meer.
Maak van je beste filters echte landingspagina’s. Wordt er veel gezocht op een specifieke combinatie, geef die dan een eigen adres, een eigen titel en een eigen stuk tekst. Dat is precies de pagina die je wél wilt laten ranken.

Paginering: houd het simpel

Voor doorgenummerde categoriepagina’s gold jaren de aanbeveling om met speciale verwijzingen aan te geven wat de vorige en volgende pagina was. Google gebruikt die signalen al geruime tijd niet meer. Wat nu telt, is veel eenvoudiger: zorg dat elke vervolgpagina een gewone, klikbare link heeft in de broncode, zodat producten op pagina vier ook echt bereikbaar zijn. Laat elke vervolgpagina naar zichzelf canoniek verwijzen, niet naar pagina één — anders verdwijnen de producten op de latere pagina’s uit beeld.

Werkt je overzicht met “meer laden” of oneindig scrollen, dan is er zonder gewone paginalinks vaak geen enkele route naar je oudere producten. Bied in dat geval altijd een klassieke paginering aan als alternatief, ook al gebruiken bezoekers hem nauwelijks.

Hoe controleer je of het goed staat?

Begin in Google Search Console bij het overzicht van geïndexeerde pagina’s. Zie je daar adressen met vraagtekens en filterparameters in staan, dan weet je genoeg. Kijk daarnaast naar het aantal gecrawlde pagina’s per dag: als dat een veelvoud is van het aantal pagina’s dat je werkelijk hebt, gaat er budget verloren. Een crawltool die je site doorloopt zoals Google dat doet, maakt in een half uur zichtbaar hoeveel unieke adressen je eigenlijk aanbiedt. Die uitkomst is voor de meeste webshopeigenaren een verrassing.

Conclusie

Filters en paginering zijn onmisbaar voor je bezoekers en verraderlijk voor je vindbaarheid. Laat Google weten welke versie de hoofdversie is, houd filtercombinaties uit de index maar laat de links wel volgen, en zorg dat elk product via gewone links bereikbaar blijft. Promoveer alleen die paar filtercombinaties waar echt op gezocht wordt tot volwaardige pagina’s. Dan werkt je webshop voor bezoekers én blijft je crawlbudget waar het hoort: bij je producten.

De checkout van je webshop optimaliseren: minder velden, meer bestellingen

Hardlopers springen over de waterbak tijdens een steeplechase

Een bezoeker heeft je website gevonden, je product bekeken, de reviews gelezen en op “in winkelwagen” geklikt. Al het moeilijke werk is gedaan. En dan haakt hij af bij het afrekenen. Dat is niet uitzonderlijk: van alle bezoekers die aan een checkout beginnen, maakt een aanzienlijk deel hem niet af. Het pijnlijke is dat dit de goedkoopste omzet is die er bestaat — deze mensen wílden al kopen. Je hoeft ze alleen niet meer kwijt te raken.

Waarom juist de checkout zoveel afhakers kent

In de rest van je webshop is de bezoeker aan het rondkijken. In de checkout moet hij ineens werk leveren: gegevens invullen, keuzes maken, zijn portemonnee pakken. Elke seconde twijfel is daar duurder dan waar dan ook op je site. En elke onnodige vraag is een aanleiding om te denken “ik doe het later wel” — waarna later meestal nooit wordt.

De standaardcheckout van WooCommerce is bovendien niet ontworpen voor jouw shop, maar voor alle shops. Hij vraagt daarom naar velden die jij misschien helemaal niet gebruikt, en toont een indeling die voor een fysiek product logisch is en voor een download totaal niet.

Schrap wat je niet gebruikt

Bedrijfsnaam: verkoop je aan consumenten, dan is dit veld pure ruis. Verkoop je aan bedrijven, dan hoort het er juist wel — maar dan als verplicht veld, niet als optie ertussen.
Tweede adresregel: zelden nodig en altijd verwarrend. Laat hem weg of verstop hem achter een klein linkje.
Telefoonnummer: alleen vragen als je klant er iets aan heeft, bijvoorbeeld omdat de bezorger belt. Vraag je het “voor het geval dat”, dan kost het je bestellingen.
Apart afwijkend afleveradres: houd dit standaard dichtgeklapt. De meeste mensen laten bezorgen op het adres dat ze net hebben ingevuld.
Verplicht account aanmaken: de klassieker. Bied afrekenen als gast aan en vraag pas ná de bestelling of iemand een wachtwoord wil instellen. Dan is de order al binnen.

De vuistregel: elk veld moet je kunnen verantwoorden met “hier gebeurt iets mee”. Kun je dat niet, dan gaat het eruit.

Eén pagina of meerdere stappen?

Hier bestaat geen universeel antwoord, en iedereen die dat wel beweert, verkoopt iets. Een checkout in één scherm werkt goed bij weinig velden en een simpel product: de klant ziet in één oogopslag dat het meevalt. Meerdere stappen werken beter bij veel invoer of meerdere bezorgopties, omdat elk scherm dan overzichtelijk blijft. Kies je voor stappen, laat dan altijd zien hoeveel er zijn en waar iemand zich bevindt. Een onbekend aantal stappen is precies het gevoel dat mensen doet afhaken.

Wat in beide gevallen helpt: houd het overzicht van de bestelling voortdurend zichtbaar, inclusief het eindbedrag met verzendkosten en btw. Onverwachte kosten die pas in de laatste stap opduiken, zijn de meest genoemde reden om een bestelling te laten staan.

Vertrouwen op het moment van betalen

Vlak voor het afrekenen bekruipt iedereen even de twijfel of dit wel goed zit. Dat is het moment om te laten zien dat het klopt. Toon de betaalmethoden als herkenbare logo’s, benoem kort je retourtermijn en zet je klantenservicegegevens in beeld in plaats van ze weg te stoppen in de footer. Heb je beoordelingen of een keurmerk, dan is dit de plek — niet je homepage. En zorg dat alles er op een telefoon net zo verzorgd uitziet, want daar wordt het merendeel van de bestellingen gedaan.

Meten waar het misgaat

Raden is zonde, want dit is uitstekend meetbaar. Zet een trechter op in je statistiekenpakket met de stappen winkelwagen, checkout en bedankpagina; het gat tussen twee stappen wijst je meteen de plek aan. Nog directer is een sessieopname: je ziet dan letterlijk bij welk veld iemand aarzelt, terugscrolt of afsluit. In de praktijk komt dat vaak neer op één specifieke oorzaak — een foutmelding die niet uitlegt wat er mis is, een verzendkeuze die pas laat verschijnt, of een postcodecontrole die buitenlandse adressen weigert.

Conclusie

De checkout is geen formulier maar de laatste meter van je verkoop. Schrap elk veld dat je niet gebruikt, laat afrekenen als gast toe, toon het eindbedrag vanaf het begin en maak op het moment van betalen zichtbaar dat je te vertrouwen bent. Meet daarna waar mensen alsnog afvallen en los dat ene punt op. Dit is de goedkoopste omzetgroei die je webshop te bieden heeft, want het publiek staat er al.

WP-CLI: je WordPress-website beheren vanaf de commandline

Mengpaneel met faders en draaiknoppen in een geluidsstudio

De meeste WordPress-beheerders kennen maar één manier om iets aan hun website te veranderen: inloggen op wp-admin en klikken. Dat werkt prima voor één website met tien plugins. Maar zodra je twintig sites onderhoudt, een verhuizing moet uitvoeren of een zoek-en-vervangactie over een database van een gigabyte wilt doen, wordt klikken de langzaamste route die er is. Daarvoor bestaat WP-CLI: dezelfde WordPress, maar bediend vanaf de commandline. Wie er eenmaal aan gewend is, gaat niet meer terug.

Wat is WP-CLI precies?

WP-CLI is de officiële commandline-tool voor WordPress. Je typt een commando in een terminal op de server en WordPress voert het uit — precies dezelfde functies die de beheeromgeving achter de schermen ook aanroept, alleen zonder de omweg van een browser. Je installeert plugins, draait updates, maakt gebruikers aan, exporteert de database of leest een instelling uit, allemaal met één regel. Bij vrijwel elke serieuze hostingpartij staat de tool al klaar; je hebt alleen SSH-toegang nodig.

Belangrijk om te begrijpen: WP-CLI is geen los systeem dat langs WordPress heen werkt. Het laadt je hele installatie, inclusief je thema en plugins. Wat je met een commando doet, is dus exact wat er via de beheeromgeving zou gebeuren — alleen sneller en herhaalbaar.

Waar het echt tijd scheelt

Updates over meerdere sites: plugins bijwerken op tien websites is via wp-admin tien keer inloggen. Met een commando en een lijstje sites is het één handeling die je bovendien in een script kunt vastleggen.
Verhuizingen: na het overzetten van een site moeten alle oude domeinnamen in de database vervangen worden. Dat is exact waar WP-CLI in uitblinkt, ook in geserialiseerde data waar een gewone SQL-vervanging je site sloopt.
Als je er niet meer in komt: een fatale fout door een plugin sluit je buiten wp-admin. Vanaf de commandline deactiveer je die plugin alsnog, ook als de voorkant plat ligt.
Opruimen: revisies, spamreacties, verlopen transients en oude ordergegevens verwijder je in seconden, zonder plugin die je er permanent bij moet installeren.
Herhaalbaar werk: een reeks commando’s in een script is een procedure die volgende keer identiek verloopt. Klikwerk is dat nooit.

Zoeken en vervangen: de belangrijkste reden

Als één functie WP-CLI rechtvaardigt, is het deze. WordPress slaat veel instellingen op als geserialiseerde data: een tekstformaat waarin de lengte van elke waarde is meegeschreven. Vervang je daarin met een gewone databasequery een lange domeinnaam door een kortere, dan klopt die lengte niet meer en wordt de hele waarde onbruikbaar. Het gevolg is een site waarvan de widgets leeg zijn, de thema-instellingen verdwenen en de paginabouwer niets meer terugvindt.

WP-CLI pakt geserialiseerde data correct uit, vervangt de tekst en pakt het weer in. Bovendien kun je de actie eerst als proefdraai uitvoeren: je ziet dan precies hoeveel vervangingen er in welke tabellen zouden plaatsvinden, zonder dat er iets verandert. Die proefdraai is bij elke verhuizing de stap die je nooit overslaat.

Waar je moet opletten

De commandline vraagt geen bevestiging en kent geen prullenbak. Een verkeerd getypt commando dat berichten verwijdert, is meteen definitief. Maak dus altijd eerst een export van je database — met WP-CLI zelf is dat één regel — en werk waar mogelijk eerst op een testomgeving. Let er ook op dat je commando’s uitvoert als de juiste gebruiker: draai je als root, dan kunnen bestanden ontstaan die je webserver daarna niet meer mag beschrijven.

Een laatste praktisch punt: sommige plugins zijn niet gebouwd voor gebruik buiten de browser en kunnen een commando laten vastlopen of onverwacht veel geheugen opeisen. Loopt een commando vast, dan is het tijdelijk overslaan van die ene plugin bijna altijd de oplossing.

Conclusie

WP-CLI verandert WordPress-beheer van klikwerk in een handeling die je kunt herhalen, vastleggen en overdragen. Voor eenvoudige sites is het een luxe, maar zodra je meerdere websites beheert, verhuist of een database moet aanpassen, is het het verschil tussen een middag werk en twee minuten. Begin klein: een proefdraai van een zoek-en-vervangactie, of een database-export voor je aan het werk gaat. De rest volgt vanzelf.