WEBVTT 1 00:00:05.879 --> 00:00:09.519 Well, hello folks, and welcome back. It's a bright, beautiful day 2 00:00:09.640 --> 00:00:13.679 and even more bright sooe and beautiful so because of Dan Shapiir, who's going 3 00:00:13.759 --> 00:00:17.800 to be telling us a little bit about Oh gosh, we've got six acronyms 4 00:00:17.800 --> 00:00:21.359 in a row here, Dan, what's what's our topic in summary? Yeah, 5 00:00:21.440 --> 00:00:25.600 I called it the web performance alphabet soup. Don't worry. I'll get 6 00:00:25.679 --> 00:00:30.039 into all the various acronyms during the show. But yeah, stuff like FCP 7 00:00:30.320 --> 00:00:34.920 and TTFB and and etc. Whatnot. All right, for those of you 8 00:00:35.039 --> 00:00:38.119 following along at home, those are all letters in the alphabet, all right. 9 00:00:38.200 --> 00:00:42.039 Also on the show, we've got Amy Knight Hello. Oh my gosh. 10 00:00:42.159 --> 00:00:47.320 Yeah, so don't have primnavirus, but have something so Hello from Nashville. 11 00:00:47.880 --> 00:00:52.039 Don't listen too closely you might catch it. And also Steve Edwards Hello, 12 00:00:52.119 --> 00:00:57.119 Hello from sunny Portland. And with that, this is JavaScript jemmer By 13 00:01:00.119 --> 00:01:03.240 start. Hey, folks, this is Charles Maxwell. I've been talking to 14 00:01:03.280 --> 00:01:07.599 ahole bunch of people that want to update the resume and find a better job, 15 00:01:07.079 --> 00:01:10.840 and I figure, well, why not just share my resume? So 16 00:01:10.920 --> 00:01:15.519 you if you go to topendevs dot com slash resume, enter your name and 17 00:01:15.560 --> 00:01:19.480 email address. Then you'll get a copy of the resume that I use that 18 00:01:19.519 --> 00:01:23.400 I've used through freelancing through most of my career, as I've kind of refined 19 00:01:23.400 --> 00:01:26.959 it and tweaked it to get me the jobs that I want. Like I 20 00:01:27.000 --> 00:01:30.799 said, topendevs dot com slash resume. We'll get you that, and you 21 00:01:30.840 --> 00:01:34.799 can just kind of use the formatting. It comes in word and pages formats 22 00:01:34.840 --> 00:01:38.239 and you can just fill it in from there. All right, Dan, 23 00:01:38.280 --> 00:01:44.519 I think that means you're on. Yeah, I guess so. So today 24 00:01:44.560 --> 00:01:47.799 we're going to talk about a topic that's really near and dear to my heart, 25 00:01:47.840 --> 00:01:52.680 which is web performance and a whole bunch of acronyms and metrics and measurements 26 00:01:52.680 --> 00:01:56.200 that are associated with it. As some of our listeners may recall, my 27 00:01:56.319 --> 00:02:00.000 day job is a performance declely at Wicks, where I deal with the performance 28 00:02:00.040 --> 00:02:05.280 of millions of websites hosted on the WIGS platform. Literally billions of websites, 29 00:02:05.319 --> 00:02:08.280 even more hundreds of millions, I don't know. Anyway, this means that 30 00:02:08.360 --> 00:02:13.879 I'm constantly involved with how to best monitor and optimize performance on the web. 31 00:02:14.039 --> 00:02:17.599 That's like what I do day in day out and today I wanted to talk 32 00:02:17.639 --> 00:02:24.000 about performance monitoring, specifically about the alphabet soup, which is web performance measurements 33 00:02:24.000 --> 00:02:28.319 and metrics. I mean we mentioned a few, I'll mention them again. 34 00:02:28.759 --> 00:02:34.680 I mean metrics such as TTFB, FCP, LCP, TTI, TBT, 35 00:02:35.400 --> 00:02:39.439 and et cetera. Lots and lots and lots of acronyms. Now when one 36 00:02:39.439 --> 00:02:46.520 algorithm do you have TTFN for now? From here? Yeah? Wtf? 37 00:02:46.599 --> 00:02:52.520 I guess as well. Anyway, Yeah, I got to say, like 38 00:02:52.800 --> 00:02:58.039 maybe start us off, so I know that not everybody knows about like the 39 00:02:58.159 --> 00:03:01.120 changes from light how the six five? Would that be a good starting point 40 00:03:01.159 --> 00:03:06.319 to kind of like frame our conversation. I actually wanted to start a little 41 00:03:06.360 --> 00:03:10.439 bit back in front of that because I really wanted to talk about what performance 42 00:03:10.479 --> 00:03:15.960 measurement really is and why it's important because we get to a specific measurement tool, 43 00:03:16.000 --> 00:03:20.000 which is Google Lighthouse. But yeah, once we get to there, 44 00:03:20.280 --> 00:03:24.280 that's definitely an interesting topic of conversation. So I found that, like I 45 00:03:24.280 --> 00:03:30.240 said, that many web developers are actually not familiar with the various performance metrics, 46 00:03:30.719 --> 00:03:35.319 are confused by them. They're not sure what metrics, what the metrics 47 00:03:35.360 --> 00:03:38.879 mean, which metrics are the most relevant for the particular use case. In 48 00:03:38.879 --> 00:03:43.520 fact, it's even worse than that. I have a talk that they give 49 00:03:43.599 --> 00:03:47.439 which is titled my website is slow Now what, which is essentially a laundry 50 00:03:47.520 --> 00:03:52.319 list of action items that you can take to improve the performance of a website 51 00:03:52.439 --> 00:03:57.759 or a web ap And essentially the first item on this list is to measure 52 00:03:57.800 --> 00:04:05.360 and monitor. And you'd be surprised by how many web developers or companies or 53 00:04:05.639 --> 00:04:13.159 teams or whatever neglect to measure and monitors performance at all of the websites that 54 00:04:13.199 --> 00:04:15.680 they build, let alone do it on a regular basis. So you know, 55 00:04:15.720 --> 00:04:20.439 we're going to be talking about all these metrics and measurements, but the 56 00:04:20.480 --> 00:04:26.519 most important thing that you actually do it, regardless of which ones you ultimately 57 00:04:27.160 --> 00:04:30.800 choose and which tools you ultimately use. There's a quote that's attributed to a 58 00:04:30.839 --> 00:04:35.399 well known management consultant by the name of Peter Drucker, which I actually like, 59 00:04:35.879 --> 00:04:39.879 which is, if you can't measure it, you can't improve it. 60 00:04:40.360 --> 00:04:45.600 And I definitely think that measuring in monitoring performance is a prerequisite for being able 61 00:04:45.680 --> 00:04:49.800 to actually improve it. Otherwise there's a very good chance that you'll waste time 62 00:04:49.879 --> 00:04:57.519 and effort on changes that provide very little benefit, and you'll totally neglect significant 63 00:04:57.600 --> 00:05:02.120 possible gains. So folks, please please please measure the performance of the websites 64 00:05:02.120 --> 00:05:06.040 that you build. So okay, So let's say I convinced you hopefully I 65 00:05:06.120 --> 00:05:11.920 have how do you actually do that? So it turns out that there are 66 00:05:11.959 --> 00:05:16.120 really two main ways to measure performance if I put them in like in categories 67 00:05:16.199 --> 00:05:21.240 or buckets. One is known as synthetic monitoring, and the other one is 68 00:05:21.279 --> 00:05:26.720 known as real user monitoring, which is also has an acronym, which is 69 00:05:26.879 --> 00:05:32.639 rum rum. Synthetic monitoring is about monitoring the performance of a website in a 70 00:05:32.800 --> 00:05:39.639 quote unquote laboratory environment. Often it involves some sort of automation tooling, but 71 00:05:39.720 --> 00:05:43.839 you can really just do it manually yourself. You create some sort of a 72 00:05:43.879 --> 00:05:50.399 synthetic environment that simulates typical user scenarios or maybe the worst case user scenarios, 73 00:05:50.399 --> 00:05:55.920 depends on you, and then you measure the performance of your website in those 74 00:05:56.000 --> 00:05:59.480 environments. So say, for example, you know that a lot of your 75 00:05:59.560 --> 00:06:04.600 users are using mobile devices that say Android, and they're coming from let's say, 76 00:06:04.639 --> 00:06:10.120 Okay networks, So you might use some Android device on a four G 77 00:06:10.279 --> 00:06:15.639 network or maybe a fast feed GIN network to try to measure the performance of 78 00:06:15.680 --> 00:06:19.839 your website. If you want to also account for the users who have lower 79 00:06:19.920 --> 00:06:26.759 end devices and networks, then maybe you'll buy some cheap low end mobile device 80 00:06:26.839 --> 00:06:31.000 for one hundred bucks and then connected via like three G and try to measure 81 00:06:31.000 --> 00:06:34.920 your performance on that, and you can also simulate those environments these days, 82 00:06:35.000 --> 00:06:41.439 then something like the Chrome debv tools actually lets you specify both a CPU slow 83 00:06:41.519 --> 00:06:45.639 down and the network slow down, so you can actually even do that on 84 00:06:45.720 --> 00:06:47.920 your computer. But you need to do that. So, like I said, 85 00:06:47.959 --> 00:06:53.600 there are many options and tools out there for synthetic monitoring, but Google 86 00:06:53.680 --> 00:06:57.360 Lighthouse has become something of a standard. In fact, you can run it 87 00:06:57.399 --> 00:07:00.600 directly from within the Chrome debv tools in the audit stab, so you literally 88 00:07:00.680 --> 00:07:04.759 have it built into your browser. You can also integrate it into your release 89 00:07:04.839 --> 00:07:11.319 process using something called Lighthouse CI, which is an open source project by Google. 90 00:07:11.399 --> 00:07:15.319 Lighthouse itself is an open source project, or you can use it online 91 00:07:15.439 --> 00:07:20.040 using sites like Google Paid speed Insights, which also has an API which you 92 00:07:20.079 --> 00:07:24.959 can connect to do it as part of your build process. As I said 93 00:07:25.040 --> 00:07:30.560 before, I highly recommend incorporating some sort of synthetic monitoring into your CI process 94 00:07:30.879 --> 00:07:36.439 if you're building any sort of a website that you hope will see some production 95 00:07:36.519 --> 00:07:43.079 traffic. This will enable you to specify stuff like performance budgets, which are 96 00:07:43.240 --> 00:07:47.279 just a fancy term for limits on various performance related aspects of your project, 97 00:07:47.560 --> 00:07:53.040 for example, the total size of the JavaScript that you download. So you 98 00:07:53.079 --> 00:07:58.639 can say I have a performance budget that my total JavaScript download doesn't exceed say 99 00:07:58.800 --> 00:08:03.519 one hundred kilobytes of or the wire and then if you actually exceed that, 100 00:08:03.040 --> 00:08:09.079 then your build brakes and you need to make hard decisions of whether to remove 101 00:08:09.360 --> 00:08:15.800 some functional JavaScript and maybe some functionality, or maybe to increase your limit, 102 00:08:16.319 --> 00:08:20.399 knowing that it will have an adverse impact on the performance that your users experience. 103 00:08:20.920 --> 00:08:26.439 Any questions about synthetic monitoring before I move to real user measurements, have 104 00:08:26.560 --> 00:08:31.279 you guys played around with various tools like that. I'm definitely familiar with the 105 00:08:31.319 --> 00:08:37.240 stuff that's in Chrome, and it is so refreshing when you try to tell 106 00:08:37.279 --> 00:08:41.080 someone, hey, your site's slow, and they're like, no, it's 107 00:08:41.120 --> 00:08:45.879 not, and you're like, well, even if I just simulate a poor 108 00:08:45.919 --> 00:08:52.399 connection, it's terrible. So that's kind of what I've used those tools for 109 00:08:52.039 --> 00:08:56.320 quite a bit, is letting other people know and like, no, really, 110 00:08:56.600 --> 00:08:58.600 like, here's how you can see for yourself that when you're not on 111 00:09:00.120 --> 00:09:05.679 Viber Ethernet, it doesn't work that well. And then Lighthouse is something I'm 112 00:09:05.960 --> 00:09:09.240 fairly familiar with, though I don't know when I've looked at it, I've 113 00:09:09.240 --> 00:09:13.159 often been confused about how to take full advantage of it. Okay, that's 114 00:09:13.399 --> 00:09:18.919 hopefully something I'll have enough time to cover this episode, or if not, 115 00:09:18.039 --> 00:09:22.960 we can do a continuation one. Okay, So in any event, like 116 00:09:22.000 --> 00:09:28.840 I said, the other bucket or method of performance monitoring is real user monitoring 117 00:09:28.879 --> 00:09:35.840 or RUM, which measures the performance of pages in real live sessions. So 118 00:09:35.320 --> 00:09:43.360 you add some code, you instrument your code so that it actually measures and 119 00:09:43.720 --> 00:09:50.200 reports back performance of actual user interactions, and you collect this information into some 120 00:09:50.279 --> 00:09:54.240 sort of a database that you can then run queries over. If you recall 121 00:09:54.360 --> 00:10:01.120 my previous JavaScript Jabber episode where I spoke about this stuff, that was episode 122 00:10:01.159 --> 00:10:05.879 three three four, I spoke about the Web Performance API. That's actually how 123 00:10:07.639 --> 00:10:11.159 most RUM measurement tool these days gather all the information that they do. You 124 00:10:11.200 --> 00:10:15.759 can do it yourself, or you can get a third party tool that will 125 00:10:15.759 --> 00:10:20.840 do it for you. Interestingly, Google is actually now also exposing rum data 126 00:10:20.879 --> 00:10:26.519 themselves, at least from sessions that run on Chrome. There's this thing called 127 00:10:26.600 --> 00:10:31.159 the Chrome User Experience Report or CROCS for short, which collects performance information from 128 00:10:31.240 --> 00:10:35.840 Chrome itself. When you install Chrome, you have this option to opt out 129 00:10:37.200 --> 00:10:41.360 of Google gathering information to improve their service. If you don't, then it 130 00:10:41.399 --> 00:10:46.840 turns out that they also gather anonymous performance information about all you know, your 131 00:10:46.960 --> 00:10:54.200 browsing, and they put this information into a database that's actually open to anybody 132 00:10:54.240 --> 00:10:58.240 to query. If you run big queries on it, it might cost you 133 00:10:58.279 --> 00:11:01.919 a bit, but you know, anybody can do it. There are actually 134 00:11:01.960 --> 00:11:05.840 even tools out there that give you free access to this information. So, 135 00:11:05.879 --> 00:11:13.240 for example, there's this free CRUs run service by a company called Edgemash which 136 00:11:13.279 --> 00:11:18.600 provides access to this information. Also in the Chrome search console itself, they 137 00:11:18.639 --> 00:11:24.120 actually now have performance information from there, and Google Page Speed Insights also shows 138 00:11:24.159 --> 00:11:31.080 you information that it retrieves from that from that database. So Google Page with 139 00:11:31.240 --> 00:11:37.759 insights now shows you both information from the synthetic tests that it performs and from 140 00:11:37.039 --> 00:11:43.000 real user sessions Now there's a caveat with that because first of all, crocs 141 00:11:45.399 --> 00:11:50.000 Google kind of updates it one month back, so you can do queries on 142 00:11:50.519 --> 00:11:54.840 data for your sessions, but if you make changes, you'll also you'll only 143 00:11:54.879 --> 00:12:00.240 see the impact of those changes like a month later. And likewise, guys, 144 00:12:00.720 --> 00:12:05.240 they only actually maintain information about sites that have or pages that have sufficient 145 00:12:05.279 --> 00:12:09.879 traffic. So if you're like putting up a new page, you might not 146 00:12:11.039 --> 00:12:16.679 actually get any data for that from crocs because it's just not getting enough traffic 147 00:12:16.759 --> 00:12:20.879 yet. Be that as it may, there are many many third party services 148 00:12:20.919 --> 00:12:26.080 out there that you can add to your site. Obviously they cost some money, 149 00:12:26.159 --> 00:12:28.240 but they can provide a lot of benefit. And I'm not going to 150 00:12:28.279 --> 00:12:31.399 advertise any one of them. You just you know, Google search for Web 151 00:12:31.440 --> 00:12:37.480 performance monitoring and many such services will come up. So that's that's RUM data. 152 00:12:37.639 --> 00:12:41.320 Have you actually have you guys actually used Rum in any of your project 153 00:12:41.399 --> 00:12:46.720 I can tell you that we at wigs use RUM like a ton. We 154 00:12:46.759 --> 00:12:50.159 are very data driven company, but we're kind of you know, huge. 155 00:12:50.679 --> 00:12:54.720 I'm wondering if you guys had the chance to use stuff like that, wean 156 00:12:54.799 --> 00:12:56.799 don't. Unfortunately, the use it where we are I want to though, 157 00:12:58.200 --> 00:13:01.039 Yeah, I highly recommend it because at the end of the day, if 158 00:13:01.159 --> 00:13:07.080 you're just doing synthetic measurements, then you're kind of guessing what your users are 159 00:13:07.120 --> 00:13:11.200 experiencing. Like I said to begin with, I would highly recommend for you 160 00:13:11.320 --> 00:13:16.279 to use something like crucks run to look at your current situation. Like I 161 00:13:16.320 --> 00:13:20.120 said, it's a month late, but it's better than nothing, and you 162 00:13:20.120 --> 00:13:24.480 can actually look at how your performance in the field changed over the past six 163 00:13:24.600 --> 00:13:28.519 months. I believe in that using that tool, so it's actually quite informative. 164 00:13:28.759 --> 00:13:31.879 I'm looking at it right now for my blog and I'm not sure what 165 00:13:31.960 --> 00:13:35.440 to make sense of all the numbers, but it's cool to see them, 166 00:13:35.519 --> 00:13:39.600 that's for sure. Well, they mostly show you I'll get to what that 167 00:13:39.720 --> 00:13:45.200 means, but they show you stuff like your TTFB and FCP and the DCL. 168 00:13:45.960 --> 00:13:48.320 I'll get to that hopefully in a bit. One thing that I see 169 00:13:48.360 --> 00:13:56.120 here is that it looks like there can be quite a variation in where things 170 00:13:56.120 --> 00:14:01.639 are falling in these different composite sidebar So I'm not sure what to call this 171 00:14:01.720 --> 00:14:03.440 type of graph. It's almost like a pie chart, but it's a bar 172 00:14:03.519 --> 00:14:07.039 graph instead. So it's like ten percent is on the left, fifty percent 173 00:14:07.159 --> 00:14:11.440 in the middle, thirty percents on the right. Yeah, Google kind of 174 00:14:11.480 --> 00:14:16.799 defined the scale somewhat arbitrarily of what it means to have a good, average, 175 00:14:18.120 --> 00:14:20.759 or bad performance. So, for example, they might say that for 176 00:14:22.240 --> 00:14:26.399 first content ful paint, which we'll get to FCP, having a value of 177 00:14:26.480 --> 00:14:30.840 under one second is good, having a value of one second up to two 178 00:14:30.879 --> 00:14:35.759 and a half seconds is average, and having a value that's over to and 179 00:14:35.799 --> 00:14:39.960 a half seconds is bad. So, since my site is a static site, 180 00:14:39.039 --> 00:14:43.759 and granted it's with some blog temperate template from a while back, so 181 00:14:43.080 --> 00:14:46.799 it probably isn't optimized, and I don't even I don't know if it's even 182 00:14:48.080 --> 00:14:50.720 No, it isn't menified. I'm pretty sure anyway. But I know when 183 00:14:50.720 --> 00:14:54.159 I've looked at Google Analytics, like half of my traffic is from India. 184 00:14:54.279 --> 00:15:01.480 Maybe it's somewhere in that range. It's quite a bit of by traffic because 185 00:15:01.480 --> 00:15:05.360 it's a technical blog, and I think that's why. And so I'm wondering 186 00:15:05.559 --> 00:15:07.679 if as I'm looking at this data, because historically month over month, my 187 00:15:07.759 --> 00:15:11.639 blog hasn't changed, you know, it's the same server. I add a 188 00:15:11.679 --> 00:15:16.519 couple more articles now and then, but seems like there's quite a bit of 189 00:15:16.600 --> 00:15:22.360 variation in you know, say in January, lots of people were in the 190 00:15:22.399 --> 00:15:26.480 fast segment, and there's also a fair number of people in the slow segment, 191 00:15:26.519 --> 00:15:30.399 but then in November not so many people in the fast segment. Almost 192 00:15:30.519 --> 00:15:35.639 everybody is in the average segment. If we go back to September, almost 193 00:15:35.720 --> 00:15:39.039 everyone's in the fast segment. And so I don't know how to make sense 194 00:15:39.039 --> 00:15:41.159 of this historical data. Do you have any light to shut on that? 195 00:15:41.639 --> 00:15:48.519 Well, crucks Run being free is somewhat limited in the amount of information that 196 00:15:48.559 --> 00:15:52.840 it shows. If you actually go to the Crux database itself, you can 197 00:15:52.879 --> 00:15:58.639 actually query, like, you know, geographical locations your visitors are coming from, 198 00:16:00.080 --> 00:16:03.120 and you can get more fine grained information. So it can definitely be 199 00:16:03.440 --> 00:16:07.200 the result of you know, fluctuations. It might be for example, if 200 00:16:07.200 --> 00:16:11.320 there's a holiday in India, for example, like you said, you've got 201 00:16:11.360 --> 00:16:17.360 a lot of visitors coming from there, then that can obviously impact your you 202 00:16:17.360 --> 00:16:21.159 know, the distribution of your traffic and consequently the performance that you see. 203 00:16:21.519 --> 00:16:26.039 So so yeah, just looking at the overall numbers is useful, but if 204 00:16:26.039 --> 00:16:30.120 you really want to dig in and make sense of them and turn some of 205 00:16:30.159 --> 00:16:36.679 them into actionable items, then you probably may need more information. For example, 206 00:16:36.759 --> 00:16:41.080 if if you know you're doing your blog is like out of the goodness 207 00:16:41.159 --> 00:16:44.639 of your heart, but if you actually make it into a business, for 208 00:16:44.720 --> 00:16:48.120 example, and you say, hey, I've got a lot of quote unquote 209 00:16:48.120 --> 00:16:52.200 customers coming from India, that maybe it makes sense for me to have either 210 00:16:52.240 --> 00:16:56.799 a server in India or use some sort of a CDN service that accelerates access 211 00:16:56.799 --> 00:17:00.600 from India so that they don't have to wait for the data to count, 212 00:17:00.639 --> 00:17:03.240 you know, for the request to go all the way to my server in 213 00:17:03.279 --> 00:17:08.519 the States and then come back to their computers in India. Maybe you'll want 214 00:17:08.599 --> 00:17:17.400 to replicate your server onto an Amazon cloud in India or something like that in 215 00:17:17.519 --> 00:17:22.319 order to provide them with faster access. But yeah, so in order to 216 00:17:22.359 --> 00:17:27.119 turn it into actionable items, you do need the appropriate information. When I 217 00:17:27.160 --> 00:17:30.920 think about the performance, you know how, when I try to analyze performance 218 00:17:30.920 --> 00:17:36.519 and what performance actually means, I like to use a model that's called the 219 00:17:36.640 --> 00:17:41.079 rail performance model, which is also created by Google. Google will actually feature 220 00:17:41.119 --> 00:17:45.799 quite a bit here. They're doing a lot of work related to web performance, 221 00:17:45.880 --> 00:17:48.680 and good on them for doing that. I think we're really lucky that 222 00:17:49.079 --> 00:17:56.079 the good of the web happens to at least currently align with the benefits to 223 00:17:56.160 --> 00:18:00.960 Google's business. So they have business interests in improving the web. Hopefully that 224 00:18:02.039 --> 00:18:07.119 this will continue in any event. They have this model which they proposed or 225 00:18:07.599 --> 00:18:12.480 created called RAIL, which stands for Response, Animation, idle, and load. 226 00:18:14.200 --> 00:18:19.200 So response deals with measuring how quickly a web page reacts when you interact 227 00:18:19.240 --> 00:18:22.720 with it. So like, if there's a button, you click on a 228 00:18:22.720 --> 00:18:29.440 button, how fast do you actually get some visual response to that click. 229 00:18:29.799 --> 00:18:34.480 Now, don't confuse response with responsiveness, which deals with how pages react to 230 00:18:34.519 --> 00:18:41.720 different display sizes. This is about just reacting to user interactions on the page. 231 00:18:41.960 --> 00:18:47.359 So having good performance means that when a user interacts with some element on 232 00:18:47.400 --> 00:18:51.480 the page, you want the page to respond to that interaction in under one 233 00:18:51.599 --> 00:18:57.319 hundred milliseconds. According to researchers done that gives your users your visitors the feeling 234 00:18:57.359 --> 00:19:02.759 that the response is kind of instantaneous. Now, it doesn't mean that the 235 00:19:02.839 --> 00:19:07.400 actual operation that they're looking for happened within that one hundred millisecond. You know, 236 00:19:07.519 --> 00:19:11.480 they might be doing some really complex operation that you need to send back 237 00:19:11.519 --> 00:19:18.680 to your back end and perform some lengthy computation or database look up or whatever. 238 00:19:18.039 --> 00:19:22.640 I'm talking about the fact that they need to see some visual indication that 239 00:19:22.720 --> 00:19:27.599 the system received their input and is reacting to it. It can be you 240 00:19:27.640 --> 00:19:33.079 know, even something like you know, popping up some sort of a spinner, 241 00:19:33.119 --> 00:19:36.279 if that's what you can do. But anyway, like I said, 242 00:19:36.279 --> 00:19:38.240 you want to do that within one hundred milliseconds. Now, to be able 243 00:19:38.279 --> 00:19:42.920 to do that within one hundred milliseconds, it means that the actual event handler 244 00:19:44.200 --> 00:19:49.880 should not take longer than fifty millisecond, and that any background operation that the 245 00:19:51.039 --> 00:19:57.640 browser is performing should be broken up into segments that are also not longer than 246 00:19:57.680 --> 00:20:03.279 fifty milliseconds. So if a user happens to click right at the beginning of 247 00:20:03.319 --> 00:20:07.359 such a segment, you have to wait fifty milliseconds for that segment to finish, 248 00:20:07.680 --> 00:20:11.839 and then another fifty milliseconds for the exact event handler to finish. All 249 00:20:11.880 --> 00:20:17.160 in all, you know, one hundred milliseconds or less, well preferably less. 250 00:20:17.519 --> 00:20:19.799 This kind of has to do with how browsers work. As you know, 251 00:20:21.200 --> 00:20:26.519 browsers are single threaded. So if the browser is busy handling some sort 252 00:20:26.519 --> 00:20:33.200 of a JavaScript task, it can't react to your clicks or intro or whatever, 253 00:20:33.480 --> 00:20:37.920 you know. Until that JavaScript finishes, the browser is like effectively kind 254 00:20:37.920 --> 00:20:41.720 of frozen. I'm sure we're all familiar with that, so so yeah, 255 00:20:41.759 --> 00:20:49.119 and whenever a background task like that takes longer than fifty milliseconds, that's referred 256 00:20:49.119 --> 00:20:53.640 to as being a long task. And we will see that long tasks are 257 00:20:53.720 --> 00:20:59.440 kind of feature quite a bit in the performance metrics that you know, once 258 00:20:59.559 --> 00:21:04.000 I start elaborating on them. Animation is the a in RAIL. It deals 259 00:21:04.079 --> 00:21:11.880 with how smoothly the browser performs transitions and animations. For animations to appear visually 260 00:21:11.920 --> 00:21:18.000 smooth, you want them to happen at sixty frames per second or FPS. 261 00:21:18.400 --> 00:21:22.680 A sense of browser itself needs something like more or less six milliseconds to render 262 00:21:22.720 --> 00:21:29.200 a frame. That only leaves like ten eleven milliseconds max for your code to 263 00:21:29.279 --> 00:21:33.079 generate the content for the frame. And that's definitely not a lot of time. 264 00:21:33.960 --> 00:21:37.720 But that's a whole big discussion in and of its own how to do 265 00:21:37.920 --> 00:21:41.240 like efficient and effective animations on the web. And I'm not going to talk 266 00:21:41.279 --> 00:21:45.200 about this today. Maybe this is a topic, so for some future discussion. 267 00:21:45.759 --> 00:21:49.240 I is for idle, which isn't really a measurement. It just means 268 00:21:49.240 --> 00:21:53.880 that you should schedule background tasks for when the browser is idle and break them 269 00:21:53.920 --> 00:22:00.359 down into segments that are shorter than fifty milliseconds each. For that, you 270 00:22:00.359 --> 00:22:04.440 can use request the idle callback dom API, which I think Amy you recently 271 00:22:04.519 --> 00:22:11.640 found out isn't available on all browsers unfortunately. Yeah, it can be simulated 272 00:22:11.759 --> 00:22:15.359 kind of we set time out, but yeah, yeah, it's really a 273 00:22:15.359 --> 00:22:18.720 shame that it's missing. Basically, you give it some a callback and it 274 00:22:18.799 --> 00:22:22.599 will schedule your call back when the browser seems idle. But really, these 275 00:22:22.680 --> 00:22:29.440 days it's actually better to move lengthy background operations into workers so that they execute 276 00:22:29.480 --> 00:22:33.839 completely off of the browser's main thread and don't block it at all. If 277 00:22:33.880 --> 00:22:37.319 you recall, this is something We had Soma from Google as a guest explaining 278 00:22:37.319 --> 00:22:42.559 this in detail on episode three ninety three. It was an excellent episode which 279 00:22:42.640 --> 00:22:47.160 unfortunately wasn't able to participate in. I was, you know, I think 280 00:22:47.200 --> 00:22:51.319 I only joined around episode four hundred, but yeah, it was a really 281 00:22:51.319 --> 00:22:56.119 good one. When I think about like the most intense application I use daily. 282 00:22:56.680 --> 00:23:02.200 I think it's got to be either Gmail or Slack, which neither of 283 00:23:02.240 --> 00:23:04.279 those seem like they should be intensive. But they're the things that seem like 284 00:23:04.359 --> 00:23:07.680 if I look at my browser usage, they're the things that are pegging it 285 00:23:07.759 --> 00:23:12.279 right. And then the other thing is like maybe a news site because it 286 00:23:12.359 --> 00:23:15.400 loads six hundred ads. Now I use an ad blocker so that that doesn't 287 00:23:15.440 --> 00:23:19.240 crash my browser anymore. But it's actually fairly common for a news site to 288 00:23:19.319 --> 00:23:25.480 crash the browser because it's loading just too many ads. And then beyond that, 289 00:23:25.960 --> 00:23:27.839 I mean, I'm looking at a lot of blog articles, I'm shopping 290 00:23:27.839 --> 00:23:33.400 on Amazon, I am I don't know, I don't know. I listen 291 00:23:33.480 --> 00:23:38.400 to music online sometimes I don't play games online. What what are the types 292 00:23:38.400 --> 00:23:42.920 of applications where you see these types of metrics that you're talking about, you 293 00:23:42.920 --> 00:23:47.880 know, having a scheduled background tasks and have an idle time. Where where 294 00:23:47.920 --> 00:23:52.599 do they fall in in like either what you think a lot of these people 295 00:23:52.880 --> 00:23:56.440 they're listening or building, or that you know we experience on the day to 296 00:23:56.480 --> 00:24:00.799 day. So we had some conversations in which we splow not necessarily on the 297 00:24:00.839 --> 00:24:06.200 air about boot camps. For example, and we talked about the fact that 298 00:24:06.240 --> 00:24:11.799 people at boot camps usually learn something like React, and if you're building a 299 00:24:11.839 --> 00:24:17.759 web page using React, there's a good chance that you'll run into long tasks 300 00:24:18.160 --> 00:24:23.519 because React either renders or hydrates. And unless you're using some really new React 301 00:24:23.559 --> 00:24:30.960 technology like React, suspense that React rendering operation is a blocking operation. And 302 00:24:32.039 --> 00:24:34.720 if you've got a sophisticate IT or complex a UI, which a lot of 303 00:24:34.720 --> 00:24:41.000 websites now have that can actually take a fairly long time to render any old 304 00:24:41.039 --> 00:24:48.680 websites, that the website that users React can easily have long tasks. And 305 00:24:48.720 --> 00:24:55.240 as for animations, I think we've all of us seen animations that stutter or 306 00:24:55.279 --> 00:25:00.519 aren't smooth on websites. In ninety percent of the time, that's just loading 307 00:25:00.559 --> 00:25:04.200 animation. You know, it's like, yeah, but what does that matter? 308 00:25:04.240 --> 00:25:07.799 It is what it is. For example, these days, people on 309 00:25:07.119 --> 00:25:12.200 you have this situation on mobile in particular, where people have come to expect 310 00:25:12.319 --> 00:25:18.920 really smooth and responsive behavior when they're using their mobile devices because they're used to 311 00:25:19.079 --> 00:25:25.519 native apps, and then when they use web apps or web pages, they 312 00:25:25.519 --> 00:25:32.200 don't get that because people build really heavy websites for noness is not necessarily a 313 00:25:32.200 --> 00:25:36.599 good reason. Again, what comes to my mind on my phone is anytime 314 00:25:36.640 --> 00:25:41.000 I'm reading a news article, like just the thing just comes to a halt, 315 00:25:41.400 --> 00:25:44.720 like can barely get it to scroll up. Yeah again, but again, 316 00:25:44.799 --> 00:25:48.599 if you even go into some you know, store, or you do 317 00:25:48.680 --> 00:25:52.400 some online shopping and for some reason you do it from your phone, then 318 00:25:52.559 --> 00:25:56.119 you will find that a lot of online retailers the web performance that they provide 319 00:25:56.200 --> 00:26:03.119 isn't necessarily that great. Again, especially on lower end devices anyway, which 320 00:26:03.160 --> 00:26:07.119 which brings us to the final letter in the rail, which stands for load. 321 00:26:07.319 --> 00:26:11.400 And this is what most web developers currently focus on when they're like, 322 00:26:11.480 --> 00:26:15.279 you know, decide to work on web performance. So so load is kind 323 00:26:15.319 --> 00:26:21.359 of the loading time is kind of front and center for most web developers. 324 00:26:21.799 --> 00:26:26.400 That's because we've come to learn to know to learn that uh, lengthy load 325 00:26:26.440 --> 00:26:30.279 time means a high bounce rate. Just to clarify, I assume a lot 326 00:26:30.279 --> 00:26:34.480 of our listeners are familiar with it, but clarified nonetheless, a bounce rate 327 00:26:34.640 --> 00:26:41.039 is when somebody visits your site or your page and then leaves without clicking anything. 328 00:26:41.400 --> 00:26:45.319 So it's kind of like if you want a physical analogy, It's kind 329 00:26:45.319 --> 00:26:51.799 of like somebody walking into a store physical store, looking around, and then 330 00:26:51.920 --> 00:26:56.200 turning around and leaving without speaking to anybody, without trying anything on, without 331 00:26:56.400 --> 00:27:00.839 actually you know, checking anything, certainly without buying anything. So you've managed 332 00:27:00.839 --> 00:27:07.039 to get somebody to your site. That person actually started loading your site and 333 00:27:07.079 --> 00:27:12.000 then just left without doing anything for some reason. So you've apparently disappointed them 334 00:27:12.000 --> 00:27:17.079 in some way. And it turns out that slow load or sow loading site 335 00:27:17.160 --> 00:27:19.880 is a great way to disappoint users and cause them to leave and increase your 336 00:27:19.920 --> 00:27:25.680 bounce rate. So, unfortunately, load performance is one of those things that 337 00:27:25.839 --> 00:27:30.119 can is easily easy to experience, so you can go to a website and 338 00:27:30.119 --> 00:27:33.920 say, hey, this website loads quickly or this website loads slowly, But 339 00:27:34.000 --> 00:27:41.400 it's it's much more difficult to actually describe specifically what exactly does a web For 340 00:27:41.440 --> 00:27:45.640 example, when does a website actually finish loading when the content is visible, 341 00:27:45.799 --> 00:27:49.680 When some of the content is visible, when all of the content is visible, 342 00:27:51.319 --> 00:27:55.440 maybe just when the main content is visible, But then how do you 343 00:27:55.559 --> 00:28:00.000 define the main content? For example, aja you gave an example of news 344 00:28:00.039 --> 00:28:03.319 sites, most a lot of the content, sometimes even most of the content 345 00:28:03.720 --> 00:28:07.759 are ads. Obviously, visitors don't care about the ads finishing loading, so 346 00:28:08.279 --> 00:28:12.759 you kind of want to maybe disregard the ads as from the visitors or the 347 00:28:12.839 --> 00:28:18.799 user's perspective when you're thinking about when the page is loaded. But you know, 348 00:28:18.000 --> 00:28:22.680 if you're using some sort of a synthetic tool to measure performance, how 349 00:28:22.759 --> 00:28:30.039 does that how will that tool distinguish between the actual interesting content and the noise? 350 00:28:30.319 --> 00:28:37.599 And maybe you actually want to base your measurements on interactivity when are some 351 00:28:37.920 --> 00:28:42.799 input elements interactive or maybe when all the input elements are interactive? So how 352 00:28:42.799 --> 00:28:48.200 can you even tell when all the elements on a page are visible and interactive? 353 00:28:48.599 --> 00:28:51.839 You know, the page, the JavaScript in the page can keep creating 354 00:28:51.880 --> 00:28:59.079 additional elements and then making hiding and showing stuff. So how do you know, 355 00:28:59.759 --> 00:29:03.240 like when it's the end of the load process and starts like being like 356 00:29:03.359 --> 00:29:07.000 the page just doing its stuff. And as I previously explained, it's not 357 00:29:07.480 --> 00:29:12.480 enough that the elements just become like that you attach the event handlers to the 358 00:29:12.559 --> 00:29:18.720 various input elements. You also want to handle user input quickly, like I 359 00:29:18.759 --> 00:29:23.079 said, preferably in under one hundred milliseconds. How do you know that you've 360 00:29:23.079 --> 00:29:27.880 reached that point. Are you going to simulate the click at each on each 361 00:29:27.920 --> 00:29:33.599 and every element and each at each and every stage of the loading process and 362 00:29:33.640 --> 00:29:37.799 measure how long it takes to respond? You know, obviously that's not something 363 00:29:37.799 --> 00:29:42.440 you can visibly do. So because of all this, instead of thinking about 364 00:29:42.519 --> 00:29:48.200 a page load as a specific point in time, like saying I've gotten to 365 00:29:48.279 --> 00:29:52.039 this point and now the page is loaded, we should really think about as 366 00:29:52.039 --> 00:29:57.480 a sequence of events or milestones. And on top of that, instead of 367 00:29:57.599 --> 00:30:04.279 measuring a concrete currencys, we often have to make do with various heuristic metrics, 368 00:30:04.680 --> 00:30:10.079 which gets us to all those terms that I threw out at the beginning 369 00:30:10.839 --> 00:30:15.039 of our conversation. And that's why we do have so many performance metrics and 370 00:30:15.240 --> 00:30:22.599 why it's important and important step in the performance monitoring is deciding which metrics are 371 00:30:22.640 --> 00:30:26.279 relevant to you and which metrics you should focus on depending on your particular use 372 00:30:26.319 --> 00:30:32.480 case. Hey there, this is Charles Maxwood. I'm excited because I wanted 373 00:30:32.480 --> 00:30:36.000 to let you know about this thing that I pulled together that I had just 374 00:30:36.359 --> 00:30:40.440 I've been dying to have this for years and I never felt like I could, 375 00:30:40.720 --> 00:30:42.119 And then I just realized that there's no reason why I can't. So 376 00:30:42.519 --> 00:30:47.519 I'm putting together book club and we're going to read development focused books, career 377 00:30:47.640 --> 00:30:49.920 books, you know, technical books, whatever. The first book that we're 378 00:30:49.920 --> 00:30:55.440 going to do is going to be Clean Architecture by Uncle Bob Martin. If 379 00:30:55.480 --> 00:30:57.920 you're not familiar with clean code or some of the other stuff that Bob has 380 00:30:57.960 --> 00:31:00.240 done, check that out. And I've also talked to him on the Clean 381 00:31:00.279 --> 00:31:04.119 Coders podcast which is on top End Devs. But yeah, we're going to 382 00:31:04.160 --> 00:31:07.440 get on. He's going to show up to some of our meetings. And 383 00:31:07.480 --> 00:31:11.240 what I'm thinking is we'll probably have like five or six people part of the 384 00:31:11.240 --> 00:31:15.839 conversation along with Bob and I at the same time, and we'll just so 385 00:31:15.880 --> 00:31:18.279 somebody can come on, they can ask their question, and then we'll just 386 00:31:18.680 --> 00:31:22.680 rotate people through, so we'll mute one person, unmute another person when it's 387 00:31:22.720 --> 00:31:26.480 their turn to come on and be part of the discussion. So we'll do 388 00:31:26.559 --> 00:31:29.960 that for like an hour hour and a half. And then the other part 389 00:31:29.960 --> 00:31:33.519 of it that I'm putting together is just kind of a meet and greet gather 390 00:31:33.680 --> 00:31:38.680 area on gather Town, and so after the meetup and the call we we'll 391 00:31:38.680 --> 00:31:41.799 do as we'll all go over to gather Town and you can just log in, 392 00:31:41.880 --> 00:31:45.119 walk up to a group and have a conversation, and that way we 393 00:31:45.119 --> 00:31:49.039 can all kind of get to know each other and make friends and get to 394 00:31:49.079 --> 00:31:52.079 know people across the world. One thing that I'm finding is that, yeah, 395 00:31:52.119 --> 00:31:55.720 the meetups are starting to come back, but a lot of people don't 396 00:31:55.720 --> 00:31:57.480 have the opportunity to go to a meetup. And I really want to meet 397 00:31:57.480 --> 00:32:00.920 you guys and talk to you. So we're going to put all that together. 398 00:32:00.000 --> 00:32:02.400 It'll all be part of that book club. You can go to topendevs 399 00:32:02.440 --> 00:32:06.720 dot com slash book Club to be part of it, and I'm looking forward 400 00:32:06.720 --> 00:32:09.880 to seeing you there. The first book club meeting will be in December, 401 00:32:10.160 --> 00:32:15.519 the beginning of December. We're starting the first week of December, and you'll 402 00:32:15.559 --> 00:32:19.200 also be part of the conversation about which book we do next. I have 403 00:32:19.279 --> 00:32:22.400 one in mind, but I want to see where everybody's at. So there 404 00:32:22.400 --> 00:32:28.880 you go. So before I start going down the list, any comments or 405 00:32:29.000 --> 00:32:36.039 questions, Okay, then let's run down this alphabet soup. So when reviewing 406 00:32:36.079 --> 00:32:40.000 the different performance metrics, I like to proceed more or less sequentially from the 407 00:32:40.079 --> 00:32:49.039 session start as time progresses. Roughly this translates to first looking at the metrics 408 00:32:49.079 --> 00:32:54.480 that measure the network performance, then to metrics that cover visibility, and finally 409 00:32:54.599 --> 00:33:00.160 to the metrics that deal with interactivity, because usually that's how things go. 410 00:33:00.359 --> 00:33:02.599 First, it needs the stuff needs to be downloaded over the network, over 411 00:33:02.640 --> 00:33:07.599 the from the you know, from the web server whatever, and then the 412 00:33:07.160 --> 00:33:14.559 stuff becomes visible, the browser renders the various elements, and finally we hook 413 00:33:14.640 --> 00:33:20.519 up the various event handlers so that and the JavaScript kind of finishes running so 414 00:33:20.599 --> 00:33:25.200 that the site can actually respond quickly to user interaction. So starting with the 415 00:33:25.240 --> 00:33:30.400 network stuff, as I said, one of the first metrics to look at 416 00:33:30.640 --> 00:33:35.880 is time to first bite or TTFB. Basically, that's the time from when 417 00:33:36.400 --> 00:33:38.799 like the user, let's say, clicked on a link in a Google search 418 00:33:38.960 --> 00:33:45.240 for a particular website and until the first byte is received by the browser from 419 00:33:45.359 --> 00:33:53.039 that website. So it incorporates stuff like the DNS lookup to figure out the 420 00:33:53.079 --> 00:33:59.200 IP address of the service you're connecting to from its domain name. It involves 421 00:33:59.319 --> 00:34:04.720 establishing it TCP connection if you've not yet, if they're not yet using quick 422 00:34:05.079 --> 00:34:08.360 it involves established if it's you know, it should be a secure connection, 423 00:34:08.559 --> 00:34:15.239 so there's a SSL or handshake that needs to happen. You just mentioned QUICK. 424 00:34:15.840 --> 00:34:22.159 I was under the impression that that was still very experimental and very few 425 00:34:22.960 --> 00:34:27.599 web servers had something in place to be able to handle like, for example, 426 00:34:27.639 --> 00:34:32.000 I don't think node can handle it, and I don't I don't know 427 00:34:30.880 --> 00:34:37.199 that it can probably handle anything, so somebody probably wrote a module for it. 428 00:34:37.280 --> 00:34:39.320 I wouldn't be surprised. But if, for example, you're using the 429 00:34:39.320 --> 00:34:45.400 Google CDN to deliver your static assets, they use quick and your browser supports 430 00:34:45.440 --> 00:34:49.719 quick, they will use quick at Google of course because they invented it, 431 00:34:49.760 --> 00:34:53.760 but like the average, but it's not really part of h GDP two or 432 00:34:53.800 --> 00:34:59.320 three, so so eventually we will get it everywhere. It's not that TCP 433 00:34:59.480 --> 00:35:01.960 is bad, is great. The Web was built on TCP. The Internet 434 00:35:02.039 --> 00:35:05.320 was built on TCP, and the Web is built on the Internet, so 435 00:35:05.360 --> 00:35:09.679 it's built on TCP. But you know, the behavior of our networks have 436 00:35:09.920 --> 00:35:15.599 changed since the sixties and seventies whenever TCP was invented, so so stuff like 437 00:35:15.800 --> 00:35:19.920 you know, I'm not going to go into that because these are really big 438 00:35:19.960 --> 00:35:24.280 topics, but and you can, and our listeners can definitely find great talks 439 00:35:24.320 --> 00:35:29.280 about this stuff on YouTube for example, or articles that they can find if 440 00:35:29.320 --> 00:35:32.599 they google for it. But Quick is basically built on UDP instead of TCP, 441 00:35:34.119 --> 00:35:38.800 and it's just it's it's more it appears to be more appropriate to modern 442 00:35:38.840 --> 00:35:45.679 networks than TCP is. For example, TCP starts with a very fairly small 443 00:35:45.719 --> 00:35:49.920 window, which is then it then grows as it sees the quality of your 444 00:35:49.960 --> 00:35:55.679 network connection. So it's kind of throttling itself for the first packets because you 445 00:35:55.719 --> 00:36:00.199 know, back in the day networks were much slower than they are today, 446 00:36:00.960 --> 00:36:07.039 and Quick does this better. So in any event, TTFB, just as 447 00:36:07.039 --> 00:36:12.239 I said, talks about how quickly the bite start arriving at the browser after 448 00:36:12.599 --> 00:36:16.639 the user click the link. And it mostly has to do with, for 449 00:36:16.679 --> 00:36:22.519 example, either just making sure that your place your server as close as possible 450 00:36:22.599 --> 00:36:25.119 to where your users are. So we were talking before about the fact that 451 00:36:25.519 --> 00:36:30.599 UAJA have a lot of visitors from India, so maybe it makes sense for 452 00:36:30.679 --> 00:36:32.880 you to also have a server in India. Can be a virtual server of 453 00:36:32.920 --> 00:36:37.639 course, or just making sure to use some sort of CDN. If you 454 00:36:37.679 --> 00:36:45.960 look at solutions like GATSBJS or next JS or Netlify, all of these guys, 455 00:36:45.599 --> 00:36:52.519 all these companies, they actually have solutions where you can actually statically generate 456 00:36:52.559 --> 00:36:57.760 your HTML files and then push them onto CDNs, which makes the delivery of 457 00:36:57.800 --> 00:37:01.800 these files down to the browsers a lot faster and more efficient because they're just 458 00:37:02.239 --> 00:37:07.280 that much closer to the actual user devices. The request needs to go through 459 00:37:07.320 --> 00:37:13.719 far fewer hops to actually get to the data. So we had time to 460 00:37:13.760 --> 00:37:16.760 first bite, and then we have kind of time to last bite, which 461 00:37:16.800 --> 00:37:22.559 is when the HTML finished downloading. That's not such a common metric to use. 462 00:37:23.400 --> 00:37:30.719 More commonly, people use something called content loaded or DCL, which means 463 00:37:30.800 --> 00:37:36.280 that HTML is loaded and has been parsed. You can actually have a JavaScript 464 00:37:36.280 --> 00:37:40.960 event tender for that if for those of us remember jQuery. jQuery already actually 465 00:37:42.000 --> 00:37:47.239 fires at DCL. So when you look at something like crucks Run and they 466 00:37:47.320 --> 00:37:52.199 show you the TTFB metric, let's say they also show you the DCL metric. 467 00:37:52.679 --> 00:37:57.920 So this way you know when your HTML started arriving, and you know 468 00:37:58.000 --> 00:38:01.760 when your HTML finished arriving and also finished parsing, which is also kind of 469 00:38:01.760 --> 00:38:07.360 dependent on the size and complexity of your HTML. It used to be that 470 00:38:07.559 --> 00:38:12.000 the main metric for performance was onload, and now it's hardly used anymore. 471 00:38:12.079 --> 00:38:16.519 It's not that interesting. That's because modern websites are so dynamic and with single 472 00:38:16.559 --> 00:38:22.239 page applications and JavaScript that keeps on running and downloading more and more stuff even 473 00:38:22.280 --> 00:38:28.360 after the page is loaded, so onload is not really that useful anymore. 474 00:38:28.719 --> 00:38:32.960 But just to touch on it, the main difference between DCL and onload is 475 00:38:34.000 --> 00:38:39.400 that DCL just looks at the HTML itself, and onload also looks at all 476 00:38:39.480 --> 00:38:46.119 the resources that were requested by the while the web page was still downloading. 477 00:38:46.400 --> 00:38:51.320 So, for example, if you have an image tag inside the HTML and 478 00:38:51.360 --> 00:38:55.599 that image tag starts downloading an image as soon as it's received by the browser, 479 00:38:57.719 --> 00:39:01.440 then onload will also wait for that image to finish downloading before it's fired. 480 00:39:01.840 --> 00:39:06.199 If, on the other hand, you have some JavaScript that runs later 481 00:39:06.679 --> 00:39:12.840 and just assigns creates an image element or signs and new image to an existing 482 00:39:13.079 --> 00:39:17.599 image element, if that JavaScript runs after the HTML finished downloading, it's not 483 00:39:17.719 --> 00:39:23.159 actually counted for the onload, so that more or less covers the network key 484 00:39:23.159 --> 00:39:30.440 part of the performance metrics, which moves us over to the visual parts or 485 00:39:30.440 --> 00:39:35.719 the visible parts. So the first metric. There is something called first paint 486 00:39:35.920 --> 00:39:40.440 or FP, which is just when a pixel changed as a result of the 487 00:39:40.599 --> 00:39:45.239 HTML. I don't know if a lot if you've noticed that, but it 488 00:39:45.360 --> 00:39:49.800 used to be that when you started navigating to some web page, let's say 489 00:39:49.800 --> 00:39:53.559 again from a Google search, the page would immediately become like white and then 490 00:39:53.639 --> 00:40:00.880 eventually you will get the actual page that you were navigating too. Browsers kind 491 00:40:00.880 --> 00:40:05.000 of change their behavior there. What they do is they actually keep the old 492 00:40:05.440 --> 00:40:13.159 page content around until they actually get the HTML from the new page and start 493 00:40:13.199 --> 00:40:16.760 passing the new HTML and being able to render the HTML that new page. 494 00:40:16.800 --> 00:40:23.559 So there's like more continuity between pages. This is especially useful if you have 495 00:40:23.679 --> 00:40:28.840 like a multipage application for your site, so as you're moving between the pages 496 00:40:28.880 --> 00:40:32.360 and your site, you don't see those white gaps in between the pages. 497 00:40:32.400 --> 00:40:37.599 They're not as obvious, but still you know, once the HTML arrives, 498 00:40:37.000 --> 00:40:43.280 then the previous content is erased, you get that white background, and then 499 00:40:43.440 --> 00:40:46.760 pixels are starting to be drawn. And when the first pixel is drawn, 500 00:40:47.320 --> 00:40:52.840 that's a first paint. It will often be something like a background color or 501 00:40:52.840 --> 00:40:57.599 whatever. So it doesn't provide a whole lot of value, just shows the 502 00:40:57.719 --> 00:41:01.400 visitor that something's happening. So yeah, so because of that, because it 503 00:41:01.440 --> 00:41:06.440 doesn't provide a whole lot of value, this is not a metric that's so 504 00:41:06.559 --> 00:41:09.960 commonly used. A much more commonly used one is something called first content ful 505 00:41:10.000 --> 00:41:17.360 paint or FCP, which means that the first pixel of some content is drawn. 506 00:41:17.480 --> 00:41:24.760 And content is an image or text or an SVG or canvas, those 507 00:41:24.800 --> 00:41:29.880 are basically the things that count as content. So if it's just a pixel 508 00:41:29.960 --> 00:41:34.920 that's part of a background color, that's not counted for first content ful paint, 509 00:41:35.039 --> 00:41:38.760 but if it's part of an image, then it is counted. Often 510 00:41:38.800 --> 00:41:43.159 though, I see that FP and FCP are pretty close to each other, 511 00:41:43.519 --> 00:41:47.559 maybe even the same, if the first pixel drawn is part of an image, 512 00:41:47.559 --> 00:41:52.079 for example. So what I would say, for example, is if 513 00:41:52.119 --> 00:41:57.599 you're considering text, for example, it's often not just enough that the HTML 514 00:41:57.639 --> 00:42:01.679 w a text arrive. You actually need to wait for the font to download 515 00:42:02.079 --> 00:42:08.360 because unless you use the font the new font display CSS attribute Chrome for example, 516 00:42:08.440 --> 00:42:13.880 if you've got the custom font associated with the text, will not show 517 00:42:14.039 --> 00:42:19.360 the text until either the font has arrived or some internal timeout is reached, 518 00:42:19.639 --> 00:42:22.480 in which case it will go to a full back font. You can now 519 00:42:22.800 --> 00:42:27.000 tell the browser to immediately go to the full back font, but then that 520 00:42:27.039 --> 00:42:30.840 can cause a sort of a flash effect when when the browser then switches fonts. 521 00:42:31.400 --> 00:42:36.960 So you know which one is preferable to you depends on you know, 522 00:42:37.000 --> 00:42:40.480 your own design considerations. That's something i'd say, I'd see like every day 523 00:42:40.800 --> 00:42:45.880 is the fun flash and it's kind of it feels amateurish to me, feels 524 00:42:45.880 --> 00:42:47.800 like I'd rather you just picked Telvetica. I would I would not have known. 525 00:42:49.239 --> 00:42:52.199 Yeah, but you're not a designer. No, No, I like, 526 00:42:52.320 --> 00:42:54.760 I love fonds, I love them, like, but you have to 527 00:42:54.760 --> 00:43:00.800 have some sort of value being brought with a fund and most of these sites 528 00:43:00.880 --> 00:43:04.400 I don't think that they really have any value being brought with the font. 529 00:43:04.480 --> 00:43:07.480 Like if they had the designer that chose that funt on purpose, great, 530 00:43:07.559 --> 00:43:08.840 But I don't think that's the case of most of these sites. I think 531 00:43:08.840 --> 00:43:13.159 most of them is just like, oh cool Google fonts, let's pick one 532 00:43:13.559 --> 00:43:16.599 and it's not. But yeah, I guess like I would say too. 533 00:43:16.960 --> 00:43:21.119 I mean, this is something that I'm hitting where I'm at right now, 534 00:43:21.159 --> 00:43:24.639 and that's like to AJ's point, I think this is where like dav and 535 00:43:24.679 --> 00:43:30.000 design you actual really need to work together because like branding is important, but 536 00:43:30.480 --> 00:43:34.920 you don't want it to come at the cost of page speed because of how 537 00:43:34.920 --> 00:43:38.039 closely that's tied to revenue. And I see stuff fail all the time, 538 00:43:38.280 --> 00:43:43.679 because it seems to me like if you just pound refresh on any site that's 539 00:43:43.719 --> 00:43:46.159 loading Google fonts, if you let it reload like twenty times, it'll fail 540 00:43:46.199 --> 00:43:50.920 at least once. That's that seems to be a very fragile area of the 541 00:43:50.960 --> 00:43:55.400 web, the font loading. Yeah, but look, there are workarounds for 542 00:43:55.440 --> 00:43:59.239 this sort of thing. So, like I said, there's a CSS attributes 543 00:43:59.239 --> 00:44:02.239 which can actually lets you control the behaviorally somewhat. So you can either have 544 00:44:02.840 --> 00:44:07.840 it wait a little bit for the font that you want, but then go 545 00:44:07.960 --> 00:44:10.239 to the fall back font if you take downloading the font takes too long, 546 00:44:10.880 --> 00:44:16.719 or it can immediately go to that fallback font and then switch to the custom 547 00:44:16.760 --> 00:44:22.599 font when the custom font finally arrives, or it can actually there's even the 548 00:44:22.679 --> 00:44:27.480 option of having it the fallback font for the first session, download the custom 549 00:44:27.559 --> 00:44:30.000 font, keep it in the browser cash so that when the next time you 550 00:44:30.119 --> 00:44:32.719 visit, it comes from the cash, it arrives immediately, and then it 551 00:44:32.719 --> 00:44:37.280 will use the custom font. So the first time you visit a certain site, 552 00:44:37.280 --> 00:44:40.519 you will get the fallback, but for every consecutive visit, you'll get 553 00:44:40.519 --> 00:44:44.920 the custom font. Look. It's like Amy said, it's a part of 554 00:44:44.960 --> 00:44:50.239 the brand. Marketeers and designers agonize over this sort of a thing. They 555 00:44:50.280 --> 00:44:55.360 will tell you that they want to convey the spirit and the intent and whatever, 556 00:44:55.760 --> 00:44:59.960 and it has to be on brand. And it's not something that we 557 00:45:00.119 --> 00:45:02.440 can just say, oh, you know, oh bah humbug and ignore that. 558 00:45:02.599 --> 00:45:07.440 But if it comes at the cost of conversion, then we don't have 559 00:45:07.559 --> 00:45:10.320 jobs to design things. So you can you can also, like I said, 560 00:45:10.360 --> 00:45:14.480 there are also like various workarounds that you can do. You can use 561 00:45:14.840 --> 00:45:19.280 preloading to try to get the phonts down faster. You can even go as 562 00:45:19.400 --> 00:45:24.199 far as inlining the font as data URLs inside the htmil itself. There are 563 00:45:24.239 --> 00:45:28.239 various like tricks and hacks that you can use. But yeah, at the 564 00:45:28.320 --> 00:45:31.639 end of the day, it's all about compromises. That's our life as developers 565 00:45:31.639 --> 00:45:37.000 and people working in tech. Continuing from first content ful paint, the next 566 00:45:37.039 --> 00:45:42.239 one is first meaningful paint, and that's when when are the pixels the When 567 00:45:42.320 --> 00:45:46.519 does the browser paint the pixels that actually have a meaning for you as a 568 00:45:46.599 --> 00:45:52.159 site visitor. For example, if you're visiting let's say a weather website, 569 00:45:52.480 --> 00:45:59.119 then the pixels that you care about are the pixels that have the temperature and 570 00:45:59.159 --> 00:46:01.239 whether it's going to raise or not. You don't really care about the ads. 571 00:46:01.320 --> 00:46:05.440 You don't even care about the logo of the site. All of these 572 00:46:05.440 --> 00:46:09.079 pictures count for first content ful paint, but they're not meaningful for you. 573 00:46:09.760 --> 00:46:14.599 The problem with first meaningful paint is that it's at the end of the day, 574 00:46:14.639 --> 00:46:20.440 it's least subjective. Certainly, generic tools like Google Lighthouse don't really know 575 00:46:20.960 --> 00:46:23.920 what's meaningful in any website out there. You know, they can try to 576 00:46:23.960 --> 00:46:29.760 guess. There are certain heuristics around it, but any heuristic is really problematic 577 00:46:29.800 --> 00:46:34.599 in this context. Because of this, first meaningful paint is kind of being 578 00:46:34.719 --> 00:46:38.440 sort of deprecated in favor of a new metric, which I'll get you in 579 00:46:38.480 --> 00:46:43.039 a second. I just want to say though, that if, for example, 580 00:46:43.119 --> 00:46:46.960 you know that a particular image on your website is the meaningful content, 581 00:46:47.559 --> 00:46:52.159 you can even just put an onload on that image and measure the meaningful paint 582 00:46:52.199 --> 00:46:58.159 of that image yourself. So, like I said, because of this problem 583 00:46:58.159 --> 00:47:05.079 with meaningful paint, Google recently introduced in the proposed to the W three C 584 00:47:05.840 --> 00:47:12.199 Web Performance Working Group a new measurement calling called largest contentful paint or LCP. 585 00:47:12.760 --> 00:47:16.320 Basically, they figured out that the most meaningful content is probably going to be 586 00:47:16.440 --> 00:47:22.039 the biggest content on the page. So the biggest image or the biggest headline, 587 00:47:22.360 --> 00:47:25.679 that's probably going to be the most important one. So largest contentful paint 588 00:47:25.840 --> 00:47:30.119 is basically just an event that you can get from the Web Performance API that 589 00:47:30.280 --> 00:47:37.960 fires whenever there's a bigger, something bigger being drawn that whatever was drawn before, 590 00:47:37.159 --> 00:47:44.599 which is a really powerful mechanism but also highlights its limitation because first contentful 591 00:47:44.679 --> 00:47:50.599 paint is like accurately defined, you know, a particular pixel that's the first 592 00:47:50.599 --> 00:47:53.639 pixel. Any pixel that is drawn afterward is not going to be the first 593 00:47:53.639 --> 00:48:00.159 pixel. Largest contentful paint raises the question of when do I stop If something 594 00:48:00.320 --> 00:48:05.719 big is drawn, maybe something even bigger is still being downloaded then will be 595 00:48:05.800 --> 00:48:12.559 drawn later, And sometimes things are intentionally delayed by the way all of the 596 00:48:12.599 --> 00:48:16.280 stuff that I'm talking about all these painting operations are for I neglected to mention 597 00:48:16.440 --> 00:48:22.079 there for stuff that is above the fold, So anything that is below the 598 00:48:22.159 --> 00:48:28.519 fold doesn't count for fp FCP or does that mean above fold below fold? 599 00:48:29.360 --> 00:48:31.599 So you know how maybe if you know, we're old enough to remember, 600 00:48:31.719 --> 00:48:37.960 but once newspapers really really big, so that when our dads used to go 601 00:48:37.079 --> 00:48:42.119 to the bathroom with a newspaper, they would have to fold it so that 602 00:48:42.199 --> 00:48:46.280 they could hold it while they were sitting there comfortably. And as a result, 603 00:48:46.559 --> 00:48:52.519 when newspaper men thought about where or people thought about where to put based 604 00:48:53.119 --> 00:48:57.920 back then it was bothly men, I guess, but now it's certainly a 605 00:48:58.039 --> 00:49:02.599 newspeople. When they thought about where to put the most important content, they 606 00:49:02.679 --> 00:49:07.679 wanted to put it above where the people used to fold the newspaper. So 607 00:49:07.719 --> 00:49:12.000 the most important stuff was at the top of the front page, above where 608 00:49:12.039 --> 00:49:15.800 people would fold the front page. The less important stuff was below that fold. 609 00:49:16.239 --> 00:49:20.599 Even less important stuff was on the back of the newspaper, and the 610 00:49:20.679 --> 00:49:23.840 least important stuff that you really didn't care about was in some center page. 611 00:49:24.199 --> 00:49:30.000 So the term above and below the fold now in the browsers mean the content 612 00:49:30.119 --> 00:49:37.320 that's visual where the page loads before the user does anything like scroll or zoom 613 00:49:37.559 --> 00:49:43.119 out or whatever. So what's initially visible in the browser's viewport, that's the 614 00:49:43.199 --> 00:49:46.239 content that's above the fold. Anything that you need to scroll down to get 615 00:49:46.280 --> 00:49:51.760 to that's below the fold. A long story for a fairly simple term. 616 00:49:51.840 --> 00:49:53.480 I was just going to add really quickly to you to the largest content for 617 00:49:53.639 --> 00:49:59.440 paint. So I don't think that's something because as part of white House Pie 618 00:49:59.440 --> 00:50:04.760 six, it's reporting on just yet in page speed Insights. But if you 619 00:50:04.800 --> 00:50:07.400 go to web dot Dev, they have code provided to you that you can 620 00:50:07.559 --> 00:50:12.400 inject into basically like you're under pipeline on your app, and it will tell 621 00:50:12.440 --> 00:50:16.480 you what the largest note is. Actually even even like even page speed Insights 622 00:50:16.519 --> 00:50:21.280 already collects this information, they just don't display it yet. So if you 623 00:50:21.519 --> 00:50:25.440 use if you use the paid speed Insights API, you will actually get the 624 00:50:25.519 --> 00:50:31.480 largest contentful paint. But yes, they've they've announced that in V six, 625 00:50:31.559 --> 00:50:35.840 which was already supposed to come out, I think, but you know it'll 626 00:50:35.840 --> 00:50:40.119 be there when it gets there, that they're kind of eliminating the first meaningful 627 00:50:40.159 --> 00:50:45.840 paint which is still there, and they'll replace it with the largest contentful paint. 628 00:50:45.119 --> 00:50:49.480 So going forward that that's the metric to use, and like I said, 629 00:50:49.519 --> 00:50:53.880 it's actually already supported in the Web Performance API. So I assume that 630 00:50:53.960 --> 00:50:59.360 the various, like I said, tools that you can use to gather performance 631 00:50:59.400 --> 00:51:06.280 information from real user sessions will also start reporting largest contentful paint. Two more 632 00:51:06.280 --> 00:51:08.719 items that I want the measurements that I wanted to mention in the context of 633 00:51:08.800 --> 00:51:14.639 visibility, one older one and one a newer one. The older one is 634 00:51:14.920 --> 00:51:20.840 something called speedy deck Speed Index or SI. That's not one that Google invented, 635 00:51:20.880 --> 00:51:23.159 that's one that they inherited. Think about it this way. Let's say 636 00:51:23.199 --> 00:51:29.280 you have a page that loads and needs to display or render some really complex 637 00:51:29.320 --> 00:51:31.679 scene. It can work one or two ways. You can have nothing, 638 00:51:31.800 --> 00:51:36.679 nothing, nothing, nothing, and then bam the entire scene. Or you 639 00:51:36.719 --> 00:51:42.840 can have the scene built up gradually until finally so they finish. Let's say 640 00:51:42.840 --> 00:51:46.079 it at the same time. But one there was nothing and then suddenly you 641 00:51:46.119 --> 00:51:52.639 got everything, and the other one built up gradually. From the performance perspective, 642 00:51:52.519 --> 00:51:58.320 then building up gradually is preferable because the user has something to see, 643 00:51:58.599 --> 00:52:02.440 hopefully something that's going tenful and maybe even meaningful. While the page is building 644 00:52:02.519 --> 00:52:06.320 up. You know, one of the things that really annoy me about some 645 00:52:06.480 --> 00:52:10.920 news apps, even native apps, is that they don't show the content and 646 00:52:12.280 --> 00:52:16.239 at all until after the ads are loaded. They have like a spinner or 647 00:52:16.239 --> 00:52:21.320 something that until everything in the page is downloaded, they don't show you anything. 648 00:52:21.639 --> 00:52:24.440 And that's really annoying to me because I'm waiting on the content that I 649 00:52:24.559 --> 00:52:29.239 don't care about, while I could have already been reading the content that I 650 00:52:29.360 --> 00:52:31.960 do care about. So in terms of performance, you do want that gradual 651 00:52:32.000 --> 00:52:36.199 build up, and that's what speed index measures. It kind of takes, 652 00:52:36.360 --> 00:52:40.480 uh, like screenshots of of the of the browser as it it's as it 653 00:52:40.519 --> 00:52:46.159 builds up the display and and and and sees how much content is available at 654 00:52:46.159 --> 00:52:50.039 each point in time, and based on that it gives you the score. 655 00:52:50.519 --> 00:52:53.079 Now, because of that, because of this whole process of taking screenshots and 656 00:52:53.119 --> 00:53:00.000 whatnot, the speed Index or SI score is really only relevant for synthetic tests 657 00:53:00.480 --> 00:53:05.840 because you can't really take those screenshots in real user sessions. But Google Lighthouse, 658 00:53:05.880 --> 00:53:08.039 for example, that's one of the measurements that they currently use. A 659 00:53:08.079 --> 00:53:12.840 new measurement that they recently introduce and one that can be measured in The field 660 00:53:13.280 --> 00:53:19.559 is called commulative layout shift. I'm sure you've all encountered the situation where you 661 00:53:19.639 --> 00:53:24.719 were reading something and then because let's say something additional was downloaded, it pushes 662 00:53:24.800 --> 00:53:31.119 everything down, and suddenly you lost your spot in whatever it is that you're 663 00:53:31.159 --> 00:53:37.119 reading because everything shifted down because something on top just finished downloading. It can 664 00:53:37.159 --> 00:53:43.719 be even worse if you're trying to click on something in the document that explains 665 00:53:43.760 --> 00:53:46.920 this measurement. Good They actually even have like this animated gift or video or 666 00:53:47.000 --> 00:53:52.599 something that shows a really amusing scenario when somebody trying is trying to cancel a 667 00:53:52.639 --> 00:53:58.079 purchase, but because something appeared and pushed everything down, they click the purchase 668 00:53:58.119 --> 00:54:01.719 button instead by accident because it got pushed down the instant that they clicked. 669 00:54:01.960 --> 00:54:07.480 So obviously you want to avoid that. So commulative layout shift or CLS for 670 00:54:07.559 --> 00:54:13.280 short, that kind of is a measurement that combines how much the size of 671 00:54:13.320 --> 00:54:16.039 the content being shifted down, how much area of the screen is being shifted 672 00:54:16.039 --> 00:54:21.280 down by how far is it shifted. So it's like a combination of these 673 00:54:21.280 --> 00:54:24.480 two values, and you want to have this as small as possible. You 674 00:54:24.519 --> 00:54:30.280 want you don't want stuff jumping around as the as the user is, you 675 00:54:30.280 --> 00:54:35.519 know, scrolling through your page. So just recently and you know, thanks 676 00:54:35.559 --> 00:54:38.440 to Dan, I've been able to like chat with him and get his insight 677 00:54:38.519 --> 00:54:44.159 to which I like immensely appreciated. But some of the tricks that I've been 678 00:54:44.239 --> 00:54:49.239 kind of doing is so one of the first ones was because I work for 679 00:54:49.239 --> 00:54:52.840 an e commerce company, we have a lot of different like tracking pixels and 680 00:54:52.960 --> 00:54:57.920 all kinds of stuff. We also have a chat box that is pretty heavy 681 00:54:58.800 --> 00:55:02.519 on initial page. So what I did I couldn't use the request idle callback 682 00:55:02.559 --> 00:55:07.400 because it wasn't available. What what I did do is, since that was 683 00:55:07.440 --> 00:55:12.920 like a huge chunk blocking the page from being usable to the user, is 684 00:55:13.079 --> 00:55:16.000 I delayed that to only occur once the user has actually interacted to the with 685 00:55:16.039 --> 00:55:20.239 the page, so that it can load more quickly. Does another thing just 686 00:55:20.320 --> 00:55:23.079 like make sure you're auditing like all your caching headers and especially if you're using 687 00:55:23.079 --> 00:55:29.440 third party services. So we at work use zite and the app was not 688 00:55:29.559 --> 00:55:34.119 always on site, and so we had some headers that were actually interacting with 689 00:55:34.320 --> 00:55:37.679 the default caching that Zite gives you. And then the last thing that I've 690 00:55:37.679 --> 00:55:44.719 been working on, which seems a little bit more creative is we have because 691 00:55:44.719 --> 00:55:50.119 we're building out multiple properties, we have some reusable chunks of React code in 692 00:55:50.159 --> 00:55:52.639 a Mona rebo, it's not necessarily needed on the page. So what I 693 00:55:52.639 --> 00:55:59.119 did is using like dynamic imports and JavaScript is I'm only loading those things if 694 00:55:59.159 --> 00:56:02.840 a certain user interaction is required to load those things. And that's also cut 695 00:56:02.880 --> 00:56:09.360 down pretty drastically on this kind of stuff. So basically you're doing tree shaking 696 00:56:09.679 --> 00:56:15.440 and lazy loading of stuff only as needed. By the way, I completely 697 00:56:15.519 --> 00:56:21.840 agree with you about the caching. One of the easiest or quickest wins is 698 00:56:22.440 --> 00:56:27.760 just making sure that all your resources have the appropriate cash headers. I've seen 699 00:56:27.840 --> 00:56:32.880 so many cases in which stuff that's totally static is either not cashed or cashed 700 00:56:32.920 --> 00:56:38.519 for really short duration. Another quick win that's similar to that is making sure 701 00:56:38.559 --> 00:56:44.719 that all your downloaded content is compressed. I mean, everybody, every browser 702 00:56:44.760 --> 00:56:50.239 these days support JESIP and even broadly for even greater compression. So you know, 703 00:56:50.400 --> 00:56:58.159 downloading your HTML or JavaScript without compression or CSS without compression is just like 704 00:56:58.679 --> 00:57:02.760 sad, and there's no reason not not to take advantage of that. But 705 00:57:02.760 --> 00:57:07.920 but yeah, I totally concur with you, there's there are there are a 706 00:57:07.960 --> 00:57:12.239 lot of wins that can be achieved. You know, we spoke with with 707 00:57:12.400 --> 00:57:17.639 Bruce a couple of shows back Bruce Lawson about semantic HTML. I forget the 708 00:57:17.760 --> 00:57:22.119 number of the show. You can check this out later, but he was 709 00:57:22.159 --> 00:57:27.599 talking about the picture element, for example, as a means of downloading appropriately 710 00:57:27.760 --> 00:57:32.159 sized images. Because let's say your more the mobile screen is going to be 711 00:57:32.239 --> 00:57:37.360 smaller than the desktop screen, so why would you want to download a huge 712 00:57:37.360 --> 00:57:43.559 image for your mobile device? So you can use media queries to uh download 713 00:57:43.639 --> 00:57:49.559 them more proper, properly sized images using using that you don't even need JavaScript. 714 00:57:49.880 --> 00:57:52.920 I think this also one thing Amy that you discussed on a couple of 715 00:57:52.960 --> 00:57:59.800 shows is the ability that now exists in some browsers to lazy load images, 716 00:58:00.159 --> 00:58:06.199 so images that are below the fold don't download until the user actually scrolls to 717 00:58:06.320 --> 00:58:08.320 them, And all you need to do in order to get that is just 718 00:58:08.360 --> 00:58:12.880 to add an attribute to your image tag. You don't need to write any 719 00:58:12.960 --> 00:58:15.000 jobscript or anything for it. So so yeah, there are a lot of 720 00:58:15.039 --> 00:58:20.360 winds that can be achieved without too much effort, especially if you know what 721 00:58:20.480 --> 00:58:23.280 to look for and then you can kind of measure what you where you were 722 00:58:23.480 --> 00:58:29.159 before these changes and measure where you are after these changes. And you know, 723 00:58:29.480 --> 00:58:32.280 if you're if you're looking for a raise, for example, it's it's 724 00:58:32.360 --> 00:58:37.960 really useful to be able to have this graph that shows how much you improved 725 00:58:37.000 --> 00:58:45.320 something when the next time you're you're negotiating your salary and I guess, yeah, 726 00:58:45.480 --> 00:58:46.519 and I'll have to hop off. My pick is just going to be 727 00:58:46.559 --> 00:58:51.639 the web dot dev docs. I think they are not a lot of people 728 00:58:51.639 --> 00:58:55.920 know about them necessarily and they're absolutely amazing. Yeah I do. My pick 729 00:58:55.960 --> 00:59:01.519 is Dan as well. Thank you very much for that. And two seconds, 730 00:59:01.719 --> 00:59:06.280 just want to point out something. You can use picture now. It 731 00:59:06.360 --> 00:59:13.159 is backwards compatible with other browsers. So your default image inside of your picture 732 00:59:13.199 --> 00:59:17.400 tag is an image tag, which means that no users that don't have supported 733 00:59:17.440 --> 00:59:22.679 browsers will have any deficit, and all users that do have a supported browser 734 00:59:22.719 --> 00:59:27.599 will get the benefit and supported browsers for that, like any browser from twenty 735 00:59:27.719 --> 00:59:30.199 sixteen, you will definitely get a lot of benefit for stuff from stuff like 736 00:59:30.239 --> 00:59:34.519 that. But I totally agree with you Amy about web dot dev. In 737 00:59:34.559 --> 00:59:38.480 fact, more or less all the terms that I'm talking about have definitions on 738 00:59:38.559 --> 00:59:43.320 web dot dev. So if one somebody wants to look like wants to reread 739 00:59:43.360 --> 00:59:47.119 the definition, or wants to see like images or graphs that show what these 740 00:59:47.719 --> 00:59:52.599 terms are, want more, who needs more clarification, they can definitely find 741 00:59:52.639 --> 00:59:55.920 it web dot dev. It's an excellent website. So I guess I'll resume. 742 00:59:57.559 --> 01:00:01.079 So I finished more or less the visual metrics, So now it's time 743 01:00:01.199 --> 01:00:07.519 for the metrics that kind of measures interactivity. The most explicit one you could 744 01:00:07.519 --> 01:00:15.280 say is simply called time to interactive or TTI, which kind of looks at 745 01:00:15.559 --> 01:00:22.480 when does the page become consistently interactive? And by consistently interactive, it means 746 01:00:22.519 --> 01:00:30.360 that you can expect reasonable reaction, that all the elements that should respond to 747 01:00:30.440 --> 01:00:36.599 user input have the event handlers associated with them, and that they'll respond relatively 748 01:00:36.679 --> 01:00:42.079 quickly to that user input. The problem is how to measure that. Now 749 01:00:42.320 --> 01:00:52.519 Google has some fairly complex and sophisticated heuristic algorithm inside of Lighthouse. I have 750 01:00:52.599 --> 01:00:58.239 to say that I'm not such a huge fan of that algorithm, and I 751 01:00:58.320 --> 01:01:01.480 think there are you know, be improved and maybe I'll do that or this. 752 01:01:01.639 --> 01:01:06.400 I'll propose an alternative to the existing algorithm. Let's see how they respond 753 01:01:06.480 --> 01:01:10.880 to that. But in any way, it's really only appropriate for synthetic tests 754 01:01:12.199 --> 01:01:17.480 because measuring it in the field is kind of problematic. For example, if 755 01:01:17.599 --> 01:01:25.800 the user interacts with the session, that actually impacts this whole measurement of TTI, 756 01:01:27.039 --> 01:01:31.199 so you might get wrong TTI value simply because the user actually interacted with 757 01:01:31.239 --> 01:01:36.760 the session. So that makes this measurement kind of problematic, and like I 758 01:01:36.800 --> 01:01:42.440 said, it's mostly using synthetic tests. A newer measurement is something called TBT, 759 01:01:43.079 --> 01:01:46.000 or total blocking time. This measurement, if you recalld I talked about, 760 01:01:46.039 --> 01:01:52.280 long tasks, are those segments when the browser is busy for more than 761 01:01:52.360 --> 01:01:58.400 fifty milliseconds, which means that if the user does some sort of interaction, 762 01:01:58.519 --> 01:02:02.000 it's highly likely that we won't be able to respond in under one hundred millisecond. 763 01:02:02.239 --> 01:02:10.519 So TBT essentially counts all those longer than fifty millisecond segments. It looks 764 01:02:10.559 --> 01:02:17.360 at all the long tasks that happen until the time to interactive, and then 765 01:02:17.440 --> 01:02:23.639 it looks at how much longer than fifty milliseconds they were, and just sums 766 01:02:23.639 --> 01:02:28.599 this all up. So it's it's like a sort of again a heuristic value 767 01:02:29.079 --> 01:02:35.880 that gives some sort of a measurement of how likely or unlikely the web page 768 01:02:35.920 --> 01:02:43.320 is to quickly respond to user interactions. And the last measurement that I want 769 01:02:43.320 --> 01:02:46.480 to talk about, because I really I think went through a whole lot is 770 01:02:46.519 --> 01:02:52.719 again a relatively new one called first input delay or FID. That's a measurement 771 01:02:52.920 --> 01:02:59.800 that's intended for actually for the field, and it looks at when the user 772 01:03:00.119 --> 01:03:06.280 interacted for the first time with anything something in the session. So, for 773 01:03:06.320 --> 01:03:08.400 example, if there's a button, the user clicked on that button, so 774 01:03:08.639 --> 01:03:15.480 it looks at when the first interaction occurred relative to the start of the session, 775 01:03:15.000 --> 01:03:21.119 and how long it took the browser to respond to that interaction. And 776 01:03:21.239 --> 01:03:25.559 by respond, they're looking at how long it took until the first screen or 777 01:03:25.960 --> 01:03:32.320 update after that interaction, essentially the time that it took from that interaction until 778 01:03:32.400 --> 01:03:38.280 something visually happened in response to that interaction. So the values that you can 779 01:03:38.320 --> 01:03:42.840 get from FID are like, you can get like three things from it. 780 01:03:43.159 --> 01:03:46.440 How many sessions actually have FID. You can say that those that don't have 781 01:03:46.480 --> 01:03:52.519 an FID, those are that's your bounce rate, how long relative to the 782 01:03:52.559 --> 01:03:59.039 start of the session did FID happen because people probably don't interact with your site 783 01:03:59.159 --> 01:04:04.079 before it's like visually sufficiently complete for them to interact with it, and how 784 01:04:04.199 --> 01:04:10.920 and the length of that duration until it responded to the browser responded to that 785 01:04:11.000 --> 01:04:14.880 interaction, and as I keep harping, you want that to be as under 786 01:04:14.920 --> 01:04:17.960 one hundred millisecond or close to that as possible. So those are the values 787 01:04:18.000 --> 01:04:21.880 that you can get from FID. The final thing that I wanted to say 788 01:04:21.920 --> 01:04:30.559 about about metrics is that you can also create custom performance metrics for yourself that 789 01:04:30.679 --> 01:04:35.159 match your own particular use case. For example, there's a well known story 790 01:04:35.239 --> 01:04:43.480 that Twitter created when they went to their big performance push. They created their 791 01:04:43.480 --> 01:04:48.440 own custom metric called time to first tweet, where they measured the amount how 792 01:04:48.480 --> 01:04:55.559 long it took from when the page started until the first tweet became visible. 793 01:04:55.880 --> 01:04:59.960 So for them, obviously when you visit Twitter, that's what they really can 794 01:05:00.039 --> 01:05:02.840 care about, how quickly do you see the top tweet in your feed, 795 01:05:03.360 --> 01:05:06.679 so that that's the thing that they measured. But let's say you're built, 796 01:05:06.800 --> 01:05:13.760 Let's say you're building an online store, then you may decide that one of 797 01:05:13.800 --> 01:05:17.599 the most important metrics for you might be a measurement of how long it takes 798 01:05:17.679 --> 01:05:23.840 until the visitor can make a purchase, for example, when does the buy 799 01:05:24.000 --> 01:05:30.920 now button become interactive and quickly responsive, So that might be your metric for 800 01:05:30.920 --> 01:05:36.960 for deciding you know how quickly your how how well your web page performs. 801 01:05:38.440 --> 01:05:42.199 Or again, you can use a whole combination of all the various metrics that 802 01:05:42.280 --> 01:05:47.000 I mentioned, along with your custom ones. Now, just to finish off, 803 01:05:47.480 --> 01:05:53.280 if you use a tool like Lighthouse or Paid Speed Insights, then you 804 01:05:53.400 --> 01:05:56.920 get the sort of a score, and the score that they do is just 805 01:05:57.039 --> 01:06:02.440 the weighted average of of some of these metrics. So they use a certain 806 01:06:03.480 --> 01:06:10.039 combination in Lighthouse version five, which is what you currently get. But like 807 01:06:10.079 --> 01:06:14.639 I said, they're about to release Lighthouse version six and they intend to make 808 01:06:15.400 --> 01:06:18.960 some changes there use different metrics in different ways, so it's likely that we'll 809 01:06:19.000 --> 01:06:25.440 see all of a sudden different scores. For anybody who's using pagebed Insights, 810 01:06:25.440 --> 01:06:29.159 for example, will suddenly see different scores when they do that, we will 811 01:06:29.199 --> 01:06:33.719 see if it's more accurate, certainly hope so that more or less covers all 812 01:06:33.760 --> 01:06:38.039 I had to say. I know that I said quite a bit all right, 813 01:06:38.440 --> 01:06:42.480 enough said certainly, well, thanks Dan, thanks for that in depth 814 01:06:42.519 --> 01:06:50.079 explanation. I was really well repared, prepared and researched, and I think 815 01:06:50.119 --> 01:06:53.840 there was a lot of value there. So I hope that our listeners got 816 01:06:53.920 --> 01:06:57.480 that as well as always feel free to tweet a us with more questions and 817 01:06:57.519 --> 01:07:01.760 comments. We'd love to come back around to some of these topics and discuss 818 01:07:01.800 --> 01:07:05.480 them again with more information. So so don't forget to check us out on 819 01:07:05.519 --> 01:07:12.199 Twitter where what js jabber these days? Yeah, and also this topic is 820 01:07:12.239 --> 01:07:15.480 definitely my passion and like I said, what I do day in, day 821 01:07:15.480 --> 01:07:20.039 out, So if anybody wants to reach out to me, the best place 822 01:07:20.039 --> 01:07:24.679 to get to reach me is also on Twitter. I'm just Dan shapp here 823 01:07:24.679 --> 01:07:28.079 on Twitter, so you know, feel free to reach out. That's with 824 01:07:28.199 --> 01:07:32.159 two p's and no e at the end. Correct. Have you ever wished 825 01:07:32.199 --> 01:07:35.159 that you had a group of people that were just as passionate about writing code 826 01:07:35.159 --> 01:07:39.119 as you are? I know I did. I did that for most of 827 01:07:39.119 --> 01:07:42.320 my career. I'd go to the meetups, I try and create other opportunities 828 01:07:42.360 --> 01:07:45.440 and it was just really hard. Right the meetups. I got some of 829 01:07:45.440 --> 01:07:47.239 that, but they were only like once or twice a month, and it 830 01:07:47.320 --> 01:07:50.480 was just really hard to find that group of people that I connected with and 831 01:07:50.880 --> 01:07:55.239 really wanted to, you know, talk about code a lot, right, 832 01:07:55.320 --> 01:07:58.599 I mean, I love writing code. I think it's the best. And 833 01:07:58.679 --> 01:08:03.840 so I've decided to create this community and create a worldwide community that we can 834 01:08:03.840 --> 01:08:06.960 all jump in and do it. So we're going to have two workshops every 835 01:08:06.960 --> 01:08:10.920 week. One of those or two of those every month, are going to 836 01:08:10.960 --> 01:08:13.360 be Q and A calls right where you can get on you can ask me 837 01:08:13.519 --> 01:08:15.880 or me and another expert questions. The rest of them are going to be 838 01:08:15.880 --> 01:08:20.680 focused on different aspects of career or programming or things like that. Right, 839 01:08:20.760 --> 01:08:26.680 So it'll go anywhere from like deployments and containers all the way up to managing 840 01:08:26.680 --> 01:08:30.760 your four oh one K and negotiating your benefits package. Well, we'll cover 841 01:08:30.800 --> 01:08:33.079 all of it, okay. And then we're also going to have meetups every 842 01:08:33.119 --> 01:08:38.680 month for your particular technology area. So we have shows about JavaScript, react, 843 01:08:38.720 --> 01:08:42.039 angular view and so on. We're going to have meetups for all of 844 01:08:42.039 --> 01:08:45.199 those things. I'm going to revive the freelancer show. We'll have one about 845 01:08:45.199 --> 01:08:47.560 that, right, so you can get started freelancing or continue freelancing if that's 846 01:08:47.560 --> 01:08:53.520 where you're at. And I'm working on finding authors who can actually do weekly 847 01:08:53.640 --> 01:08:59.680 video tutorials on some thing for ten minutes. That's related again to those technology 848 01:08:59.680 --> 01:09:01.479 areas, so that you can stay current, keep growing. So if you're 849 01:09:01.520 --> 01:09:06.319 interested, go to topendevs dot com slash sign up and you can get in 850 01:09:06.399 --> 01:09:12.000 right now for thirty nine dollars. When we're done, that price is going 851 01:09:12.039 --> 01:09:15.760 to go up to seventy five dollars, and the thirty nine dollars price gets 852 01:09:15.840 --> 01:09:21.199 you access to two calls per week. The full price at one hundred and 853 01:09:21.239 --> 01:09:25.319 fifty dollars, which is going to be seventy five dollars over the next few 854 01:09:25.359 --> 01:09:29.079 weeks. That price is going to get you access to all of the calls 855 01:09:29.439 --> 01:09:32.079 and all of the tutorials and everything else that we put out from top endevs, 856 01:09:32.079 --> 01:09:36.479 along with member pricing for our remote conferences that are coming up next year. 857 01:09:38.000 --> 01:09:43.199 So go check it out topendevs dot com slash sign up. All right, 858 01:09:43.600 --> 01:09:46.039 well, thanks very much for being our guest today, and do you 859 01:09:46.079 --> 01:09:49.840 have any picks for us? Yes, so I actually do have a few 860 01:09:49.880 --> 01:09:57.439 picks, actually just too really so The first pick is that a few days 861 01:09:57.479 --> 01:10:00.840 ago, I found out that there's this neworks stability feature in the Chrome deav 862 01:10:00.880 --> 01:10:06.960 tools, and I want to highlight that you can actually simulate vision deficiencies from 863 01:10:06.960 --> 01:10:12.079 within Chrome dev tools. So if you want to see how, yeah, 864 01:10:12.119 --> 01:10:16.159 if you want to see how people who are let's say color blind or have 865 01:10:16.279 --> 01:10:21.199 blurred visions or whatever, how they perceive your website, you can now actually 866 01:10:21.720 --> 01:10:27.800 simulate that and see it for yourself right now. It's not in the production 867 01:10:27.920 --> 01:10:30.239 version of Chrome. You can find it in Canary, but you just you 868 01:10:30.279 --> 01:10:34.119 know, open the depv tools, go to the bottom of the rendering tab 869 01:10:34.560 --> 01:10:39.039 and you will find a drop down there that you know, you can choose 870 01:10:39.079 --> 01:10:44.119 the what kind of vision deficiency you want to check, and just see how 871 01:10:44.199 --> 01:10:47.840 the browser window adjusts. It's really really cool and really really useful, and 872 01:10:47.880 --> 01:10:53.159 I'm really happy that Google has done that. So that's my first pick and 873 01:10:53.439 --> 01:10:58.319 my second pick. You know, you guys keep picking TV shows and I 874 01:10:58.439 --> 01:11:00.359 never did, so I decided to pick one as well. And the one 875 01:11:00.359 --> 01:11:04.039 that I want to pick is one that I really really I'm currently enjoying. 876 01:11:04.079 --> 01:11:09.640 I really love it. It's a better called Soul I was a huge fan 877 01:11:09.920 --> 01:11:13.560 of Breaking Bad. You know, it's up there, like I would guess 878 01:11:13.560 --> 01:11:17.079 in my top three shows of all time, and Better Call Soul is just 879 01:11:17.159 --> 01:11:20.479 awesome. When it started, I was really worried that they couldn't live up 880 01:11:20.560 --> 01:11:26.319 to Breaking Bad, but they have. It's really different. The pace is 881 01:11:26.319 --> 01:11:30.840 completely different, and the characters there's a lot of similarity, but the main 882 01:11:30.960 --> 01:11:34.000 character is certainly different than the main character of Breaking Bad. It's a totally 883 01:11:34.039 --> 01:11:39.640 different personality. But the show is still is just so great. I'm really 884 01:11:39.680 --> 01:11:43.720 really loving it. I'm really enjoying it, and I can't recommend it highly 885 01:11:43.800 --> 01:11:47.279 enough. So those are my picks. Awesome. So in terms of media, 886 01:11:47.800 --> 01:11:53.840 I have got to pick Brandon Sanderson's The Way of Kings. I think 887 01:11:54.079 --> 01:12:00.000 that it might be I haven't watched that dirty, filthy, soft porn show 888 01:12:00.119 --> 01:12:06.680 myself, but I think that's Some people say it's tactically a similar idea to 889 01:12:08.760 --> 01:12:13.119 Game of Thrones, but in a family friendly way where you know, yeah, 890 01:12:13.119 --> 01:12:15.279 there's a little bit of blood, but there's no just lewdness to it. 891 01:12:15.680 --> 01:12:19.880 So I can't say for sure, but it seems like the two have 892 01:12:20.159 --> 01:12:24.840 some level of comparison. But I just I just love it, Oh my 893 01:12:24.920 --> 01:12:30.800 gosh. And Brandon Sanderson is just such an amazing author. He's I mean, 894 01:12:30.399 --> 01:12:35.199 I would have never picked fantasy as a genre that I was interested in, 895 01:12:35.720 --> 01:12:41.359 But the way that Brandon Sanderson writes, it's so methodical and logical that 896 01:12:42.039 --> 01:12:47.000 the fantasy feels more like science fiction that he writes. It's interesting that you 897 01:12:47.119 --> 01:12:51.760 use that as the comparison. I just want I've read it as well. 898 01:12:51.920 --> 01:12:57.439 I've also enjoyed it a whole lot. I just want to make sure people 899 01:12:57.439 --> 01:13:01.159 are aware that the series is not yet complete. I think he's supposed to 900 01:13:01.159 --> 01:13:05.600 write quite a number of additional books there. Hopefully this won't end up like 901 01:13:05.680 --> 01:13:11.000 what's going on with Game of Thrones, where you know it never actually happens 902 01:13:11.199 --> 01:13:15.399 and where it kind of stuck. So Brandon Sanderson has a good track record 903 01:13:15.600 --> 01:13:23.039 of rotating through his novels and completing them, so I like it may be 904 01:13:23.119 --> 01:13:26.960 a decade before the series is complete, because it seems like this one is 905 01:13:27.600 --> 01:13:31.119 like his masterpiece that he's been working on here and there, letting it float 906 01:13:31.159 --> 01:13:34.560 around in the back of his head since like the nineties or something, and 907 01:13:35.000 --> 01:13:39.840 has finally gotten it to a point where over the last several years he's been 908 01:13:39.840 --> 01:13:45.159 publishing. But I have faith that Brandon Sanderson will actually complete his works because 909 01:13:45.159 --> 01:13:47.640 he seemed to have demonstrated that in the past, and he's talked about his 910 01:13:47.760 --> 01:13:53.840 methodology of how he writes his books, and from what I understand, he 911 01:13:54.800 --> 01:14:00.399 writes the outline of the of the series so that the plot points are developed, 912 01:14:00.960 --> 01:14:06.640 and then starts writing each book and revises as he goes. So he 913 01:14:06.720 --> 01:14:13.119 makes a point of talking about how he knows where the story is going before 914 01:14:13.159 --> 01:14:17.000 he publishes the first book, which I think with some other authors. I 915 01:14:19.159 --> 01:14:25.199 the Name of the Wind comes to mind. Yeah, he stuck. I 916 01:14:25.279 --> 01:14:30.079 understood that he wrote the book and then threw it away or something. Supposedly 917 01:14:30.119 --> 01:14:34.399 the third book he wrote it and didn't like it and is revamping it, 918 01:14:35.840 --> 01:14:40.800 But I don't know. Like it started so strong, Like the Way of 919 01:14:40.880 --> 01:14:45.479 Kings is what I wanted out of Name of the Wind really like that's what 920 01:14:45.600 --> 01:14:48.000 I thought that I was getting into. It has very similar vibe and feel 921 01:14:48.079 --> 01:14:55.119 and storytelling technique and jumping back and forth between time periods and so like. 922 01:14:55.319 --> 01:14:58.520 To me, the books feel very similar, except that the Way of Kings. 923 01:14:58.840 --> 01:15:01.039 I step confidence that the whole thing's going to come to a conclusion. 924 01:15:01.079 --> 01:15:06.720 Whereas Name of the Wind, it started becoming tangent after tangent, after tangent 925 01:15:06.800 --> 01:15:12.520 after tangent, and then it's like, okay, well, like even if 926 01:15:12.560 --> 01:15:15.960 you could wrap this all up, does it mean anything anymore? So, 927 01:15:15.399 --> 01:15:18.960 yeah, I know what you mean. It's kind of like lost in a 928 01:15:19.039 --> 01:15:25.479 sense the TV show that you create this really amazing yarn, but then you 929 01:15:25.520 --> 01:15:30.159 have a problem pulling all the threats together. Another issue that I have, 930 01:15:30.279 --> 01:15:32.760 though, even with that book, is that by the time the next book 931 01:15:32.840 --> 01:15:36.840 comes out, so much time would have elapsed. I might start forgetting the 932 01:15:36.880 --> 01:15:44.560 plot. I don't know what the plot is, my wife. So my 933 01:15:44.560 --> 01:15:47.640 wife and I started reading it last year, and then I kind of felt 934 01:15:47.720 --> 01:15:50.960 like, I don't know if this guy's going to deliver, So I became 935 01:15:51.039 --> 01:15:55.079 less invested. And then she read through the second book on her own and 936 01:15:55.159 --> 01:15:58.359 kind of like gave me the recaps, and every time she told me what 937 01:15:58.399 --> 01:16:00.760 was going on, I'm like, this just seems like it's less and less 938 01:16:00.760 --> 01:16:04.119 focused. Anyway, not a bag on it, because I think that the 939 01:16:04.119 --> 01:16:08.159 premise was awesome, and you know, he could tie it up really well. 940 01:16:08.199 --> 01:16:11.119 The execution of the third book. Maybe why he's waiting on it so 941 01:16:11.159 --> 01:16:13.119 long, as you know, is to get it just right. So he 942 01:16:13.239 --> 01:16:15.479 yeah, maybe he'll just nail it and hit it out the park, so 943 01:16:15.800 --> 01:16:19.039 hopefully. Well so yeah, one last thing I'll say about that is that 944 01:16:19.159 --> 01:16:24.600 it's set in the same universe as his other books, the so called cosmir 945 01:16:24.920 --> 01:16:28.279 Oh. Yeah, if anybody wants to go through a series that he did 946 01:16:28.359 --> 01:16:32.000 start and then finish, they can look at his excellent miss Bourne series as 947 01:16:32.039 --> 01:16:36.960 well. Yeah. The miss Bourne is a wonderful work, and I in 948 01:16:38.000 --> 01:16:42.359 some ways I prefer Lantris, which I think was more his entry into his 949 01:16:42.399 --> 01:16:47.199 own you know, like his first popular book that he did himself. But 950 01:16:47.359 --> 01:16:51.720 at Lantris is very interesting. It takes like five chapters to get into because 951 01:16:51.760 --> 01:16:56.680 they rotate through the characters, and it takes you the five chapters just to 952 01:16:56.760 --> 01:16:59.960 kind of understand like, oh, this is the place that we're in, 953 01:17:00.000 --> 01:17:02.640 and this is how these characters are relating to each other, and you can 954 01:17:02.640 --> 01:17:06.079 start to imagine a path where they start converging that it's not just three separate 955 01:17:06.119 --> 01:17:11.880 stories, but the first three chapters it's just like three completely different stories. 956 01:17:11.920 --> 01:17:14.960 And that was a new way of storytelling for me. The way of Kings 957 01:17:15.000 --> 01:17:17.359 kind of bounces back and forth. It's not methodical, like this chapter is 958 01:17:17.359 --> 01:17:20.039 about this character, this chapter is about this character, this chapter is about 959 01:17:20.039 --> 01:17:23.880 this character. But it does bounce back and forth where it's like, here's 960 01:17:23.880 --> 01:17:27.239 two chapters about this character, now here's a chapter about this character. We're 961 01:17:27.239 --> 01:17:30.239 gonna skip this other character for a little bit because nothing's going on in their 962 01:17:30.279 --> 01:17:31.680 world right now. We've said all we need to say about them, and 963 01:17:31.720 --> 01:17:38.439 then come back to them ten chapters later. So I'll throw in another retroactive 964 01:17:38.520 --> 01:17:42.800 pick. If you've listened, if you've listened to my other picks. Throughout 965 01:17:43.560 --> 01:17:48.119 all the episodes of jas Jabbra that I participated on, I actually described various 966 01:17:48.439 --> 01:17:55.079 fantasy classics like books fantasy books that I really really love. So if you 967 01:17:55.199 --> 01:17:59.000 go back even just look at the pick section on the jas Jabbra website, 968 01:17:59.279 --> 01:18:02.920 you will find quite a number of really excellent fantasy books, most of them 969 01:18:02.960 --> 01:18:08.199 complete series is that you can chew that I would definitely highly recommend for you 970 01:18:08.279 --> 01:18:11.079 to check out. So if you're into that kind of stuff, you know, 971 01:18:11.520 --> 01:18:15.520 please do then you know, since I haven't babbled on long enough. 972 01:18:15.920 --> 01:18:18.960 I'm also going to pick Taco Bell. If you don't have a Taco Bell 973 01:18:19.000 --> 01:18:21.800 in the country where you live, let me tell you you are missing out 974 01:18:21.920 --> 01:18:29.680 on the finest American misrepresentation of Latin food that you could possibly be missing out 975 01:18:29.720 --> 01:18:34.560 on. A ninety seven cent burtas have never tasted so good, and I 976 01:18:36.119 --> 01:18:43.079 just I can't stomach the authentic stuff in comparison, I really don't like most 977 01:18:43.199 --> 01:18:45.640 Latin food, but I do love Taco Bell. And there's a couple of 978 01:18:45.680 --> 01:18:50.479 like American Latin fusion restaurants that I do really like because they, you know, 979 01:18:50.520 --> 01:18:54.399 they do the things that Americans like. They have nice presentation, they 980 01:18:54.800 --> 01:18:58.520 put on the mole i sauce on probably things that maybe Mola doesn't traditionally go 981 01:18:58.640 --> 01:19:04.560 on. And which way, yes, yes, the I forget how to 982 01:19:04.560 --> 01:19:11.079 say chicken, but you know the chicken fingers with with with vinegar, tomato 983 01:19:11.199 --> 01:19:17.800 sauce. Uh no, anyway. Uh So that's all. Thanks for listening 984 01:19:17.800 --> 01:19:24.000 in. Thanks for everybody that was on the show today that was already left 985 01:19:24.039 --> 01:19:27.960 now. Yeah, and we wore them out. We wore them out, 986 01:19:28.000 --> 01:19:31.119 we wore them down. We'll catch you next time on a new episode. 987 01:19:31.359 --> 01:19:34.960 Of J. S. Jabberz Bye ideas