Categorie:AlleAISEOMarketingDesignCodeWordpressWoocommerceHTML/CSS

WebP en AVIF: moderne afbeeldingsformaten voor een snellere website

Camera-objectief op een stapel boeken

Afbeeldingen zijn op de meeste websites veruit de zwaarste bestanden — vaak goed voor meer dan de helft van het totale laadgewicht. Jarenlang was de keuze simpel: JPEG voor foto’s, PNG voor logo’s en transparantie. Maar die formaten stammen uit de jaren negentig, en er zijn inmiddels opvolgers die hetzelfde beeld in een fractie van de bestandsgrootte leveren: WebP en AVIF. Wie ze goed inzet, maakt zijn website merkbaar sneller zonder ook maar iets aan het ontwerp te veranderen.

Wat zijn WebP en AVIF?

WebP (ontwikkeld door Google) en AVIF (gebaseerd op de AV1-videocodec) zijn moderne afbeeldingsformaten met veel slimmere compressie dan JPEG en PNG. In de praktijk is een WebP-bestand zo’n 25 tot 35 procent kleiner dan een vergelijkbare JPEG; AVIF gaat verder en haalt regelmatig 50 procent of meer besparing bij gelijke beeldkwaliteit. Beide ondersteunen transparantie (als vervanger van PNG) en animatie (als vervanger van GIF). Browserondersteuning is geen zorg meer: WebP werkt al jaren overal, en AVIF wordt inmiddels door alle grote browsers ondersteund.

Wat levert het op?

Kleinere afbeeldingen betekenen snellere laadtijden, en dat telt dubbel: bezoekers haken minder snel af, en Google gebruikt laadprestaties (Core Web Vitals, met name de LCP — het moment waarop het grootste beeld in beeld staat) als rankingfactor. Juist die LCP wordt meestal bepaald door een grote header- of productfoto. Diezelfde foto als AVIF in plaats van JPEG scheelt zomaar honderden kilobytes — winst die je direct terugziet in de meetcijfers van PageSpeed Insights. Voor webshops met honderden productfoto’s telt het ook op in bandbreedte- en opslagkosten.

Zo zet je het in op WordPress

Het goede nieuws: je hoeft niet handmatig duizenden afbeeldingen om te zetten. Er zijn drie routes. Eén: WordPress zelf ondersteunt het uploaden van WebP al een tijd, en recente versies kunnen uploads automatisch naar moderne formaten converteren. Twee: een optimalisatieplugin of -dienst (zoals ShortPixel, Imagify of Smush) converteert je hele mediabibliotheek op de achtergrond en serveert automatisch WebP of AVIF aan browsers die het aankunnen, met de originele JPEG als terugvaloptie. Drie: een CDN met beeldoptimalisatie doet de conversie on-the-fly, zonder iets aan je site te wijzigen. Voor de meeste sites is route twee de praktische keuze: eenmalig instellen, en elke toekomstige upload wordt automatisch geoptimaliseerd.

Waar je op moet letten

Een paar aandachtspunten. Controleer na het omzetten steekproefsgewijs de beeldkwaliteit — vooral AVIF kan bij agressieve instellingen detail gladstrijken in foto’s met veel structuur. Houd de originelen als bron; converteer altijd vanaf het origineel en niet van WebP naar AVIF. En vergeet de rest van de beeldhygiëne niet: het beste formaat helpt weinig als je een afbeelding van 4000 pixels breed laadt in een kader van 400 pixels. Juiste afmetingen, lazy loading voor beelden onder de vouw en een modern formaat vormen samen het complete pakket.

Conclusie

WebP en AVIF leveren hetzelfde beeld in de helft van de kilobytes, en elke serieuze browser kan ermee overweg. Met een optimalisatieplugin of CDN zet je je complete mediabibliotheek zonder handwerk om, met JPEG als vangnet voor de zeldzame uitzondering. Het is een van de weinige snelheidsoptimalisaties die niets kosten aan design of functionaliteit — gratis winst voor je bezoekers én je Google-scores.

Een WordPress-thema kiezen: waar let je op (en wanneer kies je maatwerk)?

Rek met kledingstukken om uit te kiezen

Wie een WordPress-website begint, staat voor een keuze uit letterlijk tienduizenden thema’s — gratis, premium, multipurpose, niche. De demo’s zien er allemaal prachtig uit. Toch is het thema een van de meest bepalende keuzes voor je website: het beïnvloedt je snelheid, je flexibiliteit en hoeveel je de komende jaren kwijt bent aan gedoe. In dit artikel lees je waar je op moet letten — en wanneer je beter om een thema héén kunt kiezen.

De demo is niet het product

Themademo’s zijn verkooppagina’s: volgeladen met professionele fotografie, perfecte teksten en elke denkbare module. Jouw site gaat er met jouw content anders uitzien — en dat is het eerlijke vertrekpunt bij het kiezen. Kijk daarom voorbij de demo en beoordeel het skelet: de typografie, de indelingsmogelijkheden, hoe het thema oogt met gewone content in plaats van modelfoto’s.

Waar je op let bij een kant-en-klaar thema

  • Snelheid: test de demo zelf in PageSpeed Insights. Veel populaire multipurpose-thema’s slepen megabytes aan scripts mee voor functies die jij nooit gebruikt — die rekening betaal je bij elke paginaweergave.
  • Onderhoud: wanneer was de laatste update? Een thema dat al een jaar stil ligt, wordt vroeg of laat een beveiligings- en compatibiliteitsprobleem.
  • Beoordelingen en verkoop: niet vanwege de sterren zelf, maar omdat een breed gebruikt thema langer onderhouden blijft.
  • Afhankelijkheden: vereist het thema een specifieke page builder of een sliert bijgeleverde premium-plugins? Elke afhankelijkheid is een toekomstig updateprobleem.
  • Mobiel: bekijk de demo op je telefoon, niet alleen op je laptop. Daar komt het merendeel van je bezoekers vandaan.

De verborgen kosten van het “doe-alles-thema”

Multipurpose-thema’s beloven dat je er élke website mee kunt bouwen, en dat klopt — maar tegen een prijs. Al die flexibiliteit betekent duizenden opties, zware page builders en code die overal rekening mee houdt. In de praktijk zien we het patroon steeds terug: het eerste jaar is iedereen blij, daarna beginnen de trage laadtijden, de conflicten na updates en de ontdekking dat die ene aanpassing “niet kan binnen het thema”. De site zit dan gevangen in zijn eigen fundament — en overstappen betekent opnieuw beginnen.

Wanneer maatwerk de logische keuze is

Een maatwerkthema — gebouwd op precies jouw ontwerp en jouw functionaliteit — draait die rekensom om. Het kost vooraf meer dan een thema van zestig euro, maar je krijgt er iets voor terug dat geen kant-en-klaar thema biedt: code die alléén doet wat jouw site nodig heeft (en dus snel is), een beheeromgeving die is ingericht op jouw content in plaats van duizend opties, en volledige vrijheid om door te ontwikkelen. Voor een hobbyproject is dat overdreven; voor een bedrijfswebsite die jaren mee moet, aanvragen moet opleveren en moet meegroeien, is het vaak de goedkopere keuze over de hele looptijd.

Conclusie

Kies je een kant-en-klaar thema, beoordeel het dan op snelheid, onderhoudsritme en afhankelijkheden — niet op de demo. En maak vooraf de eerlijke afweging: voor een serieuze bedrijfswebsite is een licht maatwerkthema over drie tot vijf jaar gerekend vaak sneller, stabieler én voordeliger dan een doe-alles-thema dat je nooit helemaal de jouwe kunt maken.

Je website verhuizen naar een andere hostingpartij: zo doe je het zonder downtime

Zeecontainers gestapeld in een haven

Trage servers, oplopende prijzen, ondermaatse support: er zijn genoeg redenen om je website naar een andere hostingpartij te verhuizen. Wat veel ondernemers tegenhoudt is de angst dat de site er tijdens de verhuizing uit ligt, of erger. Onterecht: met de juiste volgorde verhuis je een website zonder dat een bezoeker er iets van merkt. Dit is het stappenplan.

Stap 1: breng in kaart wat er verhuist

Een website is meer dan een mapje bestanden. Inventariseer vooraf: de websitebestanden en de database, maar ook e-mailadressen die op het domein draaien, SSL-certificaten, cronjobs (geplande taken) en eventuele koppelingen die aan een server-IP hangen. E-mail is de klassieke verrassing: wie alleen de website verhuist en vergeet dat de mailboxen bij dezelfde partij draaien, zit na de DNS-wijziging ineens zonder e-mail.

Stap 2: maak een volledige back-up

Maak een complete kopie van bestanden én database, en bewaar die ook lokaal — niet alleen bij de oude host. Dit is je vangnet: wat er ook misgaat, je kunt altijd terug.

Stap 3: zet de site klaar op de nieuwe host

Zet de kopie op de nieuwe hosting terwijl de oude site gewoon live blijft draaien. Voor WordPress betekent dit: bestanden overzetten, database importeren en de databasegegevens in wp-config.php bijwerken. Let bij de nieuwe omgeving op de PHP-versie (gebruik een recente, maar dezelfde of nieuwere dan de oude host) en zet vast een SSL-certificaat klaar.

Stap 4: test vóórdat je overschakelt

Dit is de stap die downtime voorkomt — en die de meeste doe-het-zelvers overslaan. Je kunt de nieuwe site testen alsof hij al live is, door op je eigen computer het domein tijdelijk naar het nieuwe server-IP te laten wijzen (via het zogeheten hosts-bestand, of met een voorbeeld-URL die veel hosts aanbieden). Loop dan alles na: laden alle pagina’s, werken de formulieren, doet de checkout het, staan alle afbeeldingen erop? Pas als de nieuwe omgeving foutloos werkt, ga je door.

Stap 5: verlaag de TTL en zet de DNS om

De daadwerkelijke “verhuizing” is één DNS-wijziging: het domein naar het nieuwe IP-adres laten wijzen. Twee professionele details maken het verschil. Verlaag een dag van tevoren de TTL (de cachetijd van je DNS-instellingen) naar bijvoorbeeld vijf minuten, zodat de overschakeling wereldwijd snel doorwerkt in plaats van uren te na-ijlen. En bevries wijzigingen: vanaf de laatste synchronisatie tot de DNS-omzetting geen nieuwe blogs, bestellingen verwerken op de oude omgeving, of formulierinzendingen — anders lopen oude en nieuwe database uit elkaar. Voor webshops plan je dit venster op een stil moment en synchroniseer je de database vlak vóór de omzetting nog één keer.

Stap 6: controleer en ruim op

Na de omzetting: controleer of het SSL-certificaat actief is, test formulieren en betalingen nogmaals, en houd de eerste dagen de logboeken en het e-mailverkeer in de gaten. Zeg de oude hosting pas op als alles aantoonbaar een paar weken goed draait — die overlap van één factuurmaand is goedkope verzekering.

Conclusie

Een hostingverhuizing zonder downtime draait om volgorde: eerst alles inventariseren (vergeet e-mail niet), dan de site op de nieuwe host opbouwen en volledig testen terwijl de oude gewoon doordraait, en pas als laatste stap de DNS omzetten met verlaagde TTL. Wie die discipline opbrengt, verhuist zonder dat ook maar één bezoeker het merkt.

Gebruikersrollen in WordPress: wie mag wat op je website?

Sleutel in een ouderwets deurslot

Bij veel WordPress-websites heeft iedereen die er ooit aan gewerkt heeft een beheerdersaccount: de stagiair die twee blogs plaatste, het oude marketingbureau, de neef die de site “even had opgezet”. Dat is niet alleen rommelig, het is een beveiligingsrisico van de eerste orde. WordPress heeft een prima rollensysteem ingebouwd — je moet het alleen wél gebruiken. In dit artikel lees je wat elke rol mag en hoe je het slim inricht.

De vijf standaardrollen

  • Beheerder (Administrator): mag álles — plugins en thema’s installeren, instellingen wijzigen, gebruikers aanmaken en verwijderen. Dit is de rol die je zo min mogelijk uitdeelt.
  • Redacteur (Editor): beheert alle content: schrijft, bewerkt en publiceert berichten en pagina’s, ook die van anderen. Kan níét aan plugins, thema’s of instellingen komen.
  • Auteur (Author): schrijft en publiceert alleen eigen berichten.
  • Schrijver (Contributor): schrijft concepten, maar publiceren doet een redacteur — handig voor gastbloggers of nieuwe collega’s.
  • Abonnee (Subscriber): kan alleen inloggen en het eigen profiel beheren; relevant voor sites met ledengedeeltes of reacties.

WooCommerce voegt daar nog rollen aan toe, zoals Shopmanager: die beheert producten en bestellingen zonder bij de rest van de site te kunnen.

De gouden regel: zo min mogelijk rechten

Het principe is simpel en heet in beveiligingsland “least privilege”: geef iedereen precies genoeg rechten voor zijn taak, en niets meer. De collega die blogs schrijft is een auteur of redacteur, geen beheerder. Waarom dat zo belangrijk is? Elk account kan gehackt, gephisht of vergeten worden. Wordt een redacteursaccount gekraakt, dan heeft de aanvaller je content. Wordt een beheerdersaccount gekraakt, dan heeft hij je hele website — inclusief de mogelijkheid om malware in plugins te verstoppen. Elke beheerder minder is een risico minder.

Ruim regelmatig op

Plan twee keer per jaar tien minuten voor gebruikersonderhoud. Loop de lijst door (Gebruikers → Alle gebruikers) en stel per account drie vragen: werkt deze persoon hier nog, heeft hij deze rol nog nodig, en is het e-mailadres nog actueel? Oud-medewerkers en ex-bureaus verwijder je — of je wijst hun content eerst toe aan een collega, WordPress vraagt daar netjes naar bij het verwijderen. Externe partijen die tijdelijk toegang nodig hebben (een ontwikkelaar, een SEO-specialist) geef je een eigen account met een passende rol, dat je na afloop weer verwijdert. Nooit je eigen inloggegevens delen: met een eigen account is achteraf te herleiden wie wat deed.

Maatwerk: rollen op maat

Soms passen de standaardrollen nét niet: de klantenservice moet bestellingen kunnen zien maar geen producten wijzigen, de tekstschrijver moet pagina’s bewerken maar niet publiceren. Rollen en rechten (capabilities) zijn in WordPress volledig aanpasbaar — met een plugin of een paar regels code maak je een rol die precies past. Zeker bij webshops en sites waar meerdere teams in werken is dat de moeite waard: het voorkomt zowel ongelukken als de verleiding om dan maar iedereen beheerder te maken.

Conclusie

Het WordPress-rollensysteem bestaat niet voor niets: geef elke gebruiker de lichtste rol die volstaat, houd het aantal beheerders op één of twee, en ruim de gebruikerslijst twee keer per jaar op. Het kost een kwartier per jaar en het dicht een van de meest onderschatte beveiligingsgaten die een website kan hebben.