Google held their second Chrome Dev Summit last month in Mountain View. In their own words, “The Chrome Dev Summit is an exclusive event to connect with Chrome engineers and leading web developers for a two-day exploration of building beautiful and fast mobile web applications.”

The first edition of the conference was excellent, so I (once again) watched all of the talks and took notes.

Progressive web apps: web apps that work “better” as they enable push notifications, add to the homescreen, work offline, but don’t rely on these technologies.

Products and themes of the summit

Average user interacts with 25 apps a month but visits 100+ websites a month. 80% of the time in apps is spent within 3 apps.

62% of global mobile connections are 2G. In India it is 87%.

Chrome will start requiring HTTPS for access to powerful APIs such as the system camera.

HTTPS 102: A set of Chrome tools coming to a new security tab in the Chrome developer tools that will help developers understand and move to HTTPS.

App shell plus server worker model is the best way to structure web apps for instant load times.

This does not mean that we shouldn’t still use cache-busting techniques in file names and long expiring HTTP headers.

sw-toolbox provides different loading strategies for various routes.

Life of a service worker: Service worker fires install event, activate event, idles, and then fetches but is later torn down when it stops.

HTTP requests talk to service worker which determines if it should read from the cache or network.

The app shell, along with dynamic content, is the page.

App shell: HTML, CSS, and JS that provides the structure of the page.

Mobile push notifications are an open standard developed by Google, Mozilla, and others.

You shouldn’t ask for notification permissions on initial page load. Show it after an action so the user understands what the notifications are for.

The mobile web push notifications work through service workers. A web server communicates with a push server which communicates with a service worker on the phone. The service worker doesn’t have any context or data so it must fetch information from the server.

Google wants the URL bar to be able to show URLs that are being “broadcasted” from nearby devices.

Website can request to see the nearby Bluetooth devices based on service type (devices that have a battery level, for example) or a custom device UUID. User then chooses the device.

Web Bluetooth will enable the browser to connect to devices without additional software and in a very responsive interface.

If the user doesn’t grant permission, the UI should update accordingly and handle the failure gracefully.

Show why before asking for permission and let users skip before the permission dialog opens. This allows developers to ask again at a better time.

The new permissions API allows developers to ask for permission at the right time.

Web components are happening: all of the browsers have some sort of support in the nightly versions.

chrome://inspect lets developers run the Chrome inspector on their physical device.

The manifest file allows developers to specify app icons, theme color, and other properties that make the website feel like a native application.

Apps must support service workers, be HTTPS, and include a manifest file to show a “Add to home screen” prompt in Chrome.

There have been plenty of tools that allow web apps to work offline. Service workers are finally a low-friction solution.

We have been trained to not use the web browser when offline. This is a great reason why Chrome’s new web app install banner is useful.

Browsers that support custom elements have an :unresolved pseudo class that developers can use to make the element look like it will once the content loads.

Check to see if web components are supported before loading the polyfill.

For custom elements, you get the visual rendering, DOM object, but not the accessibility node.

When you create an element on a page, you get a visual rendering, a DOM object, and an accessibility node that is used by screen readers.

Types of disabilities that users might:

The user context matters when speaking of performance. 50ms when scrolling feels like an eternity compared to 50ms on page load.

Many animations are a complex combination of small animations. DevTools can now group these together , allowing developers to slow them down and see a timeline of each animation.

“Inspect Devices” feature is being moved to the DevTools, not a hidden page in Chrome.

A new device mode is being built for the mobile first world. The UI is much simpler and it now provides the ability to show the Android system bars, and shows a list of the media queries. Throttling is being moved to the “Network” tab.

Developers can’t control the user’s connection, but they can implement service workers to ensure that subsequent page loads are quick.

Last: Add a class that puts it in the final position. Call getBoundingClientRect again.

First: Find the position of the initial state with a function like getBoundingClientRect .

Don’t use micro-benchmarks to make design decisions. Developers should look at their app benchmarks, not an isolated environment.

TurboFan is the new JavaScript compiler for V8.

Make the critical path local with ServiceWorker using the application shell.

A new API window.requestIdleCallback (mentioned in a previous talk) allows developers to move work into the browser’s idle blocks.

Frame Timing API: PerformanceObservers will allow developers to listen for slow frames.

New API called IntersectionObserver will allow developers to determine when a selector is in the viewport without needing to constantly poll on the main thread and block execution of other, higher priority code.

Implementation underway to add third parameter to document.addEventListener that, when passed with { passive: true } prevents the browser from blocking on the main thread and promises that preventDefault won’t be called.

There was a team at Google that discovered their application ran slower when it was hot outside. That is because drivers used the product and the sun from the windshield slowed down the phones.

Paul has done many performance audits that are available online.

The height of a callstack is not necessarily a problem.

Green blips under the red represents the frame rate. Taller is better.

Holding Shift when hovering over a file shows the complete path to the resource and the relationships between the files.

DevTools has a hidden “Priority” column in the table of network requests. Right click on the table header to enable it. The priorities map (more or less) to if it is render blocking or not.

It’s a good idea to look at the first meaningful paint and look at the requests that happened beforehand.

Presented by Surma, engineer on the Chrome team

There is no way that HTTP/2 will be slower. It is performance for free.

Concatenation, minification, inlining, spriting, sharding, vulcanizing, and gzipping are all workarounds for the HTTP/1.x limitations.

HTTP/2 is an upgrade to HTTP1/.1. In other words, all connections start as HTTP/1.1 but get “upgraded” if the client supports HTTP/2.

HTTP headers can now be compressed in HTTP/2 thanks to HPACK, a header compression specifically for HTTP.

Financial TImes saw a large decrease in load time by moving static assets to a HTTP/2 enabled Akamai server.

In HTTP it is better to keep the number of asset origins as small as possible because of how the compression works.

The “Push” feature allows the server to send back certain assets such as style sheets and JavaScript in the initial response before the client even requests it.

Even with HTTP/2, developers still need to worry about: GZIP/deflate, improving first render, minimizing DNS lookup, and cache-control.

Almost all browsers, servers, and languages support HTTP/2. Complete list exists at bit.ly/http2implementations

You can see the protocol that an asset was loaded over by showing the “Protocol” column in the table within the DevTools “Network” tab.

You can put static assets on an HTTP/2 CDN and serve the rest of the site over HTTP/1.1.