This is a story of how we saved 250Gb of disk space and kept saving it simply by choosing not to cache resized images on a hard drive.
This article is for you!
- If you often run out of disk space and you are told that you have a lot of images even though you know that in reality, you don’t.
- If you have already purchased a second HDD for images and it’s also almost full, but you have no idea why this is happening.
If disk space runs out, your website will stop working
If a database server is located on the same drive as your website and files (media), and the disk space on the server runs out, your website will stop working and your customers will see 503 Error Page, while the server logs will display a message “No Space Left On Device”.
Input data
There are about 20864 products in our webstore with visibility “Catalog, Search”. This is what is available and can be found. In other words, these products are seen by customers and most likely they have images.
- Below are rather average values:
- Products have 5 images;
The image size is about 3.5 MB.
As a result on average, it takes 365120 MB - 356 GB.
For us, this number is logically sound. I have a number of images and they take some specific space. But there is a big nuance! There may be images of different sizes on your website. For instance, a source image may have a size of 1000x1000 px and it would be silly to load such a large image somewhere on a cart page or a popup where the requested size is 100x100 px. It will eat up the user’s traffic, and a page will be loading slowly.
Calculating additional disk space – an entry point to the problem
Let’s take a standard website with such pages: Homepage, Category Page, Product Page with additional features like Quick view and Cart popup, Cart Page, Checkout, Thank you Page, along with notifications that may content product images.
For example, you uploaded a 2000x2000 px image to a product. This is the original image. On one of the pages, it will be necessary to display the same image but 500x700 px-sized and Magento using special functions will resize this image and save it in the cache. It is stored in a special folder, so the next time we need an image of this size it won’t be created again but loaded from cache. It works like this for the purpose of optimization. Images resizing takes time and server resources, so to speed it up a previously created version of a file will be used in the future.
Options of using images in webpages and how new files will be created
Homepage
- A banner or a promotional product. A large 1000x1000px image may be used, it’s okay.
- Additional banners - 2 of them. For instance, it may be the most popular product of the week/month, 300x500 px image – a new file.
- A slider-banner with top-selling products - 8 items (products are being rotated very quickly and randomly). Image size is 250x300 – new files.
Category
- A product grid - 200x250 px images - new files.
- Top sales in this category - 250x350 px images - new files.
Product page
- A main photo – everything is okay here.
- A carousel with thumbnails - 50x50 px – new files.
“Customers also buy” carousel - 250x310 px – new files.
Elements/windows
- Shopping cart. 40x45 px image of a product – a new file.
- Quick view. 500x500 px image of a product – a new file.
If you have any additional promotional sections, carousels, blog and also you export products to a feed (e.g. Google, Facebook, etc) that includes image sizes you will have much more new image files. Moreover, don’t forget about email notifications if they have product images. So, you’ve got the point, right?
Based on this list, which is far from complete, you will get about 20-30 additional image sizes for each product. Taking into account a number of products on the website you may have quite a lot of additional files.
Could it have been avoided? And what to do?
You can use several universal sizes for many different blocks and pages. For example, 200x200px image may be suitable for:
- Shopping cart
- Feeds
- Category Page/menu, if images are used
- Sliders on the homepage
- Email notifications
At what stage can a problem and a solution be identified?
Design. In theory, designers should take a number of different image sizes into consideration and probably provide developers with a manual for the use of images on the website with notice that it’s possible to use one image size on such pages: Homepage, Category, Cart. These images are not much different in size, so you don’t need to resize them and create new files. Yes, 3 image sizes won’t suffice, because your website won’t look good enough. Still, you can use just several universal sizes and also width and height attributes to set a required size directly in HTML code.
A development company or a contractor received a design but didn’t inspect the provided layout and didn’t discover a bottleneck. Maybe, you weren't asked about the quantity of products you were going to have on the website and how many images each product might have. Or probably nobody checked if you planned to use CDN and didn’t explain what advantages it might bring.
Problem solution
You should unify the sizes of images. Check view.xml file for examples of sizes that may be combined.
You don’t even need to write any code or change parameters of functions like init($product, 'related_products_list')->getUrl() ?>
The problem can be resolved on view.xml level. Just review the file and determine what image sizes can be used in your case. Move from larger to smaller sizes, but not vice versa. Keep an average size. For example, if you have a list of 100 px, 200 px, 300 px, 350 px sizes you need to keep 300 px or even replace it with 250 px. It will be a perfect size and an image will look good in both 100 px and 350 px. Don’t keep too small sizes as images will look awful on large sizes.
If you are using CDN it’s great, but if you’re not you should definitely implement it. It will cost some money, but now you will understand why it’s worth it.
CDN services cache files, especially images. As a result, you don’t need to store changed or cached images on the drive! In other words, you need to generate images of the correct size and they will be sent directly to CDN without saving on your drive.
If you are using CDN for your Magento webstore, than an operation of saving a changed image to the drive (Magento saves changed images to a special folder /pub/media/catalog/product/cache/) is unnecessary and you’re just losing money, because CDN service stores images and they won’t be loaded from your server. This is one of the main promotional mottos of such services: ‘We cache traffic and save your money’. So let’s really save your money!
The solution would be to disable saving/caching of changed images on the drive and to extend the cache storage period in your CDN to the maximum possible. We set it to 365 days, because, for instance, we are pretty sure that a table will look the same and will include 4 legs during the whole year. In case we do need to update the cache for some product, we can update it for a specific URL or remove it completely - for the whole website.
Unfortunately, such a wonderful feature doesn’t exist in Magento and your drive is still being filled with files.
You can hire us to get consultations, as well as the development and support of your project.
