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 alt text 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.
  • Use srcset and sizes attributes 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 it’s 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 width and height attributes 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="preconnect"> and <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.

Similar Posts