WEBVTT 1 00:00:00.080 --> 00:00:03.359 You know that feeling when you click a link and well, 2 00:00:03.439 --> 00:00:05.960 nothing happens. You just sit there staring at a blank 3 00:00:05.960 --> 00:00:09.720 white screen or that little spinning. 4 00:00:09.439 --> 00:00:12.199 Wheel, Oh yeah, the wheel of death, right, and. 5 00:00:12.160 --> 00:00:14.759 By second three you're tapping your fingers. By second five, 6 00:00:14.800 --> 00:00:17.239 I mean you're probably just closing the tab and going 7 00:00:17.239 --> 00:00:20.719 somewhere else. We have all felt the pain of a 8 00:00:20.760 --> 00:00:21.719 slow loading. 9 00:00:21.440 --> 00:00:25.000 Website completely is universally frustrating. 10 00:00:24.679 --> 00:00:27.960 But the sheer mechanics of what is actually happening behind 11 00:00:27.960 --> 00:00:31.679 the scenes in those agonizing seconds is well, it's a 12 00:00:31.719 --> 00:00:36.439 fascinating puzzle, like why do some sites render instantly while 13 00:00:36.479 --> 00:00:38.640 others drag on as if they're pulling data through a 14 00:00:38.640 --> 00:00:39.719 straw Exactly? 15 00:00:39.840 --> 00:00:41.799 And that's exactly what we're tackling today. 16 00:00:42.000 --> 00:00:44.079 Yeah, So today we are going on a mission to 17 00:00:44.159 --> 00:00:47.679 shortcut your path to understanding web performance. We're looking at 18 00:00:47.679 --> 00:00:50.960 some core concepts from Dan Allen Hume's book fastasp dot 19 00:00:51.000 --> 00:00:53.399 net websites. We're really going to break down where the 20 00:00:53.439 --> 00:00:57.159 real bottlenecks live and how developers actually fix them. 21 00:00:57.399 --> 00:01:00.359 Yeah, and doing that requires taking a step away from 22 00:01:00.719 --> 00:01:04.719 viewing the Internet as magic and visible tubes. We have 23 00:01:04.760 --> 00:01:08.239 to look at the actual physical mechanics of digital communication. Right, 24 00:01:08.640 --> 00:01:12.239 the Internet is basically a series of highly choreographed conversations 25 00:01:12.280 --> 00:01:16.159 between your device and servers that might be well thousands 26 00:01:16.159 --> 00:01:18.879 of miles away, which is wild when you think about it, it is, 27 00:01:18.959 --> 00:01:21.719 and when that choreography is even slightly unoptimized, the whole 28 00:01:21.719 --> 00:01:24.599 system just grinds to a halt. So the goal for 29 00:01:24.640 --> 00:01:27.439 today's deep dive is to dissect that process so you, 30 00:01:27.879 --> 00:01:30.560 the listener, can see the friction points for yourself. 31 00:01:30.920 --> 00:01:34.719 Okay, let's unpack this and starting with a proverb. Actually, yeah, 32 00:01:34.719 --> 00:01:37.519 the text frames this entire problem around a Zulu proverb, 33 00:01:37.560 --> 00:01:40.760 which is, even a small ant can hurt the mighty elephant. 34 00:01:40.959 --> 00:01:42.400 I love that framing right. 35 00:01:42.959 --> 00:01:46.359 When thinking about website architecture, this completely reorients how we 36 00:01:46.400 --> 00:01:49.400 look at bottlenecks. Usually we assume the slow parts of 37 00:01:49.400 --> 00:01:52.200 the web or the massive complex things we picture, you know, 38 00:01:52.319 --> 00:01:57.519 heavy databases, complex back end co crunching algorithms, intense security protocols. 39 00:01:57.560 --> 00:01:59.239 Yet a big step exactly that. 40 00:01:59.280 --> 00:02:01.599 Is the mighty elephan. But the reality is that the 41 00:02:01.680 --> 00:02:05.560 elephant is rarely what slows the site down. The chaos 42 00:02:05.599 --> 00:02:09.639 comes from an army of tiny, seemingly insignificant front end 43 00:02:09.639 --> 00:02:13.199 components the ants, and they trip at the browser and 44 00:02:13.400 --> 00:02:15.280 slow the load time to a crawl. 45 00:02:15.639 --> 00:02:18.560 Because, I mean, the elephant might be heavy, but its 46 00:02:18.639 --> 00:02:22.439 movements are localized and highly predictable. The ants, on the 47 00:02:22.479 --> 00:02:27.159 other hand, require constant chaotic coordination across massive distances. 48 00:02:27.319 --> 00:02:28.759 Constant coordination, right. 49 00:02:28.599 --> 00:02:31.520 And this dynamic is the foundation of what Steve Souders, 50 00:02:31.520 --> 00:02:34.639 he's a former head performance engineer at Google, actually what 51 00:02:34.719 --> 00:02:36.479 he called the performance Golden Rule. 52 00:02:36.520 --> 00:02:37.360 Okay, what's the rule. 53 00:02:37.479 --> 00:02:39.960 The rule states that eighty percent or more of the 54 00:02:40.080 --> 00:02:43.240 end user response time is spent entirely on the front end. 55 00:02:43.319 --> 00:02:46.960 Wait eighty percent. That completely flips the conventional wisdom of 56 00:02:47.000 --> 00:02:48.520 where the heavy lifting is actually happening. 57 00:02:48.599 --> 00:02:49.479 Yep, it really does. 58 00:02:49.639 --> 00:02:51.759 So. If I wait five seconds for a page to load, 59 00:02:52.199 --> 00:02:55.319 for those seconds are just my browser struggling to assemble 60 00:02:55.360 --> 00:02:56.240 the surface level. 61 00:02:56.039 --> 00:02:58.680 Pieces exactly, And looking at the data from a study 62 00:02:58.719 --> 00:03:01.919 of two hundred and fifty third URLs, you can see 63 00:03:01.919 --> 00:03:04.240 exactly why the browser struggles so much. 64 00:03:04.560 --> 00:03:05.280 Okay, laid on me. 65 00:03:05.479 --> 00:03:08.919 Well, the actual HTML document, which is the core code 66 00:03:08.960 --> 00:03:11.400 that the back end server generates to give the page 67 00:03:11.479 --> 00:03:15.319 its structure. That's incredibly lightweight. On average, it's just forty 68 00:03:15.360 --> 00:03:16.080 eight kilobytes. 69 00:03:16.120 --> 00:03:21.159 Oh wow, So the back end finishes its job almost instantly, Yeah, 70 00:03:21.199 --> 00:03:24.120 handing over this tiny forty eight kilobyte text file. 71 00:03:24.240 --> 00:03:27.039 Yeah, pretty much instantly. But then the ants take over, uh, 72 00:03:27.400 --> 00:03:30.439 your coming ants, right, So while the HTML is only 73 00:03:30.479 --> 00:03:32.960 forty eight kilobytes, the average weight of the images on 74 00:03:33.000 --> 00:03:35.400 those pages is six hundred and eighty four kilobytes. 75 00:03:35.520 --> 00:03:37.240 Oh that's a huge jump. It is. 76 00:03:37.599 --> 00:03:41.039 And the JavaScript that makes things interactive that averages another 77 00:03:41.120 --> 00:03:44.120 two hundred and ten kilobytes. So the vast majority of 78 00:03:44.120 --> 00:03:46.280 the time you spend waiting for a page to load 79 00:03:46.639 --> 00:03:49.240 isn't spent waiting for the server to figure out the structure. 80 00:03:49.360 --> 00:03:51.599 It's just downloading the pieces exactly. 81 00:03:51.639 --> 00:03:54.599 It's the time spent downloading all those decorative and interactive 82 00:03:54.599 --> 00:03:57.039 elements one by one over the network. 83 00:03:57.159 --> 00:03:59.039 Okay, but I have to push back on the economics 84 00:03:59.039 --> 00:03:59.759 of this for a second. 85 00:03:59.759 --> 00:04:00.439 Sure, go ahead. 86 00:04:00.560 --> 00:04:04.000 If the service side code is so incredibly complex, and 87 00:04:04.360 --> 00:04:07.560 you know, companies spend millions building out these massive back 88 00:04:07.680 --> 00:04:11.919 end architectures, why is the return on investment for optimizing 89 00:04:11.960 --> 00:04:12.800 them so terrible? 90 00:04:13.039 --> 00:04:14.479 That's a really good question. 91 00:04:14.319 --> 00:04:16.519 Because the data shows that if you cut back end 92 00:04:16.639 --> 00:04:20.319 processing time in half, you only yield a ten percent 93 00:04:20.360 --> 00:04:24.000 increase in overall speed, but cutting front end time in 94 00:04:24.079 --> 00:04:27.120 half yields a forty percent increase. Why does the back 95 00:04:27.240 --> 00:04:31.079 end optimization yield so low if it's like the most 96 00:04:31.160 --> 00:04:32.399 complex part of the system. 97 00:04:32.759 --> 00:04:35.680 It really comes down to network latency versus raw computation. 98 00:04:35.879 --> 00:04:39.759 I mean, back end optimization often involves rewriting intricate database 99 00:04:39.879 --> 00:04:44.120 queries or upgrading server hardware. It's highly specialized and very expensive, right, 100 00:04:44.279 --> 00:04:47.120 But a server rendering a forty eight kilobyte HTML file 101 00:04:47.199 --> 00:04:49.040 is already doing it in a fraction of a second, 102 00:04:49.319 --> 00:04:51.879 So if you optimize that process to be twice as fast, 103 00:04:52.000 --> 00:04:53.800 you're only shaving off a few milliseconds. 104 00:04:53.879 --> 00:04:55.360 Don't even notice exactly. 105 00:04:55.879 --> 00:04:59.600 The front end, however, is constrained by network roundtrips. The 106 00:04:59.639 --> 00:05:02.680 browse has to look at that HTML file, realize it 107 00:05:02.720 --> 00:05:06.399 needs fifty different images, scripts, and style sheets, and then 108 00:05:06.519 --> 00:05:10.439 send fifty individual requests across the physical Internet to fetch them. 109 00:05:10.600 --> 00:05:14.519 Oh physical Internet like actual cables, yes, actual fiber optic cables. 110 00:05:15.000 --> 00:05:17.720 The latency of data traveling back and forth through those 111 00:05:17.759 --> 00:05:21.160 cables is a physical limit, So optimizing the front end 112 00:05:21.240 --> 00:05:24.319 means reducing the number of those trips, which bypasses the 113 00:05:24.399 --> 00:05:25.879 latency bottleneck entirely. 114 00:05:26.000 --> 00:05:29.079 Okay, so we're eliminating hundreds of small network trips rather 115 00:05:29.120 --> 00:05:32.560 than making one heavy lift slightly faster precisely, But realistically, 116 00:05:32.560 --> 00:05:36.240 those trips still only take milliseconds. Right. Why does saving 117 00:05:36.240 --> 00:05:39.560 a fraction of a second justify tearing apart a website's architecture. 118 00:05:40.319 --> 00:05:42.399 It's easy to look at a forty percent speed increase 119 00:05:42.439 --> 00:05:44.800 and think, you know, I saved one second, so what? 120 00:05:45.040 --> 00:05:47.680 Well the so what is that? Online? Our perception of 121 00:05:47.680 --> 00:05:51.600 time is fundamentally warped worked out well in the physical world. 122 00:05:51.680 --> 00:05:56.519 A one second delay is imperceptible online it breaks user trusts. 123 00:05:56.680 --> 00:05:57.680 That is so true. 124 00:05:57.879 --> 00:06:01.240 Yeah, and data from a Gomez survey illustrates this perfectly. 125 00:06:01.720 --> 00:06:05.160 They found that thirty two percent of consumers will abandon 126 00:06:05.199 --> 00:06:07.639 a site completely if there's a delay of just one 127 00:06:07.680 --> 00:06:08.839 to five seconds. 128 00:06:08.959 --> 00:06:12.000 Wow. If a greeter at a physical store takes three 129 00:06:12.040 --> 00:06:15.040 seconds to say hello, you don't instantly spin around a 130 00:06:15.079 --> 00:06:15.839 walk out the door. 131 00:06:16.079 --> 00:06:19.680 No, of course not. But digital patients just doesn't exist. 132 00:06:19.879 --> 00:06:20.600 It really doesn't. 133 00:06:20.680 --> 00:06:23.879 And Google actually tested the absolute limits of that Digital 134 00:06:23.920 --> 00:06:27.399 patients by injecting artificial latency into their search results. 135 00:06:27.439 --> 00:06:28.480 They did that on purpose. 136 00:06:28.600 --> 00:06:31.480 Yep, they purposely delayed the page load by just one 137 00:06:31.560 --> 00:06:33.240 hundred to four hundred milliseconds. 138 00:06:33.319 --> 00:06:34.800 That's like what a third of a second? 139 00:06:34.920 --> 00:06:37.160 Yeah, third of a second, and the result was a 140 00:06:37.279 --> 00:06:39.560 point two two point six percent drop in the number 141 00:06:39.600 --> 00:06:42.000 of searches per user, a drop. 142 00:06:41.720 --> 00:06:45.720 And engagement over delay you can barely consciously register. That's insane. 143 00:06:45.959 --> 00:06:49.160 It is. Now apply that percentage drop to the billions 144 00:06:49.160 --> 00:06:52.920 of queries Google handles, the revenue loss is staggering. 145 00:06:52.399 --> 00:06:54.279 Oh millions of dollars easily easily. 146 00:06:54.319 --> 00:06:58.040 And conversely, when Google Maps optimize their homepage, they reduced 147 00:06:58.040 --> 00:07:00.639 the size from one hundred kilobytes down to seventy or 148 00:07:00.639 --> 00:07:04.639 eighty kilobytes. The results were explosive. What happened, Traffic jump 149 00:07:04.720 --> 00:07:07.399 ten percent in the very first week, and over the 150 00:07:07.439 --> 00:07:10.680 next three weeks it jumped an additional twenty five percent just. 151 00:07:10.639 --> 00:07:13.279 From shaving off twenty to thirty kilobytes. 152 00:07:13.360 --> 00:07:13.680 That's it. 153 00:07:14.439 --> 00:07:17.399 That proves that speed is not just a byproduct of 154 00:07:17.439 --> 00:07:20.319 good design. Its speed is a core feature of the 155 00:07:20.319 --> 00:07:23.600 product itself. Absolutely, and it's not just about keeping corporate 156 00:07:23.600 --> 00:07:27.759 bounce rates low or pleasing Google search algorithms, which, by 157 00:07:27.800 --> 00:07:31.560 the way, heavily penalized slow sites. It directly impacts the 158 00:07:31.639 --> 00:07:32.319 user's wallet. 159 00:07:32.399 --> 00:07:34.600 Oh, definitely because of mobile data right. 160 00:07:34.959 --> 00:07:38.199 Mobile users are constantly browsing on unpredictable three G or 161 00:07:38.240 --> 00:07:41.519 four G networks with strict data caps. So when a 162 00:07:41.519 --> 00:07:45.120 company serves up a bloated, unoptimized website, they are actively 163 00:07:45.199 --> 00:07:48.439 eating into the user's paid data plan. A lighter side 164 00:07:48.519 --> 00:07:50.519 is honestly an issue of accessibility. 165 00:07:50.639 --> 00:07:54.240 That's a great point. Performance optimization is inherently user centric. 166 00:07:54.279 --> 00:07:58.000 You are respecting the user's device constraints, their network limitations, 167 00:07:58.040 --> 00:07:58.759 and their time. 168 00:07:59.120 --> 00:08:01.319 But here's where it gets really interesting. It's not just 169 00:08:01.399 --> 00:08:04.720 about saving the user money on data. The physical mechanics 170 00:08:04.720 --> 00:08:07.480 of pulling that data across the network have a massive 171 00:08:07.560 --> 00:08:08.519 environmental cost. 172 00:08:08.800 --> 00:08:12.560 Oh the carbon footprint. Yeah, because every single time a 173 00:08:12.600 --> 00:08:15.839 browser requests a file, a physical server in a data 174 00:08:15.879 --> 00:08:20.040 center has to wake up, allocate CPU cycles, retrieve the 175 00:08:20.120 --> 00:08:22.199 data from a hard drive, and transmit it. 176 00:08:22.240 --> 00:08:23.360 And that all requires power. 177 00:08:23.560 --> 00:08:28.000 Exactly, that entire chain requires electricity, and processing generates heat, 178 00:08:28.040 --> 00:08:31.639 which means massive air conditioning units have to run constantly 179 00:08:31.680 --> 00:08:34.440 to keep those data centers cool, so a compounds it does. 180 00:08:34.759 --> 00:08:37.840 If a developer optimizes a frontend to reduce the number 181 00:08:37.879 --> 00:08:41.720 of server requests by forty percent, that server load drops significantly. 182 00:08:42.200 --> 00:08:45.360 Extrapolate that across millions of daily visitors, and a company 183 00:08:45.399 --> 00:08:50.240 can physically decommissioned servers. Optimizing code directly and measurably shrinks 184 00:08:50.279 --> 00:08:51.639 a company's carbon footprint. 185 00:08:52.000 --> 00:08:56.720 So literally compressing a JPEG image can incrementally help lower 186 00:08:56.759 --> 00:09:00.080 carbon emissions. That is the ultimate digital butterfly effect what 187 00:09:00.159 --> 00:09:03.360 it really is. But to understand how developers actually achieve this, 188 00:09:03.639 --> 00:09:06.120 how they eliminate those requests, we have to look at 189 00:09:06.120 --> 00:09:09.480 the fundamental conversation happening between a browser and a server. 190 00:09:09.519 --> 00:09:13.399 Right, and that conversation is governed by HTTP or Hypertext 191 00:09:13.399 --> 00:09:16.919 Transfer protocol. Every interaction on the web is built on 192 00:09:16.960 --> 00:09:18.559 this request and response cycle. 193 00:09:18.759 --> 00:09:21.200 I feel like the easiest way to visualize an HTP 194 00:09:21.840 --> 00:09:25.120 get request is to think of a fast food drive through. 195 00:09:25.240 --> 00:09:26.720 Okay, I like this, walk me through it. 196 00:09:26.879 --> 00:09:29.799 So the browser pulls up to the speaker and places 197 00:09:29.840 --> 00:09:32.679 an order. That's the request. You tell the server what 198 00:09:32.720 --> 00:09:36.360 you want, but you also include specific delivery instructions in 199 00:09:36.399 --> 00:09:39.799 browser terms. You might send an accept encoding header. Right, 200 00:09:40.000 --> 00:09:42.759 You're basically saying, hey, I want the data, but please 201 00:09:42.799 --> 00:09:45.679 compress it using GESIP before you send it so it 202 00:09:45.759 --> 00:09:46.519 travels faster. 203 00:09:46.720 --> 00:09:49.799 And that GESP mechanism is vital there. Because the server 204 00:09:49.919 --> 00:09:53.039 looks at the text file, finds repeating strings of code, 205 00:09:53.279 --> 00:09:57.480 and compresses them. It drastically reduces the payload size before 206 00:09:57.519 --> 00:10:00.759 it hands the package out the drive through window. 207 00:10:00.159 --> 00:10:01.919 Taped to the bag. When it gets handed out as 208 00:10:01.919 --> 00:10:05.320 a detailed receipt, that receipt contains the HTTP headers and. 209 00:10:05.279 --> 00:10:08.679 Status codes, and the status code dictates the entire outcome 210 00:10:08.679 --> 00:10:11.639 of the interaction. Like a two hundred success code means 211 00:10:11.679 --> 00:10:14.600 the server found exactly what you asked for and delivered. 212 00:10:14.200 --> 00:10:15.519 It the golden number YEP. 213 00:10:15.919 --> 00:10:18.120 A four hundred level code, on the other hand, is 214 00:10:18.159 --> 00:10:21.399 a client error that means the browser asked for a 215 00:10:21.639 --> 00:10:24.919 URL that doesn't exist or formatted the request badly. 216 00:10:25.080 --> 00:10:27.240 That's the equivalent of trying to order a pizza at 217 00:10:27.240 --> 00:10:30.120 a burger joint. The server says, you made a mistake, 218 00:10:30.399 --> 00:10:32.080 I can't fulfill this exactly. 219 00:10:32.679 --> 00:10:35.320 And a five hundred level code is a server error 220 00:10:35.679 --> 00:10:40.159 the database crashed or the code broke during execution. Basically, 221 00:10:40.240 --> 00:10:42.720 the kitchen is on fire. No good, not good at all. 222 00:10:42.919 --> 00:10:46.639 But alongside those status codes, the HTTP headers contain the 223 00:10:46.679 --> 00:10:50.720 instructions for caching, which is arguably the most powerful tool 224 00:10:50.759 --> 00:10:51.679 for web performance. 225 00:10:51.759 --> 00:10:52.679 Cashing is huge. 226 00:10:52.840 --> 00:10:55.799 It is headers like cash control and expires allow the 227 00:10:55.799 --> 00:10:58.519 server to tell the browser, Hey, this company logo isn't 228 00:10:58.519 --> 00:11:00.639 going to change for the next thirty days. Don't ask 229 00:11:00.679 --> 00:11:02.440 me for it again, just store it locally. 230 00:11:02.600 --> 00:11:04.879 So cashing is basically digital meal prep. 231 00:11:05.080 --> 00:11:06.200 Yes, perfect analogy. 232 00:11:06.440 --> 00:11:09.480 Instead of cooking every single meal from scratch every night, 233 00:11:09.919 --> 00:11:12.200 which is an empty cash where you have to fetch 234 00:11:12.240 --> 00:11:15.279 everything over the network, you do the heavy lifting on Sunday. 235 00:11:15.559 --> 00:11:18.519 You store the ingredients in the fridge, so on Wednesday 236 00:11:18.519 --> 00:11:21.600 you're just assembling the pieces locally. It bypasses the drive 237 00:11:21.679 --> 00:11:22.960 through entirely, and the. 238 00:11:22.919 --> 00:11:26.080 Performance difference between those two states is just massive. The 239 00:11:26.120 --> 00:11:29.639 text highlights a profile of a website experiencing a brand 240 00:11:29.639 --> 00:11:31.720 new visitor with an empty cash. 241 00:11:31.879 --> 00:11:34.039 Okay, so cooking from scratch, right. 242 00:11:34.399 --> 00:11:39.000 The browser had to initiate ten separate HTTP requests, downloading 243 00:11:39.000 --> 00:11:42.080 a total of one hundred and thirty kilobytes of data. 244 00:11:41.759 --> 00:11:43.919 Ten full round trips over the network. 245 00:11:44.000 --> 00:11:46.879 Yeah, but on a repeat visit from that same user. 246 00:11:47.200 --> 00:11:50.600 The browser utilized a primed cache. It had already stored 247 00:11:50.639 --> 00:11:53.519 the static components like the CSS layout and the images 248 00:11:53.759 --> 00:11:54.960 based on those headers, so. 249 00:11:54.919 --> 00:11:56.759 They just pulled it out of the fridge exactly. 250 00:11:57.240 --> 00:12:00.919 The repeat visit required only six HTTPS requests, and the 251 00:12:00.960 --> 00:12:04.080 total weight downloaded plummeted from one hundred and thirty kilobytes 252 00:12:04.080 --> 00:12:06.039 to just thirty nine point eight kilobytes. 253 00:12:06.080 --> 00:12:08.679 Wow, so the data paylo dropped by over two thirds 254 00:12:09.039 --> 00:12:11.840 simply because the browser followed the meal prep instructions from. 255 00:12:11.720 --> 00:12:14.600 The first visit exactly. It's a huge saving. 256 00:12:15.080 --> 00:12:17.720 But the issue for developers though, is that when they're 257 00:12:17.759 --> 00:12:22.320 testing these optimizations, they can't really rely on a primed cache. 258 00:12:22.840 --> 00:12:24.639 I mean, they need to see exactly what the first 259 00:12:24.639 --> 00:12:25.519 time user. 260 00:12:25.279 --> 00:12:27.120 Sees, right, they have to see the blank slate. 261 00:12:27.200 --> 00:12:28.799 So if I'm a developer and I want to see 262 00:12:28.799 --> 00:12:31.240 what a brand new user sees, how do I clear 263 00:12:31.320 --> 00:12:33.759 this cache? Yeah, because if they just hit the standard 264 00:12:33.759 --> 00:12:37.600 refresh button, the browser's local heuristics will intervene and serve 265 00:12:37.720 --> 00:12:38.759 up the saved files. 266 00:12:38.879 --> 00:12:41.279 Yeah. F five alone won't cut it. They have to 267 00:12:41.320 --> 00:12:46.039 force a hard refresh, which is often CRLF five that 268 00:12:46.080 --> 00:12:49.360 tells the browser to bypass the local storage entirely and 269 00:12:49.480 --> 00:12:51.919 force the worst case scenario over the network. 270 00:12:52.240 --> 00:12:54.559 You have to suffer through the worst case scenario to 271 00:12:54.679 --> 00:12:55.879 know where the friction is. 272 00:12:55.879 --> 00:12:59.960 You do and to visualize that friction. Developers rely on 273 00:13:00.120 --> 00:13:05.320 a four step performance cycle. It's profile, identify, implement monitor. 274 00:13:05.440 --> 00:13:07.919 Okay, profile, identify, implement monitor. Yeah. 275 00:13:07.960 --> 00:13:10.440 So you gather the data, find the specific bottleneck, deploy 276 00:13:10.480 --> 00:13:12.679 the fix, and then watch to ensure it doesn't degrade 277 00:13:12.720 --> 00:13:15.720 over time. And the most critical tool in that profile 278 00:13:15.759 --> 00:13:17.440 stage is the waterfall chart. 279 00:13:17.720 --> 00:13:20.399 Oh. The waterfall chart is such a brilliant piece of 280 00:13:20.480 --> 00:13:21.519 data visualization. 281 00:13:21.679 --> 00:13:23.399 It really makes the invisible visible. 282 00:13:23.600 --> 00:13:27.039 It does basically, time moves horizontally from left to right. 283 00:13:27.559 --> 00:13:31.600 Every time the browser requests a specific file, a horizontal 284 00:13:31.679 --> 00:13:36.120 bar starts drawing across the timeline. As fifty different files 285 00:13:36.120 --> 00:13:40.000 are requested, the bars stack vertically down the page, creating 286 00:13:40.039 --> 00:13:42.919 this cascading waterfall effect, and the length. 287 00:13:42.679 --> 00:13:45.559 Of each bar shows exactly how long that specific file 288 00:13:45.600 --> 00:13:48.759 took to download. Right and within that cascade, developers are 289 00:13:48.799 --> 00:13:52.759 looking for two major milestones. The first is the green line, 290 00:13:53.000 --> 00:13:55.480 which represents the dom content loaded event. 291 00:13:55.799 --> 00:13:58.240 Okay, so if we think about building a house. The 292 00:13:58.320 --> 00:14:01.240 dom content loaded line is the moment the blueprint is 293 00:14:01.240 --> 00:14:03.600 mapped out and the wooden framing is up. I like 294 00:14:03.639 --> 00:14:06.440 that the browser has downloaded enough of the HTML to 295 00:14:06.440 --> 00:14:09.519 know where the walls are and how the rooms connect exactly. 296 00:14:09.799 --> 00:14:13.039 The core structure is defined and the API is ready 297 00:14:13.039 --> 00:14:15.600 for interactions. But you know the house isn't. 298 00:14:15.480 --> 00:14:17.759 Livable yet, no drywall, no paint. Right. 299 00:14:18.240 --> 00:14:20.840 That requires the blue line, which is the load event. 300 00:14:21.279 --> 00:14:24.720 The blue line signifies that every image is downloaded, the 301 00:14:24.720 --> 00:14:28.639 CSS styles have painted the walls, and the complex JavaScript 302 00:14:28.639 --> 00:14:29.799 has fully executed. 303 00:14:30.159 --> 00:14:31.919 The page is finally fully rendered. 304 00:14:32.039 --> 00:14:35.639 Yes, and that spinning icon in the browser tap finally stops. 305 00:14:35.799 --> 00:14:39.200 A beautiful moment. So the entire goal of optimization is 306 00:14:39.200 --> 00:14:42.080 trying to push that blue line further to the left, 307 00:14:42.440 --> 00:14:45.519 squashing the timeline. But when you look at these charts, 308 00:14:45.799 --> 00:14:49.039 the obvious problemaris are the massive gaps of white space 309 00:14:49.639 --> 00:14:52.080 right like you'll see a horizontal bar for a single 310 00:14:52.120 --> 00:14:55.200 file stretching out for seconds and nothing else below it 311 00:14:55.279 --> 00:14:55.720 is moving. 312 00:14:56.080 --> 00:14:59.120 Yeah, that white space is what we call a blocking resource. 313 00:14:59.720 --> 00:15:03.360 See browsers are generally single threaded, meaning they read code sequentially. 314 00:15:03.519 --> 00:15:04.480 Top to bottom right. 315 00:15:04.639 --> 00:15:08.039 So if the browser hits a massive unoptimized file, it 316 00:15:08.159 --> 00:15:11.080 simply refuses to continue building the rest of the page 317 00:15:11.120 --> 00:15:13.919 until that specific file is completely downloaded and parsed. 318 00:15:13.960 --> 00:15:16.120 It just sits. They're holding up traffic exactly. 319 00:15:16.480 --> 00:15:20.440 The book profiles osos dot Com a major UK clothing retailer, 320 00:15:20.840 --> 00:15:24.440 and their waterfall chart was just riddled with these blocking resources. 321 00:15:24.679 --> 00:15:29.919 Okay, let me guess a clothing retailer probably had massive 322 00:15:30.279 --> 00:15:33.679 uncompressed product images blocking everything else. 323 00:15:33.960 --> 00:15:36.360 Well, high resolution images certainly add a lot of weight, 324 00:15:36.440 --> 00:15:40.279 but images generally don't block the browser from processing other files. 325 00:15:40.440 --> 00:15:44.639 Oh really, Yeah, the true bottlenecks there were architectural. They 326 00:15:44.639 --> 00:15:48.320 were forcing the browser to download five separate CSS files 327 00:15:48.360 --> 00:15:50.159 and eight or more JavaScript files. 328 00:15:50.240 --> 00:15:51.799 That sounds like a lot of requests. 329 00:15:51.879 --> 00:15:56.000 It is the sheer volume of concurrent requests overwhelmed the 330 00:15:56.000 --> 00:15:59.799 browser's connection limits, causing massive delays and pushing that blue 331 00:15:59.840 --> 00:16:01.159 line further and further out. 332 00:16:01.320 --> 00:16:04.320 So to even diagnose that kind of traffic jam, what 333 00:16:04.480 --> 00:16:07.240 tools are developers using? I assume they are just guessing 334 00:16:07.279 --> 00:16:08.440 based on load times. 335 00:16:08.600 --> 00:16:11.519 No, not at all, and the tooling is incredibly accessible. 336 00:16:11.639 --> 00:16:14.600 Chrome developer tools are built right into the browser, allowing 337 00:16:14.639 --> 00:16:16.759 you to instantly view the network tab and see the 338 00:16:16.799 --> 00:16:19.879 waterfall chart right there. Very convenient it is, and it 339 00:16:19.919 --> 00:16:23.279 shows the physical server latency for each request too. There 340 00:16:23.320 --> 00:16:26.600 are also tools like Firebug and Fiddler that log network traffic, 341 00:16:26.879 --> 00:16:28.720 but one of the most revealing tools mentioned in the 342 00:16:28.759 --> 00:16:31.039 book is webpagetest dot org. 343 00:16:31.399 --> 00:16:34.320 Okay, I assume web page test provides a metric you 344 00:16:34.360 --> 00:16:37.480 can't get just by opening Chrome on your local machine, 345 00:16:37.519 --> 00:16:39.440 right Otherwise, why leave the browser? 346 00:16:39.679 --> 00:16:41.559 It provides geographical reality. 347 00:16:41.720 --> 00:16:42.399 Oh? Interesting? 348 00:16:42.559 --> 00:16:44.519 Yeah, if you are developing a site in New York, 349 00:16:44.840 --> 00:16:48.919 your local server latency is practically zero. The site feels 350 00:16:49.000 --> 00:16:50.840 instantly responsive. 351 00:16:50.240 --> 00:16:52.720 To you because you're right next to the server exactly. 352 00:16:52.759 --> 00:16:55.320 But web page test allows you to generate a waterfall 353 00:16:55.440 --> 00:16:59.320 chart from a server physically located in Tokyo or London. Wow, 354 00:16:59.399 --> 00:17:02.879 okay revealed how the speed of light, physical network routing, 355 00:17:02.919 --> 00:17:07.319 and distance exacerbate every single unoptimized file on your site. 356 00:17:07.359 --> 00:17:10.079 Okay, So a developer runs a test from Tokyo, sees 357 00:17:10.119 --> 00:17:13.119 a massive gap of white space caused by eight JavaScript 358 00:17:13.200 --> 00:17:17.039 files and realizes the site is crawling for international users. 359 00:17:17.240 --> 00:17:18.640 How do they systematically fix it? 360 00:17:18.960 --> 00:17:21.400 While they turn to the fourteen rules of Web optimization 361 00:17:21.519 --> 00:17:22.720 established by Steve. 362 00:17:22.480 --> 00:17:24.400 Souders the eighty percent rule guy the. 363 00:17:24.480 --> 00:17:28.720 Very same These rules target the exact mechanisms causing the bottlenecks. 364 00:17:29.119 --> 00:17:34.039 For example, one rule is simply make fewer HTTP requests, which. 365 00:17:33.880 --> 00:17:35.640 Goes back to the drive through just make. 366 00:17:35.559 --> 00:17:39.599 Fewer trips exactly, Combine those five CSS files into one 367 00:17:39.640 --> 00:17:42.640 file to eliminate the network overhead of multiple trips. 368 00:17:42.960 --> 00:17:45.960 Makes sense. Another rule in there is putting CSS at 369 00:17:45.960 --> 00:17:48.599 the top of the page. But why does the placement 370 00:17:48.720 --> 00:17:52.200 matter if the browser has to download it all anyway. 371 00:17:52.119 --> 00:17:55.440 It matters because of how the browser renders visuals. If 372 00:17:55.480 --> 00:17:58.039 the CSS is at the bottom, the browser builds the 373 00:17:58.039 --> 00:18:03.400 structural HTML first displays a completely unstyled, broken looking text page. 374 00:18:03.480 --> 00:18:05.079 Oh I hate when that happens. 375 00:18:04.839 --> 00:18:07.480 Right, and then suddenly it snaps the styling into place 376 00:18:07.559 --> 00:18:10.960 once it reaches the bottom. Putting CSS in the head 377 00:18:10.960 --> 00:18:13.680 of the document ensures the browser knows how things should 378 00:18:13.759 --> 00:18:15.519 look before it starts drawing them. 379 00:18:15.559 --> 00:18:18.119 Which prevents that jarring flash of unstyled content. 380 00:18:18.279 --> 00:18:22.559 Exactly, and conversely, Souder says to put JavaScript at the 381 00:18:22.559 --> 00:18:26.079 bottom of the page because it blocks. Yes, because JavaScript 382 00:18:26.079 --> 00:18:28.680 has the power to alter the page structure. When the 383 00:18:28.720 --> 00:18:32.519 browser parser encounters a script tag, it stops everything. It 384 00:18:32.559 --> 00:18:35.000 assumes the script might change the layout, so it pauses 385 00:18:35.039 --> 00:18:38.279 all visual rendering until the script is fully downloaded and executed. 386 00:18:38.400 --> 00:18:40.039 So if you put a heavy script at the top, 387 00:18:40.119 --> 00:18:42.599 the user just stares at a blank, white screen. 388 00:18:42.680 --> 00:18:47.240 Okay, so layout rules matter. Another major rule mentioned is minification. 389 00:18:48.000 --> 00:18:50.440 It sounds like a compression technique, but it's actually about 390 00:18:50.440 --> 00:18:54.359 cleaning house right, Yes, exactly, because developers write code with 391 00:18:54.400 --> 00:18:57.720 lots of spacing, line breaks, and explanatory comments so other 392 00:18:57.799 --> 00:19:00.799 humans can read it. But minification and strips all of 393 00:19:00.839 --> 00:19:01.240 that out. 394 00:19:01.519 --> 00:19:04.400 Yep, the browser doesn't care about human readability. 395 00:19:04.000 --> 00:19:06.160 Or rep The browser doesn't need spaces or comments to 396 00:19:06.200 --> 00:19:09.839 execute code. It just needs the raw syntax, so stripping 397 00:19:09.839 --> 00:19:12.880 those out shrinks the file size down to the absolute 398 00:19:12.880 --> 00:19:15.079 minimum before it ever travels over the network. 399 00:19:15.119 --> 00:19:18.519 It's super effective, and the best part is you don't 400 00:19:18.559 --> 00:19:22.200 have to manually hunt for these inefficiencies. Automated tools like 401 00:19:22.319 --> 00:19:26.480