View preact.md

Working with a React codebase and want to use Preact? Ideally, you should use preact and preact-compat for your dev, prod and test builds. This will enable you to discover any interop bugs early on. If you would prefer to only alias preact and preact-compat in Webpack for production builds (e.g if your preference is using React DevTools and enzyme), make sure to thoroughly test everything works as expected before deploying to your servers.

View workbox.md

Workbox runtime caching recipes

Your Service Worker script will need to import in Workbox and initialize it before calling any of the routes documented in this write-up, similar to the below:

importScripts('workbox-sw.prod.v1.3.0.js');
const workbox = new WorkboxSW();

// Placeholder array populated automatically by workboxBuild.injectManifest()
View image-decoding.md

Image Decoding in Blink / Chrome (August 18th, true as of M62)

Blink decodes off the main thread for image elements and for CSS styles (an image us as an element's background style, for example). Moving the decode to the compositor thread (or the compositor worker thread pool?) does free-up the main thread to work on other tasks. We call this deferred decoding. With deferred decoding, the decode work remains on the critical path for presenting a frame to the display, so it can still cause animation jank.

The HTMLImageElement.decode() API should help with the jank problem. Also deferred decoding does not work with SVG image resources. There are still cases where decoding images happens synchronously on the main thread: 2D canvas drawImage() and createPattern(), and WebGL texture uploads.

View minify-detect.js
// https://hg.mozilla.org/mozilla-central/rev/2f9043292e63
// Used to detect minification for automatic pretty printing
const SAMPLE_SIZE = 30; // no of lines
const INDENT_COUNT_THRESHOLD = 20; // percentage
function isMinified (str) {
let isMinified;
let lineEndIndex = 0;
let lineStartIndex = 0;
let lines = 0;
View bytecode.md

Some quick thoughts on https://twitter.com/dan_abramov/status/884892244817346560. It's not ignorant at all to ask how browser vendors approach performance. On the V8 side we've discussed bytecode precompilation challenges a few times this year. Here's my recollection of where we stand on the idea:

JavaScript engines like V8 have to work on multiple architectures. Every version of V8 is different. The architectures we target are different. A precompiled bytecode solution would require a system (e.g the server or a CDN) to generate bytecode builds for every target architecture, every version of V8 supported and every version of the JavaScript libraries or bundles bytecode is being generated for. This is because we would need to make sure every user accessing a page using that bytecode can still get the final JS successfully executed.

Consider that if a cross-browser solution to this problem was desired, the above would need to be applied to JavaScriptCore, SpiderMonkey and Chakra as well. It would need to ca

View sites.txt
http://www.corral.net/
http://www.arizonasportsfans.com/
http://www.oi.com.br/
http://www.likeable.com/
http://www.nysportsday.com/
http://www.tstllc.net/
http://www.statnews.com/
http://www.springmobile.com/
http://www.folhadeparnaiba.com.br/
http://www.bilibili.com/
View scratchpad.md

"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:

  • Ensure you're using a production build of your framework: new webpack.DefinePlugin({ 'process.env': env })
  • Minify your JS: webpack.optimize.UglifyJsPlugin
  • Compress your resources (GZip): compression-webpack-plugin
  • Split your vendor chunks: CommonsChunkPlugin