TYPO3 sites accumulate media fast. Between editorial images, processed thumbnails, and the fileadmin/_processed_ cache, a mid-sized site can burn through gigabytes of disk without anyone noticing. Uncompressed originals slow down page loads, and every image variant TYPO3 generates lives on your server's storage. This guide walks through three fixes that work together: tuning image processing for smaller files, enabling automatic WebP conversion, and pushing bulky media off your account onto S3 or a CDN so your primary storage stays lean and fast.

Why TYPO3 Storage Balloons

TYPO3 doesn't serve your uploaded images directly. When an image is rendered at a specific dimension, TYPO3 generates a resized copy in fileadmin/_processed_ (or under typo3temp/assets/). A single hero image referenced in five different sizes produces five processed files plus the original. Multiply that across hundreds of content elements and you understand why disk usage climbs.

The processing engine matters too. TYPO3 relies on either GraphicsMagick or ImageMagick on the server. On our Shared Hosting and Cloud VPS plants, ImageMagick is available and LiteSpeed serves the output over HTTP/3, so the goal is producing the smallest possible files without visible quality loss.

Step 1: Verify Image Processing in the TYPO3 Backend

Before optimizing, confirm TYPO3 can talk to the image library.

  1. Log in to the TYPO3 backend.
  2. Go to Admin Tools → Environment.
  3. Open Test Image Processing (Image Processing tab).
  4. Run the tests. Every sample (GIF, PNG, JPG, WebP read/write) should render without red errors.

If the WebP tests fail, the server's ImageMagick build may lack WebP delegate support. On our stack it's compiled in; if you hit issues, open a ticket and we'll confirm the delegate is active on your node.

Step 2: Configure Graphics Settings

Head to Admin Tools → Settings → Configure Installation-Wide Options and review the [GFX] section. Key values to set:

  • processor: ImageMagick (or GraphicsMagick if that's what's installed).
  • processor_path: usually auto-detected, e.g. /usr/bin/.
  • jpg_quality: 75 is a strong balance between size and quality.
  • processor_allowUpscaling: leave off to avoid generating oversized copies.

You can also set these in config/system/settings.php if you prefer version-controlled config:

'GFX' => [
    'processor' => 'ImageMagick',
    'processor_path' => '/usr/bin/',
    'jpg_quality' => 75,
    'processor_enabled' => true,
    'processor_effects' => true,
],

Step 3: Enable Automatic WebP Conversion

TYPO3 v12 and v13 support WebP output natively through processing configuration. The cleanest approach is to instruct TYPO3 to emit WebP for rendered images.

Add a fileExtension to your image rendering in Fluid or TypoScript. For a Fluid image:

<f:image image="{fileReference}"
    fileExtension="webp"
    width="1200"
    alt="..." />

For content-wide conversion, adjust the processing instructions via TypoScript so lib elements output WebP. You can also control WebP quality in settings.php:

'GFX' => [
    'webp_quality' => 80,
],

To force WebP everywhere without editing every template, install a well-maintained extension such as web-vision/webp from the TER, which hooks into the image processing pipeline and serves WebP with a fallback for older clients. Test on staging first, then clear the processed files cache under Admin Tools → Maintenance → Remove Temporary Assets so old JPEG/PNG variants regenerate as WebP.

WebP typically cuts image weight 25–35% versus JPEG at equivalent quality. Combined with LiteSpeed's HTTP/3 delivery, this noticeably improves Largest Contentful Paint.

Step 4: Raise PHP Limits for Large Media Uploads

Processing large source images and uploading big media requires adequate PHP memory and upload limits. If editors get errors uploading high-resolution files, adjust the PHP directives.

On DirectAdmin (Evolution Theme):

  • Go to Extra Features → Select PHP Version (PHP Selector).
  • Confirm PHP 8.2, 8.3, or 8.4 is selected.
  • Open the Options tab and set upload_max_filesize to 64M, post_max_size to 64M, and memory_limit to 512M.
  • Save to apply.

On cPanel (Jupiter Theme):

  • Under Software → Select PHP Version, confirm PHP 8.2+ is active.
  • Click Options (or use Software → MultiPHP INI Editor).
  • Set upload_max_filesize, post_max_size, and memory_limit to the same values above.
  • Save.

ImageMagick can be memory-hungry with very large originals, so the 512M memory limit prevents processing failures. If you're facing broader upload ceiling issues on other apps, our guide on fixing upload limit and media size errors covers the same directives in depth.

Step 5: Offload Media to S3 or a CDN

The biggest storage win is moving fileadmin uploads off your account entirely. TYPO3's FAL (File Abstraction Layer) supports external storage drivers, so you can register an S3-compatible bucket as a storage.

  1. Install an S3 driver extension such as andersundsehr/aus-driver-amazon-s3 or autofelix/typo3-cdn via Composer: 
    composer require andersundsehr/aus-driver-amazon-s3
  2. Activate the extension under Admin Tools → Extensions.
  3. Go to File → Filelist, then in the List module for the sys_file_storage table (or via the backend Storage records), create a new File Storage.
  4. Choose the AmazonS3 driver, enter your bucket name, region, access key, and secret key.
  5. Set the public base URL to your CDN or bucket endpoint so files serve directly from S3/CDN, not your server.

New uploads land in the bucket, and TYPO3 references them through FAL transparently. Editors won't notice a difference in the backend, but your hosting storage stops growing with every image.

Serving processed images from the CDN

For maximum effect, configure the storage so _processed_ variants also write to S3. Alternatively, keep processing local but front your entire domain with a CDN so the LiteSpeed-served WebP files are edge-cached. Point your CDN origin at your domain, then use TypoScript config.absRefPrefix or a prefix in your rendering setup so asset URLs resolve to the CDN hostname.

Step 6: Clean Existing Processed Files

Old variants keep consuming space until you clear them. In the TYPO3 backend:

  • Go to Admin Tools → Maintenance.
  • Click Remove Temporary Assets to purge typo3temp and processed caches.
  • Run the scheduler task File Abstraction Layer: Update storage index so the file index matches reality.

Schedule the cleanup to run periodically so processed caches never balloon again.

On DirectAdmin: go to Advanced Features → Cron Jobs and add a job calling the TYPO3 CLI scheduler:

0 3 * * * /usr/local/bin/php /home/USER/domains/example.com/public_html/vendor/bin/typo3 scheduler:run

On cPanel: under Advanced → Cron Jobs, add the same command, adjusting the PHP binary path and site path to match your account layout.

FAQs

Will WebP break for older browsers?

Modern browsers (Chrome, Firefox, Edge, Safari 14+) all support WebP. Extensions like web-vision/webp include a fallback, and native TYPO3 rendering keeps the original format available. Coverage is effectively universal today, so the risk is minimal.

Does offloading to S3 slow down the backend?

There's a small latency cost when listing files in the backend Filelist, since TYPO3 queries the bucket. Choose an S3 region close to your server and enable the driver's caching options. Front-end delivery is unaffected because files serve straight from S3 or your CDN edge.

How much storage can I realistically save?

Sites that offload originals and processed variants to S3 typically free 60–90% of their media footprint from the hosting account. Combined with WebP, you also cut bandwidth, which improves load times regardless of where the files live.