Sessions is temporarily moving to YouTube, check out all our new videos here.

The Five Stages of JavaScript Performance Grief

Simon Hearne speaking at JS Monthly London in May, 2017
1064Views
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

We use JavaScript for everything, but how well do we understand how it performs? There are benchmarks out there for different frameworks, JS engines and libraries that give us an idea. But it becomes much harder to measure performance once we start writing our own code, extending libraries and delivering code to real people. Let’s have a look at the effect that JS has on user experiences, why it is such a critical issue, and some quick wins to improve the experience for those weird real people.


Transcript


- So this is a JavaScript conference, or meetup. How many of you are paid to write JavaScript? Anyone not put their hand up? Anyone willing to admit they didn't put their hand up? You pay people to write JavaScript for you, that's different. Cool, and hands up if you test the performance of your JavaScript? Ooh, about 50%. Hands up if you use real mobile devices to test the performance of you JavaScript? Andy hand down. So maybe, 10%? Good for you. For the rest of you, this is going to be enlightening. So first off, let's talk about speed. Who reckons they know how to test the speed of their web app? Not you, front row man. Awesome, this is gonna be a great presentation. So there's this magical thing called real user performance. Anyone heard of the Navigation Timing API? James has, oh wow. So, oh I have an image of a hero. Wait a minute, wait a minute, there, Navigation Timing API! We'll get back to that. So, who here has used WebPageTest before? Cool, so maybe about 5%. So webpagetest.org is a free resource to test the performance of your web applications, and you can write whole scripts to log in, interact with the page, and measure the performance of that web app using real devices, including mobile phones, but only from Dulles, and Dulles is probably quite far away from the majority of your customers, or the people who use your web app. But it gives you charts, lots of charts, waterfall charts, and this one is for a data visualisation conference I was interested in going to see, and when I clicked on it, it took ages to load on my brand new Galaxy S8, aaahh! So I tested it on WebPageTest, and WebPageTest gives you some metrics to look at, like DOM interactive, which makes you feel like you can interact with a web page, but it just means that JavaScript can interact with your web page. It gives you DOM content loaded, so I've parsed the CSS and I've started to download the resources that are required to render this page. DOM complete. All my JavaScript, CSS, image are loaded. And then page loaded, which in this page is about the same, so that's your window.onload event. Your document.ready is here, so that purple area is all the code that's executing in document.ready, things that are manipulating the DOM before you've exposed it to the user. So, they also give a best guess at FirstPaint. It depends on the browser, Chrome is actually quite good at guessing when you've first started to paint content to a customer. Anyone used anything like FirstPaint before to measure how quickly you're rendering your app to someone? Awesome. Question is, from this chart, can you tell when the web page was usable to the person trying to load this app? Page Loaded. So Page Loaded, so you've got your CPU bar here, so this is all the things that you have in your CPU, yellow is JavaScript execution, your main thread. Nothing's really happening between in this period here. Page Loaded is when your third-party content should start to come in. So you'd expect your page to be loaded before Page Loaded, of course. - [Man] When do you find it's usable? - Good question! It's really hard to tell from like a synthetic point of view, which this is. You get your film strip as well, and I've cleverly aligned this to the time scale, and you can see that your first pane is when the loading spinner arrived. Thank God for single page applications. And at this point, 23 seconds in, the first image renders and your web font loads so you can see text, isn't that amazing? So, this waterfall chart, who uses waterfall charts on a regular basis? Digging the wrong hole. All right, let's move on. You should use these things, because it gives you magical insight into your applications, like this purple area here, that shows you when your JavaScript, that particular JavaScript asset is hogging the main thread, and that becomes important. This here, WebPageTest, gives you an indication of when the page is actually interactive. So if someone tried to click on a button or tried to scroll, it would respond. Green, red, it's not gonna respond within a reasonable period of time. So we spend a lot of time writing our JavaScript applications to be functional, but we don't spend much time working out how much time is in the green and how much time is in the red. This purple area here as well, you can see it expand to like six seconds when you rewrite every DOM element on the page, which I'm sure we've all done at some point, 'cause we had to because we were working with a legacy code base and we had to use JavaScript to rewrite what the server was giving us. The Navigation Timing API is our hero because it lets us collect the information, those kind of metrics we spoke about earlier from every browser that loads your web app. How cool is that? And what it tells us, if you look at any website in the world, basically, is that iPhone experiences are faster than Android. Is this surprising to anyone? Oh quick, server, who here uses an Android device as their daily driver? Are all geeks, and iPhone users? Okay, we're mostly geeks, sorry iPhone users. The problem, can anyone guess why iPhone user experiences tend to be faster than Android? Oh yes, single core performance. You can get a gold star. Yeah? Device fragmentation. 'Cause you've got like 10-quid Android phones that still have a web browser, even though they should just cut the web browser 'cause it's basically useless. If you look at the top 10 devices, this is a client that sells lots of things online, the iPhone devices, in aggregate, because it's very hard to tell whether it's version six or a 6S, kind of the mode is around three seconds, so the peak of that distribution is a reasonable experience, three seconds for a page load. You get to the Galaxy S7, and I did this before the S8 came out, and you've got a slower experience, twice as slow, so six seconds. And then you've got the S6, which is still a reasonable smartphone, you know it's got an eight-core 2.3 gigahertz processor, which would have been great on your desktop a couple of years ago. And all the way down to the J5 and A3, which are still being sold today as kind of budget smartphones. When I say budget, they're not like an Amazon $50 job, they're still 200 quid for the device, but the experience for the users loading this website, is much broader, and generally slower. So do you care about that? - [Man] Yes. - Yes, thank you! Wooh, enthusiasm! Distributions of engagement. So this is like pages per session, how engaged someone is with this website. With the iPhone, peaks at three seconds, but iPhone users are impatient, right? They just want to get back to Snapchat and Flickr, and what else do iPhone users use, I don't know. Android users, sorry? - [Man] Apple News. - Apple News, oh that a great app. Whereas Android users actually spend more time on the site for the kind of peak in the distribution. We're more patient, loving, giving people. Even though the distribution has peaked around 10 seconds for an average page load time. It's hard to imagine sitting there waiting 10 seconds for a page to load. And that's the difficulty with these metrics. So Page Loaded, can be quite a long way after the page starts to render. So we're working out ways to make that better. So this is fragmentation, right. In 2015, I don't have metrics from more recent than this, there were 25,000 unique Android devices. So this is one, this is two, and I could go on for at least three more. But there's 25,000, 'cause Android is awesome and open source, so people can use it for free. The Play Store's a bit different. Apple is lazy. They only release about two phones a year, which makes it really easy to test on iPhones, so we tend to test a lot on iPhones. I can't afford to fill the rest of this chart out, it gets expensive. And I was thinking about this when I sat with my three-year-old son watching Peppa Pig. Anyone have a toddler-aged child? So none of you have experience of Peppa Pig, or do you watch it for fun? It's a mind-numbing toddler, I don't know, I'd call it a babysitter, because it's so good at engaging toddlers. It's horrible because it beats up on the dad a lot. But one of the episodes I was sat there with my son thinking this is going through the five stages of grief. And somehow I thought I could bring that into the next talk I did, so we've got some kind of horrible mashup of kind of concepts. Denial, bargaining, anger, depression, and acceptance, and I'm gonna fit JavaScript performance into these five stages. Are you excited to see how it works? I am. All right, denial. We don't have much smartphone traffic for our JavaScript application. Anyone said that lately? Yeah, is it because people with smartphones aren't trying to use the application, or because your metrics are lying? This is three major UK retailers, and the red area is the amount of smartphone traffic they have. Which do you reckon is the fastest? - [Man] Middle one. - The middle one! You get a gold star too. So this is the median page load time, or DOM complete, so that's the earliest point a page can start to render. 60% of this retailer's traffic is smartphone, and their median page load time is 1.8 seconds, compared to, oh that horrible one over there. It's actually one of my favourite customers because they make bicycles. But it leads us to the conclusion that sites with faster mobile experiences have more mobile traffic. And it's really hard to pin down, because your analytics will lie to you, in that if someone has a poor experience, they'll be a bounce once, but they won't come back. So the numbers will be like one page view. Whereas if someone has a good experience, they're more likely to consume more pages on that first session, and then come back again. So for an application that isn't kind of locking you in, so a Facebook or a Twitter, something where you are trying to capture new customers, this can have a massive impact. So the speed of your JavaScript execution can affect the success of your business. This is big stuff. We don't have much Android traffic. Anyone said that lately? Someone say yes, someone say yes... Yes! Two gold stars. I've picked a really generous time period here, so this is three months ending December 2016, which is two and a half months after the iPhone 7 was launched. So you think Apple's market share would be about at the peak. 50% of devices sold in the UK were Android, and the web traffic is kinda like 46%, 'cause there are low-end Android devices that are just sold for people who need a phone and don't use the web. But around 50/50 is your iPhone to Android traffic split. If your application is seeing different stats, it's not because the customers don't want to come to it, it's because you're giving them a poor experience. Anyone willing to shout out their iPhone Android traffic split? Bleddyn? - [Bleddyn] I'll find out. - Yes, awesome! You can have a gold star if you tell me before the end of the talk. - [Man] What's other? - Sorry? - [Man] What's other, 0.1%? - Um, other you've got Blackberry, iOS, Windows, yeah you got the Firefox phone, for example, let me think, the Green Phone ties in, - [Man] Amazon phone. - Yeah, the unsuccessful ones, basically. - [Man] There was Nokia. - Yeah, well Nokia, and maybe they were Microsoft, and now they're Android, so you know, they might come back. And this is a great stat from DoubleClick, which I'll breeze through, but about half of clicks on ads from mobile phones where the resulting web page took more than three seconds to load, ended up in that page not being loaded. So, this is a weird study by DoubleClick and Google, because they compared DoubleClick data with Google Analytics data to prove that you're spending too much money on DoubleClick. 'Cause if your website takes more than three seconds to load, half of your ad click cost is just going down the pan. 'Cause people never appear. And this isn't like a bounce in your analytics, this is a something in an analytics void, something poetic, but this is traffic that you never see apart from in your outgoing marketing spend, which is crazy. And DoubleClick presented that data and published it, which means they care a lot about performance, right, which is good. So three seconds on this chart, that animation takes exactly three seconds, thank you very much. So, okay, Android users may expect a slightly slower experience because everything's a little bit slower, but only iPhone users are within that three-second magic period for this retailer, which is crazy. Why is there such a disparity, and how much money are they losing, how much customer satisfaction are they losing to their ridiculously poorly performing mobile website? Well, we can find out, 'cause we'd say, "What's your conversion rate on Android," and they'll say, "Ooh, 0.01%, on iPhone, 10%". In general, it should be about the same, Android and iOS conversion rate, 'cause, you know, people who can spend 800 pound on an Android phone still want to buy stuff. It's crazy isn't it? So, Android and iPhone should be equal in general. If they're not, then there's something wrong. And I think the most important thing here is question assumptions about your users, we have a lot of assumptions that someone with an iPhone 7 is more likely to spend money than someone with a Nexus 4, for example. I'm not gonna pick on Andy again, but Andy's daily driver is a Nexus 4. It's a four and a bit year old phone, still limping along. Bet you someone who might buy things on Amazon, or from a retailer website, you're not gonna not buy something just 'cause you haven't bought an iPhone 7 or an iPhone 8, soon. All right, bargaining. Android devices are getting faster. So, even though there's a disparity between the experience we're giving our iPhone users and our Android users, it doesn't matter because we get shiny new Android phones every couple of minutes out of China, Hong Kong, Taiwan. Two years I waited to upgrade this smashed old phone. 15% is the increase I get in my JavaScript benchmarks. Sad isn't it? Especially when the iPhone 7 is already three times