[emsixteen]

Forgive my ignorance, feel like it's embarrassing to ask here to be honest, but can someone explain how this helps/works? I've never actually used these placeholders, but I always imagined that they work by processing the image beforehand on the server and using something like a super low quality image or gradient or such as the placeholder. If this is done in pure CSS, does the browser not need to download the image first to figure out what's in it, before then doing the placeholder effect? Perhaps it doesn't help that I've not had my morning coffee yet, but I don't understand.

[diiiimaaaa]

These placeholders are generated by processing the image on a server beforehand. Generally they create some html, css or svg markup that is served inline. Having to do a separate request for such placeholder is very bad idea.

It's not clear if these placeholders do actually help, especially placeholders with very low quality. In my opinion, they only add visual noise.

I'd focus more on avoiding layout shifts when images load, and serving images in a good format (avif, webp) and size (use `srcset` or `<picture>`).

[biker142541]

> It's not clear if these placeholders do actually help

Well, it depends what you mean by help. It’s very dependent on use case and desired UX. Obviously you can prevent layout shifts without them, you can provide feedback on loading status in other ways, and ensure images don’t slow load time without colored placeholders. But they can provide a pleasant UX for some use cases, when done right. They can be annoying when not done well.

[WorldMaker]

There are certainly legitimate cases where the placeholders come from a separate request. Most CRDTs and similar sync engines you don’t want to (and/or are not allowed to) store binary images directly inside them, so you need to store references to some other blob storage. But Blurhash is a simple short string (and LQIP here is a simple integer) and those store well in CRDTs and other sync engines, so you can pair that with your reference pointer (which might not even be a URL depending on your blob storage engine and its sync mechanics and authorization schemes and whatever else) and whatever other metadata you want/need to include like width/height or aspect ratio and alt/title/caption.

When the CRDT or document sync engine inevitably sync much faster than your blobs you have something to show in that placeholder. If the blob sync fails for some reason, you still have something to show more interesting than your browser’s old broken image logo under your “Sync is slow or broken” warning.

I think placeholders help a bunch in situations like that where your image fetch is a lot more complicated than a URL that you can add in a `src` attribute. It’s also really easy to get into situations where such blob fetching is complex: In cases where you have to respect user and/or tenant privacy and need complex OAuth flows. In cases where you need end-to-end photo encryption. In cases where you need peer-to-peer sync and only P2P sync because you’ve been mandated to reduce touch points and likelihood of accidentally storing photos at rest in middle layers. Situations like images of HIPAA data, PII, PIFI, etc.

On a static site with public (or cookie sessioned) images direct linked by URL, yeah the placeholders don’t do much other than check certain design boxes. There’s lots of other places images (and their metadata) come from, and placeholders are a useful fallback in the worst cases.

[JimDabell]

It’s still computed at build time or dynamically, by a programming language. The “pure CSS” part of it means that the hash is decoded into something visual by CSS without any JavaScript required.

[simonw]

Here's the server-side (Node.js) build script that calculates the integer placeholder image values and adds them to the document: https://github.com/Kalabasa/leanrada.com/blob/7b6739c7c30c66...