3 ms·
They claim this is good for responsive images: The download or file read operations can be stopped as soon as sufficient detail is available, and if
by cbr 11y ago
They claim this is good for responsive images:
The download or file read operations can be stopped
as soon as sufficient detail is available, and if
needed, it can be resumed when for whatever reason
more detail is needed.
-- http://flif.info/responsive.php
Unfortunately that's not how HTTP works. Your browser opens several connections to a website, and makes requests for resources. Each connection is in use until that resource is fully loaded, at which point you can send a request for another resource up that connection. Yes, the browser could close the connection after it has received enough of the image for the desired quality, but there's a lot of overhead in setting up a new connection, including some round trips, and so that is probably a net loss.
The JPEG image format also supports progressive images, in browsers today, and no one has figured out how to use that for single-file responsive images yet.
(You might be able to do something in HTTP/2 where you set the priority of the stream to 0 after you have enough of it for your needs, but I don't think anyone has gotten this working yet.)
- XCSme 11y agoWhy do you say it is a net loss? Maybe the server could signal the end of file based on some request parameters (the resolution of the image).
- AshleysBrain 11y agoYes, handling it on the server side sounds like a reasonable workaround. For example photo.flif?res=1x returns Content-Length: 100000, and photo.flif?res=2x returns Content-Length: 200000, with both returning data from the same file.
- cbr 11y agoI say net loss because with current http the loss of closing the connection is typically much higher than the loss of downloading more bytes than you need. Connection reestablishment needs a lot of round trips.
- szym 11y agoCould use range requests (RFC 7233), albeit with some overhead.
- cbr 11y agoTo use a range request the client needs to know what range of bytes it needs. Currently your html is: <img src="foo.jpg"> Now, let's say foo.jpg is progressive, and if you examine the file you can see that you need H bytes for the header, N bytes for the first layer, M for the next, and so on. Then you could mark up the html as: <img src="foo.jpg" bytes-1x="(H+N)" bytes-2x="(H+N+M)" ...> but that's a huge pain to generate by hand, and people like to compose html by hand. If we want something that can catch on, it needs to be something where browsers and servers can negotiate in a fully automated way. Or we can just use srcset/picture.
- szym 11y agoCould leverage HTTP Client Hints: https://github.com/igrigorik/http-client-hints https://github.com/igrigorik/http-client-hints
- cbr 11y agoClient hints are a nice solution, but they don't require an image format stored in progressive order. They work fine with storing multiple copies on disk, and the overhead of low-rez versions server-side is minimal.
- tracker1 11y agoHTTP supports range headers to get a portion of a file...