Waarom WordPress-afbeeldingen wazig zijn na het uploaden (en hoe je dat oplost)

In negen van de tien gevallen zijn je afbeeldingen niet echt onscherp — WordPress heeft ze bij het uploaden verkleind en serveert nu de begrensde kopie. Sinds WordPress 5.3 wordt elke afbeelding die breder of hoger is dan 2560px stilletjes vervangen door een -scaled-versie met een maximum van 2560px op de langste zijde, en dat kleinere bestand is precies wat je thema uitrekt om een hero, full-width blok of retina-scherm te vullen. De oplossing is om eerst te bewijzen dat dit gebeurd is, en vervolgens de drempel te verhogen of te stoppen met het uploaden van afbeeldingen die groter moeten zijn dan het vak waarin ze staan.

Waarom het gebeurt

Wanneer je een foto uploadt, draait WordPress wp_create_image_subsizes() (in wp-admin/includes/image.php). Als de langste zijde groter is dan de big_image_size_threshold — standaard 2560px — roept het _wp_image_meta_replace_original() aan, genereert your-photo-scaled.jpg en herschrijft de bijlage-metadata zodat het full-formaat nu naar de verkleinde kopie wijst. Je echte origineel blijft op de schijf bewaard als your-photo.jpg en wordt aangewezen door wp_get_original_image_path(), maar niets aan de voorkant serveert het. Elk tussenliggend formaat en elke srcset-kandidaat wordt gegenereerd vanuit het verkleinde 2560px-bestand, niet vanuit wat je hebt geüpload.

Hier zit dus de onscherpte. Je uploadt een scherpe afbeelding van 4000px voor een full-bleed header. WordPress begrenst die op 2560px. Op een standaardscherm in een container van 1600px breed is dat prima. Op een 2x retina-scherm heeft de browser ongeveer 3200 echte pixels nodig om die container scherp te vullen, heeft er maar 2560, en schaalt het verschil op. Zachte randen, wazige tekst-in-beeld, precies het symptoom van “wazig na het uploaden”.

De andere helft van hetzelfde probleem is dat srcset een formaat kiest dat te klein is. Als je thema een contentbreedte doorgeeft die niet overeenkomt met het daadwerkelijk gerenderde vak, geeft WordPress de browser een tussenliggend -1024x683 of -1536x1024 bestand en wordt dat opgerekt. Zelfde oorzaak — weergavevak groter dan de beschikbare pixels — andere aanleiding.

Controleer wat WordPress daadwerkelijk heeft geserveerd

Ga niet gokken. Klik met de rechtermuisknop op de wazige afbeelding, open deze in een nieuw tabblad en kijk naar de bestandsnaam in de URL. Als die eindigt op -scaled.jpg of een afmeting-suffix zoals -1024x683.jpg, dan heb je het bevestigd: de browser rendert een verkleinde afgeleide, niet je upload. Je kunt ook het element inspecteren en currentSrc uitlezen om precies te zien welke kandidaat de browser heeft gekozen.

Om het volledige plaatje te zien voordat je iets opnieuw uploadt, sleep je de afbeelding in de WordPress afbeeldingsformaten-tool — die toont elke afgeleide die WordPress van dat exacte bestand zal genereren, inclusief of er een -scaled-kopie wordt aangemaakt en in welke afmetingen, zodat je vooraf weet of je bron groot genoeg is voor de plek waar je hem plaatst.

Op de server kun je elk begrensd bestand opsommen:

find wp-content/uploads -name '*-scaled.*'

Hoe je het oplost, op volgorde

1. Als je afbeeldingen terecht groter moeten zijn dan 2560px (grote hero’s, retina, galerijen in printkwaliteit), verhoog dan de drempel:

// functions.php or a small mu-plugin
add_filter( 'big_image_size_threshold', function () {
    return 3840; // longest edge, in pixels
} );

Of schakel de begrenzing helemaal uit:

add_filter( 'big_image_size_threshold', '__return_false' );

2. Upload de betreffende afbeeldingen opnieuw. Dit is de stap die mensen overslaan. Het wijzigen van de drempel heeft alleen effect op nieuwe uploads. Afbeeldingen die al in je bibliotheek staan behouden hun oude metadata, en het opnieuw genereren van thumbnails bouwt de tussenliggende formaten opnieuw op vanuit het begrensde -scaled-bestand — het voegt geen resolutie terug toe die is weggegooid. De betrouwbare weg is: wijzig de filter, verwijder de bijlage, upload opnieuw.

3. Als je bron al ≤2560px is en toch onscherp, dan is de drempel niet je probleem — het weergavevak is groter dan de afbeelding. Upload een grotere bron, of verklein de container. Voor retina-scherpte moet je bron ongeveer twee keer de CSS-pixelbreedte zijn van het vak dat hij vult.

4. Pas na het bovenstaande genereer je thumbnails opnieuw zodat de tussenliggende formaten consistent zijn — maar begrijp dat dit opruimwerk is, geen oplossing.

Wat je niet moet doen

Zet de JPEG-kwaliteit niet op 100. WordPress comprimeert standaard naar een kwaliteit van 82 via wp_editor_set_quality, en de helft van de adviezen online zegt je om dat te overschrijven:

add_filter( 'wp_editor_set_quality', function () { return 90; } );

Dat is prima om compressie-artefacten te verminderen, maar een uitgerekte, opgeschaalde afbeelding is een resolutieprobleem, geen compressieprobleem. Van 82 naar 100 gaan blaast je bestanden op en doet vrijwel niets aan de onscherpte die je ziet.

Schakel -scaled niet uit uit reflex. De begrenzing uitschakelen (daar is een tool voor) is de juiste keuze als je afbeeldingen boven de 2560px serveert — maar als je echte probleem een te klein tussenliggend formaat is dat wordt uitgerekt, verandert het uitschakelen niets en verlies je zonder reden de bandbreedtebesparing. Stel eerst een diagnose.

Geef niet eerst de cache de schuld en genereer niet eerst de thumbnails opnieuw. Het opnieuw genereren leest uit dezelfde begrensde bron, dus het kan geen detail herstellen. Het legen van een CDN- of paginacache raakt een bestand niet aan dat vanaf het begin al klein op de schijf stond.

Grijp niet naar de CSS van het thema of object-fit. Geen enkele hoeveelheid styling voegt pixels toe. Als het geserveerde bestand eindigt op -scaled of een afmeting-suffix, dan is het bestand het probleem, niet de layout.

Kom je er nog niet uit?

Als je hebt bevestigd dat het geserveerde bestand je upload op volledige resolutie is — geen -scaled, geen afmeting-suffix — en het is nog steeds onscherp, controleer dan of een plugin (een optimizer, een CDN-afbeeldingsverkleiner of een lazy-load-bibliotheek) je src herschrijft naar een gecomprimeerde proxy. Haal de afbeelding door de afbeeldingsformaten-tool om te bevestigen wat WordPress zou moeten genereren, en vergelijk dat vervolgens met wat de browser daadwerkelijk laadt. Als die twee niet overeenkomen, is er iets tussen WordPress en de browser dat de boosdoener is.