WEBVTT 1 00:00:05.240 --> 00:00:08.839 Hey, folks, welcome back to another episode of JavaScript Jabber. 2 00:00:09.039 --> 00:00:12.320 This week, on our panel, we have Steve Edwards. 3 00:00:12.000 --> 00:00:15.160 Yo yo yo, come in at you live from Portland. 4 00:00:15.480 --> 00:00:17.640 I'm filling in for a j since he's not here 5 00:00:17.679 --> 00:00:18.760 right now right. 6 00:00:18.800 --> 00:00:20.239 We also have Dan shpier. 7 00:00:20.839 --> 00:00:25.320 Hey sitting in the air conditioning room in hot and sunny. 8 00:00:25.320 --> 00:00:26.320 Tell the league. 9 00:00:26.399 --> 00:00:28.600 I'm Charles Maxwood from Top End Devs and we have 10 00:00:28.600 --> 00:00:33.240 a special guest this week and that's your weiss. Do 11 00:00:33.280 --> 00:00:34.359 you want to introduce yourself? 12 00:00:34.439 --> 00:00:35.159 Let people know it. 13 00:00:35.520 --> 00:00:37.399 We've had you on before, so I think some people 14 00:00:37.439 --> 00:00:38.520 know who you are, and then. 15 00:00:39.280 --> 00:00:41.399 There may be a few they don't. They should. 16 00:00:41.920 --> 00:00:45.399 Yeah, sure I can introduce myself. 17 00:00:46.119 --> 00:00:51.799 So hey, I've been working on web performance for way 18 00:00:51.840 --> 00:00:56.759 too long, trying to solve it and so far not 19 00:00:56.840 --> 00:01:05.519 being super successful. I been working on browsers since twenty twelve, 20 00:01:07.519 --> 00:01:12.719 and initially on my own, then at a Kamai working 21 00:01:12.799 --> 00:01:18.599 on both browsers and server features, then at Google for 22 00:01:18.640 --> 00:01:22.480 a few years, and nowadays I'm at Shopify, still working 23 00:01:22.519 --> 00:01:27.560 on the web platform amongst other things. I co chair 24 00:01:28.000 --> 00:01:33.599 the Web Performance Working Group and I'm one of the 25 00:01:33.840 --> 00:01:39.760 doink api owners, which is basically the folks that sign 26 00:01:39.799 --> 00:01:47.599 off on features getting released in Chromeum. 27 00:01:46.359 --> 00:01:49.040 The working group is what it's worth mentioning is part 28 00:01:49.079 --> 00:01:50.040 of the W THREEC. 29 00:01:50.760 --> 00:01:53.840 Yes, yeah, yeah, the W three C Web Performance working Group. Yeah. 30 00:01:54.319 --> 00:01:56.200 I would like to point out that it's from a 31 00:01:56.280 --> 00:01:58.359 visual standpoint, it's easy to tell how smart he is 32 00:01:58.359 --> 00:02:02.480 by his haircut, just saying so, yeah. 33 00:02:02.359 --> 00:02:05.280 He's one of these guys that shapes his head even 34 00:02:05.319 --> 00:02:06.280 though he has hair. 35 00:02:09.240 --> 00:02:14.639 Yeah yeah, I wouldn't define it as has. 36 00:02:14.479 --> 00:02:17.360 Hair, but yeah, well got made only so many perfect 37 00:02:17.400 --> 00:02:20.039 heads and the rest he covered with hair, So that's right. 38 00:02:20.960 --> 00:02:25.159 I like to say that I'm also I'm an invited 39 00:02:25.280 --> 00:02:28.639 expert on that same working group. The guy who invited 40 00:02:28.639 --> 00:02:31.719 me over it is job, so I'm very thankful for that. 41 00:02:33.400 --> 00:02:35.120 I'm thankful for contributions. 42 00:02:35.199 --> 00:02:39.840 So yeah, doing fighting the good fight, trying to make 43 00:02:39.879 --> 00:02:42.240 the web faster for everybody's sake. 44 00:02:43.199 --> 00:02:48.599 So, Yo, we got this document from you about JavaScript loading, 45 00:02:49.039 --> 00:02:53.520 and it's interesting because it starts off with you changed jobs. 46 00:02:53.520 --> 00:02:56.800 So you want to kind of give us some context 47 00:02:56.840 --> 00:02:58.680 on that and then we can jump in and talk 48 00:02:58.680 --> 00:02:59.680 about JavaScript floating. 49 00:03:00.159 --> 00:03:04.960 Yeah sure, so yeah, So basically, I, like I said, 50 00:03:05.599 --> 00:03:11.240 worked on Chrome at Google for five years up until 51 00:03:11.439 --> 00:03:15.120 a few months back. And yeah, and earlier this year 52 00:03:15.280 --> 00:03:22.639 I changed employers. But the good thing about open source 53 00:03:22.840 --> 00:03:24.879 is that I get to do a lot of the 54 00:03:24.960 --> 00:03:31.000 same things with a different head on. Basically, I've been 55 00:03:31.199 --> 00:03:36.680 working on making the web faster by default, I've been 56 00:03:36.719 --> 00:03:42.360 doing that before joining Google, and I get to do 57 00:03:42.439 --> 00:03:48.520 that afterwards. So I continue to work on on Chromium. 58 00:03:49.120 --> 00:03:51.800 I now also get to work on WebKit, which is 59 00:03:52.199 --> 00:03:58.120 a refreshing change and the only thing with I guess 60 00:03:59.400 --> 00:04:03.840 with the change from working for a browser vendor to 61 00:04:03.919 --> 00:04:07.479 working more like closer to the industry, it kind of 62 00:04:07.479 --> 00:04:12.439 helps to keep me aligned with what developers actually need, 63 00:04:12.800 --> 00:04:19.879 because working for a browser vendor is great, but it's 64 00:04:19.959 --> 00:04:25.040 also it makes it hard to keep up with what 65 00:04:26.199 --> 00:04:31.319 actual developers are doing because browser developers are not Web developers, 66 00:04:31.360 --> 00:04:37.480 at least not really. Yeah, and working as part of 67 00:04:37.560 --> 00:04:43.519 the you know, quote unquote industry makes it easier to 68 00:04:43.639 --> 00:04:47.240 make sure that my work is actually aligned with what 69 00:04:47.399 --> 00:04:50.839 people need, So that part is something I'm very very 70 00:04:50.839 --> 00:04:51.399 happy about. 71 00:04:51.600 --> 00:04:51.800 Yeah. 72 00:04:51.839 --> 00:04:56.040 Other than that, there aren't a lot of commerce voices 73 00:04:56.519 --> 00:05:01.199 amongst people who work on browsers, so I'm very happy 74 00:05:01.240 --> 00:05:04.360 to bring in that perspective to those discussions. 75 00:05:04.920 --> 00:05:10.759 That's especially interesting given that probably the organizations or the 76 00:05:11.240 --> 00:05:16.839 web that's websites web apps that have potentially the greatest 77 00:05:16.959 --> 00:05:22.240 need for web performance or see the greatest impact from 78 00:05:22.319 --> 00:05:28.000 improving web performance are commerce related websites. In many cases. Yeah, 79 00:05:28.199 --> 00:05:34.079 there's always those you know, research papers showing like Amazon 80 00:05:34.759 --> 00:05:38.639 increase their revenue by a trillion dollars because they spend 81 00:05:38.720 --> 00:05:42.319 up loading time by five milliseconds or something along these sides. 82 00:05:42.800 --> 00:05:47.639 Yeah, I don't know about these exact numbers, but but yeah, 83 00:05:47.720 --> 00:05:52.120 basically performance is very important. There are a lot of 84 00:05:52.680 --> 00:05:57.199 public case studies about the relationship between web performance and 85 00:05:57.240 --> 00:06:02.040 conversion rates. And I'm biased, but it seems to me 86 00:06:02.319 --> 00:06:06.560 that it's like crucial to have that kind of influence 87 00:06:07.120 --> 00:06:11.000 on you know, on web standards and and where the 88 00:06:11.000 --> 00:06:12.000 web platform is going. 89 00:06:12.480 --> 00:06:16.360 Yeah. By the way, the Google driven website web dot 90 00:06:16.399 --> 00:06:20.120 dep which is an excellent website, has a case studies 91 00:06:20.160 --> 00:06:24.639 section which actually has real numbers, not numbers invented by me, 92 00:06:25.319 --> 00:06:31.839 that describe how companies did in fact significantly increase their conversion, 93 00:06:32.079 --> 00:06:36.360 their income or whatever thanks to improving performance. And like 94 00:06:36.399 --> 00:06:41.160 you said, it's it's not really surprising. Uh, you know, 95 00:06:42.399 --> 00:06:47.680 it's we have We're in an age of you know, 96 00:06:47.839 --> 00:06:51.879 little patients and a lot of distractions, and if your 97 00:06:51.920 --> 00:06:56.079 website takes too long, too low, then people will go elsewhere. Yeah. 98 00:06:56.199 --> 00:07:00.759 If if you remove friction, good things happen in general. 99 00:07:01.800 --> 00:07:05.480 Yeah, it reminds me of when I told someone that 100 00:07:07.079 --> 00:07:13.160 the said that the pipeline or the funnel at the 101 00:07:13.199 --> 00:07:16.720 previous company that I worked at is implemented in Angular. 102 00:07:17.319 --> 00:07:21.959 Their response was, don't let angular get between your customers 103 00:07:22.000 --> 00:07:27.879 and potential customers and the payment something along these lines. 104 00:07:29.319 --> 00:07:34.839 But but yeah, it is important to reduce friction as 105 00:07:34.879 --> 00:07:38.160 much as possible, and improving performance is certainly a good 106 00:07:38.199 --> 00:07:38.800 way to do that. 107 00:07:41.079 --> 00:07:47.519 So we're talking about the JavaScript bloating today, So how 108 00:07:47.560 --> 00:07:53.120 does that get into this friction or frictionless performance set up. 109 00:07:54.439 --> 00:08:00.240 So I've been unhappy with the way that JavaScript is 110 00:08:00.279 --> 00:08:02.279 being loaded on the web for a long while, but 111 00:08:02.600 --> 00:08:09.319 haven't been able to move that too much just yet. 112 00:08:09.439 --> 00:08:15.600 But it's essentially I think that in many ways, when 113 00:08:15.639 --> 00:08:22.319 we're looking at web performance and loading performance, there isn't 114 00:08:22.399 --> 00:08:27.639 really a good way to load JavaScript, and the main 115 00:08:27.720 --> 00:08:35.080 advice that web performance folks can tell people or have 116 00:08:35.200 --> 00:08:39.840 been telling people is just to load less JavaScript, which 117 00:08:39.960 --> 00:08:47.200 is correct but not necessarily useful in today's web development environment. 118 00:08:47.759 --> 00:08:53.240 If you can load your site with less JavaScript, you should. 119 00:08:54.399 --> 00:08:56.600 But at the same time, there are a lot of 120 00:08:56.679 --> 00:09:04.720 JavaScript based but like even for those, loading performance matters. 121 00:09:05.200 --> 00:09:12.600 Loading performance matters because your users interact with your website. 122 00:09:12.639 --> 00:09:16.159 They will right click and open a new tab, they 123 00:09:16.200 --> 00:09:20.759 will reload your browser will unload your app in the 124 00:09:20.799 --> 00:09:25.159 background in order to save memory. And in those cases 125 00:09:26.080 --> 00:09:32.399 you're you're effectively heating reload even if you even if 126 00:09:32.440 --> 00:09:36.440 your if your site is you know there all day. 127 00:09:37.559 --> 00:09:40.240 There are a lot of interactions where loading performance matters. 128 00:09:40.240 --> 00:09:45.720 So essentially there are no good ways today to load scripts. 129 00:09:46.080 --> 00:09:49.159 And yeah, then and I as part of we started 130 00:09:49.320 --> 00:09:53.559 enumrating the different number of ways of that you can 131 00:09:53.600 --> 00:09:57.559 load scripts. But it's essentially if if you go back 132 00:09:57.559 --> 00:10:02.519 to the basics, we have blocking script that are you know, 133 00:10:03.200 --> 00:10:08.120 they are not a good pattern because they are blocking 134 00:10:08.200 --> 00:10:13.600 the parser from processing the rest of the document. There 135 00:10:13.639 --> 00:10:18.720 are acink scripts who are not necessarily a good pattern 136 00:10:18.840 --> 00:10:23.879 because they are racing and will potentially get in the 137 00:10:23.919 --> 00:10:28.120 way of more important things if they happen to load earlier. 138 00:10:29.399 --> 00:10:34.799 And we have deferred scripts who are really like, it's 139 00:10:34.879 --> 00:10:40.879 a relatively well defined model and it doesn't block the parser. 140 00:10:41.320 --> 00:10:45.279 But at the same time, they are often like they're 141 00:10:45.320 --> 00:10:48.360 always loading in a single milestone, a single point in 142 00:10:48.399 --> 00:10:52.360 time in the page life cycle, and that may or 143 00:10:52.399 --> 00:10:53.639 may not be sufficient. 144 00:10:53.960 --> 00:10:59.200 So I think though it is important to mention that. 145 00:10:59.360 --> 00:11:03.080 Even though so talking about blocking scripts, which are the 146 00:11:03.159 --> 00:11:07.679 most obvious way in initial and kind of the oldest way, 147 00:11:07.759 --> 00:11:11.080 I guess, because really, if you don't say anything else, 148 00:11:11.240 --> 00:11:14.679 then a script is blocking by by default, like this 149 00:11:14.799 --> 00:11:20.440 is the way the web was originally built. It's it's problematic, 150 00:11:20.919 --> 00:11:26.799 like you said, it's usually bad, but it's needed because 151 00:11:26.840 --> 00:11:33.000 sometimes you need to do some things before rendering can proceed. 152 00:11:33.200 --> 00:11:36.759 So it's it's when we say blocking, what it really 153 00:11:36.799 --> 00:11:40.679 means is render. Blocking means that when the browser hits 154 00:11:40.720 --> 00:11:45.519 that point that script tag, it has to stop rendering 155 00:11:45.720 --> 00:11:49.200 until that script finishes. I know that some browsers do 156 00:11:49.399 --> 00:11:54.360 hacks around that, but really, at the logical level, that's 157 00:11:54.399 --> 00:11:55.840 what it means, right. 158 00:11:57.320 --> 00:12:02.720 Yeah, But there so there is a better alternative to that, 159 00:12:03.279 --> 00:12:10.159 which is blocking equals render, which gives you essentially it 160 00:12:10.159 --> 00:12:13.799 gives your acing script or deferred script, the ability to 161 00:12:13.919 --> 00:12:17.759 block rendering but not block the parser, so the browser 162 00:12:17.799 --> 00:12:22.240 can continue to do work, but the user doesn't see 163 00:12:22.600 --> 00:12:26.000 things flashing around before that script. 164 00:12:26.039 --> 00:12:28.679 Oh yeah, I forgot that one, and maybe I should 165 00:12:28.679 --> 00:12:32.759 have even added that to the list. In this In 166 00:12:32.799 --> 00:12:37.279 this context, it's you know, the web is something of 167 00:12:37.759 --> 00:12:43.120 you know, like an archaeological site. You know, it's it's 168 00:12:43.279 --> 00:12:46.720 layers upon layers of history. And and the thing about 169 00:12:46.720 --> 00:12:50.720 the web is that once something has been implemented, it 170 00:12:50.799 --> 00:12:54.720 can almost never be taken away and must be supported 171 00:12:54.799 --> 00:12:58.440 forever and ever. So in the very olden days, I 172 00:12:58.480 --> 00:13:01.480 think it was brendan Ike that introduce the concept of 173 00:13:01.639 --> 00:13:08.200 document right, which enabled JavaScript to kind of inject content 174 00:13:08.639 --> 00:13:15.000 into the HTML stream, into the document downloading stream, and therefore, 175 00:13:15.399 --> 00:13:20.000 because of that, scripts had to be blocking, because you 176 00:13:20.039 --> 00:13:24.720 couldn't proceed with processing the HTML just in case something 177 00:13:25.159 --> 00:13:30.159 happened to be injected into it. Now nobody uses document well, 178 00:13:30.240 --> 00:13:35.240 I can't say nobody, but hardly anybody uses document right anymore. 179 00:13:35.240 --> 00:13:38.240 It's like a fraction of a fraction of a percent 180 00:13:38.440 --> 00:13:43.080 of websites, I would say, But it still needs to 181 00:13:43.120 --> 00:13:47.360 be there. You're smiling, you off, so I'm guessing more websites. 182 00:13:49.960 --> 00:13:55.080 Maybe sure, and we can let me see, probably like 183 00:13:57.120 --> 00:14:00.399 SSL VPNs or something. Use it for evil in the 184 00:14:00.519 --> 00:14:03.639 various things, or maybe all sorts of firewalls or whatnot. 185 00:14:04.200 --> 00:14:09.720 Use it for crazy stuff. But it's not something that. 186 00:14:09.879 --> 00:14:13.639 Let's put it differently, ninety nine point ninety nine percent 187 00:14:14.200 --> 00:14:18.720 of web developers don't use it, but it still needs 188 00:14:18.759 --> 00:14:21.879 to be supported, so it's still there. So scripts are 189 00:14:22.039 --> 00:14:28.039 not just render blocking. They're download and parsing blocking, as 190 00:14:28.080 --> 00:14:30.759 it were. And like you have said, if you put 191 00:14:30.840 --> 00:14:35.080 loading equals render, then you're telling it basically telling the browser. Look, 192 00:14:35.120 --> 00:14:39.200 you need to pause the rendering because maybe I'm doing 193 00:14:39.320 --> 00:14:45.200 logic around dark mode and I don't want content flashing 194 00:14:45.320 --> 00:14:48.720 or something, so you need to pause the rendering. But 195 00:14:49.480 --> 00:14:53.360 I'm not using document, right, I promise, so you can 196 00:14:53.519 --> 00:14:58.559 actually continue parsing stuff because I won't be modifying the 197 00:14:58.679 --> 00:15:03.240 download the documents stream. So yeah, I to be honest, 198 00:15:03.279 --> 00:15:08.960 like I said, I actually forgot about that. That option. Another, 199 00:15:09.039 --> 00:15:12.240 by the way, interesting option is again if you have 200 00:15:12.320 --> 00:15:16.000 a blocking script, whether it's in the head or the 201 00:15:16.039 --> 00:15:19.759 bottom of the body, that also kind of modifies the 202 00:15:19.840 --> 00:15:21.480 behavior as I recall. 203 00:15:21.799 --> 00:15:29.159 It modifies the priority. It's not like the script will 204 00:15:29.200 --> 00:15:35.639 block parsing whenever it's discovered, but if it's discovered at 205 00:15:35.639 --> 00:15:39.879 the bottom of the document, that like parsi're blocking, doesn't 206 00:15:39.919 --> 00:15:43.759 have a huge effect because there's nothing more than that 207 00:15:44.200 --> 00:15:48.679 actual script to parts, so it's blocking nothing behind it. 208 00:15:49.360 --> 00:15:53.840 So if you're some browsers, yeah, we talked about it 209 00:15:53.840 --> 00:15:58.720 with Robin Marx, some browsers in that scenario would actually 210 00:15:58.200 --> 00:16:02.919 reduce the priority you have the script download, some don't. 211 00:16:03.639 --> 00:16:09.600 Yes, yeah, the whole Yeah, so there are generally for 212 00:16:09.759 --> 00:16:16.600 blocking scripts browsers. All browsers nowadays have a mechanism or 213 00:16:16.840 --> 00:16:23.600 all all commercial browsers like if I'm not sure about 214 00:16:23.720 --> 00:16:30.000 for example, ady Bird, but all big browsers have a 215 00:16:30.039 --> 00:16:33.600 mechanism where they continue to parse the document in order 216 00:16:33.639 --> 00:16:38.320 to speculatively fetch resources when they're when they encounter a 217 00:16:38.360 --> 00:16:42.960 blocking script and yes whenever, Like a blocking script of 218 00:16:43.000 --> 00:16:46.320 the head would have a higher priority in some browsers 219 00:16:46.399 --> 00:16:49.799 than a blocking script at the bottom, but all the 220 00:16:50.039 --> 00:16:55.600 like the priorities as well as this speculative preloading of 221 00:16:55.720 --> 00:17:00.639 assets of resources, none of that is specified, so every 222 00:17:00.679 --> 00:17:07.240 browser can pretty much do their thing and Web developers 223 00:17:07.240 --> 00:17:11.400 shouldn't really rely on it. Yes. So basically we have multiple, 224 00:17:13.359 --> 00:17:17.440 multiple ways to load scripts. I am unhappy with all 225 00:17:17.480 --> 00:17:24.519 of them. And then we have essentially for like the 226 00:17:24.559 --> 00:17:28.039 future of script loading for the last I don't know 227 00:17:28.079 --> 00:17:31.799 how many years have been yes modules and. 228 00:17:33.599 --> 00:17:37.559 One more thing before we get to yes modules. I 229 00:17:37.599 --> 00:17:42.759 think that another key aspect that confuses people when they 230 00:17:42.799 --> 00:17:47.000 think about script loading, but really any asset loading in 231 00:17:47.000 --> 00:17:52.480 the browser, is that the difference between important and urgent 232 00:17:53.240 --> 00:17:57.880 isn't always obvious. That some stuff is important because the 233 00:17:57.960 --> 00:18:03.359 page can't work without it, but it might not be urgent, 234 00:18:03.680 --> 00:18:08.440 as in that certain things need to be downloaded sooner. 235 00:18:09.039 --> 00:18:13.759 So for example, in this day and age of SSR 236 00:18:13.880 --> 00:18:20.440 and SSG, where we present stuff visually before it actually 237 00:18:20.559 --> 00:18:25.400 becomes interactive, Like there's a difference in time between when 238 00:18:25.440 --> 00:18:29.200 a page is seen and when a page becomes interactive. 239 00:18:29.759 --> 00:18:34.880 You might say that visibility is more urgent than interactivity. 240 00:18:35.319 --> 00:18:41.559 As long as the difference between the two is sufficiently small. 241 00:18:42.279 --> 00:18:46.400 It's a painful thing because because sufficiently small is a 242 00:18:46.440 --> 00:18:50.519 problematic definition in and of itself, and if it's even 243 00:18:50.640 --> 00:18:53.960 slightly too big, it becomes a real problem. Like the 244 00:18:54.039 --> 00:18:58.839 page literally doesn't properly respond to user interactions, which is 245 00:18:58.880 --> 00:19:05.119 worse than slow, it's really broken. But yeah, I still 246 00:19:05.200 --> 00:19:08.759 think that this distinction between what is urgent and what 247 00:19:08.880 --> 00:19:12.279 is important, Like what is important is stuff that the 248 00:19:12.319 --> 00:19:16.400 page can't properly work without. If a certain image, for example, 249 00:19:16.519 --> 00:19:21.480 is not downloaded, that's not necessarily important. If it's if 250 00:19:21.480 --> 00:19:24.319 it's doesn't get in the way of the pages operations, 251 00:19:24.359 --> 00:19:27.559 so you get a broken icon, you know, you could 252 00:19:27.559 --> 00:19:30.640 still work. On the other hand, let's say if the 253 00:19:30.720 --> 00:19:34.359 CSS doesn't download, then there's a good chance that the 254 00:19:34.400 --> 00:19:38.759 page becomes totally illegible. So that's kind of really important, 255 00:19:39.279 --> 00:19:43.039 and it's also urgent because you need that CSS really quickly, 256 00:19:43.079 --> 00:19:45.960 and JavaScript can be somewhere in the middle between these two. 257 00:19:46.599 --> 00:19:52.839 Yeah, yeah, I guess fonts also is you know, one 258 00:19:52.880 --> 00:19:56.880 of those assets which is like there's no good way 259 00:19:57.119 --> 00:20:01.519 to load them because they are potentially important for branding 260 00:20:01.799 --> 00:20:06.359 and user experience and whatnot. But if they don't download, 261 00:20:06.440 --> 00:20:10.559 then you fall system fonts. That's also like it's still 262 00:20:10.599 --> 00:20:17.240 a usable site. So yeah, there's also so it's an 263 00:20:17.319 --> 00:20:22.119 interesting distinction between important and urgent. I think that there's 264 00:20:22.240 --> 00:20:29.640 also no current way like Another interesting distinction that there's 265 00:20:29.680 --> 00:20:34.599 no way to express today is the difference between when 266 00:20:34.599 --> 00:20:38.119 you want the script to load and when you want 267 00:20:38.160 --> 00:20:43.200 the script to execute, and at least for acing scripts, 268 00:20:43.359 --> 00:20:46.160 those two happen at the same time. As soon as 269 00:20:46.160 --> 00:20:50.240 the script is loaded and the main thread is clear, 270 00:20:50.680 --> 00:20:53.559 that script gets executed, and that may or may not 271 00:20:53.640 --> 00:20:57.640 be the right choice depending on when you need that script. 272 00:20:58.319 --> 00:21:03.279 So there are scripts that you want them to like 273 00:21:03.400 --> 00:21:07.960 load earlier, but still want to be able to control 274 00:21:08.000 --> 00:21:12.079 their execution either manually, and then you can use preload 275 00:21:12.160 --> 00:21:17.039 for that, but that is hacky and cumbersome or otherwise. 276 00:21:17.119 --> 00:21:21.119 The only currently official milestone you have in the page 277 00:21:21.839 --> 00:21:26.720 life cycle is the down content loaded when the whole 278 00:21:26.880 --> 00:21:32.880 HTML finished parsing, that's when the third scripts trigger. And yeah, 279 00:21:33.119 --> 00:21:38.160 there's no way today to express different preferences there. 280 00:21:39.359 --> 00:21:43.119 And again there is even a middle step in between 281 00:21:43.160 --> 00:21:47.240 the two that's kind of less important but still exists 282 00:21:47.720 --> 00:21:49.960 that people might want to be aware of, which is 283 00:21:49.960 --> 00:21:55.440 the parsing. So you're really downloading the script, you're parsing 284 00:21:55.480 --> 00:22:00.880 the script, and then you're executing the parts the parted script. Now. 285 00:22:01.079 --> 00:22:07.039 Per my recollection, some browsers, not all browsers can parse 286 00:22:07.079 --> 00:22:11.240 the script as it downloads. Some of them can even 287 00:22:11.319 --> 00:22:15.559 do it off off of the main thread. Some don't. 288 00:22:16.359 --> 00:22:20.079 Some bundlers get in the way of this by putting 289 00:22:20.319 --> 00:22:26.440 all the script inside strings and then converting those strings 290 00:22:26.480 --> 00:22:32.279 into scripts, which I never really understood why bundlers do that, 291 00:22:32.599 --> 00:22:33.640 but some of them do. 292 00:22:34.319 --> 00:22:40.119 I did not know that. That's that's interesting, and that seems. 293 00:22:41.519 --> 00:22:45.960 Yeah, I think webpack does that in certain situations, at. 294 00:22:45.920 --> 00:22:49.480 Least I wonder if it's dev mode. 295 00:22:50.680 --> 00:22:53.240 I don't think so. I think that if you I don't. 296 00:22:53.279 --> 00:22:55.119 I don't think it's defoe necessarily. 297 00:22:55.799 --> 00:23:00.200 Okay, that's that's interesting, and that can also that can 298 00:23:00.200 --> 00:23:05.400 get in the way of yeah, of parts like a 299 00:23:05.519 --> 00:23:09.599 parallel parsing in the background. It can also maybe get 300 00:23:09.640 --> 00:23:11.920 in the way of code caching, although I guess if 301 00:23:11.960 --> 00:23:20.200 those strings don't change then eventually yeah, I'm yeah, not sure, 302 00:23:20.279 --> 00:23:23.160 but it's it seems less than idea. 303 00:23:23.880 --> 00:23:30.119 So you were saying that we can separate so the 304 00:23:31.279 --> 00:23:35.559 downloading and parsing can happen together. Not even so we 305 00:23:35.680 --> 00:23:41.319 can actually download without parsing by prefetching. We can download 306 00:23:41.359 --> 00:23:47.319 and parse together but not execute by preloading, or we 307 00:23:47.359 --> 00:23:51.119 can just load the script which does all three or 308 00:23:51.160 --> 00:23:54.640 maybe avoid some of them if you've already prefetched or preloaded. 309 00:23:55.240 --> 00:23:57.880 Yes, but the problem with the script loading, like if 310 00:23:58.240 --> 00:24:01.839 that the most straightforward mechanism for just loading the script 311 00:24:02.400 --> 00:24:05.680 doesn't give you any control regarding to when that script 312 00:24:05.720 --> 00:24:10.480 is executed, at least when you're going with acinkscripts and 313 00:24:11.279 --> 00:24:13.599 like we deferred as well give to you a certain 314 00:24:13.640 --> 00:24:17.880 point in time in which your script will execute. 315 00:24:18.359 --> 00:24:22.960 And yeah, so talking about the sink scripts for a second. 316 00:24:23.000 --> 00:24:28.160 So sink script scripts become a sink either because you 317 00:24:28.319 --> 00:24:33.440 explicitly put the sync attribute on the script tag or 318 00:24:33.720 --> 00:24:39.799 if you've added them dynamically into the HTML. Then there 319 00:24:39.799 --> 00:24:44.599 are sync by default as I recall, or if there 320 00:24:44.640 --> 00:24:48.799 are our modules by default of sync or deferred. I 321 00:24:48.880 --> 00:24:51.279 always forgetfer. 322 00:24:50.480 --> 00:24:52.119 Modules are deferred by default. 323 00:24:52.680 --> 00:24:56.799 Okay, So those are the two scenarios in which it's 324 00:24:56.799 --> 00:25:01.960 a sink. A sink, as its name implies, downloads without blocking. 325 00:25:02.400 --> 00:25:05.319 It downloads the background. But the problem with it, as 326 00:25:05.359 --> 00:25:09.799 you said, is that it's executed as soon as it's 327 00:25:10.400 --> 00:25:13.960 finished downloading, and the browser can execute it if we'll 328 00:25:14.039 --> 00:25:17.680 execute it. Yes, I mean that there's no guarantee about 329 00:25:17.920 --> 00:25:21.079 order of things and what else the browser or may 330 00:25:21.200 --> 00:25:22.279 or may not have done. 331 00:25:22.640 --> 00:25:28.319 Yeah, and beyond the lack of guarantees regarding ordering, I've 332 00:25:28.359 --> 00:25:32.319 seen a lot of cases in the past where you know, 333 00:25:32.400 --> 00:25:39.200 people have some scripts are critical for rendering. They are 334 00:25:39.519 --> 00:25:43.200 like they contain they render the main content, and other 335 00:25:43.319 --> 00:25:46.759 scripts aren't. People load all of them with acing scripts. 336 00:25:47.599 --> 00:25:52.920 And then if you naively preload those scripts. Basically, if 337 00:25:53.039 --> 00:25:57.400 if you make acing script go faster, some pages will 338 00:25:57.440 --> 00:26:01.640 get slower, some pages will get will get faster, and 339 00:26:01.720 --> 00:26:07.400 some will see a mix of like essentially both where 340 00:26:08.240 --> 00:26:12.119 some parts of the like some parts of the critical experience, 341 00:26:12.200 --> 00:26:14.880 get faster, but then they there are other scripts that 342 00:26:14.920 --> 00:26:18.559 should have run later that get in the way because 343 00:26:19.279 --> 00:26:24.160 execute execution times essentially grabs a hold of the of 344 00:26:24.200 --> 00:26:27.799 the main thread for things that aren't critical. 345 00:26:29.079 --> 00:26:32.799 Yeah. So again you're you're saying something is not urgent, 346 00:26:33.000 --> 00:26:35.880 I'll make it a sync. But what you're not taking 347 00:26:35.920 --> 00:26:40.559 into account is that the browser will start downloading it immediately, 348 00:26:40.720 --> 00:26:44.039 even if it's a lower priority, and if it happens 349 00:26:44.079 --> 00:26:48.319 to be a relatively quick download, then it might get 350 00:26:48.400 --> 00:26:53.079 executed faster than you expect. Ahead of more more urgent stuff, 351 00:26:53.559 --> 00:26:57.519 and if its execution is lengthy for any reason whatsoever, 352 00:26:57.839 --> 00:27:01.480 because it loops up to a trillion or what, then 353 00:27:01.720 --> 00:27:06.599 you're basically stuck. So you either need to write if 354 00:27:06.640 --> 00:27:08.839 it's your own script, you need to write it in 355 00:27:08.880 --> 00:27:13.039 a way that ensures that it doesn't execute really too soon, 356 00:27:13.920 --> 00:27:17.200 or alternatively, you might want to load it at a 357 00:27:17.279 --> 00:27:19.759 later time, not just using a sin. 358 00:27:20.359 --> 00:27:26.359 Yeah, and in the past, I've seen optimizations that preloaded 359 00:27:26.440 --> 00:27:31.599 things and made like made everything slower because those acing 360 00:27:31.680 --> 00:27:33.880 scripts ran too too early. 361 00:27:35.039 --> 00:27:37.400 And again we kind of spoke about it with Robin 362 00:27:37.480 --> 00:27:41.079 as well. The reason that people preload scripts. You might ask, 363 00:27:41.160 --> 00:27:44.759 if I'm loading scripts up front, why would I preload 364 00:27:44.839 --> 00:27:48.640 the scripts? You know, it seems like a useless operation. 365 00:27:49.319 --> 00:27:54.079 But the thing is that preloading actually impacted the download 366 00:27:54.119 --> 00:27:58.559 priority or could impact the download priority, which could make 367 00:27:58.599 --> 00:28:02.599 the scripts and I'm making air quotes download faster. These days, 368 00:28:02.640 --> 00:28:06.279 you've got more let's call it the natural way of 369 00:28:06.319 --> 00:28:10.920 doing it, which is the fetch priority attribute. 370 00:28:11.359 --> 00:28:16.880 Yeah, but you also have you know, there are systems 371 00:28:16.880 --> 00:28:26.000 out there who detect scripts as get for example, scripture 372 00:28:26.079 --> 00:28:31.359 or else from run data and then automatically preload those 373 00:28:31.400 --> 00:28:35.440 in order to accel, Like, let's get all the scripts 374 00:28:35.440 --> 00:28:40.640 that loaded before FCPO or LCP, preload them and then 375 00:28:40.720 --> 00:28:44.440 make things faster. And some of those scripts are in 376 00:28:44.759 --> 00:28:47.519 HTML and could have just had the fetch priority, but 377 00:28:47.559 --> 00:28:53.160 some of them are laid discovered and are dynamically injected 378 00:28:53.240 --> 00:28:56.240 through other scripts, and that part is not like it's 379 00:28:56.359 --> 00:29:00.359 less trivial like in those cases helps more. 380 00:29:02.160 --> 00:29:03.160 Also, we used to. 381 00:29:03.079 --> 00:29:08.480 Have a thing called server push, which even like loaded 382 00:29:08.519 --> 00:29:12.680 these scripts even earlier, and those kind of optimizations often 383 00:29:12.880 --> 00:29:20.279 ended up with basically results, Yeah, bimodal results. Some pages 384 00:29:20.319 --> 00:29:24.119 get way faster, some pages get way slower, and. 385 00:29:24.359 --> 00:29:27.680 Some pages get faster in some scenarios and slower in 386 00:29:27.720 --> 00:29:32.920 other scenarios, like depending on network conditions and stuff like that. Yeah, 387 00:29:32.960 --> 00:29:33.680 so we live. 388 00:29:33.720 --> 00:29:34.359 So what do we do? 389 00:29:34.400 --> 00:29:34.559 Then? 390 00:29:36.640 --> 00:29:39.440 It sounds like you're kind of outlining what the issues 391 00:29:39.960 --> 00:29:45.160 could be. But then, yeah, what do I, as the 392 00:29:45.200 --> 00:29:48.240 regular old web developer do to make this better? 393 00:29:51.119 --> 00:29:57.279 So right now, I don't really have I don't have 394 00:29:57.319 --> 00:30:01.559 a perfect answer. I can, like, I think, as a 395 00:30:01.559 --> 00:30:06.400 web developer, you should probably prefer deferred scripts over. 396 00:30:06.519 --> 00:30:11.920 As is the good baseline. Always start with defer with 397 00:30:12.000 --> 00:30:12.680 you when you can. 398 00:30:13.359 --> 00:30:19.400 Yeah, with the caveat that deferred scripts all run in 399 00:30:19.480 --> 00:30:22.960 a singe like all of your pages. Deferred scripts run 400 00:30:22.960 --> 00:30:26.559 in a single task and they don't get interrupted. So 401 00:30:27.319 --> 00:30:34.079