3 ms·

This may be a super dumb question but... how is this better than using progressive jpegs?

pshc 4y ago
Looks smoother, transparency, data small enough to inline in the HTML or JSON payload, supports not just JPEGs but also PNGs, WebPs, GIFs. IMO I don't really care for a 75%-loaded progressive JPEG. Half the image being pixelated and half not is just distracting.
matsemann 4y ago
You call an API -> it returns some json with content and links to images -> you start doing a new request to load those images -> only when partially loaded (aka on request 2) you will see the progressive images starting to form. With this: You call an API -> it returns some json with content and links to images and a few bytes for the previews -> you immediately show these while firing off requests to get the full version. So I'm thinking quicker to first draw of the blurry version? And works for more formats as well.
derefr 4y ago
1. If the thing that's going to be loaded isn't a JPEG, but rather a PNG, or WebP, or SVG, or MP4... 2. These are usually delivered embedded in the HTML response, and so can be rendered all at once on first reflow. Meanwhile, if you have a webpage that has an image gallery with 100 images, even if they're all progressive JPEGs, your browser isn't going to start concurrently downloading them all at once. Only a few of them will start rendering, with the rest showing the empty placeholder box until the first N are done and enough connection slots are freed up to get to the later ones.
eyelidlessness 4y ago
A few things that immediately come to mind: - you can preload the placeholder but still lazy load the full size image - placeholders can be inlined as `data:` URLs to minimize requests on initial load, or to embed placeholders into JSON or even progressively loaded scripts - besides placeholder alpha channel support, it also works for arbitrary full size image formats

pshc 4y ago

Looks smoother, transparency, data small enough to inline in the HTML or JSON payload, supports not just JPEGs but also PNGs, WebPs, GIFs. IMO I don't really care for a 75%-loaded progressive JPEG. Half the image being pixelated and half not is just distracting.

matsemann 4y ago

You call an API -> it returns some json with content and links to images -> you start doing a new request to load those images -> only when partially loaded (aka on request 2) you will see the progressive images starting to form. With this: You call an API -> it returns some json with content and links to images and a few bytes for the previews -> you immediately show these while firing off requests to get the full version. So I'm thinking quicker to first draw of the blurry version? And works for more formats as well.

derefr 4y ago

1. If the thing that's going to be loaded isn't a JPEG, but rather a PNG, or WebP, or SVG, or MP4... 2. These are usually delivered embedded in the HTML response, and so can be rendered all at once on first reflow. Meanwhile, if you have a webpage that has an image gallery with 100 images, even if they're all progressive JPEGs, your browser isn't going to start concurrently downloading them all at once. Only a few of them will start rendering, with the rest showing the empty placeholder box until the first N are done and enough connection slots are freed up to get to the later ones.

eyelidlessness 4y ago

A few things that immediately come to mind: - you can preload the placeholder but still lazy load the full size image - placeholders can be inlined as `data:` URLs to minimize requests on initial load, or to embed placeholders into JSON or even progressively loaded scripts - besides placeholder alpha channel support, it also works for arbitrary full size image formats