Why
WordPress writes every registered image size at upload. A library of 4,000 photos easily ends up with 50,000 files, most of which are never requested.
JuZ Mirage stops writing them. Sizes are still declared to WordPress, so the editor, the media library, srcset and the REST API behave normally, but a file is only rendered the first time a browser asks for it. Then it is cached on disk and served by the web server, without PHP.
What it does
- Only the original is written at upload; every size is rendered on demand, then served statically.
- Signed URLs with bounded parameters, and a site-wide cap on concurrent renders.
- JPEG and PNG served as WebP, with a blurred preview while loading (CSS only).
- A focal point per image, kept in frame by cropped sizes.
- Nothing in the database: the plugin can be removed at any time.
Status
JuZ Mirage is in beta, for block themes only. Download it from GitLab and tell us how it works on your site. It already runs on this playground: every image of these pages is rendered on demand, then served as WebP straight from the disk cache.
// Frequently asked questions
Questions about JuZ Mirage
Does it work with a classic theme?
No. JuZ Mirage is built and tested for block themes (Full Site Editing): a classic theme can print images that never go through the filters it relies on.
What happens if I deactivate it?
A confirmation screen first offers to write the missing image sizes, then deactivates the plugin. Nothing specific to JuZ Mirage is stored in your content, so wp media regenerate also rebuilds the sizes as WordPress would have.
How much space does it save?
It depends on your library: wp juzmirage stats measures it and shows what it would weigh without the sub-sizes, without changing any file.
Does it send data anywhere?
No. No account, no external service, no telemetry: images are rendered and cached on your own server.
