Compressing Images for Faster Deliveryfor Drupal 11 , 10 , 9 , and 8

Home » Performance Optimization » Compressing Images for Faster Delivery
Last updated :  
11.x , 10.x , 9.x , 8.x

Two images can look pixel-identical at the same resolution and differ by 5x in file size, purely based on compression quality settings. A photo saved at 100% JPEG quality often looks indistinguishable from one saved at 80% — but the 80% version can be half the file size. This lesson is about that gap: the compression quality knob that costs nothing visually but matters enormously for load time.

What you'll learn in this lesson

  • Where JPEG/PNG quality is actually configured in Drupal
  • Why lossless PNG is the wrong default for photographs
  • How the image toolkit (GD vs. Imagick) affects your options

Configuring JPEG quality

// /admin/config/media/image-toolkit — or programmatically:
\Drupal::configFactory()->getEditable('system.image.gd')
  ->set('jpeg_quality', 82)
  ->save();

Drupal's default JPEG quality is 75 — already reasonably compressed. The real lesson isn't "lower the number blindly," it's understanding that this setting exists at all and testing where visible quality actually starts to degrade for your specific content, rather than accepting whatever the default happens to be.

PNG's lossless-by-design cost: PNG never discards data — it's lossless — which is exactly right for screenshots, logos, and graphics with sharp edges and flat colors, and exactly wrong for photographs, where PNG files routinely end up 3-5x larger than an equivalent-looking JPEG. A common real-world mistake: uploading photos as PNG (often because that's what a screenshot tool defaulted to) instead of JPEG, silently multiplying every photo's file size on the site.

GD vs. Imagick: your options differ

# Check which toolkit is actually active:
drush php:eval "echo \Drupal::config('system.image')->get('toolkit');"

GD (PHP's built-in image library) ships with every PHP install and handles the basics well, but Imagick (a PHP extension wrapping ImageMagick) supports more advanced compression options and formats — including better control over WebP encoding, covered in the next lesson. If your hosting supports it, Imagick is generally the better choice for a site that cares seriously about image optimization.

A quick manual comparison

# Compare file sizes at different quality levels directly, before
# committing to a site-wide setting:
convert original.jpg -quality 90 test90.jpg
convert original.jpg -quality 75 test75.jpg
convert original.jpg -quality 60 test60.jpg
ls -lh test*.jpg

Quick check: a site's content editors upload mostly photographs, but the theme's screenshot tool defaults to PNG and nobody's changed the setting. What's the likely performance cost, and what's the fix? If you said photos are being served 3-5x larger than necessary as lossless PNG instead of JPEG, and the fix is either re-saving as JPEG or converting via an image style's format-conversion effect, you've connected this lesson's core lesson correctly.

Key takeaways

  • JPEG quality is a real, configurable trade-off — test where visible degradation actually starts for your content rather than trusting the default blindly.
  • PNG's lossless nature makes it right for graphics/logos and wrong for photographs, where it can be 3-5x larger than an equivalent JPEG.
  • Imagick generally offers more compression control than GD, including better WebP support.
  • Compare actual file sizes at different quality levels with a real tool (convert) before committing to a site-wide setting.

Coming up next

Quality tuning helps within a format. Next, a format that beats both JPEG and PNG at their own game for most use cases: WebP.