"We need Webpack presets" and "Webpack and its plugins are too hard to configure correctly" have been the number one cause of developer pain shared with me from large sites adopting Progressive Web Apps and optimising their load performance.
If I was building a Webpack preset pack for performance, I might use the following:
- React: https://github.com/insin/react-hn (PWA)
- VueJS 2.0: https://github.com/vuejs/vue-hackernews-2.0 (PWA)
- Angular 2.0: https://github.com/housseindjirdeh/angular2-hn (PWA)
- Ember: https://github.com/chancancode/hn-reader
- Preact: https://github.com/addyosmani/preact-hn (PWA)
- Inferno: https://github.com/infernojs/inferno-hn
- Type chrome://flags into your browser
- Scroll down to “Enable Developer Tools experiments” and click enable
- Restart Chrome
- Open up DevTools
- Click on the gear icon — it’s typically on the top right or bottom right
- Select experiments from the menu on the left
- Hit shift 6 times to show hidden experiments
- Enable 'V8 Runtime Call Stats on Timeline'
We are hoping to turn this feature on by default soon so the above steps are not needed.
- Yoav: This can particularly be an issue on mobile. Same files getting parsed all the time for users. Theoretically if we moved the parsing work to the server-side, we would have to worry about it less.
- We've been talking about this topic over the last few weeks a bit with V8. There were three main options proposed.
- Similar to what optimize-js does. Identify IIFEs and mark them as such so the browser and VMs heuristics will catch them and do a better job than today. optimize-js only tackles IIFE bu
|Flexbox CSS helpers from the Polymer team. Extracted from https://github.com/PolymerElements/iron-flex-layout for use as just CSS.|
|Copyright (c) 2017 The Polymer Project Authors. All rights reserved.|
|This code may only be used under the BSD style license found at http://polymer.github.io/LICENSE.txt|
|The complete set of authors may be found at http://polymer.github.io/AUTHORS.txt|
|The complete set of contributors may be found at http://polymer.github.io/CONTRIBUTORS.txt|
RAIL encouraged loading a site in under 1000ms on cable and (not well documented) between 3000ms and 5000ms on 3G. Loading is a pretty broad term and we don'the think it's enough for the page to "look" done. It should be engagable.
There are many different "key moments" in loading a page however that offer us more nuance.
- “is it happening?” (i.e. time to first paint)
- “is it useful?” (i.e. time to first meaningful paint)
- “is it usable?” (i.e. time to stable layout / time to interactive)
This is a little backwards, especially when apps are used under real-world network (3G) and device