15 ms·

Can someone here help me find a proper use case for this? I mean, one beyond "I want to do everything in CSS and I don't care if I waste bandwidth and energy r

Can someone here help me find a proper use case for this? I mean, one beyond "I want to do everything in CSS and I don't care if I waste bandwidth and energy resources, let's crop this image a million times in every browser just because we can".

TekMol 4y ago
Go to AirBnB. On the homepage you will see a bunch of premises. Right click "Open image in a new tab". Boom, you see the full image. On the home page, you only saw a cutout of the image. Now imagine going to AirBnB and changing their workflow so that the server sends the right cutout. It would be a nightmare. As it is, a frontend guy can change the cutout, do a/b tests with different cutouts, change the cutout dynamically based on window size, change the cutout when the image is displayed on different pages etc etc. Try to set all of that up by talking to the frontend guys and the backend guys and try to get to a situation so that the frontend talks to the backend in a fashion that the frontend guys can easily do what they do now and the backend responds with the right images. Good luck :)
- ThatMedicIsASpy 4y ago
  So its a 'I don't care about your traffic limit' kind of thing.
  - hombre_fatal 4y ago
    Well, let's dig into this. Serving N images all cropped slightly differently isn't going to save bandwidth over serving an image one time, caching it, and then doing slightly different cropping in the browser. Airbnb's homepage images only seem to be 50-90KB per image. And they already do some image resizing: https://a0.muscache.com/im/pictures/prohost-api/Hosting-48509375/original/0862735b-4abc-4d87-a8d1-f2fb6053adc8.jpeg?im_w=720 https://a0.muscache.com/im/pictures/prohost-api/Hosting-4850... vs. https://a0.muscache.com/im/pictures/prohost-api/Hosting-48509375/original/0862735b-4abc-4d87-a8d1-f2fb6053adc8.jpeg?im_w=1440 https://a0.muscache.com/im/pictures/prohost-api/Hosting-4850... If you compare the slightly cropped homepage images to their uncropped versions, you just aren't saving a bunch of bandwidth by serving static crops, especially since you need new crops once the user clicks in to property pages. Finally, images (1.3MB) only account for 10% of airbnb's homepage transfer in desktop Chrome (13MB total) and 2% in desktop Safari (60MB total... content blocker bug?). Images seem to be the least of their worries.
- genezeta 4y ago
  I know of at least one similar site where all that is achieved dynamically in the server. Images can be rotated, cropped, and resized dynamically. Common cuts can be made, cuts are cached, and making a new cut is done on the fly without noticeable delay by passing different parameter values. This has been working now for about 6 years. It has never been a problem for the frontend team in any way.
  - bryans 4y ago
    That method is adding server, client and network load by delivering multiple versions of the same image, whereas a cached version on the front end can be freely re-used and manipulated as needed based on the specifics of the device and browser. It's not a matter of being a problem for the front end team. It's a problem for devops and the end user.
    - genezeta 4y ago
      It hasn't been a problem for the backend or devop teams either. The network load is... probably not something you, or me, can so offhandedly talk about here without the actual data. It depends a lot on which images are most used. I do know that they did in fact reduce a lot of bandwidth by serving pre-sized thumbnails instead of larger images. Typically there's only a few -3, 4- different sizes that matter; these can be -and are- cached by the browser. In this case, most visitors seemed to never need the full-size format, so that's a lot of saved bandwidth.
  - WalterGR 4y ago
    Has it been a problem for sites that don’t have that available in their backend?

TekMol 4y ago

Go to AirBnB. On the homepage you will see a bunch of premises. Right click "Open image in a new tab". Boom, you see the full image. On the home page, you only saw a cutout of the image. Now imagine going to AirBnB and changing their workflow so that the server sends the right cutout. It would be a nightmare. As it is, a frontend guy can change the cutout, do a/b tests with different cutouts, change the cutout dynamically based on window size, change the cutout when the image is displayed on different pages etc etc. Try to set all of that up by talking to the frontend guys and the backend guys and try to get to a situation so that the frontend talks to the backend in a fashion that the frontend guys can easily do what they do now and the backend responds with the right images. Good luck :)

ThatMedicIsASpy 4y ago
So its a 'I don't care about your traffic limit' kind of thing.
- hombre_fatal 4y ago
  Well, let's dig into this. Serving N images all cropped slightly differently isn't going to save bandwidth over serving an image one time, caching it, and then doing slightly different cropping in the browser. Airbnb's homepage images only seem to be 50-90KB per image. And they already do some image resizing: https://a0.muscache.com/im/pictures/prohost-api/Hosting-48509375/original/0862735b-4abc-4d87-a8d1-f2fb6053adc8.jpeg?im_w=720 https://a0.muscache.com/im/pictures/prohost-api/Hosting-4850... vs. https://a0.muscache.com/im/pictures/prohost-api/Hosting-48509375/original/0862735b-4abc-4d87-a8d1-f2fb6053adc8.jpeg?im_w=1440 https://a0.muscache.com/im/pictures/prohost-api/Hosting-4850... If you compare the slightly cropped homepage images to their uncropped versions, you just aren't saving a bunch of bandwidth by serving static crops, especially since you need new crops once the user clicks in to property pages. Finally, images (1.3MB) only account for 10% of airbnb's homepage transfer in desktop Chrome (13MB total) and 2% in desktop Safari (60MB total... content blocker bug?). Images seem to be the least of their worries.
genezeta 4y ago
I know of at least one similar site where all that is achieved dynamically in the server. Images can be rotated, cropped, and resized dynamically. Common cuts can be made, cuts are cached, and making a new cut is done on the fly without noticeable delay by passing different parameter values. This has been working now for about 6 years. It has never been a problem for the frontend team in any way.
- bryans 4y ago
  That method is adding server, client and network load by delivering multiple versions of the same image, whereas a cached version on the front end can be freely re-used and manipulated as needed based on the specifics of the device and browser. It's not a matter of being a problem for the front end team. It's a problem for devops and the end user.
  - genezeta 4y ago
    It hasn't been a problem for the backend or devop teams either. The network load is... probably not something you, or me, can so offhandedly talk about here without the actual data. It depends a lot on which images are most used. I do know that they did in fact reduce a lot of bandwidth by serving pre-sized thumbnails instead of larger images. Typically there's only a few -3, 4- different sizes that matter; these can be -and are- cached by the browser. In this case, most visitors seemed to never need the full-size format, so that's a lot of saved bandwidth.
- WalterGR 4y ago
  Has it been a problem for sites that don’t have that available in their backend?