New LQIP alternative

[transitive-bullshit]

Hey 👋

First off, I want to say that you folks have done an amazing job with sqip. The entire project is really impressive and I really loved the detailed comparison demo.

In the spirit of collaboration, I wanted to present a new take on LQIP which closely resembles Medium's approach: lqip-modern.

There are definitely tradeoffs with all of these different approaches, but for our use case, this approach provided the best combination of results in terms of visual fidelity, encoded image size, and encoding speed.

I also forked sqip's demo for lqip-modern's demo because I liked the setup so much.

Finally, you can see the completed LQIP effect in all its glory on this demo page: https://demo.notion2site.com/image-sizing-3492bd6dbaf44fe7a5cac62c5d402f06.

I'm creating this issue to start a discussion around a few areas:

1. What do you think of this approach and the tradeoffs compared with sqip potrace, blurhash, and other LQIP techniques?

2. Would you be open to a PR adding lqip-modern's default output to the sqip demo?

3. I want to make sure that the benchmarks I'm presenting are correct and unbiased -- would love to get some feedback on this front. Specifically, lqip-modern is really only meant to be used blurred client-side, so this is something that I added to my fork of sqip's demo, but it's not currently blurring the non-lqip results. Thoughts here?

Thanks!

[technopagan]

@transitive-bullshit First of all: Thank you for caring about web performance and esp. user experience regarding images. I love your effort!

I'm glad you like SQIP's approach. @axe312ger has done an incredible job here.

On the areas you'd like to discuss:

---

Regarding 2):
Yes, of course. A PR would be welcome.

---

Regarding 3):
SQIP's greatest weakness is its client-side blur because blurring is a computationally heavy task for a browser rendering engine, even if it gets offloaded to the GPU. Consider esp. how much effort it is for a user's device to render the blur correctly as the user scrolls a website's viewport. A jank-free (see Aerotwists's http://jankfree.org/) browsing experience is hardly possible if dozens of SQIP image placeholders were blurred client-side and scrolled in the same viewport.

Ergo, the same problem will affect your current approach of LQIP-Modern's client-side blur. And unlike SQIP - which because of its SVG basis has no other choice - it is a problem that you don't NEED to have because your approach uses raster images formats (WebP/JPEG).

I would therefore recommend that you apply blur on the LQIP image during creation. The "sharp" library already provides blur (see https://sharp.pixelplumbing.com/api-operation#blur):

await sharp('./input.png')
  .blur()
  .toFile('./output_blurred.png')

This way, users exposed to LQIP-Modern placeholder images do not have to "suffer" from paying the cost of blurring on their devices. Also, due to the way that lossy image compression works, the blurred 16px image will compress to a smaller bytesize than the unblurred variant. Another easy win for you. ;)

If you want to deep-dive, feel free to create an image gallery grid-layout, use SQIP on one variant and a pre-blurred LQIP variant on the other and then measure rendering + scrolling performance (see my comment on "Jank" above) to get a feeling for how much client-side blur costs.

---

Regarding 1):
That's a big question. :) I've already answered parts of it in my comments regarding question 2). Other things that might be interesting are:

• the 16px max dimension is nice because in JPEG's 8x8 block processing, you do not suffer from padding bytes.
• food for thought: the upscaling of any image in the browser rendering engine - while negligible compared to e.g. clientside blur - costs computation time and has an impact on the amount of reflow operations a browser neeeds to perform to lay out the page. While I do not recommend to create placeholder images of the same dimensions as the original - which would defeat the purpose ... :D - I would at least make sure that the HTML element carries the appropriate width+height dimensions so that the browser can lay out the page efficiently.
• since you're mentioning WebP in your LQIP-Modern, please ensure that in your visual comparison and size calculations, you're comparing apples-to-apples as much as possible. E.g. LQIP uses JPEG, so offer a JPEG-to-JPEG comparison to LQIP-Modern.
• You mention an "encoding quality of 20" for the encoder. Please be aware that compression quality is not a standardized metric across JPEG encoders and doubly so across file formats (WebP vs. JPEG). Since you're relying on Sharp and it in turn relies on the underlying OS providing libjpeg, this effectively means varying lossy compression results across devices dependent on which JPEG encoder is installed on the OS and thus providing libjpeg. Therefore, I'd recommend that 1) you investigate compression quality for WebP vs. JPEG seperately, that 2) you mention compression quality for JPEG only in relation to the underlying JPEG encoder and its current version (e.g "a JPEG quality setting of 20 on mozjpeg v.3") and that 3) you consider switching Sharp to use mozjpeg (there are ways / forks to tie Sharp to mozjpeg) so that users of LQIP-Modern get the best possible JPEG compression for the placeholder images that they generate. Last but not least, since you've already brought WebP into the mix: check out AVIF. ;)

---

Again, thank you for your efforts and pinging us here at SQIP. <3

[axe312ger]

Thanks for this extenden reply @technopagan

pretty busy right now but very open to all PRs!