Fast website, fast.

A fast website fast.

A lazy programmer’s guide to optimise speed with minimal work.

None of us wants a slow site. But most of us don’t get our hands dirty often enough to speed up our sites. It’s analogous to owning a car. We want a functioning, fast, problem free car; but most of us are not interested to look under the hood to tweak the engine, change the oil, etc.

I believe I have just successfully described myself and perhaps a few other developers in the world. At least a previous version of myself. I decided to get my hands dirty and look under the hood, and I want to share with you the discoveries I made which you can copy to quickly and easily speed up your website.

Chrome Dev Tools

Many people use chrome dev tools, but not in depth. I am guilty as well. Do not be afraid. It’s not as hard as you think.

1. Open your website in chrome incognito mode. Incognito so extensions are excluded because they can add noise to our stats.
2. Open chrome dev tools. In the Network tab:
   * Check “Disable cache”
   * Set Network throttling to “Fast 3G”

3. In the Performance tab, hit the reload button (not the browser refresh button!) that says “Start profiling and reload page”.

Profiler Results

You’ll get a pretty graph at the end. For my app, it looked like this.

Let’s see if my primitive mind can make sense of this.

1. I use webpack to produce a single js bundle for my app. I set the script to defer, so it shouldn’t block html parsing. GOTCHA: deferred scripts don’t block html parsing. They get downloaded asynchronously on separate threads. However they get executed before DomContentLoaded. So in my case, the gigantic main bundle takes 15 seconds to download on a fast 3G connection and that delayed DomContentLoaded.
2. The browser compiles and executes the bundle once it has finished downloading.
3. DomContentLoaded event is fired. This means that the “HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading” — ripped from Mozilla
4. Load event is fired. This means that the page has fully loaded.

In my case, it was easy to see that the single gigantic bundle was the bottleneck in performance. A better way is to split the bundle into smaller chunks: an app chunk and a vendor chunk (or maybe even multiple vendor chunks).

Conclusion

In the next post I will share the results of splitting the app into chunks. I will use webpack’s CommonChunksPlugin to achieve this. There will be blood (and performance gains)! In the meantime, check reactjunkie.com for my other posts related to dev and javascript.

I hope I have whet your appetite. Optimising performance to make things go fast is actually very fun and addictive! It’s like modifying a car, fine tuning the engine so it goes faster. It’s exactly like that. Happy tuning!