For example, there is a certain product, it has a short description (preview) and a full description, in which there is a big photo and preview of each of them (slider with thumbnails).

In total, each product photo we need to have in three versions in this example. And the thing is not so much in pruning, how much is that we need to give 3 different sizes of one photo from the server, and these are 3 requests. The most interesting thing is that the total size of these photos may end up more than the original :)

The question arises - is it not easier to give one photo and resize it on the client using the same CSS or JS? We give one photo for one product instead of three, and a normal browser will cache it and that's it. Then do what we want with him. As far as I understand, this approach is now using for example Twitter.

It is interesting to know who thinks about this.

  • interesting question really. Aspects a bunch. Plus - teran
  • Specify the first phrase, especially the section: "... in which there is a large photo and preview of each of them (slider with thumbnails).". The essence is lost that whose is the preview, and from where 3 variants of a photo come from. - V.March
  • We went to the product catalog (grid, for example, if it’s so clearer) - there is a product thumbnail - the first option is 100x100, for example, opened a product card (full description with dimensions, etc.), there is a slider in it - a preview for example 150x150 and the photo itself slider 300x350. Plus, unforgettable that when you click can still want to show the original. Total 4 options for one photo. The sizes are taken arbitrarily for an example. - netseac
  • In this case, I would have kept 2 options: 100 to 100, because why load many large images into the catalog, and I would load large images into the card itself (although the 100x100 and 150x150 variant can be combined into one to save). And for good, I would collect statistics on clicks on pictures in order to know what can be denied. If people do not watch large pictures, then make thumbnails (100 to 100) and thereby reduce traffic. It seems to me in this matter it is worth dancing from the load on the server (place) and page loading speed (according to the rule, do not load what is not needed) - Sergey Glazirin
  • There is also an intermediate option: we store only the original on the server, and we cut it down on the fly on request from the client. So YouTube does, for example. But for this you need a relatively powerful server to cut-down quickly (and not forget to cache) - andreymal

1 answer 1

Of course they need to be cut (scaled).

Photos of 10 megabytes will be uploaded to you, and then the user will open a page with a list of 100 products from a mobile phone.

It is better to spend space on the server than the traffic of visitors.

  • So no one bothers to limit the uploaded file, say up to 1mb. Quality shrink, if it is jpg for example, percent to 70-75. Let's be honest, I will be much more worried about my server and its resources than how much traffic the user will use. Video on mobile devices is somehow viewed after all :) So the question here is more likely not in traffic, in the number of requests, and therefore in processor time. Just imagine 3 requests for 1000 users = 3 thousand requests, and if the photo is one, then 1000. Total 3 vs 1 thousand requests, and this is if there are 1000 visitors, and if there are hundreds of thousands? - netseac