Rfc/issue 354 strict / SSG mode

[thescientist13]

Related Issue

in support of #354, introduces a "strict" mode that strips out all client side JavaScript for projects that don't need any "runtime" JavaScript

Summary of Changes

Note: #354 will have to stay open, this is not the final solution I'm looking for. Ideally, there would be a progressive mode that would have to be a Babel plugin or something that would only ship the needed "runtime" code, like the banner for the Greenwood website

1. Introduced modes configuration option
   • ssg - ships NO javascript (has some caveats)
   • spa - current behavior
2. spa mode marks the <script> tag as async

Note this neat trick with inline <script> tag

Posted some initial performance results here. In both cases, performance is improved, even if Greenwood website's performance score is low. The hope is that enabling progressive mode could solve this, but probably an issue just for Lighthouse score should be ,ade.

Questions

1. Should we change the name to something other than mode, which we might need for this?
   • yes, will call it optimization

TODO

1. initial SPA benchmark / performance report
2. rename ssg to strict mode (think of another name for spa mode?)
3. Make strict spa mode default (the long term hope is that progressive mode would be the new default)
4. Testing
   • strict as default for smoke test and test cases
   • error case
   • add unit tests and update Config query
   • add test case for spa mode
5. add documentation
6. Refactoring
   • Use async or defer? I think in our case defer would work well for us? (avoid jankiness while hydrating mid load)
     • See if html-webpack-plugin can do async setting? (Not sure if async/ defer will work when serializing though...)
     • page bundles are included as <script> tags in index.html - should be async too, or removed in strict mode?
   • Don't render *.bundle.js script tags in strict mode
   • Don't render <lit-redux-router> in strict mode (shaved off 5KB from index.html for Greenwood website!)
7. Rename from mode to optimization
8. Optimize the 404 page (nice to have, follow up issue) - done
9. Final benchmark / performance report for both modes
   • Strict
   • SPA
10. Create an issue for tracking getting performance close to 100 for Greenwood / all users - made achieve (near) 100 Lighthouse performance base score #411
    • Would like to look more into why our index bundle is so large or is it as optimized as it can be, for SPA mode. (maybe split out the webpack runtime? Might include reviewing the merits of our default babel config too.
    • related issues: html minification #357 , improvements and optimizations for webpack CLI configuration #321, Dedupe content in JavaScript #305, asset and image compression (gzip / brotli) #235
11. Explore an issue for migrating Greenwood website to strict mode - explore strict mode compatibility for Greenwood website #410

[thescientist13]

Here are some initial benchmarks from local testing in Greenwood and my personal website. Will complete with some stats of current performance in productions

Prod

Network

Lighthouse

Stats

• Lighthouse: 54
• JS Payload: 452KB
• Requests: 24

Mode: Strict

Network

Lighthouse

Stats

• Lighthouse: 95 (+41) 🎉
• JS Payload: 136KB (-316KB) 🎉
• Requests: 13 (-11!) 🎉

Obviously doing so leaves parts of the site not working (rotating home page header, shelf sub nav, but this will end up being the use case for validating progressive mode.

Mode: SPA

Network

Lighthouse

Stats

• Lighthouse: 58 (+4) 🎉
• JS Payload: 448KB (-4) 🎉
• Requests: 23 (-1) 🎉

Summary

1. Although making the index.js bundle async did boost the score a lot, it is probably still too heavy and that is why it is causing such a drain on the score. Or Lighthouse is smart enough to tell that most of this code isn't needed...?
   • Deduping content will help here ( Dedupe content in JavaScript #305 )
   • Perhaps our default Babel config is to powerful and it's over bundling? Will play around with it to see if it helps
2. Need to rebase to get Google Analytics link preconnect bump
3. There are some caveats / advantages to `strict mode
   • CSS referencing custom elements will not work since they won't be registered by the browser, so apply selectors cautiously
   • Have to write side effect free code, e.g no fetch, setTimeout, etc
   • Polyfills plugin not needed

[thescientist13]

A couple things that are also interesting to observe is that production is already pretty bad, but none of the things having to do with the size of our JavaScript will fix things, seemingly?

These suggestions can help your page load faster. They don't directly affect the Performance score.

The issues with LCP, TTI, TBT are seemingly a result of other causes then?

Naturally, strict / ssg mode passes with flying colors as can be seen in the above comment.

For comparison though, my website is doing somewhat better than greenwood production website though

Interestingly, the Getting Started repo, which is bare bones, fares surprisingly better out of all of them? (Which I guess is expected, but why such a sharp drop off?)

---

So perhaps the issues here are related to

• something specific to our app code that isn't being done in the Getting Started?
• would be good to see if commenting out some of the bundled code would help improve the score? (like if bundle size was closer to 100KB?)
• Maybe we should use more HTMLElement where possible?
• Maybe we need to move more of our babel.config.js to userland? Maybe we're pulling in too much by default?

[hutchgrant]

• comment out external font from style/theme.css - alone, 5 score increase in spa, 2 performance score increase in ssg
• comment out analytics plugins from greenwood.config.js - alone, 3 score increase in spa and 7 score increase in ssg

In spa mode, I noticed an immediate reduction in Total Blocking Time when testing lighthouse in mobile mode. Which resulted in an increase score of performance 67. Not great but an improvement none the less.

In ssg mode, those changes resulted in a performance score of 100 when testing lighthouse in mobile mode.

[hutchgrant]

Nearly a perfect lighthouse score on mobile and desktop. One issue I noticed, our "get started" button is now green again. Also footer is now messed up. This is apparent in strict mode.

[thescientist13]

From our meeting today, will make the following changes

• We'll stick with async for now
• Will make spa the default option
• Will rename it from mode to optimize

[thescientist13]

Code wise I think this is all ready, just need to make the follow up issues. Also updated the static POC branch PR.

[thescientist13]

Final Stats, not too bad. Solving for LCP would be good for either strict or spa mode.

SPA

Strict