Check out a free preview of the full Debugging and Fixing Common JavaScript Errors course

The "Slow Page Loads" Lesson is part of the full, Debugging and Fixing Common JavaScript Errors course featured in this preview video. Here's what you'd learn in this lesson:

Using screenshots capability in Chrome DevTools, Todd shows how to illustrate a page rendering over time along with network activity.


Transcript from the "Slow Page Loads" Lesson

>> So let's move on to another bug. Here's one I think we've all had in our application. User called up and they complained, sometimes your page is slow. Awesome, dude, that gives me a lot to go on. So let's see if we can figure out why it's slow.

So I'm gonna just open this back up. If I just reload the page. Seems fast to me. Works on my machine, next bug. No, obviously, we can't do that. Well, so I'm running getRANTr, locally off of my computer, using pretty okay piece of hardware and a pretty new browser, and it's kind of the only thing I'm doing.

But I bet some of my users are not using quite so nice machines and probably on not so nice Internet connections. So we can try and understand, what does my application look like for them? If we go into the network tool, there's some tools we can use to actually manipulate how the network is going to react.

So up here in the header of it, on the far-right side is a throttling selector, where I can tell Chrome to not go as fast as it could go. To instead try and simulate, what would the experience of this page be like for somebody on a not so good connection?

So for example, I could say, hey, maybe somebody is using me on a good 3G connection. Like it's all right, they're traveling, they're ranting on the go. They're in some city. So let's put it on good 3G. And so that's going to introduce some artificial latency and artificial limitations when rendering the page.

And just to help you out, so you don't forget if you've turned that on. You might see that there's a little warning symbol above network now. So that later today, when you go to Facebook or Twitter or whatever and it's running really slow, you remember, yeah, I really slowed down my Chrome for debugging.

All right, so with that throttling in place I'm gonna just reload the page here. Still going, and done. That's it, it took a little while. It says it took 11 seconds front to end, 1.4 seconds to the load event. Let's do it again. There it goes, got a little bit more, ads coming in, ads filling in.

It is kind of slow. Let's see if we can figure out why it's slow. What are the things that are causing this to be slow for those users? To do that, we're gonna use the timeline tool again. Because here's another thing that the timeline tool is really good at, for understanding how does your application load.

For this, I don't necessarily care about the memory utilization but I care about screenshots. I wanna see what did my page look like over time. And so by switching the timeline from memory to screenshots, I'm just going to hit this reload page button. And it's going to start capturing a timeline immediately from when the request takes place.

And so I can see step by step, what were the actions that took place to load the page, and how long did they take? So reloading the page. Again, still taking quite a few seconds. And I see a bunch of information, Here at the main timeline view, looks similar to what it looked like before, we see frames per second, CPU, and network.

I turned off memory, but now we see screenshots. As you mouse over this area, you can see actual screenshots of what did your page look like at this stage in the load cycle. And we can see as I'm mousing over mine, I'm about a second in and I see that we have a text box and a Rant button, and a title, and that's it.

We'll get some more data start popping in at around 1,500 milliseconds. We know who the current user is. We see that it's Donald. And we see some of Donald's rants start coming in. At about 2,000 milliseconds, we see his profile picture pop in. Then, at about 2,500 milliseconds, we realize, there's some ads that need to get rendered.

And we create some boxes for them, but they don't quite finish until, 3,500, they're about halfway done, about 4,500 milliseconds before the ads are totally done. In the middle sections here, what's more important to look at than the JavaScript execution blocks that we're looking at before is the network.

And here, we can break down and look at each individual network request that happened and the order they happened and to put together the page.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now