Recently, I’ve looked at two Sitecore sites (not written by me!) where areas of the page (<div> tags) have a background image set by inline-CSS. For example, something like this:

Which has markup like this:

Okay, what’s wrong with this? Well, I’ll ignore that setting an inline background image “smells” funny; it does make a sort of sense, even though I think it better to avoid inline CSS. But I’m a back-end dev mainly, so what do I know?

However, consider the URLs. The one in the STYLE definition doesn’t specify an image size. No ‘h’ or ‘w’ parameters for height and width. No media request protection hash.

So, the image for the style will be sent at full size, even if it’s huge. That’s one of the things we’re supposed to prevent. If an editor specifies an image with a native size of 3000×2000 pixels, that’s what will be sent.

Secondly, let’s skip over having both an <img> tag and a <div> tag with a background style; I’m pretty sure that’s an responsive design thing. However, let’s consider those URLs again. They’re different, which is fine if they’re actually different images. They could really be different images. However, in both the sites I’ve seen recently, this wasn’t the case. They were always using the same actual image, but served over 2 different URLs. This means that the browser will download both separately, rather than just downloading it once. It’ll cache them separately, even though they’re identical. It’s just plain inefficient.

To put it in perspective, on one of these sites, some pages are 40% redundant data. Half the images downloaded for the page are not required.

The lesson – if you’re using inline styles to set background images that the editors can change, then make sure you generate URLs that include image resizing parameters and media request hashes – and that match other usages in your system.