Transitioning from SPDY to HTTP/2
Thursday, February 11, 2016
Last year we announced our intent to end support for the experimental protocol SPDY in favor of the standardized version, HTTP/2. HTTP/2 is the next-generation protocol for transferring information on the web, improving upon HTTP/1.1 with more features leading to better performance. Since then we've seen huge adoption of HTTP/2 from both web servers and browsers, with most now supporting HTTP/2. Over 25% of resources in Chrome are currently served over HTTP/2, compared to less than 5% over SPDY. Based on such strong adoption, starting on May 15th — the anniversary of theHTTP/2 RFC — Chrome will no longer support SPDY. Servers that do not support HTTP/2 by that time will serve Chrome requests over HTTP/1.1, providing the exact same features to users without the enhanced performance of HTTP/2.
At the same time, Chrome will stop supporting the TLS protocol extension NPN, which allows servers to negotiate SPDY and HTTP/2 connections with clients. NPN has been superseded by the TLS extension ALPN, published by the IETF in 2014. ALPN is already used 99% of the time to negotiate HTTP/2 with Chrome, and the remaining servers can gain ALPN support by upgrading their SSL library.
We are looking forward to HTTP/2 continuing to gain adoption, bringing us an even faster web.
Posted by Bence Béky, Network Protocol Engineer and HTTP/2 Enthusiast
The Physical Web expands to Chrome for Android
Wednesday, February 10, 2016
The Physical Web helps users discover URLs relevant to their surroundings via Eddystone bluetooth low-energy beacons. Last year, Chrome for iOS took an initial step in supporting the Physical Web, and the community has already begun exploring promising applications. Starting in version 49, Chrome for Android will also surface Physical Web content, making these experiences available to an even larger audience.
As Physical Web-enabled beacons are becoming more widespread, developers are experimenting with the platform in various ways. One Physical Web demo posted by a Mozilla community contributor shows users how to use bluetooth beacons to discover and interact with a drone. *wood Middle School uses beacons from BKON to circulate class notes, sports accomplishments, and news updates. Radius Networks, a beacon manufacturer, recently deployed 1,500 beacons to help attendees of CES® (Consumer Electronics Show) navigate showrooms. The Golden State Warriors utilize the Physical Web with the help of Signal360 to provide fans with highlight videos and welcome content at Oracle Arena.
Physical Web bluetooth beacons enabled a scavenger hunt at CES® 2016.
Now, Physical Web developers can reach Chrome for Android users as well, starting with the Beta channel and rolling out more widely soon. When these users walk by a beacon for the first time, they’ll receive a notification allowing them to enable the Physical Web. On future encounters with beacons, users can quickly see a list of nearby URLs by tapping on a non-vibrating notification waiting for them.
Physical Web experience on Chrome for Android
Developers can make their web content discoverable on the Physical Web by configuring an Eddystone-supported beacon to broadcast a URL of their choice with the Eddystone-URL frame type. Now that the Physical Web is tightly integrated into Chrome for Android, a single deployment can deliver contextual information to Chrome users across multiple mobile platforms.
As we continue to improve the Physical Web experience, we’re excited to see what types of contextual experiences developers build. We encourage anyone to join the conversation on our mailing list and visit the Physical Web cookbook to learn more about what’s possible.
Posted by Ani Mohan, Physical Web Voyager
Chrome 49 Beta: CSS custom properties, background sync with service workers, and new ES2015 features
Tuesday, February 2, 2016
Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.
CSS custom properties
Modern websites often have CSS files with repeated values, such as a few colors reused throughout the page in a color scheme. Altering this data can be tedious and error-prone, since it’s scattered throughout one or more CSS files. To improve this, Chrome now supports CSS custom properties, allowing developers to define property variables in CSS without using external frameworks. Developers can then use the var() function to reference these custom properties anywhere in the document.
Changing a custom property can update multiple components in a website
CSS custom properties also inherit across shadow roots, so a web component can provide a “style API” that makes it possible to tweak and theme the component without knowing about its internals. The Polymer library uses this platform feature to simplify customizing components.
Background sync with service workers
Previously, sites could lose local changes or become out of sync if a user didn’t stay on the site until updates could be sent over the network. For example, an email client might lose a pending message if the user hit "send" and quickly navigated away. The new Background Sync API improves networking reliability by allowing service workers to schedule a one-off sync of a user’s local changes when the device next connects to the network, even if the site isn’t open.
Improved ECMAScript 2015 support
The ES2015 specification (ES6) is a major update to JavaScript that allows developers to write application logic that is more legible, powerful, and memory efficient. The latest version of Chrome’s V8 engine has 91% JavaScript ES2015 feature support. Developers can now use destructuring and default parameters to avoid boilerplate code when extracting data from arrays and objects or when setting function parameter defaults. Proxy objects and the Reflect API can customize previously hidden object behavior such as property lookup and assignment. The latest version of Chrome also makes block-level constructs such as class and let available outside of strict mode.
Keygen and application/x-x509-user-cert
The <keygen> element is used to generate a key-pair as part of an HTML form. While this can be used to enhance user security, <keygen> and user certificates sent with the MIME type of application/x-x509-user-cert can be exploited to disrupt a user’s secure communication, interfere with the functioning of their devices, or track the user without consent. Going forward, <keygen> will return an empty string by default and user certificates sent with the MIME type of application/x-x509-user-cert will no longer be automatically downloaded and installed.
Other features in this release
- With user consent, sites can record audio and video without relying on plugins by using the new MediaRecorder API.
- Developers can now control how fonts load using CSS font-display, improving page load speed.
- Sites can now detect which service worker client initiated a fetch request and return a specialized response using the FetchEvent.clientID attribute.
- Chrome now animates scrolling for discrete scrolling devices like mouse wheels, allowing for a smoother user experience.
- Chrome now more strictly protects secure cookies and allows developers to identify secure cookies using cookie prefixes.
- Sites can now prevent media from playing remotely using the disableRemotePlayback attribute as part of the Remote Playback API.
- Event.timeStamp is now a DOMHighResTimeStamp instead of a DOMTimeStamp, allowing for high-precision scroll latency and pointer velocity measurements.
- Promise rejection handling can now be tracked using the UnhandledRejection and RejectionHandled events.
- Developers can now interact with the GET parameters of a URL more easily using URLSearchParams.
- The WebAudio API now supports IIR Filters, OfflineAudioContext.suspend() and resume(), and promises in DecodeAudioData.
- WindowClient.navigate() allows service workers to navigate controlled windows to a new URL.
- Sites can detect if a user has requested reduced data usage and respond with a lighter experience by checking the Save-Data header field.
Minor changes
- Chrome’s content security policy now matches ‘script-src http:’ to both HTTP and HTTPS, preventing developers from accidentally rejecting secure resources.
- Developers now have the option to ignore case when matching attribute selectors.
- Developers can now create pop-ups that don’t expose which page opened them using 'rel=noopener'.
- addEventListener() and removeEventListener() now require their first two arguments and can have the "capture" option specified using dictionary syntax, improving spec compliance and flexibility.
- Chromium now supports the standardized version of ChaCha-Poly1305 cipher suites in TLS.
- Navigator.getStorageUpdates() has been removed as it is no longer in the Navigator spec.
- MouseEvent.webkitMovementX/Y has been removed in favor of the unprefixed version.
- initTouchEvent has been deprecated in favor of the TouchEvent constructor to improve spec compliance and will be removed altogether in Chrome 53.
- Object.observe() has been deprecated as it is no longer on the standardization track and will be removed in a future release.
- The getComputedStyle(e).cssX behaviour has been deprecated since it was not a part of the formal spec.
- Some non-standard uses of RTCPeerConnection legacy methods have been deprecated to enable promise-based implementation of the WebRTC spec.
- Document.defaultCharset has been deprecated to improve spec compliance.
Posted by Josh Karlin, Syncing Samurai
A faster, more stable Chrome on iOS
Wednesday, January 27, 2016
Out-of-process rendering was one of Chrome’s earliest innovations, and we’ve always wanted to bring its benefits to our iOS users. Unfortunately UIWebView, the component used to render web pages on iOS, is in-process, so that’s never been possible before. The introduction of WKWebView in iOS 8 gave us that opportunity, though migrating to the new framework brought significant challenges. In Chrome 48 we’ve made the switch from UIWebView to WKWebView, leading to dramatic improvements in stability, speed, responsiveness, and web compatibility.
The biggest change is in stability: with WKWebView’s out-of-process rendering, when the web view crashes or runs out of memory, it won’t bring down all of Chrome with it. As a result, Chrome crashes 70% less with WKWebView. Even when counting the “Aw, Snap!” page shown when the renderer crashes, there’s still a big improvement.
Outside of stability, WKWebView brings many other benefits. Web compatibility is improved with support for features like IndexedDB, bringing the HTML5test score for Chrome on iOS from 391 up to 409. Switching to background tabs will cause pages to reload 25% less often. JavaScript speed on benchmarks such as Octane is an order of magnitude faster, and scrolling is smoother and more responsive.
The Chrome team is committed to improving stability and performance. We hope that you enjoy these changes and we are working hard on further improving your browsing experience on iOS.
Posted by Stuart Morgan, Software Engineer and Migratory WebView Watcher
Introducing the Security Panel in DevTools
Tuesday, January 26, 2016
The web platform is becoming increasingly powerful thanks to new APIs such as service worker. Security risk is always a concern, which is why many of these new features require secure origins. HTTPS preserves the integrity of your website and ensures connections with your users are encrypted. In an effort to make deploying HTTPS easier, Chrome 48 beta includes a new security panel in DevTools which willbe rolling out more broadly over the nextfewdays.
The security panel displays connection information for every network request, demystifying what connection errors keep you away from the green lock that represents a secure connection. Glancing at the overview for a given page, you can find information about:
- Certificate verification, indicating whether your site has proven its identity with a TLS certificate.
- TLS connection, indicating whether your site uses a modern, secure protocol and ciphersuite.
- Subresource security, indicating whether your site loads insecure HTTP subresources (otherwise known as mixed content).
In addition to debugging an insecure TLS connection, you can also easily check the state of your subresources. Clicking on a subresource gives you in-depth information about the security state of a given connection, as well as details about its certificate.
For more details about the new security panel, check out our post on the Google developer blog. If you’re new to TLS, you can get started with our developer resources on Web Fundamentals.
Stay tuned for more features coming to Chrome, helping you get to the green lock and beyond!
Posted by Emily Stark, Green Lock Whisperer and Lucas Garron, Mixed Content Warrior