I am glad to hear that you are so into that and happy to see your draft. Feel free to publish your version.

This article was inspired and based on this great blog post written by Benjamin Taylor.

When I think about performance and how the websites are loaded the first thing that comes to my mind is that when the content is loaded the last elements that appear on the page are images.

Today images (their size and number on a single page) can be a major issue when it comes to performance. Keeping in mind that the page load of a website has a direct impact on the conversion rate, this issue should not be ignored.

In this article I would like to describe one way of reducing that initial weight of a website. What I will demonstrate is how to load only the content visible for the user when she/he sees the initial view and lazy load all the rest of the heavy-weight elements (like images) only when required.

To do that we need to solve two things:

1. How to store source of the image we want to load without loading it in the first place.
2. How to detect when the image becomes visible (is required) to the user and trigger the request to load the image.

We will solve the above mentioned issues using data-attributes, IntersectionObserver and Vue.js custom directive.

To make it easier to understand I created an example, a list of random articles, each one containing a short description, image and a link to the source of the article. We will go through the creation process of a components for displaying that list of articles, displaying a single article and displaying (and lazy-loading) an image for a specific article.

Most of the things I would like to show are based in the component displaying the image, so I will show a basic example of how that component looks like. We will do a step by step explanation in the next sections so don’t get too deep in the code just yet.

ImageItem.vue

In the component we have an ImageSpinner component that is shown when the image is being loaded and an img tag that is responsible for keeping the image source and displaying the image when the loading is completed.

The key lazy-load logic is extracted to a LazyLoadDirective that is used on our component by adding v-lazyload attribute.

Script part of that component looks like that:

As mentioned above the lazy-load logic is kept in a directive LazyLoadDirective:

This is just part of a working example, you can find the whole example in this Codesandbox example. We will analyse the code piece by piece and see what is actually happening in the next section.

Real-World Example: Creating a LazyLoadDirective and using it in ImageItem component

1. Create a basic ImageItem component

Let’s start with creating a component that will show an image (no lazy-loading involved). In the template, we create a figure tag that contains our image, the image itself receives src attribute that carries the image source (url).

In the script part we receive the prop source that gives us source url of the image we are displaying.

That is fine, we render the image we wanted, but if we leave it as it is, we will be loading image straight away without waiting for the component to be visible on our screen. That is not what we want so let’s go to the next step.

2. Prevent image from being loaded when the component is created.

To prevent the image from being loaded we need to get rid of the src attribute from the img tag. But as pointed out at the beginning we still need to keep the image source somewhere. Good place to keep that information is data-* attribute.

As per its definition data-* attribute allow us to store information on standard, semantic HTML elements.

Sounds like a perfect fit for our need.

Ok, with that done we will not load our image. But wait, we will not load our image… ever!

Obviously that is not what we wanted, we want to load our image but under specific conditions. We can request the image to be loaded by replacing the src attribute with the image source url kept in data-url. That is the easy part, the issue we encounter now is — when should we replace that src?

We would like to load the image when the component carrying it becomes visible to the user. How can we detect if the user sees our image or not? Let’s check that out in the next step.

3. Detect when the image is visible to the user.

If you ever encountered that challenge you probably ended up with using some crazy magical javascript that when you finished didn’t look very nice.

For example, we could use events and event handlers to detect the scroll position, offset value, element height and viewport height and calculate whether an image is in the viewport or not. It even sounds crazy, doesn’t it?

If we really needed we could probably stick to that solution (no matter how ugly that would be), but doing it that way has direct implications to our performance. Those calculations would be performed each time there is a scroll event. Even worse, imagine few dozens of images each having to recalculate if it is visible or not on each scroll event.

This is madness!

4. Intersection Observer to the rescue!

This very inefficient way of detecting if an element is visible in the viewport can be solved by using Intersection Observer API.

Looking at the definition it allows you to configure a callback that is called whenever one element, called the target, intersects either the device viewport or a specified element.

Firing a custom callback function when the element becomes visible in the viewport? Sounds like a magic spell for what we need.

So, what we need to do to use it?

To use the Intersection Observer we need to do few things:

• Create a new intersection observer
• Watch the element we wish to lazy load for visibility changes
• When the element is in viewport, load the element (replace src with our data-url)
• Once the element is loaded, stop watching it for visibility changes (unobserve)

In Vue we can use a custom directive to wrap all this functionality and then reuse it when we need.

5. Create a custom Vue directive

What is a custom directive? As per documentation, it is a way to get the low-level DOM access on elements. For example changing an attribute of a specific DOM element, in our case changing src attribute of an img element.

Our directive looks like below. Again, we will break it into pieces in a moment, I just want to give you an overview.

Let’s go step by step.

hookFunction

• allows us to fire a custom logic at a specific moment of a bound element lifecycle.
• we use inserted hook because it is called when the bound element has been inserted into its parent node (this guarantees parent node presence). Since we want to observe visibility of an element in relation to its parent (or any ancestor), we need to use that hook.

loadImage function

• responsible for replacing the src value with data-url.
• in this function we have access to our el, element on which the directive is applied. We can extract the img from that element.
• we check if the image exists and if it does, we add a listener that will fire a callback function when the loading is finished. That callback will be responsible for hiding the spinner and adding the animation (fade-in effect) to the image using CSS class.
• we add a second listener that will be called when the loading of the image from our src url fails.
• Finally, we replace src of our img element with the source url of the image we want to request and show (that triggers the request).

handleIntersect function

• IntersectionObserver callback function responsible for firing loadImage on certain conditions.
• it is fired when the IntersectionObserver detects that the element entered the viewport or parent component element.
• it has access to entries which is an Array of all elements that are watched by the observer and observer itself.
• we iterate through entries and check if a single entry becomes visible to our user isIntersecting, if it does loadImage function is fired
• after the image is requested, we unobserve the element (remove it from the observer’s watch list), that prevents the image from being loaded again.

createObserver function

• responsible for creating our IntersectionObserver and attaching it to our element.
• IntersectionObserver constructor accepts a callback (our handleIntersect function) that is fired when the observed element passes the specified threshold and options object that carries our observer options.
• options object specify root that is our reference object on which we base the visibility of watched element (it might be any ancestor of the object or our browser viewport if we pass null). It also specifies threshold value which can vary from 0 to 1 and tells us at what percentage of the target’s visibility the observer’s callback should be executed (0 meaning as soon as even one pixel is visible, 1 meaning the whole element must be visible).
• after creating the IntersectionObserver we attach it to our element using observe method.

Browser support

Even though it is not supported by all browsers, the coverage of 73% of users (as of 28th August 2018) sounds good enough.

But having in mind that we want to show images to all users (remember that using data-url prevents the image from being loaded), we need to add one more piece to our directive.

We need to check if the browser supports IntersectionObserver, fire the loadImage if it doesn’t (that will request all images at once) and createObserver if it does.

6. Registering directive

To use our newly created directive we need to register it first. We can do it in two ways, globally (available everywhere in the app) or locally (on a specified component level).

Global registration

To register a directive globally we import our directive and use Vue.directive method passing the name on which we want to register our directive and directive itself. That allows us to add v-lazyload attribute to any element in our code.

Local registration

If we want to use our directive only in a specific component and restrict the access to it, we can register the directive locally. To do that we need to import the directive inside the component that will use it and register it in the directives object. That will give us the ability to add v-lazyload attribute to any element in that component.

7. Using directive on ImageItem component

After registering our directive we can use it by adding the v-lazyload attribute to the parent element that carries our img (figure tag in our case).

Summary

Lazy Loading images can significantly improve your page performance. It allows you to load the images only when the user can actually see them.

For those still not convinced if it is worth playing with it I prepared some raw numbers. Let’s take our simple articles list. At the moment I was performing that test it had 11 articles with images (meaning 11 images on the page). I don’t think that is a lot of images, you can probably find bigger number in a second by going into any news page.

Let’s stick to our 11 images and check the performance of our page on fast 3G with only first article visible, without lazy-loaded images.

As expected 11 images, 11 requests, total page size 3.2 MB.

Now, the same page with only first article visible and lazy-loded images.

Result, 1 image, 1 request, total page size 1.4 MB.

By adding this directive to our articles we saved 10 requests and we reduced the page size by 56% and bear in mind this is really simple example.

No more comments, let the numbers speak for themselves.

Lazy Loading images with Vue.js directives and IntersectionObserver was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are situations when you want the template inside the slot to be able to access data from the child component that is responsible for rendering the slot content. This is particularly useful when you need freedom in creating custom templates that use the child component’s data properties. That is a typical use case for scoped slots.

Imagine a component that configures and prepares an external API to be used in another component, but is not tightly coupled with any specific template. Such a component could then be reused in multiple places rendering different templates but using the same base object with specific API.

For the purpose of this blog post, I’ve created a component (GoogleMapLoader.vue) that initialises Google Maps API, creates a google and map objects and exposes those objects to the parent component in which the GoogleMapLoader is used.

See below a basic example of how this can be achieved. We will analyse the code piece by piece and see what is actually happening in the next section.

The template part will look as below

GoogleMapLoader.vue

Our script will look like this, we’ll have some props passed to the component which allows us to set the Google Maps API and Map object:

This is just part of a working example, you can find the whole example in this Codesandbox example. We will analyse the code piece by piece and see what is actually happening in the next section.

Real-World Example: Creating a Google Map Loader component

1. Create a component that initialises our map

In the template we create a container for the map which will be used to mount the Map object extracted from the Google Maps API.

GoogleMapLoader.vue

Inside the script part:

• we receive props from the parent component which will allow us to set the Google Map:
• mapConfig — Google Maps config object
• apiKey — our personal api key required by Google Maps

GoogleMapLoader.vue

• we set the initial values of google and map to null

• on mounted hook we create an instance of GoogleMapsApi and Map object from the GoogleMapApi and we set the values of google and map to the created instances

So far so good, with that done we could continue adding the other objects to the map (Markers, Polylines, etc.) and using it as a ordinary map component. But we want to use our GoogleMapLoader component only as a loader that prepares the map, not renders anything on it.

To achieve that we need to allow parent component that will use our GoogleMapLoader to access this.google and this.map that are set inside the GoogleMapLoader component. That’s where scoped slots really shine. Scoped slots allow us to expose the properties set in a child component to the parent component. It may sound like an inception, but bear with me one more minute.

2. Create component that uses our initialiser component

In the template, we render the GoogleMapLoader component and pass props that are required to initialise the map.

TravelMap.vue

Our script tag will look like below at this stage.

Still no scoped slots, let’s add one.

3. Expose google and map properties to the parent component by adding a scoped slot

So finally we can add a scoped slot that will do the job and allow us to access the child component props in the parent component. We do that by adding the <slot> tag in the child component and passing the props that we want to expose (using v-bind directive or :propName shorthand). It does not differ from passing the props down to the child component, but doing it in the <slot> tag reverse the direction of data flow.

GoogleMapLoader.vue

Now when we have the slot in the child component we need to receive and consume the exposed props in the parent component.

4. Receive exposed props in the parent component using slot-scope attribute

To receive the props in the parent component we declare a template element and use slot-scope attribute. The attribute has access to the object carrying all props exposed from the child component. We can grab the whole object or we can destructure that object and get the required props. Let’s proceed with the second option.

TravelMap.vue

After doing that even though the google and map props does not exist in the TravelMap scope, the component has access to them and we can use them in the template.

Yeah, ok, but why would I do things like that, what is the use of all that?

Scoped slots allow us to pass a template to the slot instead of passing a rendered element. It’s called a “scoped” slot because although the template is rendered in the parent component scope, it will have access to certain child component data. That gives us a freedom to fill the template with custom content from the parent component.

5. Create factory components for Markers and Polylines

Now when we have our map ready we will create two factory components that will be used to add elements to the TravelMap.

GoogleMapMarker.vue

GoogleMapLine.vue

• both of them receive google from which we extract required object (Marker or Polyline) and map which gives as a reference to the map on which we want to place our element
• each component expects also an extra prop to create a corresponding element
• on mounted hook we create an element (Marker / Polyline) and attach it to our map by passing the map property to the object constructor

6. Add elements to map

Now let’s use our factory components to add elements to our map.

To add elements to our map we render the factory component and pass the google and map objects.

We also need to provide data required by the element itself (in our case marker object with position of the marker and path object with polyline coordinates).

TravelMap.vue

In our script we need to import the required factory components and set data that will be passed to the markers and lines.

Summary

That’s it. With all those bits and pieces created we can now re-use the GoogleMapLoader component as a base for all our maps by passing different templates to each one of them. Imagine that you need to create another map with different Markers or just Markers without Polylines. By using the above pattern it becomes very easy as we just need to pass different content to the GoogleMapLoader component.

This pattern is not strictly connected to Google Maps, it can be used with any library to set the base component and expose the library’s API that might then be used in the component that summoned the base component.

It might be tempting to create a very complex solutions based on the example, but at some point we can get to the situation where this abstraction becomes an independent part of the code living in our codebase. If we get to that point it might be worth considering extraction to an add-on.

Practical use of Vue.js scoped-slots was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.