DokuWiki takes a deliberately flat approach to storage. Instead of a database-backed media library, every uploaded file lands directly in data/media/, organised into folders that mirror your namespaces. Resized images are not stored as separate uploads; DokuWiki generates them on the fly and caches the results under data/media_thumbs/ and data/cache/. This design keeps the wiki portable and easy to back up, but on a shared account with a fixed inode and disk quota it can quietly consume resources. A single large PNG referenced at several display widths produces multiple cached derivatives, and a busy wiki with hundreds of articles can accumulate tens of thousands of small cache files that count against your inode limit long before you run out of actual disk space.
The performance side matters just as much. Because DokuWiki renders a resized image the first time a given width is requested, the initial visitor to a page triggers PHP GD processing for each uncached image. On LiteSpeed with CloudLinux LVE limits, that burst of CPU and memory can slow the request or trip your entgood process limits if several images resize at once. The goal of media optimization here is to reduce how much work DokuWiki repeats, shrink the bytes sent to browsers, and keep file counts manageable, all without touching anything outside your hosting account.
Controlling upload size and allowed media types
DokuWiki enforces its own upload ceiling, but that ceiling can only be as high as what PHP permits. On LiteSpeed, the effective limits come from upload_max_filesize, post_max_size, and memory_limit. Set these through the control panel rather than guessing. In cPanel Jupiter, open MultiPHP INI Editor, select your domain, and raise the values on the Basic tab. In DirectAdmin Evolution, use Select PHP Version then PHP Options (or PHP Settings) to adjust the same directives. If your panel exposes only a subset of options, create or edit a .user.ini file in the DokuWiki document root:
; public_html/.user.ini
upload_max_filesize = 20M
post_max_size = 24M
memory_limit = 256M
max_execution_time = 120Keep post_max_size larger than upload_max_filesize, and keep memory_limit comfortably above your largest expected image, because GD loads the entire bitmap into memory while resizing. A 6000x4000 JPEG can need well over 100 MB of RAM during processing even though the file on disk is only a few megabytes. Changes to .user.ini take effect after the PHP process TTL expires, usually within a couple of minutes.
On the DokuWiki side, visit Admin → Configuration Settings and review the media handling block. The upload_sizelimit value sets the maximum accepted upload in bytes and should match or stay under your PHP ceiling. The mediarevisions option keeps old versions of every replaced file; on a storage-constrained plan you may disable it, or accept that each re-upload doubles the footprint of that media item. Also tighten the allowed MIME and extension list through Admin → Extension Manager is not where this lives—instead the conf/mime.conf and conf/extension.conf defaults govern it, and you can override them by creating conf/mime.local.conf using the File Manager. Removing uncommon or risky types (such as svg if you do not need it) reduces both security exposure and accidental storage of files DokuWiki cannot optimize.
Tuning thumbnail generation and cache behaviour
DokuWiki's image scaler is controlled by a handful of configuration keys you can set in Admin → Configuration Settings. The most impactful is imconvert: if ImageMagick's convert binary is available in your account path, pointing this setting at it produces noticeably better resized images than GD and often uses less memory per operation. Many shared stacks include ImageMagick; check Admin → Information or a quick phpinfo() page for the imagick extension, and if a path such as /usr/bin/convert is reachable, enter it. If it is not, leave imconvert empty and DokuWiki falls back to GD, which is fine for typical screenshots and diagrams.
Two further settings shape output quality and size. jpg_quality defaults to 70 and is a sensible balance; lowering it to around 60 shaves bytes with little visible loss for wiki illustrations. The fetchsize key caps the largest dimension DokuWiki will fetch and scale, which prevents a page from forcing the server to process an enormous original. Combined, these keep each resize operation cheap and the cached derivative small.
DokuWiki already serves media through lib/exe/fetch.php and emits cache headers, but the on-disk cache under data/cache/ grows indefinitely unless trimmed. The built-in cleanup runs during indexing, so a scheduled task that triggers DokuWiki's maintenance keeps both the render cache and orphaned thumbnails in check. If you have already set up scheduled jobs, our guide on moving document roots cleanly is unrelated, so instead rely on the DokuWiki cron endpoint you configured for indexing to also purge stale cache entries. When inodes climb, use cPanel File Manager or DirectAdmin's file browser to inspect data/cache/; it is safe to delete its contents while the wiki is quiet because DokuWiki regenerates anything still needed.
WebP delivery and browser caching through .htaccess
DokuWiki does not natively convert uploads to WebP or AVIF, and its scaler outputs the same format as the source. Rather than fight that, the practical win on shared hosting is to make the browser cache aggressively and to serve pre-made WebP versions when they exist. Because LiteSpeed honours Apache-style rules, you can do both from the DokuWiki .htaccess in the document root. First, set long-lived cache headers for media so repeat visits avoid re-fetching derivatives:
# public_html/.htaccess
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpeg "access plus 30 days"
ExpiresByType image/png "access plus 30 days"
ExpiresByType image/gif "access plus 30 days"
ExpiresByType image/webp "access plus 30 days"
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "\.(jpe?g|png|gif|webp)$">
Header set Cache-Control "public, max-age=2592000"
</FilesMatch>
</IfModule>If you create WebP copies of heavily viewed images (for example by uploading a WebP version alongside a JPEG into the same namespace), you can serve them conditionally to supporting browsers for the static files under data/media/ only when they are accessed directly. Note that DokuWiki normally proxies media through fetch.php, so this swap applies to direct file links, not to scaler output:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule \.(jpe?g|png)$ %{REQUEST_URI}.webp [T=image/webp,L]
Header append Vary Accept env=REDIRECT_accept
</IfModule>For wikis with a lot of external traffic, a CDN sitting in front of your domain is the single most effective way to offload media bytes. DokuWiki itself needs no plugin for this; because media is served over normal HTTP(S) with cache headers, any reverse-proxy CDN caches those responses once the headers above are in place. Keep the CDN's cache key simple and let it respect your Cache-Control values. If you run into stale images after replacing a file, purge the affected path at the CDN and bump DokuWiki's cache by saving the page, since the scaler's URL includes size parameters that change the cache key naturally.
Monitoring storage and diagnosing resize failures
Watch two numbers from your control panel: disk usage and inode count. In cPanel the Statistics sidebar shows both, and DirectAdmin displays them on the user dashboard. When inodes spike without matching disk growth, the cause is almost always accumulated small files in data/cache/ or data/media_thumbs/. Use File Manager to sort folders by size and confirm before clearing. If a specific image refuses to display at a thumbnail size, open the DokuWiki data/cache/ area and check your account's error_log in the document root; GD memory exhaustion appears as a fatal "Allowed memory size" error tied to lib/exe/fetch.php, which points you back to raising memory_limit or lowering fetchsize. Keeping originals reasonably sized before upload remains the cheapest optimization, since every downstream cost scales with the source dimensions.