Negatives of lazy loading and how to handle them

In our constantly evolving world of tech, speed is of the essence especially on the web. Every second counts as consumers are often impatient.

As computers and mobiles double ram sizes, hyper-thread processors and the internet moves towards 5G, web developers try to leverage faster page loads, especially first time loads.

©Photo by Jennifer Bischoff

Lazy loading amongst others is an important technique to achieve faster application initialization on the web, especially for huge applications. It does this by allowing the developer break down an application into chunks (modules) per route and loads only the module(s) required for the route being visited. Its key principle being: Load only what you need when you need it.

However, what is not often mentioned is that this optimization is a trade off. A trade off between initial app load time and the time required later to fetch lazy loaded chunks when they are needed.

Loaded chunks in a lazy loaded application from chrome dev tools

In this article, I will explain the negative impact of using lazy loading in your application from my experience.

The best case use of lazy loading is a case where a user only accesses the root of your application or a single lazy loaded route and does not proceed to any lazy loaded routes.

Should the user proceed to a lazy loaded route, the benefits of lazy loading start to diminish.

1. Few seconds needed to fetch chunk from node server, bigger chunks may take more time: Simply put, lazy loaded routes need to perform network requests to fetch JS chunks. Network requests take time (no matter how fast) which results in few milliseconds where the application seems to be unresponsive.
2. Complicates debugging: Errors such as an undefined method in a lazy loaded module will only appear in the console when the faulty chunks is loaded at run time.
3. Loading chunk failed error which is caused by caching of application JS files by the browser which may lead to cache miss when newer versions are built because the chunk hash changes on every build.
4. The app could crash or become unresponsive if the device goes offline for a few second: For example, consider what happens when the user looses internet connection?

The route becomes too lazy so that it can’t even load!

© Photo by Zentastic

This is because a network request is required to fetch the lazy loaded route from your applications node server.

How to minimize negative effects of lazy loading:

1. If possible, do not lazy load routes that are most frequently visited by your users.
2. Keep your chunk sizes as small as possible (Only import what you need and keep shared modules as compact as possible).
3. Use router states to show a loader or animation when a lazy loaded route is being fetched so they do not think your application lags. You can even handle cases when fetching the lazy loaded route fails e.g. Show a toast notification and redirect to a previously loaded route.
4. Handle the “Loading chunk failed” error which is often caused by a browser cache miss and occurs on browsers that have previously cached JS files from your web application. Kamran Khatti already came up with a fine solution to this issue here.

In conclusion, lazy loading is a great technique that greatly reduces the initial loading time of web applications. However, one should be aware of these negatives and anticipate them while developing applications based on this technique. Responding to them appropriately will ensure a smoother user experience for the application consumers.