Sorry little offtopic but isnt this a little excessive? 13 versions of one image? I mean there is 20px difference in the first step.
I asume this is test, because if its not its totaly not worth it. Just use something small for old mobiles, something for tablet, something for regular fullhd desktop and then the highest def for hidensity. Even that is probably overengineering.
Just my 2 cents on this topic, as I spent a lot of time thinking about these issues:
This is a very hard question in general. If you really want to overshoot on that topic, you could possibly create something like the hosted image-resizing service Cloudinary. They provide a free tool with a paid API, that applies a »smart« algorithm (I guess what they really mean is brute-forcing …) to select the right sizes for an image. Ehm … okay, one could use that and the results are quite okay, but does it really make sense to rely on a third-party for such tasks as they may change their API anytime soon or shutdown the service, which might not be too easy to replace.
Another option is to serve stronger-compressed images to so-called retina displays, as the smaller pixels on these screens make JPEG artifacts less noticable. But that also means, that you need twice the amount of thumbnails. If you really want to squeeze the last byte out of your site, but also want to serve high-density displays. But to keep things sane, I would agree with you that in most cases about 5-6 images should be enough to make a good compromise between the effort it takes to generate and store all these images and the overall download size. Take a look around at the web and do some comparison with most other sites and you can be glad, that with only 5-6 images, your site will perform much better than an estimated 90% of other websites.
The size difference between for example a 1336px wide image and a 1360px wide image is not much.
If you don’t use something like (the amazing) Imagekit, Kirby will have to resize the image >10 times every time you upload a new image before loading the actual page. If there are many images, you might even have to increase your max_execution_time. It slows things down and it doesn’t even help that much.
Hey thanks HeinerEF. Bastian solve it by email. The GD library was timing out. Now I use imageMagick and everything is fine.
About the conversation to know if it is worth it or not to have that many variations. Yes this is a bit more work for me (to make the srcset) but as long as the thumbnails are pre-processed, and there is enough space on the server why not serve images to their exact size? I don’t see the problem.
The fact you can do that doesnt mean you should do it. Its exacltly like someone said in above comments. You could theoreticaly make image for every single resolution. But why it is just sily?
Just measure it:
There is realy not that big advantage if the image is same (is just scaled). You would target lowres screens like older mobiles and then there is jump to old tablets 1024px or something and then you would go for something like 1400 and then the high res. The point is that difference in size from 1400px and 1024px is almost nothing. Those resolutions are going to be mostly served by desktops anyway - so the size realy matters only on mobile phones. You realy need just like 5 steps probably less to achieve the same thing.
And frankly - you will probably waste much more kilobytes by setting up compresion of the images wrong than by not having exaclty right resolution.
If you would need the best and smallest images i would say you need some dedicated service like jpegmini or compressor.io those compress in smarter way then GD or imagemagic. But again this makes sense only for huge sites where the savings 50 kbs on image can save you money.
