Improving page load speed and reducing the exit rate

Just after I finished a successful task to improve the website I was working on, I came across a post asking, ‘How can you tell if your site is performing well?’ This post lead me to share my experience on the subject. In this article, I hope to provide you with easy tools and best practices that will help your site performance. I will, however, skip the explanation on why we should care about page load time (you can read a short explanation from articles such as this). Although the tools introduced here are based on the stack used in my SSR website (gulp + express stack), the concept should be relevant for most sites.

TL;DR:

Tools to measure your sites’ performance:

• analytics.google.com
• https://www.sitespeed.io/
• Chrome dev-tools (Network and Audits tabs)
• https://www.webpagetest.org/

Improving your site:

• Critical Rendering path — remove render blocking assets by async and preload
• Inline required sources (can be achieved via https://www.npmjs.com/package/gulp-inline-source)
• Use font loader https://www.npmjs.com/package/webfontloader
• Clean out your html, css and Js and render only what you need
• Smaller images and smarter formats (https://developers.google.com/speed/webp/)
• Lazy loading — select what’s relevant for the first view of the page and load that first

My Achievement

As part of my work as a web developer, I was asked to improve a webpage’s loading time. This is the original page’s rendering waterfall:

Old Page Rendering Waterfall

As you can see, this long rendering process resulted in a less than ideal user experience. By making a few changes to the page, I produced the following result:

New Page Rendering Waterfall

To summarize the differences:

Summarizing pages rendering differences

But what did I actually do to achieve this and how did I know there was an improvement?

The Page Loading Process

When building a website, initially you develop on your local machine where the page will render extremely fast. However, in real life scenario The user’s connection speed may vary and a real http request will go through these steps:

1. DNS: The client will make a DNS request to resolve the website’s domain to an IP address.
2. Connection: The client will then proceed to establish a connection to the server and possibly do a secure connection handshake (TLS/SSL)
3. SSR: The server will gather and create the html for the response. This is where middleware and redirects to the final url occur
4. Client View: The client receives the response and begin to process it. — the browser reads the html and request assets such as css, js, images…

In this article, we will focus on the last (Client View) step, although you can improve a lot on the SSR as well.

See Your Issues

First, you need to find out how your site operates during this step. Here are a few tools that helped me figure out what I need to improve on:

1. Chrome dev tool — the easiest and simplest. There are 2 sections that I found really helpful: Audit tab - Run the audit and view the issues it suggest you work on as well as view the process the browser takes for the page to render. Network tab - Hard refresh the page with the console on and you can see at the bottom a summary of your page loading (how many requests to the server were made, weight of data transferred and so on)
2. SiteSpeed.io — Use this great tool to create a performance report.
3. WebPageTest.org — Use this site to simulate different environments’ performance reports.
4. Google Analytics — If your website is live and registered with your google analytics account, you can check out the site to see real statistics on your site’s usage (such as behavior → page timings to view average page load time)

Fix Your Issues

Now that you have reports and can see the issues, you will want to rectify them. But how? Here are some issues I came across and how I fixed them:

Critical rendering path

Javascript can manipulate both the DOM and CSSOM. For this reason, the browser has to wait for them and only then can it execute Javascript as described in this simplified diagram:

Rendering Process

When the parser finds a script tag it blocks the DOM construction process. It then waits for the browser to fetch the file and for the javascript engine to parse the script. This is why Javascript is parser blocking. It creates the waterfall effect. In order to avoid this wasted time, try to async or defer your script requests (read more here) and try to preload them (read more here.) Also, inline could be a great way to save time on server requests. For this, I used gulp-inline-source. Some assets are better off cached for future use but for others, there’s no real need. Fonts, for example, are best to be cached, but for page specific images where there is low returning traffic, I recommend to inline them.

Lazy loading

if the user arrives to the top of your page (i.e. above the fold), why is it important to load images or other data that he can’t see yet? So, if we are looking at css files, one simple solution is to split the needed style into 2 portions: what’s needed for the top of the page view and the rest. Now, you can import them separately, one at the beginning of the page and one much later on. Another option is to inline a block of your css file into the head of your page.

Thin out your page

Try to get as much information as you can during the SSR stage (step #3 in the page loading process) so only relevant assets will be rendered. Don’t render useless html, css and js, including the libraries you use. For example, jquery might seem like a straightforward library that simplifies your work, but vanilla javascript can be more efficient and definitely lighter. Don’t be afraid to write vanilla but remember to check browser support for your vanilla code! Also, if you do need images, try to reduce their sizes by compression (and try to see if new formats can be used in your site, such as google’s webp format) as well as base64 inline relevant assets (such as icons.) Don’t forget that minifying and uglifying your code and css are a browser’s best friends. It’s important to provide the browser with the shortest and simplest code.

Fonts

every modern website requires custom fonts, so how can we improve its loading? Until the custom fonts are loaded, your site will look bad — probably with a blank area where the text should be. There are great tools, however, to help you load the fonts smartly, so the visitor will see the content faster. I used webfontloader, a great tool which allows you to set a base font-family. Then, once the targeted font you really want is downloaded and available to use, you can switch to it. This is achieved by setting the font-family on the html to a basic fall back font. This tool adds to it a class once the targeted font is loaded. Plus, this tool has added features which improve both speed and efficiency. Read the documentation for more.

Final Words

My code changes effectively cut the page’s load time in half and reduced the exit rate by 25%. Thus Google SEO rating of the page was also improved. If you take one or more of the above actions, you could improve your site’s load time and by doing so, improve your users’ experience.