Brainstorm: opportunities to improve main thread

[paulirish]

Right now we do have diagnostics which summarize some main thread activity (main thread breakdown and bootup time), but we don't have any targeted opportunities regarding interactivity.

It'd be nice to help the users figure out how to improve the health of their main thread.

---

Few general approaches:

1. Do less work
   • Don't do the work at all (Find needless stuff and nuke it)
   • Do the same work faster. (Profile it and speed it up.)
   • Do the work off the main thread.
2. Split up long tasks.
3. Do the work in downtime
   • Defer work till later, after TTI
   • Do work earlier, so TTI doesn't get pushed out

Maybe we can develop some heuristics to create specific suggestions?

[wardpeet]

maybe it's an idea to push people to Webworkers? By checking if tasks touch the dom?

[Schepp]

• A good strategy to reduce initial load is to replace any DOMContentLoaded based component setup with an IntersectionObserver driven one. Components way down the fold need no immediate setup.

• Defering below the fold component initialization with requestIdleCallback is also nice, although I hate how you determine visibility of an element currently. I would love a promised based DOM API for that (ideas here).

• Web Workers are nice but most of the initial work involves DOM, so no big wins here. What I identified as suited is template rendering and eventually DOM diffing, if the DOM being diffed on both sides is virtual.

• Maybe also hint at the fact that scripts cached by a Service Worker skip the parsing phase, which in turn means less time taken until execution?

[ebidel]

a good strategy to reduce initial load is to replace any DOMContentLoaded based component setup with an IntersectionObserver driven one. Components way down the fold need no immediate setup.

I don't think we can safely assume this. Non-visual components could be low in the tree, display: none, etc. but still play an active part in rendering the page. e.g. a <firebase-db> element which fetches data for the page to render.

[midzer]

Maybe we could check how much % of JS is actually run on audited page and give a hint that X % is parsed and compiled without effect. Splitting up large bundles could be a major benefit for non-SPA apps on low end devices.

https://github.com/GoogleChrome/puppeteer/blob/master/docs/api.md#class-coverage should provide necessary information for this approach.

edit: Code splitting is good practice for SPA, too. For example webpack recommends https://webpack.js.org/guides/code-splitting/

[patrickhulce]

We think @paulirish would be a great candidate to tackle this new audit, tentatively called "all of Lighthouse" ;)