Reduce load times

[outoftime]

The goal here is to optimize load time for a fresh session, i.e. navigating to https://popcode.org without having been recently logged in, no gist or snapshot URL, etc.

• Investigate lodash’s contribution to bundle size—seems like we’re not getting the benefits of a la carte module loading. Should we use the a la carte packages instead?
• Replace or trim down moment
• Replace or trim down text-encoding
• Asynchronously load libraries (e.g. the inlined copy of jQuery that’s used when it’s enabled for a project)
• Asynchronously load vendor code that isn’t required to bootstrap a fresh session (e.g. GitHub, Firebase clients)
• Vendor split to improve cacheability

Webpack visualizer is a great tool for finding the worst offenders in our bundle size.

[outoftime]

https://github.com/siddharthkp/bundlesize looks like a pretty good way to make sure we lock in improvements here

[outoftime]

Cross-post from #1031:

I feel like it was broken at some point but the Webpack Visualizer is working great now, ton of low-hanging fruit in here. I’d be inclined to try pulling out some of the big libraries that we don’t need for minimal bootstrap (firebase/database and github are two obvious ones) into async loads, but feel free to follow your nose/heart as well!

[outoftime]

@ajgreenb also one other thing I’m noticing that may be worth investigating—when I do a cold load and inspect the Network tab, many resources seem to be spending an alarming amount of time in a “Request to ServiceWorker” phase. Not sure what’s up with it but might be worth looking into…

[ajgreenb]

Cool, I'll check in on both of those things. Earlier tonight, I tried taking a recording using the Performance tab of the developer tools from a refresh but the recording never loaded (the tab just hung.) Have you tried that/had any luck?

[outoftime]

@ajgreenb hmm yep, was able to just run a Performance recording of the production app loading now—here’s a dump if it’s useful!

[ajgreenb]

@outoftime I took a look into lodash's contribution to the bundle size. From what I can tell, we are benefitting from a la carte module loading. The reason we see that large section from lodash in the sunburst chart from Webpack Visualizer is that stylelint imports the entire lodash library. You can verify this by using the select menu in Webpack Visualizer to filter the chart to just the vendor chunk and then just the linter chunk. Viewing just the vendor chunk, lodash contributes a much smaller percentage to the chunk size. I could be interpreting these results incorrectly, of course. Was there anything else that led you to suspect that using lodash's a la carte loading wasn't helping?

[outoftime]

@ajgreenb good investigaish! I think that probably explains what I was seeing, although it’s still not great that stylelint is importing the entirety of lodash (it’s less bad to have bloat in the async chunks but still bad).

Can we run stylelint through babel-plugin-lodash so that we’re only bundling the parts we need?

[ajgreenb]

Darn, looks like babel-plugin-lodash requires that ES2015 imports be used to load lodash. stylelint uses CommonJS 😑

[outoftime]

@ajgbreenb rats!!

maybe we submit a patch upstream to stylelint? a quick Google search does not yield an existing codemod but it seems like such a thing should be fairly easy to write…

(also i would only propose doing any of this at such time as the stylelint-imported lodash is the worst offender for bundle bloat, which i’d conjecture won’t be the case for a little while)

[ajgreenb]

Word. I'll back-burner patching stylelint and come back to it after I've spent some time optimizing the vendor chunk.

Seems like a codemod for compiling CommonJS to ES2015 would be high in demand. I wonder if it doesn't exist because CommonJS supports dynamic and conditional requires, while ES2015 imports must be static?

[outoftime]

@ajgreenb sounds good! although I should clarify that I was talking about patching stylelint to do discrete lodash module imports, not to switch to ES6-style static imports. i’m guessing there is probably a codemod for the latter ; )

[outoftime]

@ajgreenb have you come across https://www.npmjs.com/package/html-webpack-inline-chunk-plugin ? The manifest use case seems pretty good!!

[ajgreenb]

@outoftime we already use the *deep breath* inline-chunk-manifest-html-webpack-plugin for this!

[ajgreenb]

Leaving this here for later:

http://webpackmonitor.com/