Combine .css.proxy.js files into one #1407

drwpow · 2020-10-26T04:30:28Z

Changes

Background

Background: #1334

For every .css file imported into JS, Snowpack creates one .css.proxy.js file. This requires an additional network request as well as a tiny amount of main thread blocking time to add the styles to the page.

As you can see, navigating through a Snowpack site can mean extra network requests, as well as delay in rendering while styles download.

Preloading CSS

Instead, a user can opt to concatenate all the CSS imported by JS, and only that, into one file. This can be achieved by passing { preloadCSS: true } to '@snowpack/plugin-optimize'. This serves all the CSS as one request, and injects it into the <head> element (or if Snowpack isn’t controlling your HTML, there’s now a __snowpack__/optimize-manifest.json file where this generated file can be pulled into an SSR setup).

In this way, you get the best of both worlds: all the CSS-in-JS features you’d expect with a modern setup, but compiled away into zero runtime, and in a way optimized for browsers.

Tested on skypack.dev:

~48 kB saved between no longer needing to inline <style> tags in the payload + no more wrapper code needed around all the JS files
26 network requests saved (and no waterfall)
No runtime/no dynamic <style> injection/no main thread blocking (though main thread time was only ~4ms on a fast machine)

Why is this PR so big?

Very little of the PR is the feature itself; the bulk of the PR comes from a few other changes which made the work of preloading CSS a heck of a lot easier. This is marked a draft PR for review because all 4 of the following could be split out as one or multiple prereqs if needed:

chore: Organized HTML, JS, and CSS logic into separate files
feat: A new __snowpack__/optimize-manifest.json was created so that this plugin can better optimize, as well as giving people generating their own HTML a hook to see generated files from Snowpack (inspired by a discussion from Getting rid of `.css.proxy.js` files for production builds #1334)
chore: hypertag was added, which is a much better way of scanning for <script type="module"> tags than we were using (and 0 deps! 🎉 )
chore: node-html-inject (created by yours truly to solve this exact problem) was added as a better way to inject arbitrary HTML inside<head> and <body>. While I found many HTML parsers and HTML AST libraries for Node, I couldn’t find any that easily let you mutate the HTML or AST. But even of the few that could, they were either very heavy and cumbersome or they mangled the original HTML in some way (because if you mutate something, everything has to be rebuilt). So I came up with a lightweight solution that’s basically just pure string injection, but in a better way than we were doing.

And of course, all these made the process of preloading CSS easier, which is the final change on top of these.

Testing

Tests were added to test this behavior, but it was also manually tested in a vanilla JS setup, Svelte, and Vue, and all work as expected.

If you want to profile a live Vue app using this feature, go here (code here)

Docs

Plugin docs were updated

vercel · 2020-10-26T04:30:31Z

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/pikapkg/snowpack/qnz5hcc45
✅ Preview: https://snowpack-git-drwpow-optimize-css.pikapkg.vercel.app

drwpow · 2020-10-26T04:33:49Z

plugins/plugin-optimize/lib/html.js

+      const code = await fs.promises.readFile(file, 'utf-8');
+
+      // <link>
+      hypertag(code, 'link').forEach((link) => {


❤️ Are you kidding me? Can’t believe we weren’t using this before!

Nice! I'm a bit concerned about the 0.0.3 version number, but the API and performance of hypertag sure looks great

Yeah, I feel you. I took a look at the source, and it’s basically just really, really good RegEx-ing that was doing a better job than ours. It’s a simple, 0-dep library that I feel confident in its simplicity. But if we discovered a critical bug and the author didn’t respond, it’s also simple enough to fork & patch if need be.

Yea, agreed on the feeling of this not being a super well used library that hasn't seen an update in 1+ years. BUT as long as you've given it a look inside and it looks good, then I'm +1

drwpow · 2020-10-26T04:36:54Z

plugins/plugin-optimize/plugin.js

@@ -188,26 +118,65 @@ exports.default = function plugin(config, userDefinedOptions) {
        })
        .map((file) => path.join(buildDirectory, file)); // resolve to root dir

-      // 2. optimize all files in parallel
+      // 2. scan imports
+      const manifest = await scanHTML(


🆕 Import manifest. This was needed because we first needed to see if any .css.proxy.js files were imported in the entire project before we injected a <link /> tag in the HTML. This looks like…

drwpow · 2020-10-26T04:42:17Z