Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today is the second part of my interview with Scott Gell. If you missed the first episode with Scott, you may want to go back and listen to that first. We lay some of the groundwork for the second part of the episode. We talk about tooling in this one. We talk a little bit about static design files and what to do about that kind of problem. Just a lot of useful information coming from Scott. And hey, while you're listening to this part of the interview, take a minute and go into whatever app it is that you listen to podcasts in and click subscribe. That way you won't miss any future episodes and that will be easily delivered to you. If you don't listen to podcasts in an app, then you can easily subscribe to the RSS feed on developertea.com. Once again, thanks so much to Scott and we'll go to the second part of the interview now. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. And it's a very hard thing to describe. Yeah, it can be. But I think there are a lot of easily relatable parts to progressive enhancement that don't need to be so technical. Just the idea that things don't need to look the same on any given browser or any two browsers. Sure. As long as your service is being delivered to someone in a really fast, accessible manner, that's priority one. And I think a lot of business owners would easily agree with that. Yeah, absolutely. Yeah. And then the technical how of that follows. And I think it's our job to teach our clients about this stuff. But it's also, I think, the why of it all is the most important part to teach. And then as much as you can get into the technical layering, as much as they're interested, that's great too. Yeah. And ultimately, we're talking about making things that work for the most number of people in the best way possible. Right. That's what this is about. And so my biggest takeaway from, or I guess my biggest, my biggest desire when I'm creating a project, when I'm thinking about progressive enhancement, there's kind of two categories that I'm thinking in. One, can it be accessed by any device? Kind of through the filter of the most important devices. But also, can it be accessed by a very, I don't know, an old device or one that is less capable? For instance, a Kindle. A Kindle. Like, how does it access my content on the web? Sure. And then the flip side of that is how fast is it? Right. And that's the one that I think a lot of people are getting wrong right now. And even if you go back to like the basics of web development, if you're building with tables, you can make that relatively easily. You can make that viewable on most devices. But if you stick a big picture in there, and try to size it down, like that's going to cause some major problems. And we aren't just talking about simple speed problems. We're also talking about the fact that, you know, there's people who are actually paying for their data, and you are costing them money. Like, there's a lot of things to think about here. So you mentioned the 14K number, and it's a pretty common number. Can you explain a little bit about critical CSS, 14K, that first round trip, and how you can get that perceived speed on that first load, especially on a homepage? Sure. Yeah, so I think in the last year or two, we've come to terms with some practices in delivering webpages as fast as possible that, at least for me, sort of contradicted what I thought to be best practices, for quite a while. So, you know, the idea of even progressive enhancements original definition was this idea of, you know, separating your concerns. So you have your HTML, your CSS, your JavaScript, and these are all separate things that sort of unobtrusively communicate with each other and layer in, and if one fails, that's fine. And you don't mix them, right? And... Exactly. And more recently, we've been... Well, that's still, you know, absolutely, you know, a development practice. A usable idea. Yeah, yeah. And it's absolutely the way we still build websites. From a delivery perspective, more and more we've been trying to optimize for the first round trip that we make across the web and back to between the server and the browser. So when you say first round trip, let me interrupt you there and ask you, are you referring... I'm assuming that you're referring to not just the page load, but the actual, like, packet round trip, right? Yeah, so we're talking about, you know, you type a URL into your browser and it goes out to DNS and it resolves and gives your browser an IP that it can go off and fetch the first whatever the index of that... particular site happens to be or whatever page you happen to be requesting. And then it goes out and back, right? And in that first request and response, there's a limited amount of code, of data that can be transferred from the server back to your browser. And that tends to be 14 kilobytes, according to people who know a whole lot more about this than I do. But, you know, knowing that and knowing that we have a rough idea of how much data we're working with there, we can start to think about, okay, well, what's the most critical portion of our page that we can sort of cram into that first round trip? And if we think about it that way as sort of, okay, what parts of this web page, for example, are needed to start rendering the top portion of the page, the first part that you see as a user? Well, you need the markup, the HTML for however much content is going to cover the first screen full of, or first scroll full of content, which, you know, varies across devices, but you can kind of aim a little high on the viewport side. So, if you're going to do a lot of work on a specific size, you'll need some CSS for styling the layout for that portion of the content. And you might need a little JavaScript as well, depending on how you're using JavaScript to qualify the enhanced layout of your initial page view. So, thinking about, okay, well, you know, in an HTML document, and that's all that's coming back in that first round trip, because anything else, like an external document, like an external style sheet that you would reference from that HTML, anything like that is going to require another request once the HTML reaches the browser, right? And it begins to parse it and says, oh, there's a reference to a style sheet, let me go get that. And by then, you're already making a new round trip. So, we're trying to think about, okay, could we fit some CSS in line? Could we fit some very, very critical JavaScript in line, along with that first delivery of markup? And sort of optimize for that first round trip. And it turns out it's really, really, really powerful. It kind of blew me away when I first saw this in action. Because it sort of guarantees that you can deliver a page in under a second, which is at least on a reasonable connection speed. And, you know, that's great, right? I mean, we're used to much more than that. We're used to much slower page loading times than that. Especially on mobile devices. And, you know, that time varies. Like, if you're on 3G, then typically a really fast site would maybe take two seconds, which is down from whatever, the eight to ten, that's kind of the average that you'd see on 3G these days. Yeah. So, yeah. You know, it sounds sort of... simple in concept, but when you have a live code base and you're starting to think about, well, okay, I can see what portions of the content comprise the top portion of this page, how do I, you know, isolate that code? Right. That's a much harder problem. And thankfully, we're getting better tools now that sort of do that for us. So we don't have to, you know, write our style sheets in ways that we have, like, a, you know, inlined group of CSS files and then a separate group and have to manage that all on our own. Right. Yeah. What is it? Filament groups, critical CSS, right? Yeah. I mean, that's one of several that are... several tools that are out there. Addy Asmani and the rest of the Google Chrome DevRel folks kind of do that. At least for me, they were the first people that I started hearing talk about this stuff. And they started building bookmarklets and grid tasks and things like that. And we started experimenting with those and we were like, well, this idea is really great. We need it to do a couple of other things to work with some of the code bases that we typically have for clients, which tend to be live and web-based. tend to be live generated on the server kind of code bases. So, yeah, so we built our own tool as well. The one you mentioned, Grunt Critical CSS. And it's a Node.js task as well, Critical CSS. But what it does is you set up a configuration file that lists out all of the unique templates in your code base. So you might have your homepage and your about template and your blog template, things like that. Unique page templates, not necessarily unique URLs that use those templates. But, you know, generally you'll have, I don't know, less than 10 on an average site unique templates. And then you pass those to this tool, and it actually opens an example page of each template in Phantom, which is this web kit. Yeah, a headless browser, right? Yeah. So this is running. And you're running on the command line. You don't actually see, you know, if you're looking at your computer screen, you wouldn't see the pages open in a browser. But they're opening, and it resizes to a particular viewport that you specify, 1200 by 900, say. And it starts to analyze which portions of the CSS are necessary to render the layout in just that region of the page. Wow. And it isolates those styles and writes, and it it's like, oh, I'm going to have to do this. And then you just sort of load the, there's a style sheet loader workflow that we have that you can load the full CSS in a way that doesn't block rendering. Yeah, I was going to ask you about that. Two questions. One, are you then kind of repeating the styles in the secondary load? Yeah, absolutely. Okay. It's the critical styles. Negligible, basically, right? Well, yeah, it's also loaded in a way that it's not blocking rendering. It's just sort of coming in at its own convenience, right? Okay. So, yes, there's overlap between the two, but it's actually intentional because you can configure, your site to only use this inlining workflow on the first page visit. And then after that, you've got the full style sheet. And it's cached. In browser cache, yeah. So you can just reference it normally from the head of the page and not have to deal with that whole inlining workflow anymore. So in the end, you know, it spins up the initial view very quickly and then behind the scenes loads the CSS that will be needed to render the layout. So you can just render the layout. You can also render the rest of the page that's below the viewport size when you first open it, but also to render the rest of the site. Or at least, you know, a section of the site that you happen to consider unique enough to make a style sheet for. Sometimes we'll have a client that, you know, if it's e-commerce, maybe there's buyer side templates and seller side templates or, you know, different audiences using this code base. And those... Those are situations where you might break out your full style sheets into... Right. Yeah. But for the most part, you know, sites like... Like we worked on the Lego store last year. It's kind of an ongoing project and... I'm sure that was fun. Oh, man. Dream client. Yeah. It's just... It's a really fun site. The talent there is amazing. But even something like that, you know, in e-commerce, most of the site runs offline. You can just do one style sheet and then... Yeah. So I think it's doable, especially with, you know, smart use of, you know, the cascade and trying to minimize how much CSS you're writing and GZip, of course, transferring all your files with good compression. So... And would you put the actual just references to the style sheets inside of like a no script tag then? Yeah. I mean, we definitely do that for the... The use case... For the user that wouldn't have JavaScript enabled or available to the browser. Sure. And then for anyone else, we're using a utility that I wrote called Load CSS, which basically just, you know, injects a link element into the page, referencing whatever style sheet you need. And it does it in a way that ensures that it's not going to block rendering. Because by default, any reference to, like if you have a link element in your... In the head of your page that you deliver to the browser and it references an external style sheet, the browser will actually just stop in its tracks, go out and request that thing, parse it, and then begin rendering again. And, you know, that's a potential single point of failure at best. And at worst, you know, the average use case is just slowing down that initial render every time. So, yeah. Yeah. So trying to avoid that as we can. It's sort of like this inline the critical stuff and then load the rest at a leisurely pace. Yeah. Yeah, because most devices now can cache pretty heavily and pretty quickly. And then accessing things is just stupid fast. So once it's cached, there's not a worry so much about it. So if you can get... That initial load, I'm talking to the listeners at this point, try to get the initial load of your site under a second. It's, I mean, it's on a regular connection, right? So like a five megabits per second connection or on like a LTE connection or whatever you would consider regular. I know down in Florida, you said on WebAhead that you have an edge sometimes down there. Yeah, thankfully it's... T-Mobile kept promising me that they were going to upgrade the tower. And they finally did. Awesome. But, you know, it's not... Welcome to the world. Yeah, so to speak. It's, you know, the tower is no closer to my house than it was before. So it's LTE capable, but I'm still getting a really poor connection speed. So, yeah, I mean, it teaches me to be honest, I think. I've mentioned on the show before, I'm up in Chattanooga and we have the gig here. And I say the gig like everybody knows what it is. It's a gigabit internet connection. And it is incredible. And it's not through Google. It's actually through a company here called EPB. And they are like government sanctioned. And it's just fantastic service. And it's like the dreamland for development. So there's my like little pitch for any developers looking to move to Chattanooga. The internet here is awesome. You have a desk in your garage? Yes. You're welcome to come work anytime you want to at the Whiteboard office. Appreciate that. Anyhow, awesome. Well, Scott, you've got a couple of, speaking of traveling, you've got a couple of conferences coming up and they are anywhere near Chattanooga. Two of them are in Australia. Yeah, next month. I'll be in Sydney for Web Directions Respond Conference, it's called. I'm really excited about that. And then a week or so later, I'll be in Melbourne for CSSConf Australia. Nice. Yeah. Very cool. And how can people find out more? I guess they can Google it or what's a good link for them to go and find out about those? For the conferences themselves? Yeah. Hmm. I would Google Web Directions Respond. I'll throw it in the show notes. How about that? Yeah, cool. And CSSConf. And then you've got one in Germany as well? Yeah. Beyond Tellerend. That's in May. And in Dusseldorf. So, yeah. Exciting. Talking about spring coming up. Talking about responsible, responsive? Yeah. Yeah, I think a lot of the things that we sort of talked about on the call on this interview today. So, yeah. Perfect. Well, if you guys want to hear, if you want to hear more from Scott, obviously those are great opportunities for you to check out. Yeah. But also, scottgel.com. And, of course, Filament Group is always posting wonderful things on their site. Thanks. So, there's just a lot of content out there. And, I mean, just Google Scott Gel. He's all over the place. So, thank you, Scott, so much for joining me. I appreciate the time. Yeah, thanks for having me, Jonathan. We'll talk soon. All right. Thank you. Thanks to Scott, once again, for being on the show. I know that I gained a lot of valuable insight from Scott, and I will continue to do so over the years in the past, as well as in this interview. So, make sure you follow Scott online on the various places that he is tweeting and posting, etc. I will post those links in the show notes for you, which you can always find at developertea.com. Also, make sure you leave a comment if you have some thoughts on this show. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.