Setting up frontend project these days is as easy as running a single command. We will get all of the good stuff and best practices alongside with the template (vue-cli or create-react-app) when we initialised the project. But what happened when we adding more and more components, pages, 3rd party libs, etc in our project? the bundle size will increase as the time goes on and gradually slowing down our apps. What shall we do? There are some improvements methods to do depending on our project conditions. First thing first before we do any action we need to analyse it first to know what we're up against.
Google Lighthouse
this is an interesting and very useful tools to give a high level information and suggestion about how our app perform in browser. It will provide score and suggestion on how we improve the apps. This tools can be a baseline guide on which methods we should choose to improve our site.webpack-bundle-analyzer https://www.npmjs.com/package/webpack-bundle-analyzer
this tools help us to check each size of our application chunk. By looking of the report generated by this tool we can find and minimize unused chunk of code being bundled in our applicationbrowser network inspection tool
this is basic tool that offered by most browser to help us spotted files and data being transferred to our site. By combining these 3 tools we will start our improvement
Let's get started to code i'm going to use vue in this example (will add a react version later). We will be starting with a project with bunch of libraries packed into it, then we will improve step by step
clone this project https://github.com/heruujoko/performante-vue-example
navigate to branch feature/without-optimization and try to run npm run build to see our condition of initial build
Just looking at the result, somehow it still look fine and will do just ok in most browser. But we can improve more on that.
CSS Part
Look for the biggest file in the build its our css. the project doesn't have much styling and the css is too big to be that size. We could be wrong, but lets not guessing and try with google lighthouse. serve the build file in your local machine then right-click on the browser and look for audit tab
run the audit and we will find reports about unused css and our current performance.
this is because most of the css framework provide bunch of classes for all purpose use. but not all css class we use in our site, so we will need to select only we need. But how? are we suppose to copy/cut paste the class? NO WAY!! too tedious. We will use css-purge plugin to to that. what it does is looking into our build files and delete any unused css in our build files that still present in our css files. install @fullhuman/postcss-purgecss package to our project and update our postcss.config.js to the following:
const autoprefixer = require('autoprefixer');
const tailwindcss = require('tailwindcss');
const postcssPurgecss = require(`@fullhuman/postcss-purgecss`);
const purgecss = postcssPurgecss({
// Specify the paths to all of the template files in your project.
content: [
'./public/**/*.html',
'./src/**/*.vue',
],
// Include any special characters you're using in this regular expression.
// See: https://tailwindcss.com/docs/controlling-file-size/#understanding-the-regex
defaultExtractor: content => content.match(/[\w-/:]+(?<!:)/g) || [],
// Whitelist auto generated classes for transitions and router links.
// From: https://github.com/ky-is/vue-cli-plugin-tailwind
whitelistPatterns: [/-(leave|enter|appear)(|-(to|from|active))$/, /^(?!(|.*?:)cursor-move).+-move$/, /^router-link(|-exact)-active$/],
});
module.exports = {
plugins: [
tailwindcss,
autoprefixer,
...process.env.NODE_ENV === 'production'
? [purgecss]
: [],
],
};
basically the additions config is just to show purge-css where to look for css classes to keep (our index html and all *.vue files) and only enable this on production build enviroment. Ok lets try npm run build again to see the result
surprisingly, we only need the tip of the iceberg now down to 3.47 KiB !!
JS Part
CSS part was easy just add few lines of config with plugin and we have our code optimized. But JS? we need to be more careful, taking up wrong piece of code could fail our apps. To do that, we need webpack-bundle-analyzer. install it by
npm i webpack-bundle-analyzer -D
then create vue.config.js with the following code:
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
let plugins = [];
let optimization = {};
// comment line 6 to disable analyzer
plugins.push(new BundleAnalyzerPlugin());
module.exports = {
lintOnSave: false,
configureWebpack: {
plugins,
optimization,
},
};
and run:
npm run build
http://locahost:8000 will pop up to our browser and show us overview of our bundle
actually analyzing this part is not a straight to method. Most likely based on experience and requirements whether we need to include some part of the code. In this case we can see moment and lodash took a big part in our bundle and looks like we don't need them that much. They are utilities that bundles all possible usecase they cover and bundle all the functions and module. Since we just only need findIndex for lodash we can change our code into
import { Vue, Component } from "vue-property-decorator";
import UserResponse from "@/interfaces/UserResponse";
import User from "@/interfaces/User";
import axios from "axios";
import findIndex from "lodash/findIndex";
@Component
export default class Networkable extends Vue {
users: User[];
constructor() {
super();
this.users = [];
}
async getData() {
const resp = await axios.get("https://reqres.in/api/users");
const parsed: UserResponse = resp.data;
this.users = parsed.data;
}
findEmma() {
const index = findIndex(this.users, (u: User) => {
return u.first_name == "Emma";
});
alert(`emma is at index ${index}`);
}
mounted() {
this.getData();
}
}
we import only function that we need.
secondly, take a look on moment package they took up a lot of space from their locale module. In this case we only need english locale, we can strip-down all those locale by updating our vue.config.js
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
const webpack = require('webpack');
let plugins = [];
let optimization = {};
// comment line 6 to disable analyzer
plugins.push(new BundleAnalyzerPlugin());
// ignore moment locale
plugins.push(new webpack.IgnorePlugin(/^\.\/locale$/, /moment$/));
module.exports = {
lintOnSave: false,
configureWebpack: {
plugins,
optimization,
},
};
moment is a good library but it don't have a good size and it's mutable (a lot of article explain this) for frontend when size matter i will suggest to take a look date-fns (https://date-fns.org/) over moment. Finally we can enhance a bit by removing axios and use fetch API provided by most browser. This step is really depending on your target browser when you have to support very very legacy browser (IE) then you should not do this. By the time this article written the fetch API has already supported in major browser you can see the details here https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
update our network request to be like this
async getData() {
const resp = await fetch("https://reqres.in/api/users").then(response => response.json());
const parsed: UserResponse = resp;
this.users = parsed.data;
}
now lets see how our bundle looks
and our final performance result
we have reduced so much of the bundle size without breaking/changing any features.
Infra level optimization
All the steps we do above is on the codebase level, infrastructure level can give boost to performance too with compression when delivering our bundle usually with gzip or brotli compression. You can find more info here https://computingforgeeks.com/how-to-enable-gzip-brotli-compression-for-nginx-on-linux/
That's all from me on what I've learned along the way being frontend engineers. Let me know in the comments if you have more tips on how we improve the performance on our site
reference:
Top comments (0)