One thing to consider can be the Blurhash algorithm:

• https://github.com/woltapp/blurhash

Where the hash for the image can be stored as part of the meta of the image.

The Node.js AMP Optimizer has support for blurry image placeholders. Here's the implementation: https://github.com/ampproject/amp-toolbox/blob/main/packages/optimizer/lib/transformers/AddBlurryImagePlaceholders.js

The LQIP is quite a common pattern across the web now. I've worked on a few projects using https://github.com/aFarkas/lazysizes which also implements this paradigm.

One way of handling the low quality image, in order to save a server request is to encode it:
data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==

This means that theres no request to the placeholder image and the browser can carry on its business without worrying about connectivity or download issues. Im sure that may increase the byte size of the final HTML resource, but if sites are using gzip or brotli I think this could be trivial.

I have implemented blurhash for the web stories plugin. I really liked it. I would be willing to work on this as a feature plugin.

I have implemented blurhash for the web stories plugin. I really liked it. I would be willing to work on this as a feature plugin.

That looks promising, can the blurhash approach use the base64 version of the placeholder mentioned above?

Did a bit of research on this @adamsilverstein - looks like its faster to run with blurhash as opposed to implementing a base64 image - so maybe we just run with blurhash ?

Adding some additional ideas here in case we want to explore different alternatives:

• Create a smaller image 1x1
• Create a smaller image 10x10
• Store and save the predominant image color as part of the meta and use that as background to fill the container as the image loads.

One thing that we should remember is that images are indexed by search engines and one of the techniques to drive traffic to the site. If we replace images with placeholders, then this may cause images not being indexed by search engines and thus negatively affect the organic traffic for some sites.

JPEG has progressive compression that allows to achieve similar results: https://medium.com/hd-pro/jpeg-formats-progressive-vs-baseline-73b3938c2339#e3aa

Not sure how feasible it is to implement in our plugin.

JPEG has progressive compression that allows to achieve similar results: medium.com/hd-pro/jpeg-formats-progressive-vs-baseline-73b3938c2339#e3aa

Possibly we could take advantage of this with custom Image classes, we need to look into support in libgd and imagick. This wouldn't help with WebP images.

One thing that we should remember is that images are indexed by search engines and one of the techniques to drive traffic to the site. If we replace images with placeholders, then this may cause images not being indexed by search engines and thus negatively affect the organic traffic for some sites.

Good point that bears more investigation. Can the image(s) be listed in a meta tag to avoid that (ie og:image)?

My other concern about this change overall is how it might negatively impact the largest contentful paint measurement, how much of a hit will that take for this "perceived" performance boost, and is that acceptable?

I have looked at this a bit and a bit of code that works
the approach I took was to add a background image to the img tag and removed the background on image load (for transparent images)
I created the image using blurhash and stored the hash as image meta and then created the base64 on the render
It might be better to store the base64 in DB to save having to recreate it each time but this would take more space
I hacked some proof on concept code here https://github.com/pbearne/blurhash/blob/main/blurhash.php

onload="this.style.removeProperty('background');" style="background-size: cover; background-image: url(data:image/png;base64,iVBORw0KGgoAA......ORK5C=)

I need to add a filter to the media.php in core

$filtered_image = apply_filters( 'wp_img_tag_add_adjust', $filtered_image, $context, $attachment_id );

What I like about adding the image server-side is that don't have to wait for JS to render it but the downside is more data on the wire and isn't removed if no-JS (but we could handle that with CSS maybe)

Would this approach work?

I suspect that we will need a new filter for any approach we take to allow us to add elements to the img tags similar to this comint
xwp/wordpress-develop@2efb39b

@pbearne Very interesting, I was wondering about using the background - clever!

I need to add a filter to the media.php in core

Can you point specifically to where (or is there a ticket to add)? Could you try using wp_get_attachment_image filter for now? That might be sufficient for the plugin.

Have you tested how this approach affects performance metrics?

JPEG has progressive compression that allows to achieve similar results: medium.com/hd-pro/jpeg-formats-progressive-vs-baseline-73b3938c2339#e3aa

@eugene-manuilov Good point, this is a great feature of jpegs.

When researching I found that LCP doesn't take progressive images into account currently (see w3c/largest-contentful-paint#71) so I'm curious how any approach would affect both perceived and measured performance.

@adamsilverstein

Can you point specifically to where (or is there a ticket to add)? Could you try using wp_get_attachment_image filter for now? That might be sufficient for the plugin.

here is the filter I was looking at adding xwp/wordpress-develop@2efb39b
I will look at the wp_get_attachment_image filter and see if I can use that instead

Have you tested how this approach affects performance metrics?

We are looking at the metrics it does add to the content on the wire so it may well be better to use JS to convert the blurhash into the background image

@adamsilverstein I have a working(ish) plugin https://github.com/pbearne/blurhash

@adamsilverstein I have a working(ish) plugin https://github.com/pbearne/blurhash

Was looking for this all over!

module for performance plugin
https://github.com/xwp/performance/tree/INITS-199_domiant_color

video of it working

interesting related ticket shared by Joy in slack: w3c/largest-contentful-paint#68 (comment)

@pbearne - #282 is a core patch right? Have you been able to implement this in the performance lab plugin (and if so, what is the PR for that)?

original conversation on slack

As low-res image you can use the preview contained in the exif data of the jpg, a method to get that image is to use the function exif-thumbnail (php exif module needed).
To mention, it is possible for an image to not have a preview (not all have it, especially if they were stripped of metadata before being uploaded) so better to use it in combination with other methods.

this also allows us to color the drop shadow
box-shadow: var(--dominant-color) 0px 54px 55px;
or create a border
border: solid var(--dominant-color);