Let's talk about
your project
your project
Fill out the form. We'll get back to you within 24 hours with a proposal.
The task set before us: Increase available space on the server. Remove unused image formats in WordPress. Optimize the portal.
We began work on the portal after starting consultations with the WhiteMad editorial team. An issue reported from the hosting provider informed us of too much space occupied by WordPress template graphics files.
An additional problem was the 15zine template, because every image uploaded to WordPress Media generated over 20 different formats that were unused on the portal.
We started by checking the image sizes applied in the template. It turned out we had over 15 additional image sizes (beyond WordPress defaults), including several large ones (above 1024px).
Images in these larger sizes often weighed around 300-500 kB each, which — with over 100,000 uploaded photos — added more than 50 GB of extra files.
The first idea was to disable unused image sizes. However, after reviewing the site it turned out that practically every one was being used somewhere (mainly article grids). Realistically it was possible to disable maybe 3-4 sizes, which wouldn't bring significant benefits.
See the service WordPress care.
We decided on a different approach — using the "Fly Dynamic Image Resizer" plugin, it's possible to disable WordPress's generation of alternative image sizes on upload to the media library.
Instead, images are generated only when needed on the front end. In our case this significantly reduced FTP-disk usage, because all image sizes used in article grids apply only to the main post image, not to images in its body content. In total, only about 10% of all images would have alternative sizes generated, while the remaining 90% would exist only in a few default versions.
However, simply enabling the plugin isn't enough, as it doesn't replace the default behavior of WordPress's size generator. The plugin expects that when registering sizes in the template — instead of the default "add_image_size()" — we use "fly_add_image_size()", and when displaying images — instead of "wp_get_attachment_image()" and "wp_get_attachment_image_src()" — we use "fly_get_attachment_image()" and "fly_get_attachment_image_src()" respectively.
The portal we worked on used a ready-made WordPress 15zine template, so it wasn't possible to swap these functions directly in the template code. Instead, it was necessary to manually remove previously registered sizes via "remove_image_size()", then hook into the "wp_get_attachment_image" filter and override the function's logic so it automatically pulls images via "fly_get_attachment_image()".
After the whole operation we still needed to remove all previously generated image sizes to free up FTP space.
The only downside of using the "Fly Dynamic Image Resizer" plugin is that the first person to visit the site after new images are added will experience slightly longer load time (required sizes must be generated before display). In the traditional approach this operation is performed by the administrator during upload to the media library.
