This course has been updated! We now recommend you take the Introduction to Dev Tools, v3 course.
Transcript from the "Common Problems" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Jon Kuperman: So next up I wanted to talk about the most common things that you'll see from all those different network problems that can possibly happen but first I think we have a couple of questions.
>> Speaker 2: Yeah so on from Kidar we have, do people use both Chrome stable and Canary at the same time?
[00:00:20]
>> Jon Kuperman: Yeah, so that's kinda up to you like you can go either way Canaries cool because it has some extra tools and some better like the more modern stuff for a Dev tools. But Canary is also very beta in the sense that like it may well just crash on you or like some of the stuff is really experimental so I like to use Canary for everything and deal with it when it crashes.
[00:00:46] You can also just use stable for everything and just wait on new stuff to come, or you can use both. Definitely an opinion thing, so. Okay, cool, and then I had two on Twitter which where from stuff we had talked about before. One was how you would go about things like lazy loading which I had kind of mentioned before, only loading stuff that's in the viewport basically.
[00:01:11] And so the whole idea with lazy loading would just be that like I kind of mentioned it. Like, so if you have all these images and you don't want to load all of them, you would instead of putting a source on them, if you have a source, the browser's going to fetch him.
[00:01:23] You could put a data attribute on it with the source URL. Then you can do some JavaScript so you can get the view port with get client bounding wrecked or whatever. There's an API call for the view port and you can like say that anything that's out of that you can add it.
[00:01:38] You can take use the JavaScript to take the data attribute and append a source so basically it's like this trick that you do where you don't load things until they come into view and then the other one was just about like critical rendering path. In CSS, and I think it's just like, that's a term just used for like, what stuff is like the critical rendering that is like what's necessary for your app to start functioning.
[00:02:01] Because there is a lot of stuff like the HTML might be there but until the synchronous JavaScript loads, you won't be able to necessarily click around and do stuff. So it's like basically like a lot of it is kind of what I was talking about before, or just like making sure that it's usually common practice to have one CSS and one JavaScript file.
[00:02:19] But in certain situations you might wanna have like the CSS and JavaScript that you absolutely need to render your page and then a separate big file that has like all the other stuff you might need eventually. So your page renders really quick and then, so the most common networking issues that you'll see are the queued slash stalled either side of that.
[00:02:40] Again with HTTP 1 like we talked about Chrome can only handle six synchronous requests, so if you have more than that they're gonna be stalled or queued. So do what you can to get it down to six, and I think, I'm pretty sure all the browsers have slightly different numbers of synchronous requests but I'd say like the five and six range is a really good number for initial load if you can.
[00:03:02] Obviously, images throw that off, but they're also a lower priority. So yep and then slow time to first byte, which can be one of two things. One is you could be on a bad network connection, like taking a long time and the other one is a slow server.
[00:03:18] So if you can check your network connection just to see if it's slow everywhere and figure out if it's that or not and if it's not then you wanna kind of toss the ticket onto the back end team and say okay I've got a really slow time to first byte all of my CSS assets.
[00:03:33] Like can we cache these put them on a CDN and can we speed anything up that kind of stuff. No longer your job is front and developers not that anybody gets to be just a front and developer anymore but there we have it. Another thing you can do which is really useful is there's a network simulator.
[00:03:50] So I'm hover back over to Dev tools and open them up on the network tab I'm actually gonna go ahead and pin this down to the bottom. And so it over here this throttling concept. So the traveling concept is to simulate different traffic conditions all way from offline to like really really slow.
[00:04:08] I like to load sites at regular 3G just to kind of remind yourselves of what It's going to really be. I mean we just get so used to you I live in California, places you have high speed Internet everywhere. You have 4G LTE service, you have a phone that was made in the last five years.
[00:04:25] Everything is really powerful. And so you rebuild sites that way like we are on our MacBook Pros. Like a T1 line or whatever and we're building websites, and we're forgetting how many people use the web, and how different the conditions can be. So try like throttling to regular 3G and then refreshing your pages and seeing how long they take to load now.
[00:04:45] And then remember to stop the throttling. I have one time file I took it at Twitter over a page taking over the threshold to load and then realize that I had a regular 4G on, so it wasn't a real noticeable amount of throttling, but it was somewhat. So yeah remember to turn it back to no throttling when you want to go fast on the web again.
[00:05:04] But again, this also only is in play when Dev tools are open. So throttling won't actually mess up your regular sessions. So that's pretty cool and I really recommend put on good 3G and do a refresh of your one your biggest pages and see what that experience is like.
[00:05:20] I mean it's could even be if you're at a coffee shop or crappy college WiFi something like that and that's the real customers, local customers that are struggling to get your page to load.