Speaker spotlight: building faster websites with Harry Roberts

You recently seem to have shifted your focus from CSS architecture to front-end performance. Why’s that?
This is an excellent question! I guess the answer is multifaceted. I’ve always done performance work with most of my clients anyway, so the work itself is something I’ve been doing for a while. But a number of things spurred the shift in focus:

Firstly, it’s something I’m finding more and more challenging, exciting, and rewarding — it’s just work that I’m really enjoying. Secondly, I feel it’s becoming more and more pertinent: with more emerging markets coming online, we’re about to see a much more diverse (read, bad) array of connections that need to access the data that Western markets take or granted. Thirdly, it’s something of a response to a change in the market: although I definitely don’t think CSS architecture is a solved problem, or no longer in demand, it’s important as a self-employed developer that I broaden my market a little.

What’s the main reason clients turn to you for help?
Usually, it’s going to be one of two scenarios:

One is that they’re about to embark on a new project, normally entirely greenfield, where they’re keen to invest heavily in Doing It Right™ from the outset. They want guidance, opinions, advice, strategies, training, workshops, and other things to help them facilitate that.

The other scenario is almost the exact opposite. They’ve been ploughing ahead with their app/site/product for many years, and things have begun to get a little out of hand. Their CSS is a mess, there’s no discernible styleguide, things are running slowly, developer productivity is down. These types of project usually require scoping, prioritisation, and strategies for managing technical debt, and then lots and lots of refactoring.

Whilst there’s always some overlap between the two types of work, both need their own particular approaches, tactics, and methodologies.

And what’s the number one problem you see when you review their codebase?
Lack of clear documentation. Whether that’s commented code or full-blown docs, it’s almost always missing.

What do the kick-off sprints involve that you do when you consult with product teams?
They’re usually sprint-zero type things, so it would involve scoping the project, getting a high-level overview of the expectations of the codebase, and making very preliminary plans for how we’re going to architect it. An important thing to keep in mind is that my user here is the development team, not the website’s end user.

It’s key that we only keep at a high-level at this point because projects always change as we get further into them; this means that we’re likely to start coding up a specific architecture right away, but we always build in flexibility by design. It’s important to make it possible to change your mind, or your tech, or your direction as easily as you can, otherwise in five years’ time a project ends up governed by a decision that was made five years ago.

What are the three main obstacles to faster websites?

1. Third parties. I’ve written a bit about this recently, but third parties are probably the fastest way to guarantee a slow site. Ads, retargeting, tracking, analytics, etc. Almost always terrible for performance.
2. Lack of business prioritisation. It’s rare that a business makes a formal case for performance. No one thinks it’s their responsibility, and so it goes unconsidered or, at best, an afterthought. It’s hard to make a website fast after the fact.
3. Lack of empathy. I hate that word — it’s so overused these days — but honestly, most developers (particularly in the West) design and build websites on dedicated connections (often backed by fibre), on new and powerful machines. They seldom realise how fragile and temperamental the real world situations that their users are in.

Can you recommend one (maybe little known) performance trick to speed up a site?
Always define rel="noopener" alongside target="_blank"!

What kind of tools to optimise the performance can’t you live without?
It would have to be Chrome’s DevTools and WebPagetest. Absolutely no doubt about those two. They’re invaluable and free!

What can people expect to take away from your talk and workshop at Pixel Pioneers Belfast?
They’ll get an eye-opening glimpse into life online in emerging economies (case studies and anecdotes in the first half) and then fundamental strategies for beginning to deliver faster websites for those economies and beyond.

How did you get into the industry? You don’t have a degree, and you don’t even know what you got in your final year school exams, do you?
When I was around 15–16, a friend and I really wanted to be graphic designers. We landed small gigs with local firms, designing logos, flyers, etc. All really low-quality stuff, but we thought we were unstoppable. I decided that — with having such an amazing body of work! — we needed a website to showcase our talents. I volunteered to learn how to write HTML and CSS, and it all started there.

For the next couple of years, I immersed myself more and more in front-end, straying away from design work and more toward code. I ended up skipping the university thing, as I was offered my dream job when I was 17, so for the past 10 years I’ve been just working away on being a developer.

There’s a bunch more nuance to it than that, but I think that covers it for now.

What’s your favourite cocktail right now?
Whatever Josh Archer has just made for me. Like this clear pickled negroni.

A post shared by Josh ✂ Archer (@josharch) on Sep 11, 2017 at 12:54pm PDT

There are still some tickets left for Harry's Front-end Performance workshop at Pixel Pioneers Belfast but it's popular, so don't delay your decision for too long. The conference also features a Sketching Interfaces workshop, run by Eva-Lotta Lamm, as well as eight talks from the likes of Una Kravets, Christopher Murphy, and Laura Elizabeth.