Web Performance with Webpack Vendor Bundles are an Anti Pattern
Transcript from the "Vendor Bundles are an Anti Pattern" Lesson
>> Speaker 1: Can you talk about the trade offs between using vendor bundles versus code splitting entirely by the client's route?
>> Sean Larkin: [LAUGH], yes, so vendor bundles are a big anti-pattern To me this is why in Web Pack 4 we got rid of commons chunk. Because so many people were, and no offense to the person, who was it who asked me earlier, or yesterday?
[00:00:27] I'm not painting you as this person, but we had so many people who would obsess. Like, I can't synthetically get these three modules to be in this one bundle, and by using common chunk. It caused so many people to froth at the mouth obsessed about trying to optimize caching.
[00:01:16] In some browsers, you might get byte code caching, but that's just parse cost, that's not eval and execute. So you're doing yourself very little favors by trying to optimize for caching. Versus trying to optimize for the smallest amount of code that you actually need on your initial download of your page, right?
[00:01:38] So what you would find out is that by trying to do a bunch of caching, you end up with these ginormous bundles. That you force entry points to ship down the pipe, right, on your initial download. So I shouldn't discount caching as an optimization, it is still valuable, but what I tend to say, and maybe this is a little brash.
[00:02:02] But it's like, come talk to me about caching when you get to 300 kilobytes of code on your initial download. And then we can take it a step further, right? Because this is what's gonna save you tens of seconds. Seven seconds on your load time, where caching is gonna maybe save you 400 milliseconds.
[00:02:28] So, that's why we removed commons junk. That's why we do it by default now out of the box for only asynchronous bundles.