Code Coverage

[00:00:00]
>> Sean: Before I talk about code splitting, I wanna actually give you a demo of how you can determine your code coverage, right? So, what I want you to do is maybe pull up a website. I'm gonna pull up, let's say, mm-hm, let's see, what's a great website that showcases this?

[00:00:21]
Here, we'll do one, I used to work for mutualofomaha.com or Mutual of Omaha and we did an entire site redesign. It's a multipage app architecture using Vue JS for any of the front-end assets and then it is using Laravel PHP in the backend. So you can see this was actually relatively fast to load, I'll reset it, and it progressively loads, right?

[00:00:45]
So let's find out and inspect, so, you can open up Chrome Dev Tools. If you don't have Chrome Dev Tools, you can follow along or take notes, but currently, today this is the only feature in any browser that allows you to test this coverage metric. So, when you open up Dev Tools, you just wanna hit Ctrl or Cmd + P, and you'll see the little command palette.

[00:01:13]
I'm sorry, Shift + Ctrl or Shift + Ctrl + P or Shift + Cmd + P, there we go. And you just wanna type in coverage. And you'll see the first item that shows up there says, Drawer Show Coverage. So when this pops up, you'll see some dialog here and all you have to do is click this little reload icon.

[00:01:40]
>> Sean: So now you'll see here, is that instantly you can identify how much code was used across this entire application for this initial view, right? So, as you can tell here, we can identify right away, this is a huge opportunity for this team. I was just talking to them last night cuz I was doing an audit, and I said, dude, why are you not using 62% of the code right here?

[00:02:12]
What's going on? And so now, the one caviar, or the one thing that frustrates me is that unless you have full source mapping turned on, trying to identify what the unused code is, is not very friendly. And this is what I want to solve for Microsoft Edge, I have a full specification written bringing this feature to Edge after we finish our remote dev tooling work.

[00:02:38]
But the kicker is, what if you could just take a web pack bundle analyzer status data, and bind it to this? The dev tools could consume, and then, you really have a graph that shows red borders around the modules that aren't actually used, right? It's instant easy opportunity to identify.

[00:03:00]
So we can kinda see that there are areas, what was it? I can't remember exactly what the code was, but you can see here the red and green lines are gonna give you the opportunity to identify, what is used and what is not used. And so for now it's not the best way, it a little time consuming.

[00:03:22]
But if you do have pre-staging environment, you could maybe ship your code unminified, it's make it easier to see. Or just have full source mapping turned on. And so in this case, what was it? There were some legacy JavaScript files that they had to include for custom analytics and they told me that, yeah, why is this?

[00:03:50]
Okay, so here we go. So it looks like there is some library that's used to do a bunch of web GL that is not needed. That's probably taking a considerable amount of time, gonna be like none of this is used. And it's pulling in a whole bunch of shaders and like what?

[00:04:08]
So, this has will be an opportunity, at least if doesn't tell you right away, it's hey, these are pretty obvious flags, maybe you were shipping too much code upfront. I mean, I'm being hard on my former team, but really look at the total amount of code that they shipped, right?

[00:04:30]
It's only about 700 kilobytes. Now this isn't bad, what they should be doing is maybe set a standard in their CI pipeline that just breaks their build if they go over what they are today. And so every PR that they make they can try and lower that barrier every time.

[00:04:50]
And so that way you have standards, or performances as a standard just comes as a first class citizen. Is just another thing that you do and you always are concerned about. So, now when you think about this, so when I talked about, whereas the, let me see. So when I talk about these numbers here, when I say 90% code coverage, I say that, oops.

[00:05:19]
>> Sean: You wanna have this number to be about 10%. You can't really see it, but essentially you wanna have out of all the resources that we're shipping, JavaScript and CSS, you wanna be using 90% of it, even 80% is a good metric. But, the reason why I say this is because if JavaScript and CSS are the most costly things to load, and only half of your code is actually being used.

[00:05:50]
You have the instant low hanging fruit that you can reduce to have a faster page, right? So and I'm gonna show you how Webpack helps enable this.
>> Speaker 2: Quick question.
>> Sean: Go ahead.
>> Speaker 2: Let's say they had a megabit of JavaScript-
>> Sean: Absolutely.
>> Speaker 2: And 15% of it was unused.

[00:06:13]
>> Sean: Yes.
>> Speaker 2: What kind of load-time reduction would you be seeing? Are we talking like, fractions, 10ths of milliseconds?
>> Sean: No, you could have like a second, two seconds. You can significantly reduce the amount of time your page loads. What was it?
>> Speaker 2: This one's different for mobile versus.

[00:06:36]
>> Sean: Yeah, well I mean, especially mobile too, mobile even gets more, you'll see more reduction because those are the devices that struggle the most when it comes to parsing and evaluating and executing JavaScript through the V8 Engine. So much that even the temperature of that device can affect how slow it takes.

[00:06:57]
If you have a hot phone, so I was working with the flip cart and the housing.com teams who they're market is India and they literally have to test on every single device to make sure they are performing as possible. And they found through their testing that even when their phones heat up, they were seeing a two to three second load time drop or increase in their pages.

[00:07:22]
And so, even mobile devices, especially these 2G and 3G in emerging markets are not that sophisticated. Nobody is rocking the pixel or anything like that, and so, if you're trying to reach people. Or even people in rural areas, I mean, it's super important to be able to ship a super-fast experience.

[00:07:44]
And it's not that you need a megabyte of code to deliver that initial experience. That's what the code coverage really kind of unveils, it's you only need about a tenth of this code, right? And the idea is just understanding how we can reduce it.