How To Remove Page Size Placeholder Bootstrap Templates

Images are critical for every website and application today. Whether it be marketing banners, product images or logos, it is impossible to imagine a website without images. Sadly though, images are large in size making them the single largest contributor to the page size.

As per the latest HTTP Annal data, the median page size on desktops is 1511 KB. Images brand upwards for about 650 KB of that size, roughly 45% of the full page size. Now, since we cannot do away with images, we need to make our spider web pages load fast with them.

In this guide, we will talk near lazy loading images, a technique that helps amend the page load time and reduces page size, while still retaining all the images on the page.

Get this guide delivered as an eBook. Direct to your mailbox!

What is Image Lazy Loading?

Lazy Loading Images is a ready of techniques in web and application development that defer the loading of images on a folio to a later signal in time - when those images are actually needed, instead of loading them up front. These techniques aid in improving performance, amend utilization of the device's resources, and reducing associated costs.

Here is a quick video to aid you understand meliorate:

The word "lazy" in the English is ofttimes attributed to the act of fugitive work as long as possible.

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

The technique of lazy loading can be applied to about all the resources on a folio. For example, in a single page application, if a JS file is not needed until later, it is best not to load it initially. If an image is not needed up front end, load it later when information technology actually 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 image, not visible to the user when the folio loads, is loaded later when the user scrolls and the image really becomes visible. If the user never scrolls, an image that is not visible to the user never gets loaded.

It carries ii chief advantages.

1. Performance Improvement

This is the most of import one for you every bit a website administrator - meliorate performance and load time.

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

ii. Cost reduction

The second benefit for you is in terms of delivery costs. Prototype commitment, or commitment of any other asset, is ordinarily charged on the basis of the number of bytes transferred.

As mentioned earlier, with lazy loading, if the paradigm is not visible, it never gets loaded. Thus, you reduce the full bytes delivered on the page., particularly for users that bounce off the page or collaborate with simply the top portion of the page. This reduction in bytes transferred from your delivery network reduces delivery costs. This volition go more than apparent as we explore lazy loading farther.

Which Images can exist Lazy Loaded?

The bones idea of lazy loading is simple - defer loading anything that is not needed correct at present. For images it usually translates to any image that is not visible to the user upwardly front can be lazy loaded.

As the user scrolls downwardly the page, the image placeholders start coming into viewport (visible part of the webpage). Nosotros trigger the load for these images when they go visible.

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

Lazy loading is critical not only for practiced functioning, but too to deliver a skilful user feel.

Lazy Loading Techniques for images

Images on a webpage can exist loaded in two means - using the <img> tag, or using the CSS `groundwork` holding. Let's first look at the more than common of the two, the <img> tag, and so move on to CSS background images.

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

Lazy loading images can be broken down into two steps:

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

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

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

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

For this, we check that as soon as the image (i.due east., its placeholder) enters the viewport, we trigger the load.

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

Trigger epitome load using Javascript events

In this technique, we use effect listeners on the whorl, resize, and orientationChange events in the browser. The scroll event is an obvious i to check when the user scrolls the folio. The resize and orientationChange events are equally of import 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 mural to portrait mode, or vice versa. In such cases, the number of images that become visible on the screen will change. Therefore, we'll need to trigger a load for these images.

When either of these events occur, we discover all the images on the page that are to exist lazy loaded and haven't been loaded yet. From these images, nosotros check which ones are at present in the viewport. This is washed using the image'southward top kickoff, the current document scroll top, and window height. If it has entered the viewport, nosotros pick the URL from information-src attribute and put it in the src attribute. This triggers the image load. We also 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 nosotros scroll, the whorl event triggers multiple times rapidly. Thus, for performance, we add a pocket-sized timeout that throttles the lazy loading office execution.

Here is a working example of this approach.

If you discover, the beginning 3 images in the example are loaded upward front. The URL is present directly in the src attribute instead of the data-src attribute. This is essential for a proficient user experience. Since these images are at the meridian of the page, they should exist fabricated visible as before long as possible. We must not look for an event or JS execution to load them.

Using Intersection Observer API to trigger image loads

Intersection Observer API is a relatively new API in browsers. It makes it really simple to detect when an element enters the viewport, and take an action when it does. In the previous method, we had to bind events, proceed performance in mind, and implement a way to calculate if the chemical element was in the viewport or not. The Intersection Observer API makes this really simple, helps avoid the math, and delivers great performance.

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

Nosotros attach the observer on all the images to be lazy loaded. One time the API detects that the element has entered the viewport, using the isIntersecting property, we pick the URL from the data-src attribute and move information technology to the src aspect for the browser to trigger the image load. One time this is done, we remove the lazy class from the image, and also remove the observer from that prototype.

If you compare the time taken to load an prototype in both the methods, event listeners vs Intersection Observer, you would find that using the Intersection Observer API, the epitome load is triggered much quicker, and nonetheless the site doesn't appear sluggish on scrolling. In the method involving event listeners, nosotros had to add a timeout to make information technology performant, which has a marginal impact on the user feel as the image load is triggered with a slight filibuster.

However, the support for Intersection Observer API is not available beyond all browsers. Hence, we need to fall back to the event listener method in browsers where the Intersection Observer API is non supported. We take 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's latest version - Chrome 76. All Chromium-based browsers, i.e., Chrome, Border, and Safari, and Firefox. Yous tin can find more details about browser support for native lazy loading on caniuse.com.

With browser-side back up coming into play, at present, developers only need to add a "loading" attribute when embedding images, to implement lazy loading on their websites.

In fact, one does not demand to fifty-fifty be a developer to get this washed. Some bones noesis of HTML is enough to implement the "loading" attribute, making this feature accessible to many more website admins.

Then the code would now look like -

              <img src="example.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 equally soon as the folio 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, information technology's the aforementioned as not including the loading attribute.

However, for browsers that practice not support native lazy loading, the aforementioned techniques for implementing of it demand to exist applied.

Equally covered later in this blog, to prevent the surrounding content from reflowing when a lazy-loaded image is downloaded, brand sure to add summit and width attributes to the <img> chemical element or specify their values directly in an inline fashion:

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

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

Lazy Loading CSS Background Images

After <img /> tags, background images are the most common manner to load images on a webpage. For <img /> tags, the browser has a very uncomplicated approach - if the epitome URL is available, let's load the image.

With CSS background images information technology is non that straightforward. To load CSS background images, the browser needs to build the DOM (Document Object Model) tree, too equally the CSSOM (CSS Object Model) tree, to decide if the CSS mode applies to a DOM node in the current document.

If the CSS rule specifying the groundwork paradigm does non apply to an element in the certificate, 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 circuitous at first, but this same beliefs forms the basis of the technique for lazy loading groundwork images. In simple terms, we trick the browser into not applying the background image CSS belongings to an element till that element comes into the viewport.

Here is a working example that lazy loads a CSS groundwork image.

One thing to note here is that the Javascript code for lazy loading is withal the same. We are using the Intersection Observer API method with a fallback to the issue listeners. The trick lies in the CSS.

The element with ID bg-image has a background-image specified in the CSS. However, when the class lazy is added to this element, in the CSS we override the background-epitome property and gear up it to none.

Since the rule, combining #bg-image with .lazy class has a college preference in CSS than only #bg-image, the browser applies the property background-paradigm: none to the element initially. When nosotros scroll down, the Intersection Observer (or result listeners) detects that the image is in the viewport and removes the course lazy. This changes the applicable CSS and applies the actual background-image property to the chemical element triggering the load of the background prototype.

Better user experience with lazy loading images

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

Nonetheless, a lot of companies practise non opt for lazy loading because they believe information technology goes against delivering a dandy user experience quoting reasons like "the initial placeholder is ugly", "the load times are slow", etc.

How can nosotros solve such concerns effectually user experience with lazy loading of images?

i. Using the right image placeholders

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

Nosotros used the same in our example code as well. A solid lite grayness colour is used for all our image backgrounds. Notwithstanding, we tin practice improve to provide a more pleasing user experience.

A look at some examples of meliorate placeholders for our images:

a) Dominant color placeholder

Instead of using a fixed colour for the image placeholder, we find the dominant color from the original paradigm and use 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, just a very simple way of accomplishing this is to first scale down the prototype to a 1x1 pixel and then scale it up to the size of the placeholder - a very rough approximation, simply a simple, no-fuss way to go a single dominant color.

Using ImageKit, the dominant color placeholder can be obtained using a chained transform in ImageKit every bit shown hither:

Dominant colour placeholder image 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 prototype" />  <!-- Dominant colour prototype with same dimensions --> <img src="https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-1,h-1:w-400,h-300" alt="dominant colour placeholder" />

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

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

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

b) Low quality epitome placeholder (LQIP)

Nosotros can expand the above idea of using a dominant color placeholder farther.

Instead of using a single color, we use a very depression-quality, blurred version of the original image as the placeholder. Non but does it await better, it likewise gives the user some thought almost what to expect in the bodily image, while giving the perception that the prototype load is in progress. This is cracking 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 image URL example using ImageKit

              <!-- Original image at 400x300 --> <img src="https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-400,h-300" alt="original image" />  <!-- Low quality image placeholder with same dimensions --> <img src="https://ik.imagekit.io/demo/img/image4.jpeg?tr=w-400,h-300,bl-thirty,q-50" alt="dominant colour 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'south a video demonstrating how this effect works for the user:

You lot can view the working instance and code for using LQIP technique here.

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

ii. Adding some buffer fourth dimension for image load

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

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

While using Intersection Observers to load the image or using depression-quality image placeholders provides amend loading performance and user experience, in that location is another simple trick that you can 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 image simply when they exactly enter the viewport, load the images when they are, let's say, 500px away from entering the viewport. This provides additional time, between the load trigger and the bodily entry in the viewport, for the images to load.

With the Intersection Observer API, you lot can use the `root` parameter along with the `rootMargin` parameter (works equally standard CSS margin rule), to increase the constructive bounding box that is considered to find the "intersection".

With the result listener method, instead of checking for the departure between the paradigm edge and the viewport border to exist 0, we tin can apply a positive number to add together some threshold.

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

As evident from the video below (monitor the network requests closely appearing at the bottom), while scrolling, when the tertiary image is in view, the fifth image gets loaded. When the 4th image comes into the view, the 6th paradigm 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 example you haven't noticed yet, in all our examples, the third image (image3.jpg) is always loaded upwardly front, fifty-fifty though it's exterior the viewport. This was also done following the aforementioned primary - load slightly in accelerate instead of loading exactly at the threshold for better user experience.

If you are using the native image lazy loading method, browsers automatically calculate this distance from the viewport threshold to determine when the browser should trigger the paradigm load. Browsers consider the image blazon, network speed, and information-saver setting in the browser to decide this threshold, keeping in heed developer expectations and user experience.

3. Avoiding content shifting with lazy loading

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

The problem
When in that location is no paradigm, the browser doesn't know the dimensions of the content that is to exist displayed in the enclosing container. And if nosotros exercise not specify it using CSS, the enclosing container would have no dimensions, i.east. 0 x 0 pixels. So, when the image gets loaded, the browser would resize the enclosing container to fit the paradigm.
This sudden alter in the layout causes other elements to move around and it is called content shifting. As demonstrated in this content shifting article & video from Smashing Magazine, information technology's a rather unpleasant experience for a user as the content moves suddenly when the epitome loads.

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

4. Do not lazy load all the images

This is another mistake the developers frequently commit - lazy load all the images on the page. This might reduce the initial page load, simply would also effect in bad user feel as a lot of images, even the ones at the pinnacle of the webpage, won't bear witness upwardly till the Javascript gets executed.

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

a) Any epitome that is present in the viewport, or at the offset of the webpage, should not be lazy loaded. This applies to any header prototype, marketing imprint, logos, etc., every bit the user should encounter them equally soon as the page loads.

Also, every bit mobile and desktop devices have different screen sizes, they will take a different number of images that will be visible on the screen initially. And so y'all need to have into business relationship the device blazon to decide which resources to load up front and which to lazy load.

b) Whatsoever image that is just slightly off the viewport should not exist lazy loaded. This is based on the indicate discussed earlier - load slightly in advance. So, permit's say, any image that is 500px or a single ringlet from the lesser of the viewport can be loaded upwards front as well.

c) If the page isn't too long, may exist but a single gyre or ii, or if there are less than 5 images outside the viewport, then lazy loading can be avoided birthday.

It would not provide any meaning benefit to the end user in terms of performance. The additional JS that yous load on the page to enable lazy loading will offset whatever do good reaped from lazy loading such a minor 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 still close to 70%, if yous are to provide the same experience beyond all browsers, you would all the same need to apply JS libraries.

While most of your users would take Javascript execution enabled in their browser, equally it is essential for most all websites these days, you may want to plan for users that do not let javascript execution or apply 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 need to switch to a modernistic browser or enable Javascript. Or you can utilize the noscript tag to create a usable feel for these users likewise. Using the <noscript> tag approach for such users has some gotchas.

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

Popular Javascript libraries for lazy loading on your website

Since browser environments and implementation details tin can vary across browsers and devices, information technology is all-time to use a tried and tested library for lazy loading.

Here is a list of popular libraries and platform specific plugins that volition permit you to implement lazy loading with minimal endeavour

yall.js (Even so Another Lazy Loader)

Uses Intersection Observer and falls back to effect-based lazy loading.
Supports all major HTML element types but non groundwork-images.
Works on IE11+ likewise.

lazysizes

Very pop and all-encompassing functionality.
Supports responsive images srcset and sizes attribute too.
Loftier performance even without Intersection Observer.

jQuery Lazy

A simple, jquery based lazy loading library.

WeltPixel Lazy Loading Enhanced

A Magento 2 extension for lazy loading images.

Magento Lazy Image Loader

A Magento 1.x 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 y'all have implemented lazy loading, y'all'll want to bank check if the behaviour of images on your website is as intended. The simplest way is to open developer tools in Chrome browser.

Go to Network Tab > Images.

Here, when you lot refresh the page for the first time, only the images that are to be loaded up front should get loaded. And so, as you kickoff scrolling down the page, other paradigm load requests would go triggered and loaded.

You tin can also observe the timings for image load in the waterfall cavalcade in this view. It would assistance you identify image loading issues, if any, or issues in triggering the image load.

Another fashion would be to run the Google Chrome Lighthouse audit written report on your page after you have implemented the changes, and look for suggestions under the "Offscreen images" department.

Conclusion

Nosotros accept covered almost everything related to lazy loading images in this guide. Lazy loading, if implemented correctly, volition significantly improve the loading performance of your web pages, reduce page size and delivery costs by cutting down on unnecessary resource loaded up forepart, 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 at present!

Are you lot optimizing your website images? No? Get started with ImageKit's image CDN & optimization tool for free at present!