The Future of Front-End Performance - Sia Karamalegos
I'm, gonna talk to you about the, future of front-end performance I'm. Really. Excited to talk to you about this it's one of my favorite topics. And. Hopefully it's not boring for you so. My name is SIA caramel Legos as. As. Reg. Mentioned, I am, from New Orleans so, this is me at Mardi Gras with one of my friends and I'm a developer, but this picture is more interesting than the developer. Stuff but. Um I'm, also half Greek so like you know why is my name so long that's why. So. Does anyone know why elevators. Have mirrors, does. Anyone know, okay. Yeah, well I'll just answer for you, but. Um so, some people think it's so that you feel like it's bigger you, know because, it makes it less claustrophobic. But, what happened was a long time ago people really, frustrated, because it felt so slow like waiting for the elevators, and being inside the elevators, but. It's really expensive to install more elevators, or make them faster at least in the old days so. What they did is they put mirrors. In there and people, were suddenly distracted. Like by their own narcissism, as I say. So. So, you know you like the mirrors in there you're like oh and, you're like doing this stuff and you're not distracted by how long it takes so. I just want you to keep that little story, in the back of your head while we talk about performance. So. Why should you even care about, performance. Well. There's. Real world. Real. World advantages, to, making. Your website more performant, for users so for example at Pinterest. They. Increase their performance which, resulted, in a 15%. Increase in SEO, traffic and a 15% increase in conversion, rate to sign up. Aliexpress. Which is kind of like the kind, of like the Amazon in. Asia. They. Reduce their load time by 36%, and saw, a 10 and a half crease in ten. And a half percent increase, in orders. And a, twenty seven percent increase in conversion, for new customers so. That's like bottom, line impact this, is getting you more money to your company or your depending, on what role you are is a developer. Why. Else should you be, interested so now, for Google, search speed. Is now used as a ranking factor for. Mobile searches. So. If your web site is too slow you're, not gonna be ranked very high in search. So. Before we even talk about. What. Are the things you can do to make your website faster, let's, talk a little bit about measurement.
And Analysis, does. Anyone know what the Pareto principle is. It's. Also called the 80/20, rule, so, roughly it says roughly. 80%, of the effects come from 20% of the causes so. Does. That mean you should like optimize every, single thing. No. So. What you should do is you should measure, it and be. Lazy only, optimize your worst offenders. So. We don't don't like pre optimized or over optimized just. Just, do the worst offenders, and start from there like. This lazy puppy. So. Which metrics, matter, traditionally. We're always concerned about like load time but. When you think about load time it's, not necessarily. Like if you have you ever opened dev tools and run. Run. It with screenshots, the record, with screenshots sometimes, when, it says onload is not necessarily, when, the page is visually, relevant to the user so there's this other metric called speed index, I'm. Gonna go into these in a little bit more detail. In a second, time. To interactive, so, not just the load but, when can I start using the page and, then. Jank and responsiveness, which is actually quite it's, related to time, to are interactive as well so when you think about you're on a page it's loading you're trying to scroll but it's it's like not working, properly or you're clicking in an input and it's not working correctly. Let's. Look at these in detail. So. Speed index measures how quickly the, page contents. Are visually, populated, so, when is the page is visually significant, it's, expressed in milliseconds, a good, rule of thumb is about 1200. Millisecond, is a good page, load time or. Speed index load time it's. Dependent on the size of the viewport so. What the user can see or. What you might call like, above-the-fold content. So. It was very dependent on the user. Webpagetest.org. Is, my favorite tool to measure this and to actually do a lot of performance. Analysis. In addition. To dev tools, I, believe. Lighthouse, in chrome also has a speed index measurement, now using. No module cloud speed line. So. Time to interactive, let, me start this thing. This little video so you can see a visual representation, of, it oh. Wait. That's on the wrong thing. Two. Screens. It's. A time to interactive, you can see the left side is showed up quicker. But. You're clicking we're clicking nothing's. Happening, we're. Starting to get a little frustrated we're, starting to get more frustrated or, clicking clicking. And. Then finally. On. The right side it starts interacting so, that's really what time to interactive, is it's, that time. When the website, is finally, useful. So. I think my clicker, is confused. All. Right, and then jank or responsiveness, so, the, frame rate or frames per second is one measure of responsiveness. Modern. Devices refresh, your screens at about 60 frames per second so this top line isn't 60 it's 50 but it's close enough. So. If we convert that to an individual, frame and into an individual, frame we theoretically, have 16, milliseconds, to render but the browser actually needs some of that time so, when you're thinking about.
Rear. Enders you should tie it really only target SiC 10 milliseconds. For your, rear Enders or your frames. Anymore. And the human eye can can, actually see that visual jank which you can see here you, know like as my frames, per second goes lower I can we, can actually see, that, Jang keenest. So. How do we actually what, are, some ways we can measure these things. So. Synthetic testing, is like your traditional. I'm. Like come on you can do it. Let. Me try refreshing. Well, it's not working but it's not that important. So. This is a network tab in. Dev. Tools and so. We use the network tab and dev tools or we can you as webpagetest. And. This. Is what we do to optimize load, and speed NX, you can also optimize, specific. Other events. By. Clicking start before you do something and then stop at, the end of it so. That's these, these are some a synthetic. Testing way to measure. Load and speed index. And. Then when we think about responsiveness. We usually use the performance tab. So. I want you to just. Stop for a minute absorb. What's going on here and, I want you to think about how does this make you feel. Just. What's happening on this screen make you a little bit nervous, or uncomfortable. Do. You actually what's. Going on in the screen so, I feel like as developers. Sometimes. We, kind of avoid learning dev, tools to. Our. Most potential, because, we have other things to do, so. If you take one thing from this presentation, I want. You to, go home and, really. Focus, on learning more about how to use dev tools effectively because. It, makes your job as a developer, your developer. Easier it's like I said you only want to optimize the worst offenders so, you don't know what those worst offenders are until you know how to effectively use your measurement tools. So. That was synthetic, testing but there's a way to do real, user monitoring, or rum this, is a less fun room. There's. These cool api's, you can use there's the navigation. Timing API and, the resource timing API and. Those. Will automatically, do some measurements, for you I'm really excited, about the user timing, API also. Don't. Worry about trying to copy down like, I don't expect you to copy down that whole URL right now I will, share the slides with you and also all, the, links to all these resources and additional resources so, that you can learn more afterwards. But. The user timing, API is really cool so for example say you have a. Blog. Post or a blog, application. And. In. Your head or you're like okay what's the most critical, thing, for load. On this page like when will user be happy maybe it's when the. Heading, shows up like the heading for the blog post so, you can actually use the user timing, API to put, in a manual, a, manual. Flag of when that, heading. Has rendered so, you can actually get like really accurate, timing on specific, things I wouldn't, overuse this but, it's. Really cool because you can get like actual real, user monitoring you can send it to. Like. Google tag manager or. Whatever so that you can get the real timings from your real customers. Or users. All. Right. So, the other thing we should do and there's, kind of a moral, implication, of. Developing. For our, end user so, what kind of computers do you have like what kind of computers do you develop on, you. Probably have like a MacBook Pro or something like that. What. Kind of networks or what kind of phones are in your pocket I have a pixel - I know you might be have the iPhone 10, or X what does it call now I don't even know anymore. So. When. It comes down to, what people have in the real world we. Usually have devices and, networks that, are a lot faster than our end-users so. There can be a two to five X difference in the, fastest versus the slowest phones like. Just the processing, power of the phone itself. Seventy, four seventy five percent of worldwide Mobile clip connections, are on 2g or 3G I think, like forty five percent is just on 2g that's. A lot slower than most of us are used to but. It's not even that like say we're in a highly developed area for example my mom she, lives in rural Texas and so.
She, Can't get a high-speed, Internet connection directly, at her home she has to get like the mobile broadband. Thingy. And connect, via that so she's actually paying for her data. Bye-bye, bytes. And. Then like for example you're at a comprehensive, spotty Wi-Fi. This. Happens this is like real life stuff so. You still need to be concerned about speed and you need to use. You. Need to measure. And, analyze your website according to the speed of your users not the speed of what you usually have. So. There's some cool tools you can use, webpagetest.org. And you, can actually so look at your Google Analytics data for, your application. And try. To use. The same profile. You, can set up a profile, in webpagetest at work to kind of mirror those users like. For example. Google. Does a I. Think. It's actually webpagetest.org. / easy and it's, their default settings of what they do for their management of course that not, all of us have a Google, worldwide audience but, theirs is like a $200, Motorola. And, it's. A fast. Or slow 3G network, so. You can actually set up the profiles, to. Be a certain speed. And in region and, then. From. There you can also set up performance, budgets so. Say your. Website. Is you know on average, your users have this phone and, this network, and. You. Want to target maybe a five second load initially, and maybe a two second load on. On. Visiting. The page again so, you can set up a performance budget, from there so like for example there's is like a hundred and forty kilobytes one hundred and sunny kilobytes, I think, gzipped. And. Then. You can set up a performance budget, using webpack I think pre-pack would do this -. I. Think this thing fell asleep. So, now let's dive into performance, does. Anyone know what like the most bytes traveling. On the Internet are what, they're from what, it's from. Its. Images, so images account for 60% of the bytes on, average needed to load a page so. My talk is not mostly about images but I feel like because there's such a big chunk of the, volume on the internet I want. You to know a few things about images, I know this quote does not look legit because it just says Google, because. It's it's not like one of their generic, generic, web. Page Doc's and also in a. One. Of their tutorials like on Udacity, but. It is a legit. So. What's your image optimization toolbox. You, want to learn how to use the right image type for, your situation, for, example pings versus JPEGs, like for the most part JPEGs are smaller and you don't really you really shouldn't use pings unless you actually need like transparency, or something like that, you. Want to use the right size for, the, view of course and source, sets there, are web pack loaders that let you auto build these source sets. And. Then. Compressing. Images like, with a tool with imageoptim if you're doing it manually but, you can set up your bundler to do this for you as well there are some really cool tools so it's really not a lot of work in order to do, these optimizations. And they'll strip out like the image metadata but, also do. Compression. And you can, it. Comes with default settings but you can also if you're really concerned about. The. Images yourself you can put in custom, configurations, in order to do the, setup that you want for each image type, and. I provide some tools for how, you get started with those. So. What's our most expensive asset. Our. All assets, created equally, Oh. Javascript. Is our most important asset or the most. Expensive. Asset, some of you might have seen this addy Osmani, does a lot of talks. And articles. About, performance. This is one of my favorite lines I know it's a little bit small but I'll just explain it but, um say we have a hundred and seventy kilobytes of JavaScript, versus 170 kilobytes of an, image like a JPEG so.
Our Network transmission, time might be the same so in this situation it's, 3.4 seconds, this. Is I think they're actually doing that. The. Flow Network and. Slower. Phone also but. Then when we come to resource processing, it only takes maybe like 64, milliseconds, for that image to decode and then another 28, milliseconds. For rasterize, and paint. But. When we come to JavaScript, after. That after that bundle is delivered, to the browser we still have to do parse and compile so, in this situation it took like two about two seconds for parsing compile and, then, another one and a half seconds in execution, so. Javascript, is your most expensive, asset. So, if you're looking byte to byte, javascript. Is gonna be the, most expensive and the one you should probably worry about the most in terms of performance. So. In. Case you in case you just leave for the rest of the presentation. I'll tell you the TLDR now it's. Just ship, less code so. Less code is not is not only less load time but. Less parts compile and eval time, just. Less code so the rest of this presentation is mostly about less code of. Course your Holy Grail is to, prioritize. Only what's needed in view and this is also what some of the other speakers started talking about like. Above-the-fold, progressive. Rendering and we're gonna talk about this a little bit more and. Then you can lazy load the rest. It's. Funny when it goes on the big screen sometimes it doesn't look the same, so. People. Talk a lot about like server-side rendering so we're gonna talk a little bit about client versus server versus progressive, rendering so. This is an example of. Client-side. Rendering so. Maybe your, HTML. Arrives let's, see if my little highlighter thing will work oh it, does but. Where is it oh here it is so. Maybe this is when HTML, rise I just realized it's kind of small so I'm pointing at it but, then you're just you're just waiting there right like the user is waiting there like, actually see anything yet and finally the JavaScript, arrives and it's evaluated. And it's rendered so. You have this this wasted, time. That's. That that's that frustration, of the user just. Being frustrated, because it's taking so long to load they can't see anything nothing, is happening, so. That's annoying that's like your traditional or traditional, in, the old days it wasn't client-side rendered right everything was server-side, rendered but now we have you know our frameworks, and stuff and we're rendering on the front end. So. Now we. Switch to. Clients, there's server-side rendering, so. We moved up, we. Moved up the time of, when, HTML, arrives and the view is painted, but. Then it might still take a while for JavaScript, to arrive and, being parsing about and so then you have this, what. Paul Louis calls. This, uncanny, valley and, this was also that video earlier remember when you're like clicking and clicking you can see the things but they're just not working. So, it's this just time, of, frustration. For users when they see something that they expect it to be working and, so, that's annoying as well, so. Maybe instead of focusing, on client versus server-side rendering we should really focus. On progressive. Rendering and, this, is that idea that I, ship. My HTML but, then I only ship as much JavaScript, and, images that's. Immediately, needed for, the view that I can see at the moment the above-the-fold content and, then, you can lazy load, images. Or additional features after that and. Then even after that load additional routes. Depending. On what they're most likely to use oh. Yeah. I just worked again. So. How do we optimize time, to interactive, this is that that load time or time to interactive, well. Remember I want you to analyze, your loads and bundles don't, over optimize don't, make more work for yourself do. The things that have the most impact, only. Ship what's immediately needed so. Use code splitting, pre-caching. And lazy loading, so. Code splitting is when we have multiple. Bundles. That we can ship to the front end also we. Used to we. Sip, like one giant bundle but. Now with HTTP. 2 we can actually low we, can do a lot of concurrent, requests, for files so.
If We do multiple, smaller files they'll, actually load, faster and then we can parse. And compile them faster as well. Pre, caching and resource hints Patrick. Talked a lot about that earlier and then. Lazy loading, for example images that are further down the page or, future routes. Minification. I know it's like an obvious thing that most of us do but, it. Doesn't just, speed up your download of time it they've actually measured, it and it, also speeds up your parse and compile time so. Don't forget to minify and, then. Of course compress, compress, with gzip or even better broadly. And. Removing, unused code so. Tree shaking does everyone know what tree shaking is what, happens when you shake a tree, when, you shake a tree the leaves fall down the dead leaves fall down so, you want our dead code to fall down and not be in our bundles. So. There are ways you can do some of this automatically, but, then, there's things that you still need to keep in mind and. What's so awesome was, I checked Twitter right before I came on here, he. Was mani and like the same he had like a tweet exactly, about, one thing I'm about to tell you here's like. Finally. There's some code in the presentation. Because. I feel like it's I don't know why it's so important but a lot of people don't know this yet so that's why I'm doing it. So. Like for example lodash. If. You import, underscore, from low - what, are you importing the. Entire, low - library, but. You're probably not using the, whole low - library. Some. People think if you then do import curly, braket start I should have shown this is empty. From low - that, that's smaller but that also imports. The entire library of low - so, the ways to only import, that one function that you need is to, do import, is empty from low - slash, is empty, and then you can use it. Similarly. How many of you use moment, for like date/time management, on your phone and I don't. Worry I'd use it too. But. It's another one of those huge, libraries. Right and also the internationalization, stuff is like makes it even bigger there's, a way to make it slightly smaller, but, there's a newer. There. Is a newer, library. For date and time management called, date FNS that, is trying to be more functional like, lodash and so now, you can import only for example like add minutes, from date finis, slash add minutes we definitely look at that they, don't have quite, all the functionality, that moment has but. I've started. Using it and to, try to make my bundles, a lot smaller so this, is one. Aspect of tree-shaking that you kind of have to do yourself. And. There are some other tools for doing. It with web pack or, pre pack whatever bundler. You like. So. This is this is a topic I'm really excited about um. Jeremy. Wagner had a name for it and I forgot what the name is but, there's. A cost to unnecessarily. Transpiling, so. Most of us are most and most of our users are actually on modern browsers, but. We're still shipping like. Es5, code. So. Es5, code is, bigger. And slower. So. There's a way now you can you. Can actually ship multiple Brun bundles, to your front ends so if you do script type equals module, modern. Browsers were recognize that and and you can use es6 or, yes. 2015, plus code in there because. It fits a script that's type equal module it's most of the features that you're using in es6 will be in there like arrow functions and stuff like that. So. This. Is Phillip Phillip Watson who's another Google engineer he. Profiled. His blog, website or web application, and. When. He, you. Can see the is 2015. Plus bundle minified, is, less. Than half of, his. Es5 bundle and then, also the parts an eval time is. About half so. It's pretty awesome you can just cut, that time in half just. By providing a modern, bundle. For modern browsers and then the older browsers will just have to use the old version that's a little bit slower. When. Will we ever get rid of Internet. Explorer. Oh. And. A surge is gonna talk about modules, a lot in the next stop, but. As my friend Devin who's now an engineer at Netflix says most, of your time is spent using the app not waiting for it to load so. Don't, forget about the other performance, stuff. So. How can we optimize responsiveness.
Well. One of the big things is don't block the main thread, so. What are some ways you can do that avoiding, the more leaks because there's, garbage collection and composite execution, you. Can avoid long-running JavaScript, so, chunk it into smaller pieces and, you can use like requestanimationframe, requests. Idle callback to just kind of push things out of the main thread. And. Then use up-to-date frameworks, that if, you're using a framework that, prioritize, user input so like for example react, fiber starting, and react 16 I'm a react engineer so I apologize, I don't have anything against the other ones but. They. Are now starting. To prioritize, user inputs over rendering, so like if the user clicks, in the user input, they'll pause rendering, so, that we can manage that and users are still happy. And. Actually, I'll. Be honest a lot of this stuff I I didn't, mention, service. Workers and stuff like that yet but, um I do. Think a lot of tools now are, starting. To bring this inside. The tool because. It's, not easy setting, up some of these things and. Most. Of us we aren't. Going to be like a performance engineer right we just want to ship code so, that our clients are happy and so. A lot of the tools like for example create react app or GATT, CA sorry I don't know the equivalents and view and angular, and the others but, they're starting to bring some of these things than, setting them up for you in the tools themselves. So. There's a way to cheat a lot of this. So. I have another story for you does anyone know about this story about houston's baggage, claim, complaints. No. Ok good yeah. So. Houston Intercontinental, Airport they. They. Used to have it like a ton of complaints, about baggage. Like you know sitting there and waiting for baggage. They. Spend a lot of time trying, to get up to industry-standard which i think it's like something like eight minutes like, waiting for your time we're, waiting for your baggage to come out but. After. They did that what do you think happened to the complaints, do they go down. They. Did not go down so. The time went down but the complaints did not go down, and. So what they did is they observed, and they're like you know what makes us different from other airports, and they, looked and they observe and what they realized was that the. Walk time from, the gate to baggage claim was. Exceptionally, short in Houston. So. How do you think they solve this baggage claim complaint problem. So. So. Maybe like you know this is the gate. This. Is baggage thing right, so. What, they did was. So. I'm at the gate. So. They did this right anything are. People happy you, think, they would not be happy the. Complaints went away. All. Right you know they went down they probably don't go away because right like no airport, baggage experience, is that fun. So. Yeah so. Um I, can't. See my notes anymore but this mit researcher, basically, said. The. Psychology. Of the wait is more important than the wait time itself. So. Like unoccupied. Time, that if you're just sitting there waiting for your bags it's like way more painful than. Occupy, the time. So. Are, you better off making the site load faster, or ensuring. That users complete their tasks. Is. This the studies a little bit a little bit Kristine prophetic she. Worked. On this study about download time and they. Basically took like the top ten websites in, 2006. And they. Asked users like which one was faster right and, the users were very consistent they're like these these, websites, were really fast, and these websites were really slow and. When. They measured like the actual, load times, it. Was almost the opposite like the top the. Top. Website that was fast, was actually the slowest load time and one of the slowest websites, or the fastest, websites, for actual, like real load was. Actually. Ranked. Lowest by users in terms of like slow or speed. So. When it comes down at the end of the day performance, is very important, but. I would still say that user experience and, your. Users being able to get the job done that they're trying to do is still, going to trump. Performance. Itself, so. Don't don't, forget about the, core of your application, and what you're trying to do help. Your users get done what they're trying to get done and. The. Perception, of performance, will be even higher than. Probably. Your relative actual performance, so. Thank. You my. Slide. So. If you go to because. My name is really long ago hub so I made this bitly link bit. Lycia speaks, si a I'll. Put it in slack also and tweet it but, that's where it's actually all my. Presentations. But you'll find a link and it's like a gist and it has the like.
All Of these kind of resource links, that how to know more or just sources but, also the. Slides themselves, let. Me ask a question if I may yes so all this talk about bundling. Yes. Want. To get excited about it when, should I stop but like oh yeah. Yeah that's, a good question. So, I would. Say. Don't. Stop bundling, because in for. Me like. Using I'm. Not opinionated, I use webpack but for me bundling. Actually, makes my development, experience, better i, we. We bundled because we like using modules we. Like organizing, our code and having like you know separate files for these things so that we can like mentally, organize them and so to me yes. You still bundle but, just, thinking about how you bundle better for performance, as well like the setup of it not just, how. You use it but, yeah, don't stop bundling at least yet, thank. You.
2018-10-12 06:20
