Image size is bigger when added with .GetResponsiveCropUrl(crop) instead of .GetCropUrl(crop)
Dear Jeavon,
admire your work. But now I am confused about the following:
I add images in the RTE with a macro. GetResponsiveCropUrl() doesn't crop the images to the wished size. I added images additionally with GetCropUrl(). The result is:
Apart from the problem that the responsive image doesn't crop, what i try to achieve in the moment, i was wondering how much slimmage positively influences the image size. But when I 'saved image as' from the browser it was exactly the other way round. Image no 1 (responsive) is 60 kb and image no 2 17 kb in the example above. I checked again and again. The result is in average not as dramatic as in the example above, but the responsive image is always bigger.
Why is this like this? Thought slimmage with ImageResizer are meant to keep the image size small?
I think you need to add img{ width:100%;} as a CSS rule.
The way the plugin works is to determine how big the image needs to be to fill the space it is in with an image of the correct size, not that it will always be a smaller image than original.
If the space is bigger that the original requested size then it will request a bigger image.(upto a max size) If you try reducing the size of the browser window (to mobile size) and loading the page again, what is the image size then?
The idea is that page speed is increased as images are loaded in a size appropriate for what the user can see.
CSS max-width:100% is added as requested by Slimsy.
It's 2 times the same image, 1st generated with GetCropUrl(), 2nd with GetResponsiveCropUrl(), with the same CSS applied.
Because you asked I've have added the image once more as simple img (same CSS applied) and checked the image file size with browser window full width and browser window as small as possible.
The result is the following:
img generated with GetCropUrl() is the smallest, whatever the browser width is, then comes the img generated with GetResponsiveCropUrl(), the biggest is the basic img.
What I believe might be happening is that images are being resized in accordance with high resolution screen detection which will be doubling the output dimensions.
This is a common trick for ensuring the image is sharp on high resolution screens as the downscaling by the browser causes increased sharpness but it comes at the cost of file size.
Slimmage, the underlying library behind Slimsy uses a quality instruction by default for lossy image formats of 80%. For me that's far too high. I would recommend something around 60%.
Fortunately you can alter the default values by adding the following JavaScript to the top of your page before the Slimsy scripts.
window.slimmage = {
tryWebP: true, // Attempt to convert to webp format for smaller files.
jpegRetinaQuality: 60, // High definition quality
jpegQuality: 85 // Standard quality
};
The image processing itself is actually done by ImageProcessor.Web not ImageResizer so if you have the latest versions installed (v4.4.0) the output images should also be heavily optimized to reduce file size further.
Image size is bigger when added with .GetResponsiveCropUrl(crop) instead of .GetCropUrl(crop)
Dear Jeavon,
admire your work. But now I am confused about the following:
I add images in the RTE with a macro. GetResponsiveCropUrl() doesn't crop the images to the wished size. I added images additionally with GetCropUrl(). The result is:
Apart from the problem that the responsive image doesn't crop, what i try to achieve in the moment, i was wondering how much slimmage positively influences the image size. But when I 'saved image as' from the browser it was exactly the other way round. Image no 1 (responsive) is 60 kb and image no 2 17 kb in the example above. I checked again and again. The result is in average not as dramatic as in the example above, but the responsive image is always bigger.
Why is this like this? Thought slimmage with ImageResizer are meant to keep the image size small?
Thank you very much for your help.
Could this be a Css issue?
I think you need to add
img{ width:100%;}
as a CSS rule.The way the plugin works is to determine how big the image needs to be to fill the space it is in with an image of the correct size, not that it will always be a smaller image than original.
If the space is bigger that the original requested size then it will request a bigger image.(upto a max size) If you try reducing the size of the browser window (to mobile size) and loading the page again, what is the image size then?
The idea is that page speed is increased as images are loaded in a size appropriate for what the user can see.
Thanks
Carl
CSS max-width:100% is added as requested by Slimsy.
It's 2 times the same image, 1st generated with GetCropUrl(), 2nd with GetResponsiveCropUrl(), with the same CSS applied.
Because you asked I've have added the image once more as simple img (same CSS applied) and checked the image file size with browser window full width and browser window as small as possible.
The result is the following:
img generated with GetCropUrl() is the smallest, whatever the browser width is, then comes the img generated with GetResponsiveCropUrl(), the biggest is the basic img.
Hi Anja,
I'm not sure then sorry! I haven't had any issues myself using Slimsy and images have always been sized appropriately.
Hopefully one of the Slimsy devs will be able to help you soon!
Thanks
Carl
Hi Anja,
What I believe might be happening is that images are being resized in accordance with high resolution screen detection which will be doubling the output dimensions.
This is a common trick for ensuring the image is sharp on high resolution screens as the downscaling by the browser causes increased sharpness but it comes at the cost of file size.
Slimmage, the underlying library behind Slimsy uses a quality instruction by default for lossy image formats of 80%. For me that's far too high. I would recommend something around 60%.
Fortunately you can alter the default values by adding the following JavaScript to the top of your page before the Slimsy scripts.
You can see more options in the source code here
The image processing itself is actually done by ImageProcessor.Web not ImageResizer so if you have the latest versions installed (v4.4.0) the output images should also be heavily optimized to reduce file size further.
I hope this proves helpful
Cheers
James
is working on a reply...