addyosmani

• Web Page Usability Matters
• PageSpeed Insights w/Lighthouse and Chrome User Experience Report
• Data Saver for Chrome on Android - enable and then look at about:flags for Lite Pages and other interventions
• web.dev/fast - code-labs and tooling for optimizing performance
• Lighthousebot for using Lighthouse in continuous integration
• Bundlesize for JavaScript budgets in CI
• Start performance budgeting

addyosmani

Ember.js currently doesn't have baked in support for Service Worker. They want this and there's an ember-cli RFCS thread discussing strategies however a number of tooling efforts exist to help fill in this gap today.

Note: you can of course just write vanilla Service Worker code for your Ember.js apps and that will work just fine. This doc tracks tooling and libraries that lower the friction for getting this setup

Service Worker Libraries

• sw-precache
• sw-toolbox

These static resource precaching and runtime caching libraries are lower-level than Broccoli, but can be used directly

addyosmani

<img data-src="unicorn.jpg" loading="lazy" alt=".." class="lazyload"/>

<script>
// Select all images with the class "lazyload"
const images = document.querySelectorAll("img.lazyload");
// Check if the browser supports the "loading" attribute
if ('loading' in HTMLImageElement.prototype) {
  // If so, we'll update all <img src> to point to the data-src instead
  images.forEach(img => {
    img.src = img.dataset.src;

addyosmani

(function() {

    /**
     * @param {Object|Function|string} object
     * @param {string} methodName
     */
    window.captureCalls = function captureCalls(object, methodName) {

        var path = '';
        if (typeof methodName == 'undefined') {

addyosmani

#Four Ways To Do Pub/Sub With jQuery and jQuery UI (in the future)

Between jQuery 1.7 and some of work going into future versions of jQuery UI, there are a ton of hot new ways for you to get your publish/subscribe on. Here are just four of them, three of which are new.

(PS: If you're unfamiliar with pub/sub, read the guide to it that Julian Aubourg and I wrote here http://msdn.microsoft.com/en-us/scriptjunkie/hh201955.aspx)

##Option 1: Using jQuery 1.7's $.Callbacks() feature:

$.Callbacks are a multi-purpose callbacks list object which can be used as a base layer to build new functionality including simple publish/subscribe systems. We haven't yet released the API documentation for this feature just yet, but for more information on it (including lots of examples), see my post on $.Callbacks() here:

addyosmani

Re: http://blog.chromium.org/2015/03/new-javascript-techniques-for-rapid.html

V8 Optimisations to enable fast page startup

As mentioned in our Chromium blog post, Chrome 41 introduces support for streaming parsing of JavaScript files using the async or defer attributes. This is where the V8 parser will parse any incoming JavaScript piece-by-piece so the compiler can immediately begin compiling the AST when script loading has completed. This lets us do something useful while waiting for the page to load. Compare:

This means parsing can be removed from the critical path when loading up the page. In these cases such scripts are parsed on a separate thread as soon as the download begins, allowing parsing to complete very soon after the download has completed (milliseconds), leading to pages (potentially) loading much faster.

addyosmani

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

addyosmani

Yoyo. There are more articles/resources available than the below, but most appear to be older. To avoid the pain of upgrading finding things broken, I would try one of these. They're more recent.

• https://www.youtube.com/user/CodersGuide/videos (series on PhoneGap + Material Design using Polymer)
• https://www.youtube.com/watch?v=XL8NG-_Q4ds (Using Polymer with Cordova)
• https://github.com/infomofo/cordova-polymer-template (Cordova Template for working with Polymer - last year, so probably requires an update)
• https://github.com/MobileChromeApps/mobile-chrome-apps (This lets you use cross-walk (on Android) as the WebView, which is significantly faster. Worth trying for your Polymer app if you're targeting hybrid)

addyosmani

Route-based chunking

Many of us building single-page apps today use JavaScript module bundling tools that trend towards a monolithic "bundle.js" file including the full app and vendor code for multiple routes. This means if a user lands on any arbitrary route they need to wait for a large bundle of JS to be fetched, parsed and executed before the application is fully rendered and interactive.

This is a little backwards, especially when apps are used under real-world network (3G) and device

addyosmani

// 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;