If there’s one thing I’ve learned over the years as both a user and creator of websites, it’s that performance matters.
If there’s one thing I’ve learned over the years as both a user and creator of websites, it’s that performance matters. Whether it is how fast the page loads or how it behaves once it’s in place, how well that page works has a direct impact on my and other user’s opinions of that website. A website that performs quickly and smoothly feels high-quality and that feeling translates to the brand it represents. Can you imagine someone like BMW having a website that was slow and clunky? Even if they weren’t aware of it, their customers would apply that impression to BMW’s cars, viewing them as inferior to the competition.
However, the mental association isn’t always so direct. BMW isn’t a very good example for most people because most people aren’t BMW, or even a car manufacturer. But everyone who has a website does provide a service. Even that person selling bespoke cupcakes from their kitchen to nerds across the globe is providing a service. One where the mental association can still be made because that’s just how the human brain works.
As such, it’s important to make sure that our websites perform at their best, both for business reasons and as a matter of professional pride.
How to measure page performance
Some of the best ways to test a page’s performance are also the least technical. Two of my favourites are simply to scroll the page up and down and resize the window. Watching as the browser tries to redraw the page can tell you a lot about how well that page is performing. A page that’s just raw text and images will scroll and resize more smoothly than the same text and images that’s been intricately styled.
Of course, I’m not suggesting that you should remove all styles from your pages. That’s would be silly and, quite frankly, ugly.
Let’s assume we’ve built a page, moved it around a bit and decided that we think it could perform better. The first thing we should do in that situation is try to discern where the performance issue is. To that end there are three tools that I like to use.
The second tool resides directly in the WebKit developer tools. For those of you who use Chrome (it’s not in Safari just yet) you can click the Profile tab of the Web Inspector and record CSS events. Once you stop recording it presents you with information about the selectors that were called in your CSS and how much time it took to parse them (a percentage of the total).
Another related feature in Chrome’s web inspector is the Timeline tab. It allows you to record events as you interact with them on the page. By using it you get a breakdown of when things are recalculated, when layouts shift or when items are painted (rendered). This tool, while a little confusing, can be extremely powerful and very useful in narrowing down exactly where the performance starts to degrade.
A few quick tips on CSS performance
- One thing we’ve always been told is that CSS rules that target an ID perform better than rules that target a class. While this is true it’s only a tiny difference and usually not worth worrying about.
- Generally speaking, if a page is slow to resize it’s likely a layout property (float, fluid width, etc.) and if it’s slow to scroll it’s likely an aesthetic property (such as shadows and gradients) that’s slowing the page down.
- CSS 3 properties are some of the worst offenders when it comes to page performance. Especially animations and @font-face. Use them wisely.
- Mobile is a thing and even the best mobile phones aren’t as powerful as the best computers from a decade ago.
Putting it all into perspective
When you’re testing the performance of a page it’s easy to get distracted by minutia. One thing I try to keep in mind is that the human brain has a perception delay of around 80 milliseconds. That’s 80 milliseconds of time which our brains view as a single moment. So focusing on a few milliseconds here or there isn’t overly helpful.
Instead of obsessing over getting the best performance you can, focus on the big problems that slow things down and then move on. It’s important to remember what’s truly of consequence and why we’re doing this in the first place: to improve the experience for our users. We are trying to give them the best website we can and how well our pages perform is only one part of a larger story.
As always web development is a collaborative process and I’d love to hear any other tips, tricks and suggestions the community has for testing and improving a website’s performance. Let me (and others) know your advice in the comments below.