Episode Transcript

Ethan:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, we couldn’t be more excited to be speaking with Henri Helvetica, who is a freelance developer. Henri, thank you so much for joining us today.

Henri:

Folks, thanks you very much for having me. It’s a pleasure.

Ethan:

So Henri, for our audience members who may not necessarily be as familiar with your work, why don’t you tell us a little bit about yourself and some of the things you’re working on these days.

Henri:

I’m a freelance developer; I’m from Toronto, and as you probably know, if we’ve sort of had our interactions online on Twitter, I’m a bit of a performance advocate, and I’ve been spending a little bit of time dealing with that specifically. So, I’m actually almost on what I would call a bit of not so much a hiatus but kind of a mission, a bit. I’ve been spending some time doing more research on performance, but also I’m doing my best actually to go out to conferences and speak on performance and spread the word a bit more. Because I’ve always considered it a bit of a dark art, and it’s unfortunate that people may look at it sort of like on a secondary or maybe even on a tertiary level, but it’s a very important element of the web right now, especially if you look at it on a responsive web design level. So, I’ve been out there kind of “fighting the good fight” and preaching performance responsibilities.

Ethan:

Well that is squarely in line with Karen’s and my interests. We couldn’t be more excited that you’re talking to us today about performance and other things. Let’s maybe dig into that a little bit. Henri, I’d love to hear more about how you got to a point where you realized that performance was important to the web, to your practice. Tell me a little bit about that.

Henri:

It’s funny you should ask, actually, because I was thinking about it as well. I’m not here to put you on the spot, but I’m going to tell you a quick story. About three years ago, I’d been taking a class, I can’t remember which one, but afterwards I would actually stick around and finish up some work I was doing, or whenever I got into a groove I’d stay in the class. A particular teacher had a class afterwards, and I’d stick around, and he was talking about UX and whatnot, and one day I asked him a couple questions about some of his content that he’d been teaching some of his students. He eventually mentioned your book on A Book Apart. I went out and bought it and things just clicked, and that was really the beginning right there. Afterwards, I just started to attend a particular meetup group in Toronto called the Web Performance Group, and then it really started from there. I started to buy more books, read more blog posts, obviously some of the more revered writers in performance as well. It just made so much sense. The iPhone came out in 2007 and I still remember Steve Jobs saying how it was going to have the richest experience for mobile, and everything started to click. The data coming down, the images, what was going on in the background. These moments were very important in my formation in performance.

Ethan:

Well, I think that’s great. I want to go back to a point you made in your intro about elevating companies’ awareness of performance as not a tertiary concern but maybe a primary one. Can you talk a little bit about how you do that in your work? How do you actually advocate for performance as a key consideration?

Henri:

Thankfully there are so many people who’ve spent some time doing some great research, notably someone like Tammy Everts. Quite often enough, I could go on and on about the user experience element of performance, but the data is there. There are some well-documented cases—the Walmart case, the GQ case, the Obama for America case; how the checkout process is thirty-eight percent more successful with less images. Once you start to throw in these kind of numbers, hopefully you can get some of their attention. It’s still a bit of an uphill battle. Even this past week, I was listening to someone like Andy Davies speak about being able to get a retailer—and I believe retailers in particular have some of the toughest jobs online—but trying to get retailers aboard. There is a bottom line involved, and if you can prove to them that there are profits to be left on the table if you don’t take care of performance, hopefully they’ll come around and understand that this is something that has to be done.

If you start to look at the fact that the numbers are there… In fact, as you mentioned quite a few years ago in your book, that small screen devices are estimated to become the dominant form of web access in a matter of years—the matter of years is today. Right now, we do know that the primary device is the mobile phone, and if it’s not, the primary device is definitely the “primary prime,” if you understand what I’m saying right there. These are cases that hopefully they can understand, and you back those up with some numbers eventually, as well.

Karen:

Speaking of backing up your arguments with numbers, one of the things that I’m fond of talking about is saying that performance is a content strategy problem, and that the work that’s done by heroic developers to try to minimize page weight can often be greatly outstripped by organizations just making better decisions about what content they want to publish, is the content actually valuable, do they need all those giant images at all? Can you talk a little bit about how you have those conversations with organizations?

Henri:

You know, quite often enough the conversation is one thing, and in a jokingly manner sometimes I always mention the fact that one day their teenage son or daughter is going to come back and query them as to why they can’t get on their site. Usually that’s when a few fires start. It’s always nice and shiny when you’re in the office, and quite often enough this is something that’s discussed—people are working locally, everything looks good, they’re loading it up on their phone in the office and everything looks good then, and then suddenly a friend who’s aware of their project said they had a hard time getting on the site, or this wasn’t working. There are design decisions that are involved as well, and I feel that that has to be a part of the equation. In fact, I do like to speak at conferences that may have mostly CSS developers there, simply because quite often enough they might be tied into design a bit more. If you can start to show them that there is a design component in performance, they may start to think differently.

For example, I was kind of reminded of an article I’d read, Netflix had talked about making some changes in even the products that they were creating, because, as you know, they shoot some of their own material. They talked about creating films with lesser color palettes and lesser contrast, because they were getting much greater compression out of that. If you start to apply that to even some of your content—so, say, images that we know are taking the majority of the bandwidth online—you can start to understand, okay, you know what, I may not be able to use this image here, I’d much rather do this. It may need an art direction change here because we’re going to get a better mobile product out of it, because we’re going to have less data… These are little things that you want to keep in mind, and it does make for a long equation in terms of checking off what we feel you can do best, but I think it’s a necessary step in order to create the most performant product possible.

Ethan:

Henri, I’d love to hear if you have any other strategies and tips for bringing designers and developers a little closer together on this topic of performance. Have there been things that you’ve implemented either in your work or with your clients that help people have some of those conversations to see how performant their designs actually are?

Henri:

What I like to do quite often enough at, say, a talk that I might deliver, I always open up DevTools. I have a talk that I’m sort of throwing around right now, which is called “Optimized Prime: More Pixels Than Meets The Eye.” Even though it’s mostly based around images, I would show them that a lot of their work may look great on the phone when it’s all said and done, but in the background it’s unfortunate because the browser is doing so much more work to make it look as good as possible. Really and truly, it shouldn’t have to be that way.

As Paul Lewis once said, “Performance is the art of avoiding work.” If you can avoid that work as much as possible, you’re going to create a better product. So, by having conversations that are not always extremely technical, because we do know there’s a very technical component to performance, bringing in a designer and letting them understand that their font selection is going to have an effect to what they do, their designs, their images that they create… Now I’m not talking about pictures specifically, but they might go out and create a twelve-color design for a pharmaceutical website, and then they’ll create that image into a JPG. Now, if you start to drill down, there’s a chance that you may not have to make a JPG out of that; that should be a different format. So, there is a bit of an education process I believe that’s involved there.

Now, with that being said, I can hear Jason Grigsby in the background, telling me that this process should be automated. But I personally believe that with a little bit of education, I think there’s some decisions that will be much more different and hopefully will have a much more, again, performant product once people know how to look at things.

Ethan:

Let’s switch gears just a little bit: I’d love to hear if you have any tools or software that you find especially useful to you in your work, to either vet your work from a performance standpoint or to communicate to other team members about how well their work’s shaping.

Henri:

I think there are a number of steps you can take. In the performance world, everyone absolutely loves WebPageTest, that’s for sure. It is very detailed, you’re getting a lot of data out of it. But again, I like to go back to the idea that there are a lot of developers that are testing their product, or at least how it looks and loads in Chrome, but for whatever reason they barely use Chrome DevTools. I always find that shocking, because it’s basically right there. DevTools has improved vastly in the last year and a half. I’m not saying that it wasn’t good in the first place, but you’re talking about some of the additions that they’ve made to the actual product, so being able to look at the frames loading up, obviously the network panel, being able to remote debug so you can see exactly how things are loading on mobile. I believe that Chrome DevTools should be your first step, and quite often enough if there’s an issue, the smoke is going to be there, and usually when there’s smoke, there’s a little fire burning somewhere else. Now, there’s also the more recent addition to the testing environment, which is Google’s Lighthouse, and that seems to be providing a lot of interesting data as well in your testing needs for performance.

There are varied tools out there, but a lot of them do much of the same. I think if you keep it at two or three—like I said, WebPageTest; DevTools I think should be your very first check because it’s right there. And then afterwards, like I said, Lighthouse, which is a little newer, but some of the data that you get from it is really interesting, maybe it’ll give you some latency data in terms of, say, if you optimize some images, the kind of time that you’ll save on load, things like that. These are important tools to at least show developers what it is that they’re potentially sacrificing.

Karen:

Well Henri, I think that this has been such an interesting conversation. One of the things that we like to ask all of our guests is if you have any advice that might be relevant to other developers, designers in your position. What advice would you give people on how to improve performance?

Henri:

Test, ultimately. Test and measure. They’re almost kind of synonymous, but I find quite often that after things load up nicely on their screen, whether it be the desktop or mobile, most people feel they’re done. I recently bought a new monitor here, which is an UltraWide, I don’t know if you guys have seen those. But I was so happy because I basically have DevTools open and I have a viewport open, and there is no website on the planet that I run into that I don’t throw into DevTools, just to see what’s going on. That’s when you often start to see some of the challenges. Again, these may be oversights, but it’s tough to find out some of these things when things have gone live. You’ve been working locally for two, three weeks, and you’re like, okay, I’m ready. You hit the big red button, everything goes up live, and then you realize afterwards that a bunch of issues are coming up, and they could have come up easily if you had done just a minimal amount of testing. So, that’s what I always recommend: just test, measure, and figure out what needs to be improved.

Karen:

Well, I think that’s great advice for anybody who’s working on a website. Henri, thank you so much for taking some time out of your day to chat with Ethan and I here. I really enjoyed it.

Henri:

Merci bien, folks. It was my pleasure. Hopefully we’ll get to cross paths soon again.

Ethan:

Thanks to everyone for listening to this episode of a responsive web design podcast.

If your company wants to go responsive but you need help getting started, Karen and I offer a two-day onsite workshop to help you make it happen. Visit responsivewebdesign.com/workshop to find out more and let us know your company is interested.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Thanks for listening, and we’ll be back next week.