A support for Low Quality Placeholders

Here is the initial patch

Overview:

• Creates a new table and image style
  • table to store the encoded image data. this is so we aren't stuck trying to encode things on the fly
  • image style so we can control the LQP size. smaller images make for smaller encodings but come out blurrier.
• Updates the field formatted to have a checkbox to use LQP for individual displays
• Creates a new image style to generate the low-quality version of the images from
• Update the resizer to use `once` and intersection observer.
  • once so we do attach observers multi times of ajax events happen
  • intersection observer so we don't have to run updateImage() on all the images out of the gate and just load things as folks scroll
• Updates readme with some notes about LQP

In theory, I like the idea. I have been thinking about this myself as well. However, for most of the sites I have been using this on, we load a 50w image by default, which kind of accomplishes the same thing (only without all the added technical complexity). For example, a 50w hero image loads initially using about 600b. Is the base64 LQP really that much smaller and worth the added complexity?

That's fair; it does at more technical complexity, which is more challenging to maintain.

In terms of metrics, however, I can provide some data. We're currently working on a new build and have a Lighthouse test run on our feature environments. We test the same URL 3 times and average the scores for each PR. Granted, we already had a pretty performant front end, but with this patch on the site, we get an average 3-point improvement for the performance metric when testing against the homepage.

Without LQP - Current site

With LQP - Feature environment

What was the size (pixels) of the smallest image compared to the LQP (compared in bytes)?

Hi Sean

have been busy with project work recently so haven't had time to validate the data you were looking for.

What I have done is have 2 environments with the sole difference being whether LQP is enabled on each one. I then loaded the homepage through the webpagetest.org performance test.

There is a significant difference in the number of bytes and total page load speed between the two.

Without LQP

With LQP enabled

As you can see in the bytes transferred graph, we are sending more data in the HTML because of the encoded images but the total number of image files related bytes is significantly less.

Hope this helps you make a decision.

Cheers,
Paul

What is the size (width) of the smallest image src loaded for each image used in your example?

In 🐛 Improve lazy/eager loading Fixed we also added a bunch of improvements to reduce the initial number of loaded bytes. Did you enable lazy loading for images and use the latest release for your test?

I had just checked it with 1.3.1 before I fixed my patch/MR for 1.3.3

The smallest image is 650px.

I have re-run the test with the following configuration for my media displays.

Those settings give me the following scores.

1.3.3 is an improvement compared to the previous versions and is more performant than LQP.

If you decide not to merge LQP, I'll keep the MR updated as we need it for our project.

Thanks for the quick feedback. Great to hear that the latest release makes a significant performance improvement!
Another tip would be to lower the smallest image size to something like 50px. That should give similar results to something like LQP.

Since the latest release has similar (or maybe even better) performance than the LQP version, I'm inclined to close this issue as won't fix. I do appreciate the work you put into this and helping look for performance improvements.