How To Change Background Image Automatically In Javascript Code

Images are critical for every website and application today. Whether information technology exist marketing banners, production images or logos, it is incommunicable to imagine a website without images. Sadly though, images are large in size making them the unmarried largest contributor to the folio size.

As per the latest HTTP Archive data, the median page size on desktops is 1511 KB. Images make up for nearly 650 KB of that size, roughly 45% of the total folio size. At present, since we cannot practice away with images, nosotros need to make our web pages load fast with them.

In this guide, we will talk about lazy loading images, a technique that helps improve the page load time and reduces page size, while however retaining all the images on the folio.

Get this guide delivered equally an eBook. Straight to your mailbox!

What is Epitome Lazy Loading?

Lazy Loading Images is a set up of techniques in web and application development that defer the loading of images on a page to a later betoken in time - when those images are really needed, instead of loading them up front. These techniques help in improving performance, ameliorate utilization of the device'south resource, and reducing associated costs.

Here is a quick video to aid you understand better:

The discussion "lazy" in the English language is often attributed to the human activity of avoiding piece of work as long as possible.

Similarly, lazy loading defers the loading of resource on the folio till they are really needed. Instead of loading these resources equally soon every bit the page loads, which is what normally happens, the loading of these resource is put off till the moment the user actually needs to view them.

The technique of lazy loading can be applied to nearly all the resources on a page. For case, in a single folio application, if a JS file is non needed until afterward, it is best non to load information technology initially. If an image is not needed upwardly front, load it afterwards when it really needs to be viewed.

Why go for lazy loading images at all?

Lazy Loading defers the loading of an image that is not needed on the page immediately. An epitome, non visible to the user when the page loads, is loaded later when the user scrolls and the prototype actually becomes visible. If the user never scrolls, an image that is not visible to the user never gets loaded.

It carries two main advantages.

1. Performance Improvement

This is the well-nigh important one for you as a website administrator - amend operation and load time.

With lazy loading, yous are reducing the number of images that need to exist loaded on the page initially. Lesser resource requests hateful lesser bytes to download and bottom contest for the limited network bandwidth available to the user. This ensures that the device is able to download and process the remaining resources much faster. Hence, the page becomes usable much sooner as compared to one without lazy loading.

2. Cost reduction

The second do good for you is in terms of delivery costs. Image commitment, or delivery of any other asset, is normally charged on the basis of the number of bytes transferred.

As mentioned earlier, with lazy loading, if the paradigm is non visible, it never gets loaded. Thus, you reduce the total bytes delivered on the page., peculiarly for users that bounce off the page or interact with only the top portion of the folio. This reduction in bytes transferred from your delivery network reduces commitment costs. This volition become more than apparent as we explore lazy loading further.

Which Images tin can exist Lazy Loaded?

The bones idea of lazy loading is simple - defer loading anything that is not needed right now. For images it usually translates to any image that is non visible to the user up front can be lazy loaded.

As the user scrolls down the page, the paradigm placeholders kickoff coming into viewport (visible office of the webpage). Nosotros trigger the load for these images when they become visible.

You tin find out which images are a candidate for lazy loading and how many bytes you lot can relieve on the initial page load past using Google Lighthouse inspect tool. The audit performed by this tool has a department dedicated for offscreen images. You can besides use ImageKit'due south website analyzer to identify if your website uses lazy loading or not, in addition other critical image-related optimizations on your page.

Lazy loading is critical not only for practiced operation, but also to deliver a good user experience.

Lazy Loading Techniques for images

Images on a webpage can be loaded in two ways - using the <img> tag, or using the CSS `background` property. Let's first look at the more than common of the two, the <img> tag, and then move on to CSS background images.

The full general concept of lazy loading images in <img> tag

Lazy loading images can be broken down into two steps:

Footstep one is to prevent the prototype load upwardly front. For images loaded using the <img> tag, the browser uses the src aspect of the tag to trigger the image load. Irrespective of whether information technology is the 1st or the 1000th image in your HTML and well off-screen, if the browser gets the src attribute, information technology would trigger the epitome load.

Thus, to lazyload such images, put the epitome URL in an aspect other than src. Let's say we specify the image URL in the information-src attribute of the image tag. Now that src is empty, the browser doesn't trigger the prototype load

              <img data-src="https://ik.imagekit.io/demo/default-image.jpg" />

Now that we've stopped the upfront load, nosotros demand to tell the browser when to load the image.

For this, we bank check that as presently as the paradigm (i.e., its placeholder) enters the viewport, nosotros trigger the load.

To cheque when an image enters the viewport, there are two ways:

Trigger prototype load using Javascript events

In this technique, we use event listeners on the scroll, resize, and orientationChange events in the browser. The scroll event is an obvious one to check when the user scrolls the page. The resize and orientationChange events are equally important for lazy loading. The resize event occurs when the size of the browser window changes. The orientationChange event gets triggered when the device is rotated from landscape to portrait mode, or vice versa. In such cases, the number of images that go visible on the screen volition modify. Therefore, we'll need to trigger a load for these images.

When either of these events occur, we find all the images on the page that are to be lazy loaded and haven't been loaded yet. From these images, we check which ones are at present in the viewport. This is washed using the image's peak first, the electric current certificate curl top, and window height. If information technology has entered the viewport, nosotros pick the URL from data-src attribute and put it in the src attribute. This triggers the image load. We likewise remove the class lazy that identifies the images to be lazily loaded for events that trigger later. Once all the images are loaded, we remove the event listeners.

When we scroll, the coil upshot triggers multiple times rapidly. Thus, for performance, we add a small timeout that throttles the lazy loading function execution.

Hither is a working example of this arroyo.

If you notice, the get-go 3 images in the example are loaded up front end. The URL is present directly in the src aspect instead of the data-src attribute. This is essential for a good user experience. Since these images are at the top of the page, they should be made visible equally presently as possible. Nosotros must not wait for an upshot or JS execution to load them.

Using Intersection Observer API to trigger paradigm loads

Intersection Observer API is a relatively new API in browsers. Information technology makes it really simple to notice when an chemical element enters the viewport, and accept an action when it does. In the previous method, we had to bind events, go along operation in mind, and implement a way to calculate if the element was in the viewport or not. The Intersection Observer API makes this really uncomplicated, helps avoid the math, and delivers great operation.

An case of using the Intersection Observer API to lazy load images:

We attach the observer on all the images to be lazy loaded. Once the API detects that the element has entered the viewport, using the isIntersecting property, we selection the URL from the data-src attribute and move it to the src attribute for the browser to trigger the image load. Once this is done, we remove the lazy grade from the image, and also remove the observer from that epitome.

If you compare the time taken to load an image in both the methods, event listeners vs Intersection Observer, y'all would find that using the Intersection Observer API, the image load is triggered much quicker, and yet the site doesn't announced sluggish on scrolling. In the method involving issue listeners, we had to add together a timeout to make information technology performant, which has a marginal impact on the user experience as the image load is triggered with a slight delay.

However, the support for Intersection Observer API is non bachelor across all browsers. Hence, nosotros need to fall back to the event listener method in browsers where the Intersection Observer API is not supported. Nosotros accept taken this into account in the case above.

Native Lazy Loading

In their most recent update, Google has added support for native lazy loading in the Chrome browser'southward latest version - Chrome 76. All Chromium-based browsers, i.east., Chrome, Edge, and Safari, and Firefox. You can detect more details almost browser support for native lazy loading on caniuse.com.

With browser-side support coming into play, at present, developers simply demand to add a "loading" attribute when embedding images, to implement lazy loading on their websites.

In fact, one does not need to even be a developer to get this done. Some bones knowledge of HTML is enough to implement the "loading" attribute, making this feature accessible to many more website admins.

So the code would now look similar -

              <img src="instance.jpg" loading="lazy" alt="..." /> <iframe src="example.html" loading="lazy"></iframe>

The following values are supported by the loading attribute:

lazy - Deferring the loading of assets till it reaches a sure distance from the viewport.
eager - loading the assets as before long every bit the page loads, irrespective of where they are placed on the page, whether above or below the page fold.
auto - This value triggers default lazy loading. Basically, it's the same equally not including the loading attribute.

However, for browsers that do not support native lazy loading, the aforementioned techniques for implementing of it need to be practical.

As covered later in this web log, to prevent the surrounding content from reflowing when a lazy-loaded image is downloaded, make sure to add together height and width attributes to the <img> element or specify their values directly in an inline mode:

              <img src="image1.jpg" loading="lazy" alt="…" width="300" height="300"> <img src="image2.jpg" loading="lazy" alt="…" style="top:300px; width:300px;">

Become this guide delivered every bit an eBook. Direct to your mailbox!

Lazy Loading CSS Background Images

Later <img /> tags, background images are the about common way to load images on a webpage. For <img /> tags, the browser has a very simple arroyo - if the prototype URL is available, let's load the image.

With CSS background images it is not that straightforward. To load CSS background images, the browser needs to build the DOM (Document Object Model) tree, as well as the CSSOM (CSS Object Model) tree, to decide if the CSS way applies to a DOM node in the current document.

If the CSS rule specifying the groundwork image does not apply to an element in the document, then the browser does not load the background image. If the CSS rule is applicative to an element in the current document, then the browser loads the image.

This may seem complex at showtime, only this same behavior forms the footing of the technique for lazy loading background images. In simple terms, we fox the browser into not applying the background image CSS holding to an chemical element till that element comes into the viewport.

Here is a working case that lazy loads a CSS background prototype.

One affair to notation here is that the Javascript code for lazy loading is still the same. We are using the Intersection Observer API method with a fallback to the result listeners. The trick lies in the CSS.

The element with ID bg-image has a background-image specified in the CSS. Withal, when the class lazy is added to this element, in the CSS we override the background-prototype holding and gear up information technology to none.

Since the rule, combining #bg-image with .lazy grade has a higher preference in CSS than only #bg-image, the browser applies the property groundwork-image: none to the element initially. When we curlicue down, the Intersection Observer (or upshot listeners) detects that the prototype is in the viewport and removes the form lazy. This changes the applicable CSS and applies the actual groundwork-epitome property to the element triggering the load of the background image.

Better user feel with lazy loading images

Lazy loading presents a great performance benefit. For an eastward-commerce company that loads hundreds of product images on a page, lazy loading can provide a significant improvement in initial page load time while decreasing the bandwidth consumption.

Still, a lot of companies do not opt for lazy loading considering they believe it goes against delivering a bully user experience quoting reasons like "the initial placeholder is ugly", "the load times are slow", etc.

How can we solve such concerns around user feel with lazy loading of images?

ane. Using the correct epitome placeholders

A placeholder is what appears in the container until the actual paradigm is loaded. Commonly, we see developers using a solid color placeholder for images, or a single image as a placeholder for all images.

We used the aforementioned in our case code as well. A solid light grey color is used for all our image backgrounds. However, nosotros can practice amend to provide a more than pleasing user experience.

A wait at some examples of better placeholders for our images:

a) Ascendant colour placeholder

Instead of using a fixed color for the paradigm placeholder, nosotros observe the dominant color from the original epitome and employ that as a placeholder.

This technique has been used for quite some time in Google image search results and Pinterest.

Sample image picked from Manu.ninja

This might look complex to achieve, simply a very elementary style of accomplishing this is to first scale down the image to a 1x1 pixel and then scale it up to the size of the placeholder - a very crude approximation, only a simple, no-fuss way to get a single ascendant color.

Using ImageKit, the dominant color placeholder can be obtained using a chained transform in ImageKit as shown here:

Dominant colour placeholder epitome URL example using ImageKit

              <!-- Original epitome at 400x300 --> <img src="https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-400,h-300" alt="original paradigm" />  <!-- Dominant colour image with same dimensions --> <img src="https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-1,h-one:west-400,h-300" alt="dominant color placeholder" />

The placeholder image is merely 661 bytes in size, as compared to the original prototype which is 12700 bytes, making it 19x smaller . And information technology provides a more than pleasant transition experience from placeholder to the actual image.

Here's a video demonstrating how this effect works for the user:

You lot can view the working case and code for using dominant color placeholder here.

b) Low quality image placeholder (LQIP)

We tin expand the above thought of using a ascendant color placeholder farther.

Instead of using a single color, nosotros utilize a very low-quality, blurred version of the original image equally the placeholder. Not only does it look ameliorate, it also gives the user some idea almost what to await in the actual epitome, while giving the perception that the image load is in progress. This is great for improving the perceived loading experience.

This technique has been utilized by the likes of Facebook and Medium.com for images on their websites and apps.

LQIP epitome URL example using ImageKit

              <!-- Original image at 400x300 --> <img src="https://ik.imagekit.io/demo/img/image4.jpeg?tr=due west-400,h-300" alt="original image" />  <!-- Depression quality image placeholder with same dimensions --> <img src="https://ik.imagekit.io/demo/img/image4.jpeg?tr=west-400,h-300,bl-30,q-50" alt="dominant color placeholder" />

The LQIP is 1300 bytes in size, almost 10x smaller than the original image, and a significant improvement in terms of visual experience over any other placeholder technique.

Here'due south a video demonstrating how this issue works for the user:

Y'all can view the working example and code for using LQIP technique hither.

It is evident from the video samples of the two techniques to a higher place, that using dominant-colour placeholders or using depression-quality image placeholders provides a smoother transition from the placeholder to the bodily image, while giving the user an idea of what's to come and improves loading perception.

2. Adding some buffer time for paradigm load

When we discussed different methods to trigger prototype load above, we checked for the indicate of time where the prototype enters the viewport, i.due east. when the superlative edge of the image placeholder coincides with the bottom edge of the viewport.

The trouble
Often, users scroll swiftly through the page, and the epitome needs some time to load and appear on the screen. In this scenario, combined with the fact that the load epitome event might exist triggered with a filibuster considering of throttling, you would often face the scenario where the placeholders come into the viewport, the user waits for a few milliseconds while the paradigm loads up. This filibuster makes for a poor user experience.

While using Intersection Observers to load the paradigm or using low-quality image placeholders provides amend loading performance and user experience, there is another simple flim-flam that you tin use to ensure that the images are always loaded completely when they enter the viewport - introduce a margin to the trigger point for images.

The solution
Instead of loading the prototype just when they exactly enter the viewport, load the images when they are, let'south say, 500px away from entering the viewport. This provides boosted fourth dimension, betwixt the load trigger and the actual entry in the viewport, for the images to load.

With the Intersection Observer API, you can use the `root` parameter forth with the `rootMargin` parameter (works as standard CSS margin rule), to increase the effective bounding box that is considered to notice the "intersection".

With the result listener method, instead of checking for the difference between the image border and the viewport border to be 0, nosotros can use a positive number to add together some threshold.

The instance here uses a 500px threshold to load images.

Equally evident from the video beneath (monitor the network requests closely appearing at the bottom), while scrolling, when the 3rd image is in view, the 5th image gets loaded. When the 4th image comes into the view, the sixth image gets loaded. This way we are giving sufficient time for the images to load completely and in most cases, the user won't meet the placeholder at all.

In case y'all haven't noticed nevertheless, in all our examples, the tertiary image (image3.jpg) is always loaded up front, even though it's outside the viewport. This was also washed following the same principal - load slightly in advance instead of loading exactly at the threshold for better user experience.

If you are using the native prototype lazy loading method, browsers automatically calculate this distance from the viewport threshold to determine when the browser should trigger the prototype load. Browsers consider the epitome type, network speed, and data-saver setting in the browser to determine this threshold, keeping in mind programmer expectations and user experience.

three. Avoiding content shifting with lazy loading

This is some other trivial indicate which, if solved, can help maintain a proficient user experience.

The trouble
When there is no image, the browser doesn't know the dimensions of the content that is to be displayed in the enclosing container. And if we practice not specify it using CSS, the enclosing container would have no dimensions, i.e. 0 x 0 pixels. So, when the epitome gets loaded, the browser would resize the enclosing container to fit the image.
This sudden change in the layout causes other elements to movement effectually and it is called content shifting. As demonstrated in this content shifting article & video from Keen Magazine, it's a rather unpleasant feel for a user equally the content moves suddenly when the image loads.

The solution
This tin can be avoided by specifying a height and/or width for your enclosing container and then that the browser can paint the epitome container with a known acme and width. Afterwards, when the image loads, since the container size is already specified and the prototype fits into that perfectly, the rest of the content around the container stays put.

4. Exercise not lazy load all the images

This is another mistake the developers often commit - lazy load all the images on the page. This might reduce the initial page load, simply would as well consequence in bad user experience every bit a lot of images, even the ones at the top of the webpage, won't show up till the Javascript gets executed.

Here are some general principles to follow to place which images should exist lazy loaded.

a) Any epitome that is nowadays in the viewport, or at the outset of the webpage, should non be lazy loaded. This applies to any header prototype, marketing banner, logos, etc., as the user should run across them as soon as the page loads.

Also, as mobile and desktop devices have different screen sizes, they will have a different number of images that volition exist visible on the screen initially. So you need to have into account the device type to decide which resources to load up front and which to lazy load.

b) Any image that is only slightly off the viewport should not be lazy loaded. This is based on the point discussed earlier - load slightly in advance. And then, let'due south say, any image that is 500px or a single scroll from the bottom of the viewport can be loaded up forepart as well.

c) If the page isn't too long, may be just a single roll or two, or if there are less than v images outside the viewport, then lazy loading can be avoided birthday.

It would not provide whatever significant benefit to the finish user in terms of operation. The additional JS that you load on the page to enable lazy loading will offset any benefit reaped from lazy loading such a small number of images.

Javascript dependency of Lazy Loading

The entire idea of lazy loading is dependent on the availability of Javascript execution capabilities in the user's browser. Though native lazy loading promises to remove this dependency, with browser support all the same shut to 70%, if you are to provide the same feel beyond all browsers, you would still need to utilize JS libraries.

While nearly of your users would accept Javascript execution enabled in their browser, as it is essential for almost all websites these days, y'all may want to plan for users that exercise not allow javascript execution or use a browser that doesn't support javascript at all.

You could either show them a message telling them why the images won't load and that they demand to switch to a modern browser or enable Javascript. Or you can employ the noscript tag to create a usable feel for these users as well. Using the <noscript> tag approach for such users has some gotchas.

This thread on Stack Overflow does a bang-up job addressing these concerns, and is a recommended read for anyone looking to address this set of users.

Pop Javascript libraries for lazy loading on your website

Since browser environments and implementation details can vary across browsers and devices, it is best to use a tried and tested library for lazy loading.

Here is a list of pop libraries and platform specific plugins that volition let you to implement lazy loading with minimal effort

yall.js (Withal Another Lazy Loader)

Uses Intersection Observer and falls back to outcome-based lazy loading.
Supports all major HTML element types but not background-images.
Works on IE11+ as well.

lazysizes

Very popular and extensive functionality.
Supports responsive images srcset and sizes aspect as well.
Loftier performance fifty-fifty without Intersection Observer.

jQuery Lazy

A unproblematic, jquery based lazy loading library.

WeltPixel Lazy Loading Enhanced

A Magento 2 extension for lazy loading images.

Magento Lazy Image Loader

A Magento 1.ten extension for lazy loading images.

Shopify Lazy Image Plugin

A Shopify extension for lazy loading images.
It is paid though.

Wordpress A3 Lazy Load

Image lazy loading plugin for Wordpress.

How to test if lazy loading is working?

Once you have implemented lazy loading, you'll want to cheque if the behaviour of images on your website is equally intended. The simplest way is to open developer tools in Chrome browser.

Go to Network Tab > Images.

Here, when you refresh the page for the kickoff time, simply the images that are to exist loaded upwards front should go loaded. Then, as you lot start scrolling down the page, other paradigm load requests would get triggered and loaded.

You tin can also notice the timings for image load in the waterfall column in this view. It would assist you identify image loading issues, if any, or issues in triggering the paradigm load.

Some other manner would exist to run the Google Chrome Lighthouse inspect report on your page after you take implemented the changes, and look for suggestions under the "Offscreen images" section.

Determination

We have covered most everything related to lazy loading images in this guide. Lazy loading, if implemented correctly, will significantly improve the loading performance of your web pages, reduce folio size and delivery costs by cutting downwards on unnecessary resources loaded up front, while keeping the necessary content intact on the page. With faster loading pages comes a great user experience, something your visitors would love.

So, what are you waiting for? Get started with lazy loading images now!

Are y'all optimizing your website images? No? Get started with ImageKit's image CDN & optimization tool for costless now!