Lazy loading images with accessibility and printer support

Question

I am looking for a proper way to implement lazy loading of images without harming printability and accessibility, and without introducing layout shift (content jump), preferrably using native loading=lazy and a fallback for older browsers. Answers to the question How lazy loading images using JavaScript works? included various solutions none of which completely satisfy all of these requirements.

An elegant solution should be based on valid and complete html markup, i.e. using <img src, srcset, sizes, width, height, and loading attributes instead of putting the data into data- attributes, like the popular javascript libraries lazysizes and vanilla-lazyload do. There should be no need to use <noscript> elements either.

Due to a bug in chrome, the first browser to support native lazyloading, images that have not yet been loaded will be missing in the printed page.

Both javascript libraries mentioned above, require either invalid markup without any src attribute at all, or an empty or low quality placeholder (LQIP), while the src data is put into data-src instead, and srcset data put into data-srcset, all of which only works with javascript. Is this considered an acceptable or even best practice in 2020, and does this neither harm the site accessibility, cross-device compatibility, nor search engine optimization?

Update:

I tried a workaround for the printing bug using only HTML and CSS @media print background images in this codepen . Even if this worked as intended, there would be a necessary css directive for each and every image, which is neither elegant nor generic. Unfortunately there is no way to use media queries inside the <picture> element either.

There is another workaround by Houssein Djirdeh at at lazy-load-with-print-ctl1l4wu1.now.sh using javascript to change loading=lazy to loading=eager when a "print" button is clicked. The same function could also be used onbeforeprint.

I made a codepen using lazysizes.

I made another codepen using vanilla-lazyload .

I thought about forking a javascript solution to make it work using src and srcset, but this must probably have been tried before, the tradeoff would be that once the lazyloading script starts to act on the image elements, the browser might have already started downloading the source files.

Answer 1

Just show me your hideous code, I don't want to read!

If you don't want to read my ramblings the final section "Demo" contains a fiddle you can investigate (commented reasonably well in the code) with instructions.

Or there is a link to the demo on a domain I control here that is easier to test against if you want to use that.

There is also a version that nearly works in IE here, for some reason the "preparing for print" screen doesn't disappear before printing but all other functionality works (surprisingly)!

Things to try:

1. Try it at different browser sizes to see the dynamic image requesting
2. try it on a slower connection and check the network tab to see the lazy loading in action and the dynamic change in how lazy loading works depending on connection speed.
3. try pressing CTRL + P when the network connection is slow (without scrolling the page) to see how we load in images not yet in the DOM before printing
4. try loading the page with a slow network connection and then using FILE > PRINT to see how we handle images that have not yet loaded in that scenario.

Version 0.1, proof of concept

So there is still a long way to go, but I thought I would share my solution so far.

It is complex (and flawed) but it is about 90% of what you asked for and potentially a better solution than current image lazy loading.

Also as I am awful at writing clean JS when prototyping an idea. I can only apologise to any of you brave enough to try and understand my code at this stage!

only tested in chrome - so as you can imagine it might not work in other browsers, especially as grabbing the content of a <noscript> tag is notoriously inconsistent. However eventually I hope this will be a production ready solution.

Finally it was too much work to build an API at this stage, so for the image resizing I utilised https://placehold.it - so there are a few lines of redundant code to be removed there.

Key features / Benefits

No wasted image bytes

This solution calculates the actual size of the image to be requested. So instead of adding breakpoints in something like a <picture> element we actually say we want an image that is 427px wide (for example).

This obviously requires a server-side image resizing solution (which is beyond the scope of a stack overflow answer) but the benefits are massive.

First of all if you change all of your breakpoints on the site it doesn't matter, so no updating picture elements everywhere.

Secondly the difference between a 320px and 400px wide image in terms of kb is over 40% so picking a "similarly sized" image is not ideal (which is basically what the <picture> element does).

Thirdly if people (like me) have massive 4K monitors and a decent connection speed then you can actually serve them a 4K image (although connection speed detection is an improvement I need to make in version 0.2).

Fourthly, what if an image is 50% width of it's parent container at one screen size, 25% width of it's parent container at another, but the container is 60% screen width at one screen size and 80% screen width at another.

Trying to get this right in a <picture> element can be frustrating at best. It is even worse if you then decide to change the layout as you have to recalculate all of the width percentages etc.

Finally this saves time when crafting pages / would work well with a CMS as you don't need to teach someone how to set breakpoints on an image (as I have yet to see a CMS handle this better than just setting the breakpoints as if every image is full width on the screen).

Minimal Markup (and semantically correct markup)

Although you wanted to not use <noscript> and avoid data attributes I needed to use both.

However the markup you write / generate is literally an <img> element written how you normally would wrapped in a <noscript> tag.

Once an image has fully loaded all clutter is removed so your DOM is left with just an <img> element.

If you ever want to replace the solution (if browser technology improves etc.) then a simple replace on the <noscripts> would get you to a standard HTML markup ready for improving.

WebP

Of course this solution requests WebP images if supported (its all about performance!). On the server side you would need to process these accordingly (for example if an image is a PNG with transparency you send that back even if a WebP image is requested).

Printing

Oh this was a fun one!

There is nothing we can do if we send a document to print and an image has not loaded yet, I tried all sorts of hacks (such as setting background images) but it just isn't possible (or I am not clever enough to work it out....more likely!)

So what I have done is think of real world scenarios and cover them as gracefully as possible.

1. If the user is on a fast connection we lazy load the images, but we don't wait for scroll to do this. This could mean a bit more load on our servers but I am acting like printing is highly important (second only to speed).
2. If the user is on a slow connection then we use traditional lazy loading.
3. If they press CTRL + P we intercept the print command and display a message while the images are loading. This concept is taken from the example OP gave by Houssein Djirdeh but using our lazy loading mechanism.
4. If a user prints using FILE > PRINT then we instead display a placeholder for images that have not yet loaded explaining that they need to scroll the page to display the image. (the placeholders are approximately the same size as the image will be).

This is the best compromise I could think of for now.

No layout shifts (assuming content to be lazy loaded is off-screen on page load).

Not a 100% perfect solution for this but as "above the fold" content shouldn't be lazy loaded and 95% of page visits start at the top of the page it is a reasonable compromise.

We use a blank SVG (created at the correct proportions "on the fly") using a data URI as a placeholder for the image and then swap the src when we need to load an image. This avoids network requests and ensures that when the image loads there is no Layout Shift.

This also means the page is semantically correct at all times, no empty hrefs etc.

The layout shifts occur if a user has already scrolled the page and then reloads. This is because the <img> elements are created via JavaScript (unless JavaScript is disabled in which case the image displays from the <noscript> version of the image). So they don't exist in the DOM as it is parsed.

This is avoidable but requires compromises elsewhere so I have taken this as an acceptable hit for now.

Works without JavaScript and clean markup

The original markup is simply an image inside a <noscript> tag. No custom markup or data-attributes etc.

The markup I have gone with is:

<noscript class="lazy">
    <img src="https://placehold.it/1500x500" alt="an image" width="1500px" height="500px"/>
</noscript>

It doesn't get much more standard and clean as that, it doesn't even need the class="lazy" if you don't use <noscript> tags elsewhere, it is purely for collisions.

You could even omit the width and height attributes if you didn't care about Layout Shift but as Cumulative Layout Shift (CLS) is a Core Web Vital I wouldn't recommend it.

Accessibility

The images are just standard images and alt attributes are carried over.

I even added an additional check that if alt attributes are empty / missing a big red border is added to the image via a CSS class.

Issues / compromises

Layout Shift if page already scrolled

As mentioned previously if a page is already scrolled then there will be massive layout shifts similar to if a standard image was added to a page without width and height attributes.

Accessibility

Although the image solution itself is accessible the screen that appears when pressing CTRL + P is not. This is pure laziness on my part and easy to resolve once a more final solution exists.

The lack of Internet Explorer support (see below) however is a big accessibility issue.

IE

UPDATE There is a version that nearly works in IE11 here. I am investigating if I can get this to work all the way back to IE9.

Also tested in Firefox, Edge and Safari (mobile), seems to work there.

ORIGINAL Although this isn't tested in Firefox, Safari etc. it is easy enough to get to work there if there are issues.

However accessing the content of <noscript> tags is notoriously difficult (and impossible in some versions) in IE and other older browsers and as such this solution will probably never work in IE.

This is important when it comes to accessibility as a lot of screen reader users rely on IE as it works well with JAWS.

The solution I have in mind is to use User Agent sniffing on the server and serve different markup and JavaScript, but that is complex and very niche so I am not going to do that within this answer.

Checking Latency

I am using a rather crude way of checking latency (to try and guess if someone is on a 3G / 4G connection) of downloading a tiny image twice and measuring the load time.

2 unneeded network requests is not ideal when trying to go for maximum performance (not due to the 100bytes I download, but due to the delay on high latency connections before initialising things).

This needs a complete rethink but it will do for now while I work on other bits.

Demo

Couldn't use an inline fiddle due to character count limitation of 30,000 characters!

So here is the current JS Fiddle - https://jsfiddle.net/9d5qs6ba/.

Alternatively as mentioned previously the demo can be viewed and tested more easily on a domain I control at https://inhu.co/so/image-concept.php.

I know it isn't the "done thing" linking to your own domains but it is difficult to test printing on a jsfiddle etc.

Answer 2

The proper solution for printable lazy loading in 2022 is using the native loading attribute.

<img loading=lazy>

The recommendation to use a custom print button has been obsoleted as chromium issue 875403 got fixed.

Prior recommendations included adding a custom print button (which did not fix the problem when using the native browser print functionality) or using JavaScript to load images onBeforePrint the latter not being considered a good solution, as loading=lazy, as a "DOM-only" solution, must not rely on JavaScript.

Beware that, even after the bug fix, some of your users might still visit your site with a buggy browser version.