Voorkom dat WordPress je afbeeldingen op 82% comprimeert

WordPress hercodeert elke JPEG die het genereert op kwaliteit 82 op een schaal van 0–100. Die standaardwaarde zit in WP_Image_Editor::get_default_quality() en geldt voor elke afgeleide die WordPress uit je upload knipt — thumbnail, medium, medium_large, large, en elk extra formaat dat je thema registreert. Voor foto’s is 82 een verstandige balans tussen bestandsgrootte en artefacten. Voor screenshots, UI-opnames, grafieken, logo’s en alles met scherpe tekst of vlakke kleur is 82 zichtbaar destructief: je krijgt mosquito noise rond elke letter en banding over vloeiende verlopen.

Om het te wijzigen voeg je één filter toe en genereer je je thumbnails opnieuw. Om screenshots specifiek op te lossen is het betere antwoord meestal om WordPress helemaal geen JPEG te geven.

Waar het getal 82 eigenlijk vandaan komt

WordPress verlaagde zijn JPEG-standaard van 90 naar 82 in versie 4.5 (2016) als optimalisatie voor het paginagewicht. De waarde wordt geretourneerd door get_default_quality() in wp-includes/class-wp-image-editor.php en wordt gelezen zodra de actieve editor — WP_Image_Editor_Imagick als je host Imagick heeft, anders WP_Image_Editor_GD — een verkleind bestand wegschrijft.

Het belangrijke detail: 82 wordt per afgeleid formaat toegepast, niet één keer. Upload één afbeelding en WordPress haalt hem meerdere keren door de encoder, waarbij hij bij elke doorgang opnieuw op kwaliteit 82 kwantiseert. Het oorspronkelijk geüploade bestand zelf blijft ongemoeid als het onder de big-image-drempel (2560px op de langste zijde) valt. Overschrijdt het die drempel, dan produceert WordPress een hergecodeerde -scaled.jpg op kwaliteit 82 en serveert die als het “full”-formaat. Dus “mijn afbeelding op volledige resolutie ziet er prima uit maar de versie op de pagina ziet er uitgesmeerd uit” is bijna altijd een srcset die een sub-formaat op kwaliteit 82 kiest, of het -scaled-bestand.

Hoe je de kwaliteit wijzigt

Er is één filter om aan te haken. wp_editor_set_quality is de moderne, canonieke variant — hij vuurt voor JPEG en WebP en ontvangt het MIME-type zodat je kunt vertakken:

add_filter( 'wp_editor_set_quality', function ( $quality, $mime_type ) {
    if ( 'image/jpeg' === $mime_type ) {
        return 92; // up from 82
    }
    return $quality;
}, 10, 2 );

Zet dit in een kleine mu-plugin (wp-content/mu-plugins/) of een sitespecifieke plugin. functions.php werkt ook, maar dan raak je de instelling kwijt zodra je van thema wisselt.

Je zult ook het oudere jpeg_quality-filter aanbevolen zien worden. Het vuurt nog steeds (WordPress past het direct na wp_editor_set_quality toe, alleen voor JPEG), maar er is geen reden om beide aan te haken — wp_editor_set_quality dekt alles wat de oude deed en meer.

Eén ding dat iedereen vergeet: dit filter beïnvloedt alleen afbeeldingen die gecodeerd worden nadat het actief is. Elke thumbnail die al in wp-content/uploads staat is op 82 weggeschreven en blijft op 82. Genereer ze opnieuw:

wp media regenerate --yes

Als je geen WP-CLI gebruikt, doet de Regenerate Thumbnails-plugin hetzelfde via de admin.

Voordat je je op een getal vastlegt, is het de moeite waard om te zien wat een bepaalde kwaliteit daadwerkelijk met jouw afbeelding doet, in plaats van te gokken. Onze WordPress JPEG-kwaliteitstool hercodeert een voorbeeld in de browser op elk kwaliteitsniveau, zodat je de artefacten kunt zien verschijnen — het maakt het verschil tussen 82, 90 en 100 op een screenshot duidelijk op een manier die een getal in een configuratiebestand nooit zal doen.

De betere oplossing voor screenshots en vlakke afbeeldingen

Het JPEG-getal verhogen behandelt het symptoom. Het echte probleem met screenshots is dat JPEG er de verkeerde codec voor is. JPEG’s DCT-compressie is afgesteld op fotografische verlopen; hij valt uit elkaar op de harde zwart-op-wit randen van tekst en UI-elementen, precies de reden waarom kwaliteit 82 er op een screenshot zoveel slechter uitziet dan op een foto van een strand.

Upload in plaats daarvan een PNG. WordPress houdt PNG-subformaten als PNG, en PNG is lossless — het kwaliteitsfilter raakt het niet aan, dus zijn er geen artefacten bij welk formaat dan ook, alleen schone resampling. Voor een screenshot is een goed geoptimaliseerde PNG vaak zelfs kleiner dan een JPEG van hoge kwaliteit van dezelfde afbeelding, omdat vlakke kleur goed comprimeert in PNG en waardeloos in JPEG.

Wil je de kleinere bestanden van een lossy formaat zonder JPEG’s randschade, dan is WebP het middenweg — maar je stuurt de kwaliteit ervan nog steeds aan via hetzelfde wp_editor_set_quality-filter dat hierboven is getoond, vertakkend op image/webp.

Wat je niet moet doen

Zet de kwaliteit niet globaal op 100. Dit is het best beoordeelde antwoord in de helft van de forumdraadjes, en het is fout. JPEG op kwaliteit 100 is niet lossless — het kwantiseert nog steeds — maar het blaast elke foto op je site fors op zonder zichtbare winst, wat je LCP en Core Web Vitals omlaag trekt. Verhoog het getal voor het formaat dat het nodig heeft, of wijzig het formaat voor afbeeldingen; sloop niet de compressie voor de hele site.

Bewerk class-wp-image-editor.php niet. De retourwaarde van get_default_quality() in de core wijzigen werkt tot de volgende wp core update het stilletjes overschrijft. Gebruik het filter.

Schakel afbeeldingsformaten niet uit om “de compressie te vermijden”. Thumbnailgeneratie uitzetten stopt het hercoderen niet — het breekt de responsieve srcset, waardoor browsers je afbeelding op volledig formaat op telefoons downloaden. Ander probleem, slechtere uitkomst.

Ga er niet van uit dat opnieuw uploaden bestaande afbeeldingen oplost. Als je het filter instelt maar de regenereerstap overslaat, staat elke oude afgeleide nog steeds op kwaliteit 82. Het filter werkt alleen vooruit.

Geef het -scaled-bestand niet de schuld als je afbeeldingen onder de 2560px zitten — dat pad wordt voor hen nooit doorlopen. Kom je het wel tegen en wil je het onaangetaste origineel geserveerd hebben, dan is dat een aparte instelling; zie scaled images uitschakelen.

Nog steeds vast?

Als een specifiek formaat er na het regenereren nog steeds fout uitziet, controleer dan welk bestand de pagina daadwerkelijk serveert — open de afbeelding in een nieuw tabblad en kijk of de bestandsnaam eindigt op een afmetingssuffix (-1024x768.jpg) of -scaled.jpg. De afbeeldingsformaten-inspector toont elke afgeleide die WordPress uit één upload genereert, zodat je precies kunt zien welk formaat je srcset aan de browser doorgeeft en stopt met het verkeerde bestand debuggen.