A constant challenge faced by front-end developers is the performance of our applications. How can we deliver a robust and full-featured application to our users without forcing them to wait an eternity for the page to load? The techniques used to speed up a website are so numerous that it can often be confusing to decide where to focus our energy when optimising for performance and speed.
Thankfully, the solution isn't as complicated as it sometimes might seem. In this post I'll breakdown one of the most effective techniques used by large web apps to speed up their user experience. I'll go over a package to facilitate this and ensure that we can deliver our app to users faster without them noticing that anything has changed.
What Does it Mean for a Website to be Fast?
The question of web performance is as deep as it is broad. For the sake of this post I'm going to try and define performance in the simplest terms: send as little as you can as fast as you can. Of course, this might be an oversimplification of the problem, but practically speaking, we can achieve dramatic speed improvements by simply sending less data for the user to download and sending that data fast.
For the purpose of this post I'm going to focus on the first part of this definition—sending the least possible amount of information to the user's browser.
Invariably, the biggest offenders when it comes to slowing down our applications are images and JavaScript. In this post I'm going to show you how to deal with the problem of large application bundles and speed up our website in the process.
React Loadable
React Loadable is a package that allows us to lazy load our JavaScript only when it's required by the application. Of course, not all websites use React, but for the sake of brevity I'm going to focus on implementing React Loadable in a server-side rendered app built with Webpack. The final result will be multiple JavaScript files delivered to the user's browser automatically when that code is needed.
Using our definition from before, this simply means we send less to the user upfront so that data can be downloaded faster and our user will experience a more performant site.
1. Add React Loadable to Your Component
I'll take an example React component, MyComponent. I'll assume this component is made up of two files, MyComponent/MyComponent.jsx and MyComponent/index.js.
In these two files I define the React component exactly as I normally would in MyComponent.jsx. In index.js, I import the react component and re-export it—this time wrapped in the Loadable function. Using the ECMAScript import feature, I can indicate to Webpack that I expect this file to be dynamically loaded. This pattern allows me to easily lazy load any component I've already written. It also allows me to separate the logic between lazy-loading and rendering. That might sound complicated, but here's what this would look like in practice:
// MyComponent/MyComponent.jsx
export default () => (
<div>
This component will be lazy-loaded!
</div>
)
// MyComponent/index.js
import Loadable from 'react-loadable'
export default Loadable({
// The import below tells webpack to
// separate this code into another bundle
loader: import('./MyComponent')
})
I can then import my component exactly as I normally would:
// anotherComponent/index.js import MyComponent from './MyComponent' export default () => <MyComponent />
I've now introduced React Loadable into MyComponent. I can add more logic to this component later if I choose - this might include introducing a loading state or an error handler to the component. Thanks to Webpack, when we run our build, I'll now be provided with two separate JavaScript bundles: app.min.js is our regular application bundle and myComponent.min.js contains the code we've just written. I'll discuss how to deliver these bundles to the browser a little later.
2. Simplify the Setup With Babel
Ordinarily, I'd have to include two extra options when passing an object to the Loadable function, modules and webpack. These help Webpack identify which modules we should be including. Thankfully, we can obviate the need to include these two options with every component by using the react-loadable/babel plugin. This automatically includes these options for us:
// input file
import Loadable from 'react-loadable'
export default Loadable({
loader: () => import('./MyComponent')
})
// output file
import Loadable from 'react-loadable'
import path from 'path'
export default Loadable({
loader: () => import('./MyComponent'),
webpack: () => [require.resolveWeak('./MyComponent')],
modules: [path.join(__dirname, './MyComponent')]
})
I can include this plugin by adding it to my list of plugins in my .babelrc file, like so:
{
"plugins": ["react-loadable/babel"]
}
I'm now one step closer to lazy-loading our component. However, in my case I'm dealing with server-side rendering. Currently, the server will not be able to render our lazy-loaded components.
3. Rendering Components on the Server
In my server application I have a standard configuration that looks something like this:
// server/index.js
app.get('/', (req, res) => {
const markup = ReactDOMServer.renderToString(
<MyApp/>
)
res.send(`
<html>
<body>
<div id="root">${markup}</div>
<script src="/build/app.min.js"></script>
</body>
</html>
`)
})
app.listen(8080, () => {
console.log('Running...')
})
The first step is going to be to instruct React Loadable that I want all modules to be preloaded. This allows me to decide which ones should be loaded immediately on the client. I do this by modifying my server/index.js file like so:
// server/index.js
Loadable.preloadAll().then(() => {
app.listen(8080, () => {
console.log('Running...')
})
})
The next step is going to be to push all components I want to render to an array so we can later determine which components require immediate loading. This is so the HTML can be returned with the correct JavaScript bundles included via script tags (more on this later). For now, I'm going modify my server file like so:
// server/index.js
import Loadable from 'react-loadable'
app.get('/', (req, res) => {
const modules = []
const markup = ReactDOMServer.renderToString(
<Loadable.Capture report={moduleName => modules.push(moduleName)}>
<MyApp/>
</Loadable>
)
res.send(`
<html>
<body>
<div id="root">${markup}</div>
<script src="/build/app.min.js"></script>
</body>
</html>
`)
})
Loadable.preloadAll().then(() => {
app.listen(8080, () => {
console.log('Running...')
})
})
Every time a component is used that requires React Loadable, it will be added to the modules array. This is an automatic process done by React Loadable, so this is all that's required on our part for this process.
Now we have a list of modules that we know will need to be rendered immediately. The problem we now face is mapping these modules to the bundles that Webpack has automatically produced for us.
4. Mapping Webpack Bundles to Modules
So now I've instructed Webpack to create myComponent.min.js and I know that MyComponent is being used immediately, so I need to load this bundle in the initial HTML payload we deliver to the user. Thankfully, React Loadable provides a way for us to achieve this, as well. In my client Webpack configuration file, I need to include a new plugin:
// webpack.client.config.js
import { ReactLoadablePlugin } from 'react-loadable/webpack'
plugins: [
new ReactLoadablePlugin({
filename: './build/loadable-manifest.json'
})
]
The loadable-manifest.json file will provide me a mapping between modules and bundles so that I can use the modules array I setup earlier to load the bundles I know I'll need. In my case this file might look something like this:
// build/loadable-manifest.json
{
"MyComponent": "/build/myComponent.min.js"
}
This will also require a common Webpack manifest file to include the mapping between modules and files for internal Webpack purposes. I can do this by including another Webpack plugin:
plugins: [
new webpack.optimize.CommonsChunkPlugin({
name: 'manifest',
minChunks: Infinity
})
]
5. Including Bundles in Your HTML
The final step in loading our dynamic bundles on the server is to include these in the HTML we deliver to the user. For this step I'm going to combine the output of steps 3 and 4. I can start by modifying the server file I created above:
// server/index.js
import Loadable from 'react-loadable'
import { getBundles } from 'react-loadable/webpack'
import manifest from './build/loadable-manifest.json'
app.get('/', (req, res) => {
const modules = []
const markup = ReactDOMServer.renderToString(
<Loadable.Capture report={moduleName => modules.push(moduleName)}>
<MyApp/>
</Loadable>
)
const bundles = getBundles(manifest, modules)
// My rendering logic below ...
})
Loadable.preloadAll().then(() => {
app.listen(8080, () => {
console.log('Running...')
})
})
In this I've imported the manifest and asked React Loadable to create an array with module/bundle mappings. The only thing left for me to do is to render these bundles to an HTML string:
// server/index.js
app.get('/', (req, res) => {
// My App & modules logic
res.send(`
<html>
<body>
<div id="root">${markup}</div>
<script src="/build/manifest.min.js"></script>
${bundles.map(({ file }) =>
`<script src="/build/${file}"></script>`
}).join('\n')}
<script src="/build/app.min.js"></script>
</body>
</html>
`)
})
Loadable.preloadAll().then(() => {
app.listen(8080, () => {
console.log('Running...')
})
})
6. Load the Server-Rendered Bundles on the Client
The final step to using the bundles that we've loaded on the server is to consume them on the client. Doing this is simple—I can just instruct React Loadable to preload any modules it's found to be immediately available:
// client/index.js
import React from 'react'
import { hydrate } from 'react-dom'
import Loadable from 'react-loadable'
import MyApplication from './MyApplication'
Loadable.preloadReady().then(() => {
hydrate(
<MyApplication />,
document.getElementById('root')
);
});
Conclusion
Following this process, I can split my application bundle into as many smaller bundles as I need. In this way, my app sends less to the user and only when they need it. I've reduced the amount of code that needs to be sent so that it can be sent faster. This can have significant performance gains for larger applications. It can also set smaller applications up for rapid growth should the need arise.
by Luke Jones via Envato Tuts+ Code
