Optimizing Single-Page Applications: Top 3 Approaches

In this tutorial we’ll show you three great approaches to optimizing your ingle Page Applications and making it work extremely fast using Webpack. With the growing trend toward single-page applications, server-side rendering has started to lose its popularity. It remains mostly as a service since all the logic is moving to the frontend. This approach is very popular nowadays, as it helps developers to design an understandable architecture and keep it clear with the ability to extend and support it. But nothing is perfect. One of the major disadvantages of SPAs is slow loading speeds. A single bundle file with an entire application takes time to load for the first time (especially for big applications), and since nobody likes to wait, you could lose customers over it. But this actually isn’t a problem anymore with Webpack. Webpack can be configured pretty flexible, allowing you to get rid of this issue of slow loading in most cases. In this tutorial, We’ll use Webpack 3.11.0. Read our and find out how we optimized website performance and increase loading page speed. case study Photoblog Ways to speed up applications by splitting bundles into several parts with Webpack 1. Use CommonsChunkPlugins This plugin, provided by Webpack out of the box, allows you to find and store commonly used scripts in a single file. It’s extremely useful for both single-page and multi-page applications. finds and cuts out commonly used scripts, splitting your scripts and producing a file to make the whole application lighter. CommonsChunkPlugins common.js Let’s imagine we have the following project: Here we have and Let’s say that and require index.js, profile.js, user.js. index.js profile.js user.js. We want index.js and profile.js to work separately on different pages. Ordinarily, we would write something like this: const webpack = require('webpack');module.exports = { context: __dirname + '/scripts', entry: { index: './index', profile: './profile' }, output: { path: __dirname + '/app/public', filename: '[name].js' }}; This will produce the following structure in the public folder: If user.js is required in both index.js and profile.js, with this configuration Webpack will insert user.js into both files and the code in the final application will be duplicated, which isn’t good. We want to get commonly used parts into a separate file so the browser is able to load and cache the file. Let’s optimize this with . Our Webpack configuration for this purpose will be: CommonsChunkPlugins const webpack = require('webpack');module.exports = { context: __dirname + '/app/scripts', entry: { index: './index.js', profile: './profile.js' }, output: { path: __dirname + '/app/public', filename: '[name].js' }, plugins: [ new webpack.optimize.CommonsChunkPlugin({ name: 'common' }) ]}; Let’s check what has changed: Now you can see that a file has appeared. This file contains every common for all of our scripts. Also, the size of files has been reduced drastically. common.js require() Of course, a real project will be more complex, so when you use different libraries for different parts of the application you’ll find this plugin extremely useful. It’s also pretty configurable, and you can use it multiple times in the same app for any purpose. https://webpack.js.org/plugins/commons-chunk-plugin/ 2. Dynamic require() It might be a bad idea to load all of your functionality whether or not it will be used. We prefer to load things only upon request. When your application becomes very large, you should definitely consider splitting your scripts and loading parts when they’re requested. Before automation in JavaScript, there was a need to develop our own methods for inserting new files with the tag into the dynamically. Fortunately, Webpack can now serve this purpose, and it’s pretty automatic. But remember, the ordinary doesn’t allow you to load files based on rules. Webpack will simply add it to the bundle or remove it all. document require() So if you write something like: const location = window.location.pathname;switch(location) { case 'user': const user = require('./user'); user(); break; case 'profile': const profile = require('./profile'); profile(); break; default: alert('No match'); break;} You might expect that files will load dynamically on but they won’t. Instead, this will create a single file with all the required scripts regardless of the rules because Webpack won’t analyze the and the rules themselves. request(), switch Fortunately, for this purpose Webpack supplies an original require with function, which has the following syntax: ensure() const location = window.location.pathname;switch(location) { case 'user': require.ensure(['./user'], function(require) { const user = require('./user'); user(); }); break; case 'profile': require.ensure(['./profile'], function(require) { const profile = require('./profile'); profile(); }); break; default: alert('No match'); break;} After assembly we get: Webpack creates chunk files and . Main.js will not contain these files, and they’ll be loaded only upon request — in our case, if the filename matches the URL. Since they’re on the server, don’t forget to specify publicpath for the outputparameter in config. 0.js 1.js We’ll also describe the situation for developers who use the library to manage rendering. It would be great to load a file with components if they match some part of the URL. The problem is that there’s no convenient way to use in component. For this purpose, we use react-loadable ). With this library, your routes will look like this: React Router require.ensure() (https://github.com/jamiebuilds/react-loadable { const Profile = Loadable({ loader: () => import('./profile'), loading: Loading }); return ; }}/> Also, sometimes you might like to write something like this: const location = window.location.pathname;require.ensure(['/somepath/' + location], function(require) { const script = require('/somepath/' + location); script();}); This case is called a dynamic require. Since the filename is stored in a variable, it’s too complicated for Webpack to detect that file and create chunks. You’ll need to create an intermediate file with static or use . We prefer the second option: require.ensure() bundle-loader https://github.com/webpack-contrib/bundle-loader 3. Analyze your build In this section, we’ll show you (or remind you) how to use Webpack tools for analysis. First, use the key — . This will display information about the way your build stores modules. If we use it on our previous example with , it will show the following: display-modules CommonsChunkPlugins You can see that: went to the chunk, which is the entry profile.js {0} profile.js went to the chunk, which is (also a separate entry) index.js {1} index.js went to the chunk, which is because this script is used by both and user.js {2} common.js index.js profile.js But you can go even deeper with This command will also show you why the build was assembled like this. -display-modules — verbose. Here’s detailed information on why we got like this and what it contains. common.js We always use this command to keep track of our build and be sure that it’s as small as possible and doesn’t contain duplications. For most cases this is enough. But for really big projects, where you get a hundred of modules, it can be annoying to read everything from the console and have to analyze the entire application with all dependencies. Luckily, for this purpose Webpack has an analyzer with a graphical interface.To use it, we need to create a bulk report in JSON format first: To use it, we need to create a bulk report in JSON format first: This file contains all necessary information about your build. report.json Next, go to and upload . http://webpack.github.io/analyse report.json Finally you’ll get this: This tool will show you information about modules, chunks, assets, warnings, and errors. The analysis helps you to avoid duplication and keep everything working as expected. We also welcome you to visit our There, you can see how we implement our technical solutions to solve business problems. You can also refer to our with all relevant questions. case studies page. sales team