How to optimise static content load-time?

Karan Verma
Jul 9 · 3 min read

I have been working on revamping my old portfolio and I choose to do it by rebuilding it from scratch without using any framework(because it is a simple one page website).

While developing it, I was aiming for fastest page load time possible. In order to achieve that I took following measures:

  1. Using SVG for graphics where ever possible.
  2. Using CDN(Cloudfront with Lambda@Edge).
  3. Avoiding UI framework like React or Vue.
  4. Using Text-compression to reduce file size(more on this later).

I ran lighthouse tool to audit the page once I was done with all the optimisation possible. Here is what I was able to achieve:

Yes! That’s 100 for performance 🥳(with 3g applied setting).

If you notice page gets painted right from the second frame. That is because I made sure that render blocking javascript and css gets loaded as soon as possible.

Here are the few thing I did to achieve that:

  1. Uglifying and Minifing static content(CSS, HTML, JS).
  2. Compressing static content in gzip and br.

With the combination of webpack and few webpack plugins both of the above changes took relatively very less time and effort. We will dive deep on webpack config from here on(so get your webpack wizardry cap on 🧙🏼‍♂️)

  1. Uglifying and Minifying static content
    Webpack has `TerserPlugin` for JavaScript uglification. we can use plugin like `HtmlWebpackPlugin` for uglifying HTML and `OptimizeCssAssetsPlugin` for CSS uglification.
module.exports = merge(common, {
mode: "production",
devtool: "none",
output: { filename: "[name].[contentHash].js" },
optimization: {
minimizer: [
new OptimizeCssAssetsPlugin(),
new TerserPlugin(),
new HtmlWebpackPlugin({
template: "./src/index.html",
minify: {
removeAttributeQuotes: true,
collapseWhitespace: true,
removeComments: true
}
})
]
},
module: {
...
},
plugins: [
...
]
});

2. Compressing static content in gzip and br

plugins: [
...
// this plugin for compression into gzip
new CompressionPlugin({
filename: "gzip/[path]",
algorithm: "gzip",
test: /\.(js|css|html|svg|ttf|woff|eot)$/
}),
// this plugin for compression into Brotli
new BrotliPlugin({
asset: "br/[path]",
test: /\.(js|css|html|svg|ttf|woff|eot)$/
})
];

Above plugin setup generate two different encoded content in dist or build folder. This is how build folder will look like after adding this plugin.

If you notice we are testing for `/\.(js|css|html|svg|ttf|woff|eot)$/` any one of these files. We should not compress images as they are already compressed with different encoding. If we compress images we would end up increasing size of the images 😂.

You must be wondering why have I created compressed file in two different formats? Isn’t just br or gzip is enough?

Yep! Only one content-encoding is not enough. br provide higher compression as compare to gzip(at least 14% better). However br was released by google in 2015 and safari was latest to add support for it(by October 2017). which means if we use only br encoding, user on safari browser older than October 2017 will not be able to access the website 🙁.

For the users like this ☝️ gzip encoding is supported by the end of 2000. Hence two different encoding format. If you are wondering how the hell these different files are getting served. That’s a topic which deserve a blog of it’s own(I will be writing that soon).

That’s all for this blog. Hope you found it useful. I will be writing a detailed blog on my website karanverma.me in sometime future.

Karan Verma

Written by

Perpetually curious, idea obsessed, optimizer, execution procrastinator. I get: design, tech, finance, people, fidgety. I don't get: complacency, bad attitude

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade