A Beginner’s Guide to Web Performance

What you can do as a front-end developer to improve it

6 min readApr 13, 2018

Performance really does matter. Not just from a technical perspective, it can also affect how users perceive a website.

I have been very fortunate to have just spent some time working on a project where literally the sole focus of the team was to improve website performance and speed. I’ll be the first to admit that when this opportunity was first presented to me I was nervous — I knew very little about this topic, what value could I possibly add?

I thought it could be useful to share some of my learnings from this journey and put them out there so other people can start to put the interests of users first and make the web a better, and slightly faster place.

So what is the current situation?

Most people working in development tend to find themselves in a privileged position from a tooling and technology perspective. We have fast, stable internet connections, the latest mobile devices and powerful, high-end laptops or desktops using the latest hardware and software. With this in mind, we would do well to remember that not all of our users get to experience the web under these same conditions.

53% of users will abandon a website if it takes more than 3 seconds to load on mobile…*

So what can we do in order to do better by our users…?

Gather some metrics before you start

I can’t put a big enough emphasis how important metrics are. You can’t know how much of a difference you’ve made if you don’t know what your starting point was…

As a team we opted to use Calibre as it doesn’t require the use of any tracking codes or JavaScript, which actually has the potential to slow pages down even further. It uses managed agents which allow testing across a range of devices and connection profiles.

It’s a tool that is very focused on user-friendly metrics such as “time to interactive” and “time to first paint” which was appealing to us as these were the metrics we were really looking to improve.

Lazy loading is your friend

With images making up a whopping 65% of all web content these days, page load time on websites can easily become an issue — so lazy loading should be a no-brainer.

We decided to use lazysizes.js because it’s labelled as a fast, SEO-friendly and self-initialising lazyloader for images (including responsive images), iframes, scripts/widgets and lots of other things. It prioritises resources by differentiating between crucial in view and near view elements to make perceived performance much faster.

How to get it working

Download the script and include it in your webpage or install it via npm

To install simply run:

npm install lazysizes —-save

To include it in your web page use the following:

<script src=”lazysizes.min.js” async=””></script>

2. Add the class lazyload to your images/iframes in conjunction with a data-src and/or data-srcset attribute — we opted for using placeholder base64 encoded images in as many places as possible that matched the sizes of the final images. We have a lot of repetitive content on our site so this worked well.

<img class=”lazyload” data=”data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI5IiBoZWlnaHQ9IjUiPjwvc3ZnPg==” data-src=”fluffy-cat.jpg” />

Consider self-hosting and optimising your fonts

The rationale behind self-hosting is that most websites don’t change their fonts very often, so we don’t want our end users to have to pull down what is essentially the same font unnecessarily. Before we moved to self-hosting the fonts on our CDN we were using Google fonts.

Currently Google fonts doesn’t let us do two key things:

Predict the URL of the font file
Change the font-display property to improve how the font renders

By self hosting the fonts we use, we can adjust these settings and improve the time it takes the text on all pages to appear creating a better experience for our users.

Considering that fonts are critical and part of the critical request to the rendering of most sites, we can then make small adjustments like rel=”preload” which instructs the browser that this asset is a “High” priority and it should be bumped up the download queue. It’s our way of telling the browser, “you might not realise it yet, but we are definitely going to need this thing”, so let’s be a little smarter about the fetching of it.

Whilst we were making this change we also used this as an opportunity to bring in the WOFF2 version considering that browser support is starting to look a lot better.

I highly recommend reading the “Web Font Optimization” article written by Ilya Grigorik for some other excellent suggestions on this topic.

Remove things that aren’t being used

Hands up who has a lot of legacy code floating around…? Come on, don’t be shy! How much of that code is still being used?

It’s always worthwhile doing a bit of a spring clean and seeing what you can get rid of. We ended up removing some old code that wasn’t being used, some third-party scripts that were no longer in use, we uninstalled some plugins and generally got rid of some of the cobwebs.

Chunking

It’s one of those words that you’re either going to love or hate. But what is chunking some of you might ask… The idea behind chunking is to reduce unnecessary DOM depth. The theory is that if the DOM is shallower the browser should be able to render the content above the fold quicker.

A large DOM tree can have multiple performance implications.

There can be quite a substantial impact on network efficiency and load performance. If your server is shipping a large and complicated DOM tree, you may be moving lots of unnecessary bytes. This can also slow down page load time for users, because the browser may be parsing lots of nodes that aren’t even displayed above the fold.

Another thing that could potentially be affected is runtime performance. As scripts, and even users, interact with a page, the browser needs to be constantly re-computing the position and style of nodes. An excessively large DOM tree combined with complicated styles can severely impact rendering.

The current optimal DOM tree numbers according to Google the last time I checked in were:

Less than 1500 nodes in total
A maximum depth of 32 nodes
Has no parent node with more than 60 child nodes

Understand the critical rendering path and why render-blocking code is bad

So what does render-blocking mean…? If a resource is deemed to be render-blocking then the browser cannot display the page until that resource has been downloaded or handled.

In order to understand why render-blocking code is a bad you need a basic understanding of the critical rendering path. There are six stages to this:

Constructing the DOM Tree
Constructing the CSSOM Tree
Running JavaScript
Creating the Render Tree
Generating the Layout
Painting

Anyone working on performance and speed spends a lot of time trying to work out what is blocking or delaying parts of the critical rendering path, and then trying to unblock them.

Some things to consider looking into to avoid render-blocking code would be:

Try to defer or asynchronously load blocking resources
Inline the critical portions of those resources directly in the HTML — a good place to start with this is to look at what you have rendering above the fold
Consider splitting the contents of your CSS into different files according to media type and media queries
Use the preload directive on link elements, it’s not supported across all browsers yet, but no fear, there are polyfills available

Conclusion

I believe we are living in a world where performance is no longer just a technical concern. It actually matters.

We should be working out how to bake it into our workflow, we should be having conversations throughout the business about it, making design decisions taking into account what the performance implications are. As people who work on the web, and as its custodians, we should constantly be monitoring, measuring and looking to improve the speed and performance of our websites to make the web a slightly better place for everyone.

Resources that I found useful

*(Source: Google Data, Aggregated, Anonymized Google Analytics Data From A Sample Of Mweb Sites Opted Into Sharing Benchmark Data)