A few weeks ago Heart Internet sponsored the return of digital design conference New Adventures in Nottingham. One of the highlights was Harry Roberts’ popular workshop on front-end performance (which once again sold out). As building faster websites is a topic close to our heart (see what we did there?), we sat down with Harry to find out more about web performance.

Here he gives us the reasons modern browsing experiences are often slow, explains the business impact of performance, reveals the three types of performance testing, talks us through some nifty tricks to speed up our websites, and more.

There are many reasons why a website might be slow. The three main reasons would be — in no particular order — third parties, CMS issues and the over-reliance on front-end frameworks.

Third parties could include things like tag managers, tracking scripts, analytics, A/B testing tools, and retargeting ads. I help a lot of clients with third-party auditing, because as we try to monetise the web as a platform more pages are getting completely overloaded with ad networks, mainly in publishing. Ecommerce clients in particular will really heavily measure everything and track every single click and abandonment. Every tool needed to measure that will add some overhead.

Again in publishing, a lot of content editors aren’t aware of web performance and might just upload a 2.5MB image. Some of the biggest performance problems for a lot of the clients I work with are actually down to the way the site content is administered. That’s a little trickier to fix, because the cheapest way is to just train CMS users in how to optimise images but that’s also the least effective because people are lazy. They optimise the first couple of images, realise it’s boring and then go back to their old ways.

The third reason — and this is a very specific one that I deal with a quite a lot — is people’s over-reliance on JavaScript frameworks. They go full React and just put everything into big 1.2 MB JavaScript bundles! On a nice shiny machine in an office in San Francisco that’s probably going to work okay, but as soon as you get onto a mobile high-latency network, it’s a problem. I travel quite a lot for work, and on my 3G data roaming plan the only sites that frequently fail to load are 100 percent JavaScript websites.

There are two key impacts. In the simplest way, investing in performance can save you money. Netflix quite famously reduced their bandwidth bill by 43 percent just by turning on a simple server configuration. That’s a huge number.

The second way there’s a business impact is that faster sites make more money. Every case study that’s ever been done proves it: People want to turn up, find what they’re looking for, pay you some money for it and disappear again. If you owned a physical store and somebody came in and spent an hour there and then only bought one small item and left, that would be a very inefficient way of dealing with that customer. What you want is to get them they in, they can find the item immediately, they pay, they leave, they’re happy. There’s a real business impact.

I’m just one guy from Yorkshire but I was in a meeting with the CFO of NBC Universal earlier this year because people as high up as that in the businesses are interested in web performance now. They understand that if their website is slow, they will either lose users because people don’t engage as much, or they won’t make as much money because the site won’t be as profitable. The business impact is tangible.

 

I’m kind of lucky, because people only contact me when they already know they want a faster website but every time I start a new project I ask the client about their nearest competitor. We can then do some competitive benchmarking and might discover that they’re two seconds faster. Regardless of people’s personal thoughts on performance, you can always play to somebody’s competitive side. That’s a really effective way of getting people to be at least enthusiastic about performance.

I would also look at existing case studies but the strategic problem is a lot harder. It’s quite easy for me to turn up and make a website faster, but it’s difficult to convince an entire team to keep it fast. I’ve been working with a client in Estonia, and I genuinely believe the main reason this company has succeeded is because their CEO cares as much about performance than the developers do, if not more. He is very invested and really cares about it, so getting the initial buy-in from my client was easy but it was a little more difficult to get the developers on side, get them to trust me and understand that I wasn’t there to tell them they did a bad job. I wasn’t there to tell them that they built a slow website, I was there to help them make it faster and keep it fast.

I often find that convincing people that way is a case of ‘show, don’t tell’, so rather than telling them their site could be faster, I will pair with the developer for half a day and show them that it can be dead easy to make a site much faster in just three hours. I’m getting them enthused and excited, so they can actually see the results of what we’re doing.

I’ve named three types of performance testing. There’s proactive testing, which means that as you’re building a site, you’re testing it the whole time. When I work with clients I often end up thinking to myself how on earth did you manage to build a website that was this slow? There are lots of amazing tools that you can put in place to monitor the performance in the browser or locally.

If you can’t catch everything at that point (and of course that’s not always possible), then the second type of testing that you would employ is reactive testing. So if you are rolling a release to a staging environment, you would automatically run some tests against that codebase, using maybe Lighthouse or a private instance of WebPageTest. So here the release has already left your machine but hasn’t gone live to the public yet. You can react and try and capture things in the staging environment. That’s usually the next best place to catch things. You might have to schedule a bit of work in, and there is a bit of cost but it’s much cheaper than putting it live when it’s too slow.

The third type of performance testing is passive. It’s what you do in the wild, and you can use  tools like SpeedCurve, New Relic, or Dynatrace, which will constantly monitor the performance of your website. They test it on a real user’s device, and that’s called RUM — real-user monitoring. If you capture problems at this point, they’re already live, and they could be costing you money already. You could be losing revenue but it’s still better than not capturing them at all.

A really quick win would be checking if you have gzip or even better Brotli enabled. Your CDN or web host will be able to help you identify that and turn it on if need be. It’s usually the case of just one config switch somewhere in a dashboard. I switched a client of mine from gzip to Brotli, and all of a sudden our entire data transfer was reduced by 30 percent! That’s a really quick win for the sake of one checkbox. It does, however, require server access.

Something that always gets mentioned is making sure your images are well-optimised, that you’re not using 25 different fonts on one page and that the assets you’re sending to the device are minified and not too big. For example, I worked with a client a couple of years ago, who had a CSS file that weighed 1MB! It was completely atrocious because that’s 1MB of data that is blocking rendering. The browser can’t put the page together until it’s got that 1MB stylesheet.

Keep an eye out on simple things like that and ensure you aren’t sending crazy amounts of data over the wire. That’s the easiest place to start but most developers do that anyway. Most work that I tend to do is a bit more forensic and detailed, purely because most of my clients will have already dealt with the quick wins.

When I ran my workshop at New Adventures, one guy had a chart and couldn’t work out why there was a gap in how the page was loading. It was downloading some files, then doing nothing at all, and then downloading some more stuff and then rendering. I took the problem away with me, and once I found the problem, it became very obvious to me.

There’s a really interesting interplay between CSS and JavaScript: If a browser is currently downloading a CSS file, it will not execute any of the JavaScript. So if you have a big CSS file, your JavaScript will not start running until that CSS has finished downloading. And this guy had exactly that problem. The CSS file took a long time to download. Even though the JavaScript had already arrived, it wasn’t allowed to run until the CSS had arrived. So the long downloading of the CSS held back some JavaScript further up the page, and that JavaScript then called more JavaScript. A lot of people are not aware of this subtle interplay. Most developers that I’ve met aren’t aware of the fact that a browser will not run JavaScript if it’s downloading CSS.

So check when your JavaScript is running and if any CSS is slowing any JavaScript down. It could be a case of just swapping two lines of code around. It could literally be as simple as that. And that could make a site hundreds of milliseconds faster. It’s a little known technique that I employ quite a lot.

I recently worked with an international online gaming company, which focused very heavily on performance and actually reworked their site based on my consultancy input. They improved their revenue by tens of millions of Euros!

I also worked with a really large British company, and we managed to reduce their data transfer by 67 percent. They found that if they could speed up their website by 0.3 seconds, they would make an extra £8.1million a year. We managed to make it about 1.6 seconds faster, which obviously translates to huge, huge revenue wins.

Also, when it comes to performance, it’s not necessarily about having the fastest website. No one really cares about having a fast website. They care about that website making more money or having more user engagement. You could make a site 10 times faster by deleting all the CSS but you would get a really bad user engagement because it would looks so bad.

Making a site faster won’t always improve engagement and revenue. Maybe you could make it faster but one subtle UX change to make the add-to-cart button bigger might also make it more profitable. Maybe adding an extra bit of tracking to the site makes it a quarter of a second slower but that bit of tracking could give you enough data and business insights you can use to retarget that customer and actually make more money that way. So one thing I explain to developers especially is that it’s not just about making a website faster. It’s about improving it across the board, and performance is just one part of that.

The post Practical tips for faster websites: an interview with Harry Roberts appeared first on Heart Internet Blog - Focusing on all aspects of the web.