As front end engineers our applications are the first thing our users will interact with. They don’t see, touch, or even concern themselves with the backend. How our applications render and more importantly how quickly they load is what the user will remember when they interaction with our code. For the first time Mobile web interactions out number those of desktop interactions and we are heading out of the “Mobile First” design because at some point it’s all we are going to be talking about. With this idea in mind we really need to consider the speed in which our application is going to load. Mobile devices by nature are going to have less memory and processing power of their desktop counterparts and if we do not accommodate these users we are cutting out a significant amount of our user interactions.
Now there are a couple of things we can do to speed up our web applications. The first step is taking a long hard look at our web application and looking for ways we can speed up our application. The first thing we should consider ( I will not be showing you how to do this in this lesson) is caching our assets into something we’d call a vendor file. You can use web pack to do this. If I were to distill this down for you it’s basically taking javascript files in our bundle that rarely every change and sending them down to the device as a separate file. That file will typically have some sort of hash corresponding to it. What this longterm caching will accomplish for us is the the first initial load will take some time but any visits after that the browser will not have to re download all of the react, redux, and react-router dependencies needed. If that file changes it will simply re download the changed file and cache that one for safe keeping.
Turn to the person next to you and discuss the following:
What part of your code doesn’t change very often?
- Because it doesn’t change very often should our user pay for that code whenever a page reloads or changes?
Long-term caching is a massive step in the right direction but I would argue that it’s actually not enough. What we also need to consider is when a user is paying for our code. If I user your web app and you have code specific for an admin or a authenticated user that isn’t split that means I am paying for it. I haven’t event logged in and there is code within the bundle theoretically haven’t even thought of using yet. Ideally what should be done is that the minimum amount of code needed for our code to run should be sent down the wire. This is where the beauty and magic of code splitting comes in.
What’s great about this pattern is that it is particularly easy to utilize. Everything we need to accomplish what we’d like to do is already baked into ES6. On top of that we also get some help and support from wepback. All in all we’re simply taking advantage of how we use our imports in javascript.
Before we move on read this [article](read this)
Turn and talk to the person next to you and discuss the following things
How have you imported files in the past? What is the problem of loading a bunch of static files all at once? How can dynamic imports help solve the problem of large static / module imports?
Enough talking lets got and live code this!