Perceived performance

Yeah, okay. Matt was talking a lot about real performance enhancements, where we look at actual time. I'll talk a bit about perceived performance, how the user perceives performance when we are, where we can't do anything physical to enhance our performance. Yeah, my name is Rasmus, and I work with user experience and business development for a company called CropDark. Yeah, the perception of time to define what is time. Time can be approached from two angles. There is the actual time, a lot of what Matt just talked about. And then there is the perceived time, what he called speed index. I'll dig deeper into that. The actual time can be measured with a clock, and often is measured as TTI, or time to interact. That is the time until the user can actually do something on our website. The average, according to Alexa, they ranked the top 100 e-commerce sites, and their average in time to interact was 5.2 seconds. And, as Matt also said, 3 seconds. That's our limit. And only 14% of those 100 sites were actually doing a performance where the time to interact was below the 3 seconds. Okay. So, yeah, time is money. Firefox reduced their page load with 2.2 seconds, and they increased their download with 15%. That also says a lot about how important this is. And also, Matt was, within this performance budget, it can be really hard to define how a performance budget should be laid out. But there are some rule of thumbs that for the user to understand an action as an instant behavior, we have to go below 100 milliseconds. So that is, if our action is below that, the user will see it as an instant action, and they won't see the delay. Somewhere between a half second and one second. The user will experience it as an immediate action. They will see there is a wait, but it's okay. Just below that one second. And then there is the 10 seconds. If an operation takes more than 10 seconds, then it will be pretty difficult for us. To actually keep that user's attention. There isn't much we can do about it. It just takes a high from a neighbor, and they're gone. So any operation taking more than that, just forget about it. Do something else. Some studies even say that we are now at 8 seconds. Our attention span is becoming lower and lower. 8 seconds. That's around 8 seconds. So our attention span is now down to a goldfish. That's mostly due to we can do everything on our mobile. We'll just go to Facebook or Twitter, and then we're off. Yeah. When we're talking about performance, we also need to take care of where can we actually do something. Something that benefits. In 1800-something, this guy, Weber and Fechner, were making some psychological studies which described the changes that is needed for a human to perceive that change. And these rules can be added to weight, sound, distance, and time. This just notable difference. The studies said that a change in time, for instance, if it takes 5 seconds, we need to take 7 to 18% of that load time for the user to even perceive that change. So our rule of thumb is that if we can't make a performance improvement, we can't do anything. If we can't make a performance improvement that is 20% or better, then it ain't worth doing it. Because it probably won't have an effect because the user won't see it. You can also do that the other way around. If you're creating something that makes a performance hit, if it isn't more than 20%, it's probably okay. So an example, your site loads in 8 seconds. Which isn't much, as we just saw. You have to cut off 1.6 seconds of your load time before that improvement is even noticed by the user. And also, there is the other way around. Because there are also... It's... Your site loads in 5 seconds. And your competitors loads in 2 seconds. So according to this just notable difference, your site should load in 2.4 seconds to be competitive with your competitors' site load. And probably, if you were able to do that, you would have, right? Now, there is also this chasing the leader. And what we do here is... Everything else even. We can calculate our differences with this geometric middle value or mean. And the user, if we do this, they will experience a performance or a difference in performance. But it won't have an effect. When they're choosing this service. Yeah, as the example before. If we can go to 3.2 seconds and not 2.4 seconds. Then the user would choose our service regardless of the performance hit. Yeah, this... Ilja is working for Google. And he's also working on the W3C resource hints. And now we're going into my talk a bit more. Because it's not always enough to make optimizations on the actual load time. Which were the thing Matt was talking about. We should also consider their perceived performance. The perceived time... Is... Or differs from the actual time. And there are many factors that... That counts here. And an important thing to consider. Is... How the user's expectations are established. For example, Google is now saying that any page should load within a second. And that is becoming the new point where we're going to. Because as Google says it. It comes out to more and more people. And that becomes the standard at some point. And then also we can do something about how we are waiting. When we can't do anything about it. We can have active or passive wait. And as humans we would rather be active while waiting. Than passive. You probably know this when you're driving a car. And you're sitting in the queue. You would rather go another way around. Even though it takes the same time. Or even more. But sitting still. We don't like it. An example is... An airport in Houston. They were one of the best in terms of their cargo team. To unload baggage. It took eight minutes. Which... It's not much waiting time for baggage to come in. When you're off the plane. But... The airport was so small. So the passengers only had to walk for a minute. And then they were at the cargo band. And they stood there for seven minutes. And they got a lot of complaints about the time it took before the baggage came into the cargo belt. And they looked at it. And then they made a new walk path. So now people were walking. In six minutes. Instead of one. And they were waiting for the baggage to come in. In two minutes. And there were almost no complaints. The waiting time was precisely the same. But people were doing something while waiting. And we can take that into consideration also. When we're making websites. We can make it look like something is happening. Matt said something about it. The time to... The first bite. And the speed index. Yeah. If we are passive while we're waiting. We have a tendency to overestimate the wait time by 36%. That means a lot for the user experience. Yeah. Data syndicators. That is one way to make it seem like... Make it seem like something is happening. Not just telling the user something is happening. And they can work very well at some point. It shows the users that something is happening. But we have to consider when we're using which data syndicators. For example, if something is taking between one and five seconds. As I wrote there. We could use a spinner. Don't use a progress bar. Because that could make the action seem slower than it really is. Unless the action takes more than five seconds. Then we can start using progress bars. And should we make that action that takes more than ten seconds. And the user's attention span and so on. We could or we should use some kind of indicator. That actually tells the user where we are at. Are we at 10, 20, 50% in the... In the action. Are we using progress bars? Then there's some tips here. You've probably all seen those progress bars that spins. If it spins to the left. The user takes it in as it is going faster than it really is. And the perceived performance is reduced by up to 10%. It's the same thing. It's just a progress bar. That spins left. Instead of right. Or just going vertical. The pulsating progress bars that Apple has used. Also make the users think that the waiting time is less than it really is. So. Progress bars can have a positive effect on slow actions. And on less slow actions. Less slow action. We can use spinners. But. Yeah. Polar. I don't know if you know them. Polar created an app. Where. It's basically just pulse. Do you like me? Yes. No. And they had a lot of complaints in the beginning. About their performance. a lot of resources and a lot of time to optimize the performance of the app. And the performance was enhanced considerable. But when they launched the new app, the better performing app, they got even more complaints than they did before. And they found out the reason for that when they were loading in images, and there's a lot of images in that app, they were using spinners for each image load. And that just made the app seem slower than it really was. So that is a good example of how status indicators can have a negative effect on the user experience or the waiting time. So instead, they went to skeleton screens that we can use mostly on apps or websites where everything is within the grid. That is the easiest way. or the easiest places to use it. So start off by loading the grid, and as content is ready, show it to the user. You can see here the polar. They start off with white and just a gray box where the image should come. And then as the text comes, then it gets in there, and when the image is ready, then that gets in there. So they introduced that, and you see it more and more, and more and more. And the more Facebook is using it, when you open up the Facebook app, it's just gray bars, and then the content comes up. But for the user, it seems like something is happening, and the wait time seems less. For skeleton screens, a easy place to start is with images. To load in a background image, or a background color instead of an image, and then lazy load the image to be there when it's ready. I'll just pull up a little something. Yeah. There's a lot in here. Oh, up here. Yeah. What we're doing is we're using, I don't know, there is... There's a company, Aforge. They're making a lot of math plug-ins to the net framework. They're really good at math, and one of their plug-ins is called Aforge Imaging. We're using that to get the dominant color of an image. So when an editor is uploading images to the Umbraco library, or media library, then we go in, calculate the dominant color of the image, and just put it in as a property on the image node in Umbraco. And then when we load out the... Let's take out the image and show it on the screen, we just put a background color of the placeholder where the image is going. And then we're using lazy load to put on the image when it's ready. And that enhanced the experience a lot. I just took this in just to show you. This is the amount of code it takes to get the dominant color of an image when we're using Aforge Imaging plug-in. So it doesn't take a lot, but what we are doing here is there is a performance in the back office. You should really scale down the image before... Before doing this. So... Let me just... It's basically this. Now I've put a lot of time in before the lazy loading happens. But you can see the dominant colors of the images. It's just when we upload to the media library, it gets those, and then we're lazy loading it. So should we load those images, then we would probably have a waiting time of three seconds or more. But because we're doing as it is, the site is coming up pretty fast. And then when the images are ready, then it just goes in there. Yeah. That was a bit about background color placeholders. It's easy to use, and you should look into it. It's one of the most effective ways to enhance the user experience with regards to performance, or the perceived performance. Another thing, imaging. In the 1990s, progressive images was a big thing. Everybody was doing it, basically because we had slow connections at the point. For some reason, we went back to the baseline images, as our connection speeds got up. But now where images are such a big part of our website, we should consider going back to progressive image loading, because it just makes the UI seem as it comes in a bit, and the waiting time doesn't seem as large, because, yeah, the active versus passive waiting. And this is a way to create an active waiting time. In Umbra.co, we are in luck, because the new image processor in Umbra.co is doing this for us, because of, in the post-process, an image processor, they are making JPEGs into progressive loading, or rendering. Yeah. Waiting for fonts. We've all seen it. Matt also talked a bit about it. The web font performance. I don't have the exact same numbers as Matt did. I think we have different sources. But web fonts are really good because of typography. It can make a big difference in the design of a webpage. But an average website, uses up to 3.2 web fonts, different web fonts. And an average web font use takes up 123 kilobytes. That's 394 kilobytes on each request, or each page load. Probably doesn't seem like a lot, but when we compare to those huge images, the thing here is, we won't show anything to the user until those 394 kilobytes has been downloaded. Before that, we won't render anything. So, let's say we have those two web fonts, and we start, this is a network timeline by the way. First we load in the HTML file, and parallel to that we are fetching the CSS. In the CSS there is a reference to those web fonts. They won't start loading until both the HTML and CSS has been loaded, and the browser has applied the styles. So now it can start to download the font files. Now, font A has been loaded and it is rendered. So now we show all the text or content that is using font A. Luckily the browser isn't waiting for font A to load before it starts font B. But now, font B has also been fetched, and everything is now rendered. This happened in 700 milliseconds, I don't know if any sites are that fast, but here is just an example. The thing here is, what happens in that time from where the HTML is rendered, it is ready, the browser is ready. The only thing missing here is our fonts. What happens? And that is also what Matt talked about. The flash of honor. onStyleText versus the flash of invisible text. The flash of invisible text is the one at the bottom and the flash of onStyleText is the one at the top. The flash of onStyleText, it shows a fallback font and then when the font files are loaded then it shows the content with the new or the loaded font. The flash of invisible text shows nothing using the web font until the web font has been loaded and then it shows the content. Chrome, Firefox and Safari are all using the flash of invisible text but they have a delay of three seconds so if the font hasn't been loaded within three seconds they fall back to our screen. Secondary font. But remember the three seconds 40% were already off by then. So we should do something about it. And Safari even on mobile devices it doesn't, it uses flash of invisible text but it doesn't have a delay. That means if your CDN or wherever you are loading your font from, if it doesn't answer then people on an iPhone will never see the content of your website. That's not good. That's this buff, the single pointer failure. So what could we do about it? There is a font display where we can say how this should work but unfortunately not because it's only something that now, W3C is looking into and all the browsers has to, have to comment on it and say what they mean and how should have been implemented. So right now we can't use the font face option. But instead we can use JavaScript. We're using a plugin called font face observer which I think you should look into anyways. It's, it's easy and it does the job really nice. Um, and it imitates the flash of on style text. There are many other plugins but this is one that we use. Yeah. And then we can also look into optimistic actions that is making it look like that it works even though it's not. Or an action is performed and we just register the action and make it seem like we're doing something. And, but we, we aren't, that could be the network is down or something like that. It could be the user clicks the like button. We see it on Facebook, even though you're deep down in the Metro or something. If you click the like button, even without any neck net connection, it will just be blue. And then again, when we have network connection, it will just queue up. And when we're back online, and they will see if that action. So on actions that isn't necessarily going out to other users, if we can pretend that we are doing something, put it in a queue and then do something when we already again, yeah. And then we can try to anticipate what the user is going to do next. Um, we can start off. Usually it's in sign-up or an image upload or something like that, where we have to fill in some metadata. When the user has chosen the image and they start to fill out the metadata of that image, there's no need to wait for the user to click submit before uploading that image. We could just start, and then when they click submit, the image has already been uploaded, and the action will just go instant. Or do I know which page the user will visit next? Those of you who were here with Matt also checked, you saw these resource hints that you should dig into if you haven't already. There's the DNS prefetch. Not much used. It makes the DNS resolve, and that's basically it. Should you do something here, then use pre-connect, because that also makes the TCP handshake and the TLS negotiation. And you could use that widely. It just takes up of those 300 or 200 milliseconds that each DNS fetching is taking. And then there were the prefetch that Matt also talked about. You see it on... on stylesheets in JavaScript that you might need at a later point. The thing here is that it is low priority, so if the browser is downloading anything else, it'll just put it in a queue, and then when it's ready, it'll start. So it's not guaranteed that those are loaded in, because it is a low priority. Then there's the pre-render. Matt also talked about that. It renders an entire page in the background of the browser, and you might see it also on your mobile browsers. When you start typing in something in the address field, the suggestions, it will start loading the first page you have in the suggestion. So that gets pre-rendered for you. But we could also do that on our web pages. But only use it if you are almost certain the user will go there. For example, on a login page. You know where the user is going when he's done logging in, so just start pre-rendering it. And then the thing that Matt didn't say anything about is the pre-loading. It's supported in Chrome and Opera. And the thing here is it's almost the same thing as prefetch, except that you're telling the browser this is a stylesheet, or this is JavaScript, or this is an image. And based on those types, the browser will prioritize the assets for you. So, for example, a stylesheet comes in with high priority, whereas an image comes in with a low priority. So the browser will start prioritizing your prefetching. And also, as Matt said, it's pretty easy. It's just the link that you put in, the link meta tag that you put in the header. The last thing I'll just mention, as we are all, I think, making mobile first, or at least responsive, you've probably all seen it. Hitting a button on a mobile device, nothing happens for almost half a second, or at least 300 milliseconds. When you tap the button, nothing happens. And the reason for this is because it's waiting for a double tap. Because double tapping means zoom on a mobile browser. So it's waiting to see if the user is going to double tap. And so 300 milliseconds, that's a long time when we, at the beginning, saw that the ideal response to an action is less than 100 milliseconds. So the user seems to think it's instant. Luckily, Chrome and Firefox removed this. But all us guys on iPhones and so on, we still have this delay. A lot of website developers is doing this to get rid of this 300 millisecond delay. The reason why this meta tag is getting rid of the 300 millisecond delay is because we're disabling zoom, but not only double tap zoom. This also disables pinch zoom, which in many cases is a bad idea, because how often won't we like to see that image just a bit closer? So try not to, because it removes the pinch zoom. Instead, we can make it seem like something is happening. The 300 millisecond will still be there, but we're adding an active state via style sheet. Just by these three small lines here. Not every browser supports it though. So we could add a fourth one. But it's all back using JavaScript. And some mobile browsers have their own default styling to active state, so we have to remove that. So it just sets the default styles for the active state to transparent, basically. As I said, it won't remove the 300 millisecond delay, but the user will get the experience that something is happening instantly. And then, if you want to remove the 300 milliseconds totally, and you can live with a small kilobyte JavaScript, use the polyfill fast click. It doesn't take up much space. I can't remember the actual size. I think it's something like three kilobytes or something. Then another thing on mobile, the momentum scrolling. You've probably all seen it. When we try to scroll, it's kind of like it lags. It's just, ah, it doesn't feel good. Boom. And the scrolling, it's fluent again. All small things that you can try to... To implement, there's nothing huge in this, except maybe for the skeleton screens. But try to look into skeleton screens. Try to use it. Studies show that it is the most effective way of making it seem like something is happening. And then there is this HTTP2. Which I won't dig into, but start looking into it. It comes with IIS 10. So you need a Windows Server 2016. And only on TLS enabled side. So you need HTTPS for this to work, but not with an old SSL certificate. You need a TLS certificate for this to work. But are you on a Windows Server 2016? With TLS enabled HTTPS. Then you're done. You don't have to do anything. Then HTTP2 just works on those browsers that supports it. So, again, an easy fix to get a really good performance enhancement. And then as browsers start to support it fully, then we need to look at how we create our style sheets and our JavaScript. Because then we have no more domain sharding where we are having CDNs or just different domains for our style sheets and for our images and so on and so on. Because with HTTP2, a server request costs almost nothing. The DNS fetching or handshakes with the TLS and so on costs a lot more than a request to the server. With HTTP2. So also with our concatenating of style sheets and so on, that's history with HTTP2. The big files cost a lot more than have it split up in ten files with HTTP2 because it can make so many simultaneously requests. So start considering it on new sites. Maybe not on the old sites. Don't go home and, oh, we have to split it up. But on new sites, start thinking about it. When is the browser going to support this? Should we still use these sprite sheets or domain sharding or concatenating of files? Or should we make this future-proof and go with HTTP2? Yeah. Any questions? I know I've been speeding ahead. No, not yet. Not yet. I haven't seen a public release date for it yet. But sometime here in the fall, I think. Do we have the exact release date? Yeah, sure. I can put up both the entire PowerPoint and also I can put up the code for the dominant color calculation. Yeah. Oh, it's really not a problem anymore. Oh, the question was what are you doing with search engines when we're lazy loading content? It's really not a problem anymore. Unless you're going for some search engines. I'm not sure how, for example, MSN or the Microsoft Bing is handling it. But Google is handling it pretty darn good because they support JavaScript. And, and, yeah. And all the things we're lazy loading here is indexed by Google. On? Google AD? That, I think, is a question for Matt. I haven't looked into those. Okay. So, yeah. So try to ask Matt. It sounds like he's been digging it. How many ADKs do you have? How many? Oh, no. I haven't looked into the tooling there. Okay. Thank you. I'll just go ahead and start the video. Okay. So, yeah. So, yeah. So, yeah. Yeah. So, yeah. So, yeah. So, yeah. Yeah. Yeah. Yeah. So, yeah. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.