How to Audit Your Website — Part 1
Analyzing Critical Rendering Path (CRP)
For some of the frontend developers, they focus on shortening the full download time of the page, which can significantly speed up the page loading and improve the user experience. However, in most users’ points of view, the users are much more aware of the time it takes for the page to become usable, saying that it is always better to render something as fast as possible to the users than having your users staring at a blank screen, which arises another important benchmark, Critical Rendering Path, for the optimization of a website.
What is a Critical Rendering Path?
The following graph shows the improvement of optimizing the Critical Rendering Path.
The Critical Rendering Path (CRP) is the sequence of steps that the browser converts the HTML, CSS, and JavaScript into the screen.
Generally speaking, the browser would go for the following stages in the Critical Rendering Path:
- Send a request to get HTML.
- Building the DOM Tree.
- Building the CSSOM Tree.
- Executing the JavaScript.
- Generating the Layout.
- Painting.
You can also find out the whole process in the event log:
There is more much to do behind the steps I listed above, and it deserves another article to explain it. However, the most important thing to notice is that the DOM construction process is incremental, saying that when a browser parses an HTML file, it would start to construct the DOM element from top to bottom. If the browser reaches a script or style tag, the whole DOM construction process would stop immediately and start to request the CSS and JavaScript file from another location, which brings out the issue that the whole rendering process might be blocked because of the request for external resources.
How to optimize the website based on the Critical Rendering Path?
At this point, we understand that we want to deliver our content to clients as soon as possible. There are mainly two general tips to optimize your website according to the Critical Rendering Path:
- Reducing file size to shorten the blocking cycle caused by the rendering block.
- Modifying the HTML file.
And here, I want to introduce some useful optimization methods to apply the above-mentioned tips to your website easily.
Minifying and compressing the CSS and JavaScript files.
The reason to apply for minifying the file is that users will be able to download the asset faster with smaller sizes files, obviously lightening the download package for your users, resulting in improved performance.
Minification includes removing all unnecessary spaces, comments, and breaks. If you are using webpack as your web project bundler, it is really recommended to add css-minimizer-webpack-plugin and terser-webpack-plugin into your web project in order to minify the CSS and JavaScript file.
As for compression, we can use a compression method such as Brotli (A compression algorithm originally developed by Google, and offers compression superior to gzip) to reduce the size of the files. Webpack provides compression-webpack-plugin for you to compress the web project with the desired compression algorithm.
Fully reconstructing the CSS files
One method could apply to this subject: using a CSS class obfuscator to shorten the name of the classes in the CSS, HTML, and JavaScript files, resulting in reducing the total size of the CSS file. For obfuscation, I personally recommend the mangle-css-class-webpack-plugin to obfuscate the class name.
In addition, there are some CSS stylings that might not be used and are hard to notice from third-party libraries (Third-party libraries usually contain lots of unused CSS). Hence, the third step would be removing unused CSS declarations from the third party, and it is recommended to apply PurgeCSS to your web project.
Putting the JavaScript tag at the end of the HTML file
Most of the time, JavaScript would be like dynamically modifying the web content, adding event listeners to handle different actions from the users, and other program logic independent of the web content which is supposed to display to users as soon as possible.
Suppose we are not adopting a single page application framework that dynamically writes and rewrites the current web page using JavaScript with data from the server or JavaScript does not determine the web content. In that case, it is recommended to move the JavaScript files at the end of the HTML files. This prevents clients from requesting JavaScript libraries or other program logic and causing rendering blocks.
Extracting the main CSS of the page to be inline CSS
Inline CSS is considered useful as it reduces the number of files that the browser needs to download before displaying the web page. However, when you compare inline CSS vs. external CSS priority, you may consider the latter as they are cached or remembered by the browser. You don’t have to follow the same steps again and again when you visit a different page on the website.
This brings out another issue: How would we gonna distinguish if a CSS should be inlined or not. The core concept would be that you should inline only the CSS required to render your above-the-fold content. Then you should load the full style sheet asynchronously so that the page can continue rendering while it’s being parsed.
However, manually identifying the critical CSS would be a pain to maintain. There is an open-source project called Critical, which can programmatically generate the critical css styling under specific resolution.
As for a webpack project, you could apply the critical-css-webpack-plugin to the project.
Proof of Concept
I have made a POC of my personal website with Vue, you can find the source code here. For the optimization of my personal website, I applied thebrotli-webpack-plugin to compress the assets including CSS, JavaScript, and some static files and critical-css-webpack-plugin to generate the styling in the critical rendering path.
The bundle file size reduces from 1131.74 KB to 245.43 KB (about 80%) due to the brolti compression:
This is the epilogue of the article. And here, I would like to provide some powerful web audit tools to help you speed up your web project.
- Yellow Lab Test is a free online web performance analyzer, it can perform detailed test cases in different aspects of a website, like DOM access count, for your web project, which might be helpful for developers to make meticulous adjustments to the project.
- Google PageSpeed or Lighthouse in Google DevTool could also help you to identify the critical issues on your website. They mainly calculate different metrics like First Content Paint (FCP), Speed Index (SI), Largest Contentful Paint (LCP), and so on in weight. They also make suggestions based on the test result for developers, which can be a guide if you have no idea what to do for the project.
- WebPageTest provides granular settings to test under different contexts. To be more specific, you can set up the client under 3G/4G to test if the website still works properly as 5G.
