#ASKTHEINDUSTRY 39: Is a 1 MB header image too big?
I stumbled upon this question on the reddits and I figured I’d dive a little bit deeper, since I believe it is an interesting and legitimate doubt to have. What size is too big? What can we do if we really need that masthead image to be loaded fast? What follows is an extended version of my answer to this reddit user.
It all comes down to the question:
Is the image really important for the reader’s experience?
If so, compression may not be enough. When we say an image is core to the reader’s experience, what we really mean is that such an image is needed for the user to make sense of the content. In other words, we need that image to be ready as quickly as we can, or otherwise we’d deliver a bad experience. In this case, there a couple of techniques you may want to check out:
- You can preload it for faster discovery. Basically, this technique aims at triggering that network request as high as possibile in the network chain.
- Use progressive jpeg. This one plays on perceived performance and tries to show something to the reader as soon as possible, progressively enhancing that something as more information comes through the network.
- Another technique could be inlining a 1% version of your image as dataURI. In other words, you’d include the information needed to render a low resolution version of that image in the HTML document, skipping the network request altogether (at least, initially). It needs to be known, though, that this is a really controversial technique, since it can easily bloat up the size of your HTML file. (While you’d ideally want your above the fold content to be as small as 14KB)
Conversely, if the image is not fundamental for the reader, compression may be your answer. You can look up tools like TinyPNG or ImageMagick, or reduce the resolution of your image to a more common size (like 1024px wide). The rule of thumb would be to try and stay between 100K and 200K. Why? Because at that size, users on a mobile network, would be able to get the image in under a second, which is an acceptable amount of time to be passively waited.
Should I load it asynchronously via JavaScript as well?
Loading the image via JavaScript will make things even worse. In fact, that would be a technique that makes sense only for the so-called blocking resources, meaning those assets that force the browser to wait the download of such an asset before rendering the page.
CSS files and JavaScript files are blocking resources. Images are not.
In fact, the browser already loads images with low priority, and asynchronously renders them in the page as soon as they are ready.
Let’s revise how a regular image gets treated by the browser:
Download HTML ----
Parse HTML ---
Download Image ----------This is what happens if you load it via JavaScript:
Download HTML ----
Parse HTML ---
Download JS ------
Parse JS ---
Download Image ----------As you can see, your image’s download would depend on JavaScript to be ready just to be discovered.
Let’s frame the problem here: a big fat image (>500Kb) makes it for a really slow experience on mobile devices and flaky connections. The problem is relevant only if the image is somehow core to the reader’s experience (as you confirmed). In such a case, you’d want this image to be displayed as soon as possible.
Therefore, we need a way to have the request being sent sooner. The new preload directive is a standard-compliant way to achieve just that, but only in modern browsers. Here’s how it would look:
Download HTML ----
Parse HTML ---
Download Image ----------and here’s the code:
<head>
<link rel="preload" as="image" href="path/to/image">
</head>The download of the image would happen almost in parallel with the parsing of the HTML document.
Hope this helps anyone. Let me know if there’s anything unclear, or that you disagree with.
