Putting images on websites is incredibly simple, yes? Actually, yes, it is. You use
<img> and link it to a valid source in the
src attribute and you’re done. Except that there are (counts fingers) 927 things you could (and some you really should) do that often go overlooked. Let’s see…
- Make sure you use sentence-format
alttext on the image to describe what the image depicts.
- Wrap it in a
<figure>and use a
<figcaption>if you want visible text that goes with it.
- Use a
<picture>element with a variety of
<source>elements if you want to either…
- Have different source images for different screen sizes and other conditions.
- Serve different formatted images, to take advantage of next-gen image formats.
- Know enough about image formats off the bat, so that you can use formats like SVG when appropropriate.
- Know enough about your audience so that you can default to using the most modern format you can.
sizesattributes to serve differently sized images to be bandwidth efficient on differnet devices. Note that to be as efficient as possible, creating these image variations is dependent on the image itself, not pre-determined sizes.
- Optimize the image and all its variations. Try lots of image optimization software, as they all yield different results. Pick the best. Make sure the optimized versions aren’t accidentally bigger in size or lower quality than the original because that can happen.
- Lazy load the images so users don’t have to download images they won’t see. Natively, we’ve got
loading="lazy"but this is so important that it’s probably worth polyfilling.
- Make sure to include
heightattributes so that the image reserves the correct amount of space in a layout before it loads (even when the image is of fluid width).
- Host your images on a fast, cookie-less, global CDN. Probably
<link rel="dns-prefetch">to the CDN domain(s). But don’t do any CDN stuff in dev, only staging or production. The canonical source for your images should be your own servers, so you can move CDNs as needed.
- The largest image on the page could preload entirely, like
<link rel="preload" as="image">for the best possible LCP.
- Try to figure out when you should use
decoding="async"(I have no idea).
- Have fallback styling in place for when/if the image doesn’t load.
- Consider more pleasing before-load or fail states for the images, like small blurred versions of the images.
- Have performance monitoring in place to make sure rogue giant images don’t slip through and mess with your performance budgets, and can watch for broken image errors.
I’m sure I’m forgetting some. Makes you sweat, doesn’t it?
Addy covered a lot of this in more detail in this Smashing Magazine article and has a whole book on the subject.
If you ask me, it can’t be done. At least, not all of it together while being practical with your time. Fortunately: computers. I know both Eleventy Image and gatsby-plugin-image are well-regarded in how well they automate this stuff and deliver as many of these best practices as they can.
Another reality is sometimes just doing some of these things, perhaps the biggest wins, while being practical with time. In Jake’s “Half the size of images by optimising for high density displays” he writes:
Here’s the technique I use for most images on this blog: I take the maximum size the image can be displayed in CSS pixels, and I multiply that by two, and I encode it at a lower quality, as it’ll always be displayed at a 2x density or greater. Yep. That’s it.
Reminiscent of Dave’s 2013 1.5✕ hack.
<nuxt-img/>does it all for you!
See – https://image.nuxtjs.org/components/nuxt-img/
So does gatsby-plugin-image.
Long live open source
I use imgix, they have a free subscription tier and a great sdk library.
I explore some options to make images simpler in the article Images are hard. Is there a a simpler way?
Or you could use the Accept header to serve the correct next-gen image format, then you could just use a element
Sure… for the browsers that support that, the combination of both the correct header and the next-gen format. This will continue to change as image formats change. And it means having code-level control over the server that serves the images. Can be done! I’ve done it via Cloudflare Worker, which worked out pretty well.