Unoptimized images account for roughly 21% of total page weight on the average WordPress site – and that number climbs fast when you are running a multisite network with dozens of subsites uploading freely. Every subsite adds its own media library, its own uncompressed PNGs, its own oversized hero images. The weight compounds quickly.
Getting image optimization right across a multisite setup is a different challenge than fixing a single site. You need network-level rules, not just per-site plugins. This guide covers exactly that.
Why Image Bloat Hits Multisite Networks Harder
Large images are the most common LCP (Largest Contentful Paint) killer in any WordPress environment. On a multisite network, the problem multiplies because each subsite operates its own `uploads` folder under `wp-content/uploads/sites/{site-id}/`, meaning unoptimized assets pile up independently across every node.
A single 2MB hero image can add 6 to 8 seconds of load time on a mid-range mobile connection. Multiply that across 20 subsites with no shared compression rules, and you are looking at a network where page speed scores routinely sit below 50 on Google PageSpeed Insights. I have audited multisite setups where the combined unoptimized media library exceeded 40GB – all of it serving original, uncompressed files to visitors.
The core issue is governance. A single-site admin controls one upload environment. A multisite super admin has to enforce standards across every site editor, every theme, every contributor. Without network-level defaults, quality degrades at the subsite level by default.
Choosing the Right Format: WebP vs. AVIF in 2026
Format choice is the single biggest lever you have for file size reduction. WebP delivers 25 to 35% smaller files than JPEG at equivalent visual quality. AVIF goes further – typically 40 to 50% smaller than JPEG – but encoding is slower and server support still varies.
Option A: WebP (Recommended for Most Networks)
WebP has near-universal browser support as of 2026, covering over 97% of global users according to Can I Use. Plugins like Imagify and ShortPixel handle bulk conversion at the network level, applying WebP output automatically on upload. For a network running 15 or more subsites, ShortPixel’s API plan at around $9.99 per month for 10,000 credits is a practical entry point. Conversion happens server-side, so visitors get WebP without any browser-sniffing tricks.
Option B: AVIF (Better Compression, More Setup)
AVIF makes sense when you need maximum compression – product photography, high-resolution editorial images, anything where file size directly affects conversion rates. The tradeoff is real: AVIF encoding can take 3 to 5 times longer than WebP, and older versions of Nginx or Apache need explicit MIME type configuration to serve `.avif` files correctly. Add this to your Nginx config if you go this route:
“`nginx
types {
image/avif avif;
}
“`
This block tells Nginx to serve `.avif` files with the correct MIME type so browsers recognize and render them properly.
For most multisite networks, WebP is the safer default. Adopt AVIF selectively for image-heavy subsites where the encoding overhead is worth the extra compression.
Setting Network-Wide Compression Rules in WordPress
Compression policy should live at the network level, not left to individual site admins. The cleanest way to enforce this is through a must-use plugin (MU plugin) stored in `wp-content/mu-plugins/`. MU plugins load automatically on every subsite – no activation required, no way for a subsite admin to disable them.
Here is a minimal example that caps WordPress’s default image quality setting across the entire network:
“`php
// mu-plugins/network-image-quality.php
add_filter( ‘wp_editor_set_quality’, function() {
return 82;
} );
“`
This filter forces WordPress to compress all uploaded JPEG and WebP images to 82% quality at the point of upload, network-wide. Quality 82 is a well-tested sweet spot – visually indistinguishable from 100% at normal viewing sizes, but typically 40 to 60% smaller in file size.
Pair this with WordPress’s built-in `big_image_size_threshold` filter to stop WordPress from storing full-resolution originals above a set pixel width:
“`php
add_filter( ‘big_image_size_threshold’, function() {
return 2048;
} );
“`
This caps stored originals at 2048 pixels wide. Any upload larger than that gets scaled down before WordPress generates its intermediate sizes. Disk usage drops noticeably on active networks.
Four Steps to Configure Lazy Loading Across All Subsites
Lazy loading is free performance. Every modern browser supports the `loading=”lazy”` attribute natively, which defers off-screen images until the user scrolls near them. WordPress has added `loading=”lazy”` to images by default since version 5.5, but multisite networks running older themes or custom image output often bypass this.
Follow these four steps to enforce lazy loading network-wide:
- Audit your theme’s image output. Check whether your active themes use `wp_get_attachment_image()` or raw `
` tags. Only `wp_get_attachment_image()` and similar core functions apply the lazy loading attribute automatically.
- Add a network MU plugin filter if themes output raw tags. The filter `wp_lazy_loading_enabled` can be set to `true` globally, and `wp_get_attachment_image_attributes` lets you inject `loading=”lazy”` into any attachment image.
- Exclude above-the-fold images. The hero image and the first visible image on any page should use `fetchpriority=”high”` and `loading=”eager”` – never lazy. Lazy-loading the LCP image is a common mistake that tanks PageSpeed scores by 10 to 20 points.
- Test with Chrome DevTools. Open the Network tab, filter by “Img”, and scroll the page slowly. Images should load progressively as you scroll, not all at once on page load. A properly lazy-loaded page typically reduces initial image payload by 50 to 70%.
Serving Images Through a CDN on Multisite
A CDN (Content Delivery Network) is non-negotiable for multisite networks with geographically distributed visitors. Without one, every image request hits your origin server – even if a visitor in Tokyo is accessing a subsite whose server sits in Virginia.
Cloudflare and BunnyCDN are the two I recommend most often for WordPress multisite setups. Cloudflare’s free tier handles CDN delivery and includes basic image resizing via Cloudflare Images (paid add-on, around $5 per month per 100,000 images served). BunnyCDN charges roughly $0.01 per GB for storage and $0.005 to $0.06 per GB for delivery depending on region – extremely cost-effective for networks with large media libraries.
The key multisite consideration: your CDN must handle subsite URL structures correctly. If your network uses subdirectory installs (`example.com/site2/`), most CDN setups work without extra configuration. Subdomain networks (`site2.example.com`) require wildcard SSL and separate CDN zone configuration per subdomain, or a wildcard CDN zone covering the root domain.
After enabling a CDN, TTFB (Time to First Byte) for image requests typically drops from 300 to 800ms (origin) to 20 to 80ms (CDN edge). That difference is visible to real users.
Keeping the Media Library Clean Across the Network
A clean media library is an underrated performance factor. WordPress generates multiple image sizes for every upload – by default, thumbnail (150×150), medium (300×300), medium-large (768px wide), and large (1024px wide). On a busy multisite network, a single upload can generate 6 to 8 files. Over time, orphaned images and unused sizes accumulate into gigabytes of dead weight.
Run WP-CLI commands at the network level to regenerate or clean up image sizes efficiently. To regenerate thumbnails across all subsites after changing size settings:
“`bash
wp site list –field=url | xargs -I {} wp –url={} media regenerate –yes
“`
This command loops through every subsite URL in the network and runs the media regeneration process on each one without manual intervention.
For removing genuinely orphaned media files – uploads with no attachment post in the database – the plugin Media Cleaner can scan at the network level. Run a scan before any major migration or server move. On networks older than 3 years, I have seen orphaned files account for 15 to 30% of total media storage. That is disk space and backup size you can recover without touching a single live image.
Making Image Optimization Stick Across Your Multisite Network
Getting the technical pieces in place is only half the job. The other half is making sure your setup holds as the network grows, new subsites launch, and new contributors start uploading.
The most durable approach combines automated enforcement with sensible defaults. MU plugins handle compression and size limits without requiring any subsite admin to remember a setting. A CDN handles delivery at scale. A scheduled WP-CLI job – even a simple monthly cron – keeps the media library from growing out of control. When these three layers work together, the network maintains consistent image performance without constant manual intervention.
One thing I would push back on: the idea that you need an expensive enterprise plugin to do this well. The combination of a well-written MU plugin, a mid-tier CDN like BunnyCDN, and a reliable compression API like ShortPixel covers 90% of what most multisite networks need, for well under $30 per month total. The fundamentals are not complicated – they just need to be applied at the right level of the stack.
If you want to go deeper on WordPress performance architecture, understanding how WordPress handles caching at the network level pairs naturally with image optimization – the two topics together have the biggest combined impact on Core Web Vitals scores across a multisite setup.
When you implement Best practices for image optimization on WordPress multisite networks, revisit the checklist above against your real constraints.
Frequently asked questions
Does each subsite in a WordPress multisite network need its own image optimization plugin?
No – and installing separate plugins per subsite is actually the wrong approach. Network-activated plugins or MU plugins apply settings across every subsite from a single configuration point. Tools like ShortPixel and Imagify offer network-level activation specifically for this reason. Managing compression settings per subsite creates inconsistency and makes audits much harder.
Will converting images to WebP break any subsites on my network?
Unlikely in 2026. WebP support covers over 97% of browsers globally. The main risk is older cached pages serving a WebP URL to a browser that cached an older JPEG reference – a full cache flush after conversion resolves this. Always run a conversion on a staging clone of the network first, then push changes to production.
How do I prevent subsite admins from uploading oversized images?
Use the `upload_size_limit` filter inside an MU plugin to cap file size per upload, and the `big_image_size_threshold` filter to cap pixel dimensions. You can also restrict allowed file types at the network level via Network Admin > Settings > Upload Settings > Upload file types. Combining a file size cap (say, 3MB) with a pixel cap (2048px wide) stops the worst offenders before they hit the server.
Does a CDN work correctly with WordPress multisite subdomain installs?
Yes, but it requires a wildcard SSL certificate covering `*.yourdomain.com` and either a wildcard CDN zone or individual zones per subdomain. Cloudflare handles wildcard subdomains cleanly on its Pro plan and above. BunnyCDN requires a pull zone per subdomain unless you use their custom hostname feature. Test each subsite’s image URLs after CDN setup to confirm assets are being served from the edge, not the origin.
How often should I run a media library cleanup on a multisite network?
Quarterly is a reasonable default for active networks. Before any major server migration, run a cleanup first – orphaned files inflate backup sizes and transfer times. On networks where multiple contributors upload daily, a monthly WP-CLI audit script catches bloat before it becomes a storage problem. Set it as a scheduled task and you will rarely need to think about it manually.
Leave a Reply