Which option puts more load on the server?
Publishing on the website that uses a WordPress theme the images in a format, even if it’s not the one that offers the best compression for that specific image.
Implementing conditional loading of images from a WordPress theme so that, based on the browser, it loads the compatible image format. This way, each image can be published in the format that best compresses it if the browser allows it, saving space and bandwidth."
Well, in option 2 the server has more work as it would need to convert images to multiple formats. So that would put more load on the server.
Having said it, it would only need to happen once per post per image type, so it’s not as if the server would be busy with this all the time.
Unless you have a really big site with loads of traffic I don’t think you’ll notice the difference.
In point 2, the server would not perform the image format conversion. It would have conditional code with images in appropriate formats and files already uploaded to the server. For example, AVIF, WebP, and JPEG. The code would search for the appropriate file in the theme’s folder to load the required format.
In this case, do you also think it would put more load on the server?
Pay attention I m only talking about theme images, not post or other images
Perhaps a little bit, but you wouldn’t notice it.
Then is worth to make the selective load over than let the theme images in a single format?
It might be. Though I don’t know how much you’ll actually save in terms in bandwidth. It’s worth an experiment I’d say.
If you only have two image types - and I can see no reason to have more - you could always do the job with JS. Something like
const mh = document.querySelector("#mhome");
mh.addEventListener("error", function() {
mh.src = "images/mhome.jpg";
});
But its better the option of two images or the single image option? Wich of the two options puts more load on the server? The code for selective load or the not optimal compressed format?
In the case of .webp versus .jpg, I like Gandalf’s version above. It lets the server first try the .webp image, and then only in the (very rare) scenario where the browser can’t use .webp files, it’s the browser’s job to request the jpeg image instead. The server will spend virtually no extra time dealing with this, and especially in this case where almost every browser is ok with .webp.
Ok, I understand. And in the case that an image could be better compressed in AVIF, could it be done as @Gandalf says and indicate that it should load AVIF, then WebP, and if not, JPEG? In terms of workload, would it still be for the browser rather than the server?
Yes I suppose in theory you could. But as to the performance of that implementation, I would really want to see it tested. For example imagine all the network traffic and associated propagation delays you’d generate in the worst case scenario of having to bounce through all the formats to eventually display the .jpg image. And how many images are on the page, etc, etc. My gut says this could be a real problem, and would be delays the user actually sees. But implementing and measuring a scenario as much like your actual pages will look is probably the only way to really know.
Another possible implementation would be to confirm the best format for the browser just once and save it locally on the browser, then change all html img src= references to the correct image format on each page load rather than letting the browser load/fail/load/fail every image. Of course that makes some assumptions about what your html looks like, whether it’s dynamic, etc.
I believe you can achieve your goal by utilizing the sizes and srcset attributes of the img element. No need for client or server logic. Take a look at MDN for more info.
My actual experience thinks. The image needs to be compressed first. If the background of the jep format is white, it saves the most space.