Design systems have conceptually been very well documented and discussed, yielding fantastic UX results.

Web engineers have painstakingly audited, researched, and crunched numbers in order to also provide fantastic UX.

Sound familiar?

Performance By Design will explore how Design systems and web performance work in concert to achieve same first class UX result.

 

Unedited Live Transcript

Una Kravets:

All right. Next on stage, we have Henri Helvetica. Henri is a freelance developer who focuses on performance engineering and user experience design. He comes here from Toronto, Canada. I learn a ton from Henri's talks. I'm excited to hear from him today. So, give it up for Henri.

(Applause)

Henri Helvetica:

All right. Can everyone hear me? Can everyone hear me? All right. Let's go. You have been given some jokes all day and yesterday, too, so I thought I'd start my talk with a few jokes myself. All right. So, Notorious Biggie Smalls would be Big Daddo. What if LL was a big fan? He would be LL Cool JS. What if she was a fan of style sheets, she was be, beyond CSS.

(Applause)

(Laughing)

Henri:

I like that. Yes, I am French.

(Speaking French)

Henri:

I did that for the stenographer because I don't know if she could translate that in French. It is spelled with an i. By the way, my last name is not Helvetica. It was a fun joke for Twitter. People ask me every time, is your last name Helvetica? I'm like, no it's not. You can leave now if you want or you can tweet me and tell me how bad my tweets are. All right. Let's go. So, I'm glad to be back in California.

I came down I was in Vista before I came here. I was actually going to go down and get some running in because I do enjoy doing that. But, I didn't have time and especially because I had a bit of a funny ankle. So, I came down here a couple days ago and when I came, I went right to the speaker event, you know, to catch up some speakers here and I ran into Mr. Curtis. I usually don't trust people with two first names, but he's my man there.

(Laughing)

Henri:

We met in New York at Smashing magazine. I think I saw him with a Garmin watch. When I caught up with him, I was just telling him that, yes, I've been running. I had a great summer of training. It was going really well. I had a coach, as well. And, I would run three times a week. First of all, I'm a I'm not a marathon guy, I'm 5 or 10K. Everyone's like, what he's talking about? 5,000 meters. Doesn't make sense. I ran three times a week. A long run. I'll do this sort of half and half run during the week. But my favorite time was track night. So, I'll do these 200 meter, 400, 1,000 repeats because it's going to help me be faster, get better at that craft.

So, as I kept going on and on during the summer, I was really gearing towards Chicago Marathon because there was the International 5K. Am I walking out of the spotlight? Sorry. Before I went down to Chicago, I entered this one race that's in Toronto and I was able to break my goal. I ran the 5K in 19 minutes and 20 seconds, that's 6 and one quarter minutes a mile. Super happy. I broke the goal that I had in mind and I'll tell you right now, why did it happen? I mean again, I'm sorry. I have a bad habit of pacing back and forth. How I was able to sort of like reach my goal and, you know, break it? Well, it was all by design. It basically went all according to plan, I did the training. Ate well. Rested well. You know, they tell you, you got to stretch, et cetera. Essentially, I was able to have performance by design. The performance part was the running, the design was the training I went through.

Even though I know I'm in a room full of designers, we are going to talk about performance because once again, I do believe that or at least, I don't believe that performance should be something kept to the engineering side. There is no reason why engineers, developers and designers can't kick it. You know, I don't need to be in firm or color blind to care about accessibility. Like I don't need to be a female to know that women's rights are important. Just like that.

(Laughing)

Henri:

So, let's talk about performance. So, why performance? Well, performance and support. It's part of user experience. And since we were trying to improve user experience all the time, we have to look at performance and all the changes we can make to improve it. Now, once upon a time, performance was raw numbers. Man, I have to be fast. We used to look at DOMContentLoaded. These are not reflective of the user experience we are trying to convey. So, now what do we have? We have stuff like this. Now, it may look like mandarin, but it's not. We're looking at things like first paint. When is the first pixel appearing on the site when it's loaded? That's a metric that we're using now.

We're looking at first contentful paint. So at this point, we're going to see maybe the background come in, maybe a menu but there's not a lot on the screen.

We're also now looking at first meaningful paint. At this point, we probably have a bit more content, like text, the menu's there, the background's filled in. But you know what? How many times have you been looking at a site and you're like, man, I see stuff, but I can't do stuff yet? We look at time to interactive. Time to when the actual site is usable, AKA, when I hit a button, stuff happens. Sorry, I'm stopping out of the spotlight. Sometimes what happens is you'll sit there and hit these buttons and they're not interactive yet. That's something we're trying to improve. This is the one we always have in mind.

So, once again, this is all about the performance. This all about improving that user experience so that your user can load up your site and go about their business.

So, again, performance became important why? Well, I like to refer to the time this time are we in November right now? Yeah, we are. So, just about a year ago. It was a pretty important moment in sort of, like, developer web history because at this point in time, the web was being accessed officially more on mobile than it was on desktop and this is sort of like a world wide figure. This is something that is not going to change ever again. People aren't going to go back to desktops. This is officially here. And in fact, it's also because, you know, some of these phones are much more powerful than desktops, anyhow.

This was an important moment in time because now, we are forced to design with constraints because the mobile phone is not what is obviously not a desktop and it has certain characteristics that we need to keep in mind. Now, they mentioned moments ago, some of these iPhones sorry that I let that slip. Some of these phones and devices are more powerful than desktops, but as Alex Russell has mentioned, the average device is mid to lower tier Android. When we are designing with these constraints, we have to make the proper adjustments. So, for example, we have to deal with things like the network because, you know, I don't know how many of you have been in here trying to get the most awesome reception. I know I'm not. And I don't know about you guys. If you are getting some reception, hello, I'd like to tap it.

So, we have to work with phone capabilities and we have to work with the network. This is statistics a few statistics. This is one stat that performance engineers like to talk about and user experience people who know performance is the fact that you can use 50% of your users around three seconds. If the site doesn't load, poof, one out of two people are gone. In fact, the average page load on mobile took 19 seconds. So, I don't know how many people know what 19 seconds feels like but we're about to experience it right now.

So, you can look at the clock up top.

(Laughing)

Henri:

Look at me! Look at me! Yeah. I remember when this happens, news people were astonished because it was 19 second handshake, which was a little crazy.

But, the bottom line is this, some sites are taking on average 19 seconds to load on mobile. We're having to work with the critical rendering path. That is the JavaScript and CSS script to load above the fold or within the viewport immediately so that we can at least provide a resemblance of proper use. You have to do what Mina Markham said yesterday, keep it simple. Don't overdo it with CSS. Don't overdo it with CSS. Don't overdo it with images. You want to make sure that the first load is like, boom. It comes in as fast as possible. This can be achieved through some design. If you have this mock up where it's a bunch of stuff going on, fancy stuff, et cetera, et cetera, and things that are going to take quite a few requests, no. You want to keep those requests nice and low because here's the gem for you what do they say? Pro tip. The quickest request is the one never made. Take that in.

(Laughing)

Henri:

So, as I was saying, you want to keep the CSS and JavaScript as low as possible. One of the challenges we have and that we sort of observe on sites and that we want to convey to people as well is that CSS and JavaScript are both blocking resources. And, on top of that, you also have the fact that sometimes too much of it is being loaded up and you end up with audits like this and I don't know I really don't want to go into dev tools because I didn't know how it was going to show up. But can you guys see the red here? Does it show? Okay. Cool. So, you can see in some of these resources, CSS and JavaScript, the green the red is the scripts that were not used. But they were parsed. Meaning that, they're essentially parsed just to use, say, the green parts of the script and you actually can see the percentage of the script that was used or unused, 75%, 54%. So, you're essentially looking at a situation where you're parsing some JavaScript and CSS that you're not using, but you've used up some of that time and some of that time is eating into that three seconds that we need to retain the user.

In fact, here, there's another shot of dev tools. Again, I have to apologize because it doesn't show the best. But, you can see some of the JavaScript execution time in the gutter on the left. At some point, this adds up to almost 600 milliseconds. On top of taking up a lot of time, parsing, executing, we have this little green goblin right here, which is the battery. In a study that came out, actually, a few years ago not too far from here, Stanford, they basically told us that excess JavaScript, excess CSS eats into the battery. These are things that we have to look at. This falls under performance.

But again, if you wheel back, there are design decisions that you can make so this can be alleviated.

Now, batteries just one of them. CSS, Gs, that's some of the issues we have and we have to deal with. But we also obviously have fonts. I really can't see anyone, but hands up if you don't use web fonts. Okay. Just a few of you. They're outing themselves right now. But the bottom line is, is we use web fonts especially if you're going to get typography type. These things are important. And, the thing about web fonts is the following this is a great quote from Zack Leatherman. Web fonts give us the freedom to read text through the eyes of the type designer. These things are very important. But, fonts can hamper the user experience. How? Well, like this. We have this thing called FOUT, which is flash of unstyled text. This is when you probably have a system font loading up and you're like, okay, the font's here and suddenly, it changes into something completely different. That is the unstyled text changing to the actual styling that you wanted. But this is poor user experience and it falls under performance.

But, you can make some design changes to alleviate that. We also have this thing called FOIT, which is there's a different name. Flash of invisible text. And what that looks like is this. Now, this is actually pretty funny because I was someone published on Twitter that they had a new site up and I was like, oh, cool, let me check it out and I clicked on it and I sat there and waited for the content to load and I'm like, it's not loading and it took so long, I was able to take a screenshot of it and keep it for my talks because this is a perfect example. We're on mobile, we're at the mercy I think I'm on, like, one bar. And I'm on WiFi, go figure. We're at the mercy of the network and the funny thing is, is that the styling loaded, but the font had not yet because those red lines are underlines. And it's underlining fonts that have not loaded. These are things that we have to work with, as performance persons. And these are things that, as a designer and a type person, oh, man, I love this site, it's all good. The font's ready to go but it's not loading right but there's some design decisions you can make to make sure that this does not happen.

Because quite often enough, people just don't know how the font works and how it's being loaded. So, that's one element of performance that we we definitely have to deal with. The font load.

The funny part is that the image actually had even loaded in time, which is totally bizarre. Which brings me to images. Now, I could probably spend the rest of the actual conference just talking about images because there's so many challenges that have come that have come up with dealing with images on several levels. Once again, the network. You know, we're going to see how memory is impacted among other things. So, and it's also the heaviest asset on the web, which is a classic web performance problem. So, one of the things that I feel designers should definitely know about are image formats. Now, there are several out there, but they're really for in general that we like to look like give me a quick second here. Can I do this? No, I can't.

So, I'm a big advocate of knowing your formats and once you know the formats, you can learn decisions on which ones to use, like so we have the JPEG, GIFs. But, when we do end up picking the format we need, the best one, we certainly have to do some optimizing and some compression. Now, for example, who regularly creates SVGs here? All right. Cool. You're good. You're look okay. When you export it and you have a code, you have to realize that an SVG, you can have long decimal places in there. These are things you need to smooth out. You can have less points. You essentially want to render it as simply as possible. That's an optimization process that we need to go through. You might use the SCG because you're using it for a corporate logo, et cetera, et cetera.

But when you get into images, say, the rest of the formats that we talked about GIFS, JPEGs, that's when we get into compressions. Compression's absolutely needed because of the heaviest asset on the web, you want to make sure that you compress the images so they load as quickly as possible and there's a myriad of examples as to why this is absolutely needed.

So, one of the issues that we deal with, especially when, say, compressing a JPEG I mentioned it because it's the most dominant. We have chroma sampling. Show of hands? A few of you have. Chroma sampling, I'm going to put up exactly what it is. Now, it's the practice of encoding images by implementing less resolution for chroma information than for luma information, taking advantage of the human visual system's lower acuity for color differences in than for luminance. We are playing around with the photo and not the liked channel because we can well, let me put it this way. We can get away with it, which is basically way.

You know, there was a talk earlier on color, which I absolutely loved and she sort of touched on some of this a bit. But, this is a practice that's used all the time in image compression in performance. So, what we end up with is something like this, which is CCBCR:4:20. We've actually meddled with it and removed some color. Why this is important is because at some point, if there's no subsampling, you could be your image could be potentially two times bigger than it needs to be and this is not something that we're comfortable with loading online in sites.

But, in light of the fact we are playing with color, there are some challenges here. Are there any brand managers in here? Marketing managers? Yeah? No? People who work on retail sites? Yeah? A few? Okay. I mention this simply because with some of the newer devices coming out, we're also dealing with since we are dealing with color, we're we're moving essentially some color from the images. Now, for the most part, we can't really pick it up, but there are some challenges and one of the challenges is the following, wide color gamut. Some of these image formats and some of the screens we're using, in fact, can cover a wider range of colors, much wider than previous years.

Now, I was speaking to a an engineer, an imaging engineer a couple weeks ago and we were having this discussion about this and you can end up actually since we are compressing and doing chroma sampling, you can end up with a clothing item on a retail site and, you know, from three different sites, you can have the same clothing item with a slightly different hue. He's a runner, as well, and pulled up a Nike tank top. These are some of the challenges that we have to go through as people that work in the performance base because of the compression that we're employing.

Now, these are things that also, I believe, that designers should be able to sit on and decide what is best. You've heard of the challenges where the brand manager is around and they're having this big debate on the type of red they want to use. Now, imagine you have a particular product and it's out on the market and you load up on a site and someone's like, hey, the red is off. And, thus goes the battle. These are things that are very important, I believe. And they actually, again, are falling under the whole web performance umbrella because we are the ones doing the compression.

Now, with that being said, since we are still talking about images, we also have to deal with memory. Now, this is important. Because quite often enough, the memory is we can run out of memory on a device because of the sheer amount of images we are loading. I was speaking to Brian. Brian, was that you I spoke to earlier?

Brian:

Yeah.

Henri:

He had mentioned that he was loading up the Air B and B site. The designers and developers wanted the prompt experience so we're not going to load the background image. Also, what ends up happening is, like, again, the more images you have, the more taxing it is on the memory and there's some studies out there where companies, after having again some of these meetings amongst themselves with designers in the room, potentially marketing and certainly developers, they decided to go with less images online for potentially a bunch of reasons, for performance. This comes into play as well. I believe there is a site stat indicating that at retail or online retail, sites that had, like, best sort of like sell through had lesser images. So, this is something that you want to keep in mind and again, the memory is being taxed by the abundance of images.

How am I doing on time here? I think I did all right. Either way, now and that was the memory. We still have a lot of battery issues associated with the abundance of images, as well. In fact, in that same study that I mentioned where the CSS and JavaScript was sort of taxing on the memory, they actually talk about images and image formats, as well. In fact, they just plainly said the amount of energy used is proportional to the amount of size and images on the page. When makes these mock ups, that designs and UI and UX people do sort of together, these are things and a little bit of knowledge you could arm yourself with and you could have that potentially long meeting, sort of like dissecting everything that's being done. But this is all being done to provide the best user experience as possible. From the top, we want to have the quickest load possible so you want to optimize the critical rendering path. So, what does that mean? Having the least amount of southeast and JS that you need.

Beyond that, you still want to manage the entirety of those resources so that you don't have too many excesses that are being parsed for no reason. Following that, you have to also look at your font loading, sort of like, management, and see what is working best. Again, you may not need all of these weights, these font weights for a few lines, a few headings here and there. This is something you want to manage as well through some font subsetting. Thereafter, after you've sort of dealt with that, again, the images like, I could expand for hours, but images are more, more and more creating a bottleneck on several levels. Again, from the memory aspect, certainly. You also have mainly create I mean, I didn't even touch on responsive web design where quite often enough, image sizing is done improperly. I don't know what's going on, but my phone's spazzing out and it's making my watch spaz out even more, so apologies.

But, yeah. So, I was again, I was speaking to an engineer at a CVN and he talked about the biggest mistakes he sees are images and having them improperly sized. When they're improperly sized, you're using up a lot more battery than you need to. When they're improperly sized, you're using up a lot more memory than you need. We got into the whole fact that we do a lot of that chroma subsampling where we play around with the data so we can make the image size smaller. With that being said, with advancements in sort of like screen technology and whatnot, we have this wide color gamut where you want the best color fidelity as possible. You have to weigh this back and forth, what is most important? Are you I don't know. Nike and you have a brand new shoe on and you want to make sure every detail is shown, that's going to be the priority. Or, you want to make sure that the site loads as quickly as possible and you want to remove that image. So, either way

Yesterday, Cameron Moll did I say that correctly? Cameron Moll? He talked about how his company was able to achieve this 50/50 gender mix and whatnot. He said he heard it on a podcast, I believe. The person on the podcast just started to talk about it and things sort of changed along the way. Performances are really the same simply because you're on the design side doesn't mean that you can't talk about it. By bringing these things up, bringing in the developers and whoever else is a stakeholder in this and having these meetings, this is how you're going to be able to achieve some some improvements in your web performance.

Now, he had also mentioned sort of like not being able to fail and that's very important as well because I'll be honest, you're not going to nail web performance on the first try. That's guaranteed. You really have to sort of like play around, move things around, take your time, look at readings, measure, measure, measure and have a greater understanding of what's going on and with time, make some incremental changes and hopefully you'll see results like I did when I was training.

Now, again, you will fail, like when I went to Chicago and ran, you know, the marathon weekend, I blew a tire. And, I had pretty crappy race. My coach was there and said, dude, don't worry about it, these things happen. But it was a teachable moment and a teachable moment is what you should take back, as well. Take from it, as well, when you start to make some of your changes.

So, with that being said, hopefully when you take in all this information that I've shared, you could also eventually achieve some performance by design and I just want to say merci.

(Applause)

Una:

Thank you so much.

Henri:

I didn't know what time it was, so I hope I didn't go over time. Am I good?

Una:

We're just going to have a quick Q&A.

Henri:

Yeah, okay. We don't have to sit down.

Una:

We could just stand. How could we, as designers, advocate for performance first thinking?

Henri:

All you have to do is, you know, when it is live, load it on your phone. See how you feel. How it went. And quite often enough, that's the case. How many times have I heard a site going live and the CEO's daughter was like, dad, this is loading slow. He's in a slack channel screening. So, you basically just have to load it, see how things go. Look for the tale tell signs for images loading slowly or the screenshot I had where the content wasn't there, but everything else was. These are things you can easy pick up.

Una:

You showed us some chroma dev tools, do you have any other tools you use to test performance?

Henri:

Brian had mentioned web page test, which is a fantastic tool online. Very raw. Not the most awesome to look at. But he also mentioned one that he used called Speaker, which is done by a design and a developer working together, surprise, surprise. And, yeah, it's just it gives you a very readable chart, information, that you can actually take back and share with the team.

Una:

The last question's from Twitter, from Daniel, can you talk more about your placeholder skeleton holder technique for images?

Henri:

That's a good question. There's a recent blog post talking about that very topic. I think they're talking about having an SVG placeholder. I'm not a huge fan of it because I think we're potentially complicating things and adding a new asset just to bring another asset in. So, Daniel, come find me. I think it's an answer that is beyond a couple steps on stage but I'd love to discuss that more, so, like, deep more deeply.

Una:

Cool. There's a lot of different techniques, too.

Henri:

Again, too many and some aren't even that necessary.

Una:

Thank you so much.

Henri:

Thank you for having me.

(Applause)

 

Sketch Notes by Cindy Chang