I attended day 1 of Chrome Dev Summit 2016. Here are my notes:
Intermission
The intermissions between the talks were really entertaining ;)
Keynote: Darin Fisher: Chrome Engineering
Mission: Move the web platform forward.
Over 2 billion active Chrome browsers.
Bluetooth beacons are broadcasting the URL for the Chrome Dev Summit website.
polymon.polymer-project.org
Mobile web usage has far eclipsed desktop web usage.
Almost 60% of mobile is 2G.
India is experiencing the most growth in people getting online.
A lot of Indian users have so little storage space on their phones, they can't afford to install a lot of apps. They routinely install and then uninstall apps.
The web works really well in emerging markets.
Progressive Web Apps are radically improving the web user experience.
He demoed cnet.com/tech-today. It's a progressive web app. He showed a smooth experience even though his phone was in airplane mode. The icon was added to his home screen.
11/11 is singles day in China. It's happening right now. It's the biggest shopping day of the year for them. Alibaba built a Progressive Web App, and it increased conversion by 76%.
53% of users abandon sites that take longer than 3 seconds to load.
It's all based on the Service Worker API. It lets you control your caching strategy and offline approach.
Apps should be interactive within 5 seconds on a 3G connection.
Users re-engage 4x more often once you've added the site to the home screen.
Prompting users sooners yields 48% more installs.
18 billion push notifications are sent daily.
50,000 domains use push.
Seamless Sigh-In using the credential API: -85% sign-in failure, +11% conversion for Alibaba.
Lighthouse is a Chrome extension that they built to help you optimize your Progressive Web App.
There's a new Security tab in Chrome Dev Tools.
Polymer is sugaring on top of Web Components that makes the web platform more capable.
Browsers have implemented Web Components, minus the HTML imports part.
Polymer App Toolbox makes it easy and fast to prototype a Progressive Web App, and to transition from prototype to real app.
beta.webcomponents.org
AMP: Accelerated Mobile Pages
700,000 domains are using AMP.
developers.google.com/web/
browser-issue-tracker-search.appspot.com: Search for bugs across the major browsers.
Progressive Web App Roadshow: developers.google.com/web/events/
He mentioned Web Assembly, WebGL, WebVR, AR (augmented reality) etc.
Imagine you walk up to a device. It uses web Bluetooth to share a URL. The URL takes you to a website that allows you to control the device. The website uses web Bluetooth to control the device.
Intermission
bigwebquiz.com
There are a lot of subtle anti-Trump references from the various speakers.
Building Progressive Web Apps
@thaotran
A 1MB download can cost up to 5% of the monthly salary for some people.
She talks to lots of companies about being early adopters of web technologies.
Flipkart built a Progressive Web App that was really successful.
They saw as much traffic on mobile web as on their mobile app on the biggest shopping day of the year in India.
Smashing Magazine: A Beginner's Guide to Progressive Web Apps
What is a Progressive Web App: it's about radically improving the web user experience.
It should be your main web site.
developers.google.com/web/progressive-web-apps/checklist has a baseline and an exemplary checklist.
She mentioned the Lighthouse Chrome extension.
Alibaba conversion rate improvement:
+14% iOS
+30% Android
housing.com was paying $3.75 to acquire new Android users. However, it only cost them $0.07 to acquire new mobile web users.
lyft is no longer app only. They built a web app, and they got 5X more traffic than they expected.
Android app: 17MB
iOS: 75MB
PWA: < 1MB
makemytrip.com found that for first visit bookings, PWA users book 3X more than often than app users.
IBM acquired The Weather Company (The Weather Channel).
Things they're talking about:
Progressive Web Apps
Accelerated Mobile Pages
Push Notifications
Seamless Sign-In
One Tap Checkout
Sign-in on the Web
54% of users will abandon rather than register.
There's an autocomplete attribute that you can use on your login forms.
92% of users will leave a site instead of resetting login info.
g.co/2CookieHandoff: 2 cookie handoff using Service Workers
There's a Credential Management API.
It's a standards-based browser API.
It's in Chrome.
Automatically sign in the user on the homepage.
AliExpress:
11% increase in conversion
85% drop in sign-in failures
60% decrease in time spent signing in
It can work with federated accounts such as logging in with Google or Facebook.
Google Smart Lock: the browser remembers your credentials. Then, on another device, it'll automatically sign you in. Nice demo.
Google Smart Lock even works with federated accounts.
It also works even if you've signed in in multiple ways.
Really impressive.
g.co/CredentialManagementAPI
Faster Web Payments
@zachk
PaymentRequest.
Let the browser help you with checkout.
Mobile has 66% fewer conversions than on desktop.
Chrome started with autofill. Set autocomplete types on the checkout forms.
But, today, he's talking about PaymentRequest. It's a new payments API for the web.
It's *not* a new payment method or a processor/gateway.
It's a standards-based API baked into the browser.
polykart-credential-payment.appspot.com
The API is based on native UI.
Really seamless. No keyboard usage needed (except typing in the CVC).
For now, Chrome supports credit cards and Android Pay.
It's really about helping the user avoid filling in a bunch of form fields. The browser can help a lot.
Kill the cart: give the user an option to "Buy Now".
Think of this as a progressive enhancement.
PaymentRequest works best for new users and guest checkout flows.
Coming soon: support for third-party payment apps.
Integration guide: goo.gl/eLefwM
I think this is only mobile for now.
Debugging the Web
@paul_irish
The call stack now looks better, even when you shrink the window.
Chrome supports ES6 pretty well. Even in the console, ES6 is supported pretty well. Even async/await.
You can now enter multiple lines in console.log without hitting shift return. It indents as you go. It does brace matching. He pointed out that Safari had this first.
Tab completion works in the console quite nicely. It even works for arrays once you hit '['. The tab completion works with substring completion instead of just prefixes--just type any part of the word.
There's a snippets tab in the sources tab where you can have snippets of code that might be useful. These are persistent.
Inline breakpoints: You can place a breakpoint, and then it allows you to drag the breakpoint within the line.
Note to self: never use the unauthenticated GitHub API during a demo--you might get rate limited. At the very least, have some static data to use as a backup.
The workspaces feature is improved: In Sources: Network: Drag an OS X folder onto the left pane. Without configuration, you should be able to edit your code in Chrome. It works even if you're using transpilation with sourcemaps.
There's a new shadow editor.
As of today, in the Canary, there's a checkbox with CSS coverage. You hit record, and then start using the site. It'll mark the CSS styles that were never used.
He's using iTerm2.
node --inspect app.js
It gives you a URL. That's the old way.
However, in Sources, there's a Node thing under Threads. Then, in Console, there's a context.
You can use a single instance of Dev Tools to debug both the frontend and the backend.
Application tab >> Manifest: Tells you about the state of your Service Workers.
There's also Application >> Clear storage.
Application: Service Workers >> Update on reload. Lets you reload the service worker every time. There's also "Bypass for network". That's useful to skip the service worker.
He plugged the Lighthouse extension again. It's useful to turn a web app into a Progressive Web App. It also helps audit for best practices. Captures performance metrics too.
It's just a Node module. A lot of tools are already building on top of it. You can even set it up for use in CI.
Chrome Dev Tools >> Settings >> More tools >> Audits 2.0 is powered by Lighthouse.
They wrote caltrainschedule.io.
@ChromeDevTools.
He's using Visual Studio Code a bit.
Polymer, Web Components, & You
@TaylorTheSavage
"We are at war with phones."
#UseThePlatform
Polymer is the Chrome team's set of libraries for web developers to take advantage of the web platform.
Web components is an umbrella term for a bunch of low-level features.
Web components v1 is something today. All major browsers are onboard with everything--except HTML Import, that's still on hold.
Cross-browser web components are here.
Polymer is a light weight layer on top of Web Components. It's evolved with Web Components.
Polymer 1.0 is production-ready. That was released last year.
Comcast, USA Today, ING, Coca Cola, EA, etc. use Polymer.
It's used by Chrome, Play Music, YouTube Gaming, YouTube (their next version of mobile and desktop app).
There's a Polymer App Toolbox that they released a while ago to show how to build full apps:
App Components
Polymer CLI
PRPL Pattern: Use HTTP/2, and push as little as possible.
shop.polymer-project.org
75% of mobile connections in sub-Saharan Africa are 2G. It's forecasted to be 45% in 2020.
She showed off Jumia Travel. It uses very little data, yet still provides a nice UI.
They're working on Polymer 2.0. They just released the preview editing.
They're focused on:
Web Component v1 support.
Better interoperability with other JavaScript libraries. It's truly web native, and looks just like a normal web component.
Minimal breaking. There's an interoperability layer. You can incrementally upgrade.
Polymer is only 12kb.
Mobile web development is hard, expensive, inefficient, slow, and confusing.
There are about 500+ apps using Polymer.
There's an event system.
Use properties, not methods.
Use dialog.open = true instead of dialog.open().
Properties go down. Events go up.
"Fear driven development." Be afraid of your users. Be afraid of breaking changes.
tattoo = Test All The Things Over & Over = it's their repo for testing Web Components.
Be afraid of perf regressions.
polydev is a tool that you can use to see how expensive the various elements are.
polyperf lets you compare the performance between changes.
demo-snippets shows you an element and how to use it. It's dynamic, so that you can edit the code.
webcomponents.org has re-usable elements.
Progressive Performance
@slightlylate
Great talk!
He showed this comic: xkcd.com/1367
"So it takes a lot for me to get to this point. But seriously folks, time to
throw out your frameworks and see how fast browsers can be."
He mentioned extensibleweb/manifesto.
RAIL:
Respond: 100ms
Animate: 8ms
Idle work: 50ms chunks
Load: 1000ms to interactive
53% of users bounce from sites that take longer than 3 seconds to load.
The average mobile site takes 19 seconds to load.
"Your Laptop Is A Filthy Liar": Simulating real devices using Chrome is just not the real thing.
Use Chrome inspect in order to use USB to debug real devices.
It's really, really hard to hit RAIL on mobile, even with a reasonable phone like a Nexus 5X.
"The Truth Is In The Trace". Use Dev Tools attached to real devices.
He tests with cheap, slow phones. He doesn't think that emulation cuts the mustard.
If you're using a $700 iPhone and assuming the other users are like that, you're wrong. World-wide phones are getting slower as more poor people buy cheap phones.
Desktop is 25X faster than a desktop.
He added an ice pack to the bottom of a phone in order to keep it cool, and his benchmark ran 15% faster ;)
Desktops are faster because they can dissipate more heat.
He recommended the paper, "Dark Silicon and the End of Multicore Scaling".
We can't use all the silicon in our phones because of the heat dissipation constraints.
And the battery has only 10 watt hours.
We can't dissipate enough power, and we can't carry enough power.
A cell phone battery can't keep a 60W light bulb lit for more than a few minutes.
big.LITTLE refers to the technique of having a mix of:
Infrequently used "big" (high power) cores
Agressively used "little" (lower power) cores
You get what you pay for when it comes to mobile devices.
"Touch boost": when you touch the screen, it turns on the more powerful CPUs.
"Benchmarketing" is a thing.
A MacBook Pro has the maximum amount of power stored in a battery that you can bring onto a plane.
Nexus 5X has 2 fast cores and 4 slow ones.
Flash read performance:
MBP: ~2GB/s
N5X: ~400MB/s
Mobile phones use fewer flash chips which means less parallelism which means slower.
Think of mobile phones as having spinning disks from 2008.
"High Performance Browser Networking" is a really good book. He highly recommends it.
"Mobile networks hate you."
"Adaptive Congestion Control for Unpredictable Cellular Networks".
What's really killing you is the variance / volatility.
LTE speed is actually getting slower.
Different markets are wildly different.
"A 4G user isn't a 4G user most of the time." -llya Grigorik
It's really hard to get anything on the screen in 3 seconds because it takes so long to even spin up the radio.
The tools and the methods that we've brought over from the desktop just aren't working.
Using the platform well is the only way to go.
Today's frameworks are signs of ignorance or privilege or both. It's broken by default.
Server-side rendering = isomorphic rendering = universal rendering
The Pixel phone is pretty good. Most phones aren't.
Scrolling != interaction.
We want progressive interactivity.
Only load the code that you need right now.
shop.polymer-project.org
Using HTML imports with tiny scripts means you don't have big bundles that make the thread choke.
Service workers lets you return something quickly from cache.
The top-level SW shouldn't depend on the network. Don't use a SW that hits the network first.
github.com/GoogleChrome/lighthouse
"Mobile Hates You; Fight Back!"
Test on real hardware.
Use a Moto G4. Use Chrome Inspect on Dev Tools. That'll show you what it's like in the median real world.
Use WebPageTest since it lets you use real mobile phones.
PRPL is important (but I don't know what it's about yet).
The challenge is larger than you think it is.
Real Talk About HTTPS
@estark37
Over 50% of pages are loaded over HTTPS.
www.google.com/transparencyreport/https/metrics
For desktop platforms, 75% of time is spent on HTTPS. It's probably on top sites.
For some reason, it's somewhere around 33% for Android. They don't know why, but they have a theory that it's because they're those users aren't using sites like Gmail and Facebook like they would be on desktop because they instead use apps for those. Hence, any web usage is most likely for longer tail sites.
They're restricting powerful features if you're not using HTTPS. Geolocation is one example.
Mozilla is only going to support HTTPS for all new features.
istlsfastyet.com: From llya Grigorik.
HTTP/2 is only available if you're also using HTTPS.
HTTP/2's performance advantages can more than offset the cost of TLS.
They have a goal of HTTPS everywhere.
At this point, we can't yet use an insecure icon everytime there's a site that uses HTTP. It would just desensitize people to the risk.
Let's Encrypt: Free, easy certificates. It's a certificate authority.
Chrome made a large donation to Let's Encrypt.
It's usage is growing exponentially.
All Google sourced ads are already served over HTTPS.
developers.google.com/web/fundamentals/security/encrypt-in-transit/enable-https
Moving to HTTPS can be done with no impact on search rankings.
There's a Security tab in Chrome Dev Tools. It can help.
They want to start easing users into thinking that HTTP is bad.
Chrome will start saying "(i) Not secure" in the URL bar for pages that have passwords or credit card inputs on them.
Building a Service Worker
They built a service worker in real time.
He used async and await. I think he said it's only in Canary, though :-/
The service worker will look to see if it itself has been updated.
He's using VS Code.
A Service Worker can be spun down even if the tab is still open.
Wow, they keep making the Service Worker more and more complex. It seems like a giant house of cards.
There's an offline checkbox in Chrome Dev Tools in the Application tab, and there's also one at the top of Dev Tools. They're not in sync.
He's clear that his example is not production code.
Cache invalidation is hard.
That was some pretty impressive real-time coding.
Planning for Performance
@samccone
"Mobile web" is no longer a subset of the web. It is simply the web.
It's more than just responsive CSS.
Mobile has been bigger than desktop since 2014.
The average mobile web user is not on a $600+ phone. They're more likely to use the free phone you get when you sign up for a plan.
The average Android phone has 1G or less of RAM.
The average load time for mobile sites is 19 seconds.
HTTP2 + link rel="preload"
He used this trick to move from 5 seconds to 3 seconds from first byte to first useful paint.
H2 Server Push:
Push assets from the server to the client before the client even requests them.
It's not cache aware.
It lacks resource prioritization.
But, H2 Push + Service Workers = awesomeness
He went from 5 seconds to 1.7 seconds.
Preload is good for moving the start download time of an asset closer to the initial request.
H2 Push is good for cutting out a full RTT if you have SW support.
Older phones are slow when parsing a ton of JavaScript. Event relatively recent phones suffer because of how much JavaScript there is to parse.
There is no simple way to see the parse cost of JavaScript.
There's some cool new thing in Chrome Canary: V8 internal metrics in timeline
Webpack Bundle Analyzer is very helpful to figure out what's in your bundle.
Fetch but don't parse:
Put it in the page, but don't eval it until you strip the comments out:
He talked about Webpack require.ensure and the aggressive splitting plugin.
Test on real devices on mobile networks.
Optimize network utilization: sw, preload, and push for fast first loads.
Parsing JavaScript has a cost: ship the smallest amount of JS possible.
Predictability for the Web
This was a product manager-like talk about making Chrome and the web in general more predictable.
The browser companies are working together more and more.
He talked about resolving bugs in Blink, the engine behind Chrome.
2/3rds of the top 1% of bugs have been fixed.
Using chrome://flags, you can turn on "Experimental Web Platform Features".
They fix regressions very quickly.
They do want to occasionally deprecate things.
Chrome shipped something to improve power substantially by not doing as many request animation frames for iframes not showing.
Filing or starring a bug is the quickest way to get your issue resolved.
developers.google.com/web/feedback
They built a Browser Bug Searcher to search for bugs across browsers.
They're trying to treat the web as a single platform.
Panel
A lot of Google apps aren't Progressive Web Apps.
One of the most difficult things to debug in web apps is memory leaks.
HTML imports will probably not survive the way they are, but eventually, there will be something better.
A few people complained about Chrome Web Apps being deprecated.