Why image resizing at all?

[bartelsmedia]

Modern browser can resize bitmaps on the client site quite well.

So, shouldn't the Processwire image resize be disabled to reduce additional http requests (if the user resizes viewport)?

Do I miss something? Should/can it be disabled?

[szabesz]

4 minutes ago, bartelsmedia said:

Do I miss something?

Hello,
do you need something like this: https://processwire.com/blog/posts/processwire-3.0.63-adds-client-side-image-resizing/ ?

5 minutes ago, bartelsmedia said:

So, shouldn't the Processwire image resize be disabled to reduce additional http requests (if the user resizes viewport)?

Or are you after something else? Can you please explain what you are referring to?

[bartelsmedia]

I am not referring to uploading bitmaps in the Processwire backend.

I mean the front end bitmap delivery. In \site\assets\files\... I see many variations created that I actually don't need:

 

[szabesz]

6 minutes ago, bartelsmedia said:

I see many variations created that I actually don't need

260 pixel versions are generated by the admin, you need these there. 1024 versions must come from another source you somehow added to the system, so if you can identify its source, you can get rid of these.

Here is a recent discussion you might be interested in: 

 

Edited March 31, 2019 by szabesz
typos

[teppo]

2 hours ago, bartelsmedia said:

Modern browser can resize bitmaps on the client site quite well.

So, shouldn't the Processwire image resize be disabled to reduce additional http requests (if the user resizes viewport)?

Do I miss something? Should/can it be disabled?

If you don't create any variations on the front-end using size, width, etc. calls, ProcessWire won't create anything except for the variations created by default for admin (preview) purposes. Third party modules may still create their own variations, but if you're strictly against that behaviour, you can always avoid using any modules that do this ?

What you're probably missing here is the amount of data: sure, browsers can handle resizing images, but if you're considering load times and amount of data users have to download to use your site, you absolutely want to resize images before they hit the visitors' browsers.

When you're asking if this behaviour should be disabled to "reduce additional http requests (if the user resizes viewport)", it kind of sounds like you've implemented srcset on your site – otherwise there shouldn't be a additional requests when the viewport is resized due to images. Even then if you start with a larger viewport and then resize it to smaller size, browser shouldn't load the smaller sizes. Only case generating additional requests is when you go the other way, from small to large – otherwise tiny images would likely look pretty awful scaled to a larger size.

Short answer is: no, it shouldn't be disabled. That being said, you don't have to create any additional variations if you don't want to – but be considerate of the user and don't make them download more data than they actually need ?

[dragan]

I don't have much to add to previous feedback posted already here, except that delivering a suitable (physical) image variation is good practise. It impacts page speed performance and also affects mobile SEO ranking: https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.html

Even in 2019, not everyone has ultra high-speed internet access everywhere and all the time.

[Autofahrn]

3 hours ago, dragan said:

Even in 2019, not everyone has ultra high-speed internet access everywhere and all the time.

or has a flatrate, like on mobile devices.

...and don't forget cropping with respect to the focus point.

[wbmnfktr]

And people just don't want to wait for a website to load.

[happywire]

On 3/31/2019 at 1:40 PM, teppo said:

When you're asking if this behaviour should be disabled to "reduce additional http requests (if the user resizes viewport)", it kind of sounds like you've implemented srcset on your site – otherwise there shouldn't be any additional requests when the viewport is resized due to images. Even then if you start with a larger viewport and then resize it to smaller size, browser shouldn't load the smaller sizes. Only case generating additional requests is when you go the other way, from small to large – otherwise tiny images would likely look pretty awful scaled to a larger size.

This.

Going into responsive image syntax a bit due to that it might not work as expected by @bartelsmedia when the user changes viewport.
When I started to learn this I found out the hard way that using multiple "source" elements (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/source), as is done for art-direction, will indeed download the smaller or larger versions as the user changes the viewport.

This is due to the fact that for art-direction the browser assumes that the image for the smaller or larger viewport does not have the identical content but is either a crop of the original image or a completely different image.

Only when using the non-art-direction syntax will responsive images behave like you explained.
This took me some time to understand but once I did it completely made sense.
I found this resource to be very help in understanding the different approaches to the responsive images syntax.
https://dev.opera.com/articles/responsive-images/

So @bartelsmedia make sure you are using the appropriate syntax for your use case of responsive images.

[bartelsmedia]

Interesting read, thanks. I still think, it is not necessary to provide different bitmap files in the special case of screenshots.

 

We do screenshots in Retina resolution. Due to the large amount of white space in screenshots, those compress quite well with PNG.

Example: http://www.keyboard-and-mouse-sharing.com/screenshots.htm

Browsers resize those Retina bitmaps quite well for displays with non-Retina resolution.

It would be more data transfer to serve multiple bitmap file variations rather than using one single file that is resized by the browser.

[horst]

My thoughts and experiences on this are:

A) Screenshots are captures from individual content, displayed on a devices screen. <-- So, screenshots do not have a large amount of white space by its nature. (I can show you a lot of mine, where in fact is no whitespace at all. ?)

B) Example: If you send a 4 times to large image, also as a retina-variation, to a device with none retina display, you send 8 times to much data without any positive effect for the user. Only negative effects!
    (If you can do a good compression to a large image, you also can do a good compression to smaller variations.)

C) Using html scrset or picture elements do NOT send multiple bitmaps, they once send the variation that best fits to the devices screen.

[bartelsmedia]

Now for some cold hard facts:

Screenshot with Retina resolution (21KB after TinyPNG optimization):

 

The same but rescaled screenshot to 1x resolution (also 21KB after TinyPNG optimization):

 

Why would I want to generate smaller variations of a screenshot with half the dimensions but almost the identical file size?

 

I know, that the results depend on the nature of screenshots. Above comparison would fail if the screenshot would contain horizontal color fades or photo-realistic contents. But for such general screenshots it would be better to only serve the original without variations.

[Robin S]

6 hours ago, bartelsmedia said:

But for such general screenshots it would be better to only serve the original without variations.

So serve the original rather than a variation then. It's totally up to you and what you write in your template code - PW doesn't compel you to load anything on the front-end.

[Autofahrn]

Even if the compressed size does not differ much, don't forget that images need to be decompressed on client side in order to get displayed. Devices with ram limitations may fail to hold too much image data in memory and either fails to display the image completely or need to decompress whenever the viewport requires to render the image.

Edit: The larger screenshot has a resolution of 1000x679 pixels, if images are decompressed into 32 Bits (RGBA), the footprint on client side is about 20MBytes, the smaller one with 628x426 only occupies 8MBytes. I wouldn't bother about client resizing for few of such images per page as well, but if your pages may contain more pictures (like a thumbnail gallery), I'd really consider to deliver smaller versions.