De belangrijkste conclusie: WordPress genereert sinds versie 4.4 automatisch srcset- en sizes-attributen voor elke afbeelding — het probleem op de meeste sites is geen ontbrekende functie, maar een verkeerde sizes-waarde die de browser stilletjes vertelt een groter bestand te downloaden dan de lay-out daadwerkelijk nodig heeft. Dat ene attribuut corrigeren is meestal de meest impactvolle wijziging aan responsive afbeeldingen die je kunt doorvoeren.
Wat srcset en sizes daadwerkelijk doen
Een responsive <img>-tag in WordPress ziet er ongeveer zo uit:
<img src="image-1024x683.jpg"
srcset="image-300x200.jpg 300w, image-768x512.jpg 768w, image-1024x683.jpg 1024w"
sizes="(max-width: 600px) 100vw, 600px">
srcset somt de beschikbare bestandskandidaten en hun werkelijke pixelbreedtes op. sizes vertelt de browser hoe breed de afbeelding daadwerkelijk wordt weergegeven bij verschillende viewportbreedtes. De browser combineert beide, samen met de schermdichtheid van het apparaat, om het kleinste bestand te kiezen dat er nog scherp uitziet — voordat er iets wordt gedownload.
Dit is het deel dat het benadrukken waard is: de browser neemt de beslissing, niet WordPress en niet een plugin. Als sizes klopt, neemt de browser automatisch een goede beslissing. Als sizes fout is, neemt de browser een zelfverzekerde, snelle en foute beslissing — meestal in het voordeel van een groter bestand "voor de zekerheid".
Waar WordPress' standaardschatting misgaat
WordPress berekent een standaard sizes-waarde volgens een simpele regel: het gaat ervan uit dat de afbeelding op zijn eigen intrinsieke breedte wordt weergegeven, tot maximaal de viewportbreedte. Die aanname klopt voor een simpel blogbericht met één kolom. Ze gaat mis bij veel gangbare WordPress-lay-outs:
- Grid- en kolomlay-outs — een productgrid met 3 afbeeldingen per rij toont elke afbeelding op ongeveer een derde van de containerbreedte, niet op de volledige intrinsieke breedte van de afbeelding.
- Pagebuilder-lay-outs — Elementor, Divi en vergelijkbare builders stellen containerbreedtes vaak in via CSS, waar de PHP-berekening van
sizesin WordPress geen zicht op heeft. - Thema's met zijbalk — de daadwerkelijke inhoudskolom is smaller dan de viewport, maar de standaardberekening weet dat niet.
In elk geval wordt de browser verteld "deze afbeelding wordt bijna op volledige viewportbreedte weergegeven", dus downloadt hij een daarvoor gedimensioneerde kandidaat — ook al wordt de afbeelding veel kleiner op het scherm gerenderd.
Zo controleer je of jouw site dit probleem heeft
- Open de pagina in Chrome, klik met de rechtermuisknop op een inhoudsafbeelding en kies Inspecteren.
- Zoek in het Elements-paneel het
sizes-attribuut op de<img>-tag. - Vergelijk dit met de daadwerkelijk gerenderde breedte van de afbeelding — zichtbaar in het Computed-paneel als
width. - Als
sizesiets beweert dat dicht bij de volledige viewportbreedte ligt, maar de afbeelding wordt gerenderd op bijvoorbeeld 33% van de container, dan downloadt de browser zeer waarschijnlijk een bestand dat 2-3x groter is dan nodig.
Een snellere controle: open het tabblad Network, filter op Img, en vergelijk de pixelafmetingen van het gedownloade bestand (zichtbaar in het Preview-tabblad) met de gerenderde CSS-grootte. Een groot verschil tussen beide is het kenmerk van een kapotte sizes-waarde.
Het sizes-attribuut corrigeren
Voor de meeste thema's betekent dit dat je WordPress' standaardberekening overschrijft met een waarde die overeenkomt met je werkelijke lay-out, via het wp_calculate_image_sizes-filter:
add_filter('wp_calculate_image_sizes', function ($sizes, $size) {
return '(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw';
}, 10, 2);
De exacte breakpoints moeten overeenkomen met het werkelijke CSS-grid- of containergedrag van je thema — dit voorbeeld gaat uit van een lay-out met één kolom op mobiel, twee op tablet en drie op desktop. Controleer de echte breakpoints in het stylesheet van je thema in plaats van te raden.
De juiste afbeeldingsformaten meteen goed registreren
srcset kan alleen kandidaten aanbieden die daadwerkelijk bestaan. Als je thema alleen een 1024px- en een 300px-thumbnailformaat registreert, heeft de browser geen 600px-optie om te kiezen voor een middelgrote viewport — hij moet de dichtstbijzijnde beschikbare kiezen, die vaak nog steeds te groot is. Tussenformaten registreren met add_image_size() geeft de browser fijnmaziger keuzes:
| Formaatnaam | Breedte | Typisch gebruik |
|---|---|---|
| thumbnail | 150px | Adminlijsten, gerelateerde-berichtkaarten |
| medium | 600px | Mobiele inhoudsbreedte |
| medium_large | 900px | Tablet-inhoudsbreedte |
| large | 1200px | Desktop-inhoudsbreedte |
| full | Originele upload | Zelden de juiste keuze om direct te serveren |
Een formaat registreren genereert het niet met terugwerkende kracht voor al geüploade afbeeldingen — nieuwe formaten gelden alleen voortaan, of nadat je een regeneratietool op bestaande media hebt uitgevoerd.
Een concreet voorbeeld
Bij een recente audit van een WordPress-blog met een grid van gerelateerde berichten in 3 kolommen beweerde het standaard sizes-attribuut dat elke thumbnail bij alle schermformaten op 100vw (volledige viewportbreedte) werd weergegeven. In werkelijkheid werd elke thumbnail op desktop op ongeveer 320px gerenderd.
| Voor de fix | Na de fix | |
|---|---|---|
| Door browser gekozen kandidaat | 1024px breed bestand | 384px breed bestand |
| Gemiddelde bestandsgrootte per thumbnail | 145 KB | 38 KB |
| Totaalgewicht voor een grid van 6 thumbnails | 870 KB | 228 KB |
Het corrigeren van één sizes-filter bespaarde op die ene pagina zo'n 640 KB — meer dan de meeste afbeeldingscompressie-instellingen alleen zouden bereiken, omdat het probleem geen compressie was, maar het opvragen van een bestand dat vier keer groter was dan weergegeven.
Waar formaatoptimalisatie nog steeds past
srcset/sizes goed instellen bepaalt welke afmetingen worden gedownload. Het bepaalt niet het formaat van die bestanden. Een correct gedimensioneerde 384px-JPEG is nog steeds groter dan nodig als een 384px-WebP- of AVIF-versie er identiek uit zou zien bij een kleinere bestandsgrootte. Hier past Erdo Image Optimizer als aanvullende oplossing, niet als vervanging: het converteert automatisch elk geregistreerd afbeeldingsformaat — inclusief de kleinere srcset-kandidaten die WordPress genereert — naar WebP en AVIF, zodat de correct gedimensioneerde keuze van de browser ook in het kleinst bruikbare formaat wordt geserveerd.
Voor meer over de formaatkant, zie onze gids voor het converteren van WordPress-afbeeldingen naar WebP en onze bredere PageSpeed Insights-checklist, die laat zien waar responsive afbeeldingen passen in het grotere prestatieplaatje.
Meer lezen
Voor de volledige technische specificatie van hoe browsers srcset en sizes evalueren, is web.devs gids over responsive afbeeldingen de meest betrouwbare referentie — deze behandelt dichtheidsgebaseerde selectie, art direction met het <picture>-element en randgevallen waar deze gids niet op ingaat.
Tot slot
Responsive afbeeldingen in WordPress zijn niet standaard kapot — het mechanisme werkt al automatisch sinds 2015. Wat kapotgaat is de sizes-waarde bij lay-outs die complexer zijn dan een blog met één kolom, waardoor browsers stilletjes bestanden downloaden die twee tot drie keer groter zijn dan wat daadwerkelijk wordt weergegeven. Controleer het attribuut aan de hand van je echte lay-out voordat je aanneemt dat je responsive afbeeldingen al correct werken, en combineer de fix met formaatconversie voor de volledige winst.