Here’s to more HTTPS on the web!

Friday, November 4, 2016

Security has always been critical to the web, but challenges involved in site migration have inhibited HTTPS adoption for several years. In the interest of a safer web for all, at Google we’ve worked alongside many others across the online ecosystem to better understand and address these challenges, resulting in real change. A web with ubiquitous HTTPS is not the distant future. It’s happening now, with secure browsing becoming standard for users of Chrome.

Today, we’re adding a new section to the HTTPS Report Card in our Transparency Report that includes data on how HTTPS usage has been increasing over time. More than half of pages loaded and two-thirds of total time spent by Chrome desktop users occur via HTTPS, and we expect these metrics to continue their strong upward trajectory. Chart

Percentage pages loaded over HTTPS in Chrome
As the remainder of the web transitions to HTTPS, we’ll continue working to ensure that migrating to HTTPS is a no-brainer, providing business benefit beyond increased security. HTTPS currently enables the best performance the web offers and powerful features that benefit site conversions, including both new features such as service workers for offline support and web push notifications, and existing features such as credit card autofill and the HTML5 geolocation API that are too powerful to be used over non-secure HTTP.

As with all major site migrations, there are certain steps webmasters should take to ensure that search ranking transitions are smooth when moving to HTTPS. To help with this, we’ve posted two FAQs to help sites transition correctly, and will continue to improve our web fundamentals guidance.

We’ve seen many sites successfully transition with negligible effect on their search ranking and traffic. Brian Wood, Director of Marketing SEO at Wayfair, a large retail site, commented “we were able to migrate Wayfair.com to HTTPS with no meaningful impact to Google rankings or Google organic search traffic. We are very pleased to say that all Wayfair sites are now fully HTTPS.” CNET, a large tech news site, had a similar experience. “We successfully completed our move of CNET.com to HTTPS last month,” said John Sherwood, Vice President of Engineering & Technology at CNET. “Since then, there has been no change in our Google rankings or Google organic search traffic.”

Webmasters that include ads on their sites also carefully monitor ad performance and revenue during large site migrations. The portion of Google ad traffic served over HTTPS has increased dramatically over the past 3 years. All ads that come from any Google source always support HTTPS, including AdWords, AdSense or DoubleClick Ad Exchange; ads sold directly, such as those through DoubleClick for Publishers, still need to be designed to be HTTPS-friendly. This means there will be no change to the Google-sourced ads that appear on a site after migrating to HTTPS. Many publishing partners have seen this in practice after a successful HTTPS transition. Jason Tollestrup, Director of Programmatic Advertising for the Washington Post, “saw no material impact to AdX revenue with the transition to SSL.”

As migrating to HTTPS becomes even easier, we’ll continue working towards a web that’s secure by default. Don’t hesitate to start planning your HTTPS migration today!
Posted by Adrienne Porter Felt and Emily Schechter, Chrome Security Team

Making Chrome on Windows faster with PGO

Monday, October 31, 2016

Chrome is always looking for ways to speed up the web. Starting in Chrome 53, Chrome has started using Microsoft’s Profile Guided Optimization (PGO) technology to make Chrome up to 15% faster on Windows.

New tab page load time	14.8% faster
Page load (time to first paint)	5.9% faster
Startup time	16.8% faster

PGO impact on load and startup time
Chrome is a huge software project with more than a million functions in its source code. Not all functions are equal - some are called frequently, while others are rarely used. PGO uses data from runtime execution that track which functions are most common to guide optimization. To gather this data, the nightly build process now produces a special version of Chrome that tracks how often functions are used. PGO then optimizes those high-use functions for speed, in some cases increasing the binary size of those functions. To balance out that increase, PGO also optimizes less-used functions with smaller, though slightly slower code. These trade-offs result in higher overall performance, and a smaller overall code footprint. PGO also optimizes the memory location of the code, moving rarely-used functions away from frequently-used ones in memory. This results in more optimal use of the CPU instruction cache by avoiding caching of less-used code, increasing overall performance. There are many other tricks that PGO uses to make Chrome faster, and they add up to great results. 64-bit Chrome on Windows is using PGO as of version 53, and 32-bit Chrome is using it as of version 54. Try out the latest version of Chrome to see the difference with PGO. Posted by Sébastien Marchand, who is Pretty Good at Optimizing.

Chrome 55 Beta: Input handling improvements and async/await functions

Friday, October 21, 2016

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

Input handling improvements

As usage of the mobile web grows, it is increasingly important for sites to react well to touch input. Historically, this meant handling MouseEvent and TouchEvent separately, which can be difficult to maintain. Chrome now enables unified input handling by dispatching PointerEvents. PointerEvents lead to more responsive pages, as they don’t block scrolling by default. To achieve the same performance with TouchEvent, pages can use passive event listeners.

Chrome also now supports two new ways to respond to input. The touch-action CSS property enables sites to react to gestures such as panning. For mouse buttons, the new auxclick input event type allows sites to manage the click behavior of non-primary buttons.

Async and await functions

Asynchronous JavaScript can be difficult to reason about. Promises help avoid the nesting problem of callbacks, but Promise-based code can still be difficult to read when a site has large chains of asynchronous dependencies. Chrome now supports the async and await JavaScript keywords, allowing developers to write Promise-based JavaScript that can be as structured and readable as synchronous code.

Fetching a URL and logging the response using Promises:

function logFetch(url) {

return fetch(url)

.then(response => response.text())

.then(text => {

console.log(text);

}).catch(err => {

console.error('fetch failed', err);

});

}

The same code using async and await:

async function logFetch(url) {

try {

const response = await fetch(url);

console.log(await response.text());

}

catch (err) {

console.log('fetch failed', err);

}

CSS automatic hyphenation

Formatting text to fill available space can be a challenge across devices and screen sizes. Chrome now supports CSS automatic hyphenation, one of Chrome’s most frequently requested layout features, on Android and Mac. CSS hyphenation allows the browser to hyphenate words when line-wrapping, improving the visual consistency of text blocks. Hyphenation support will be extended to other platforms in future releases.

A paragraph rendered with and without automatic hyphenation

Other features in this release

The once event listener option enables callbacks to be invoked only once before removing the event listener.
Sites can now mark web storage as persistent, preventing Chrome from automatically clearing storage for that site.
Cross-origin iframes now require a user gesture to start audio playback using the Web Audio API on Android, matching the behavior of the <audio> and <video> elements.
The TLS stack now implements GREASE, a mechanism to help prevent problems with buggy TLS servers.
Developers can create a MediaStreamTrackEvent in an alternative way with its new JavaScript constructor.
RSA-PSS signature algorithms have been added to TLS to prepare for TLS 1.3.
To improve load times and prevent failed navigations, cross-origin and parser-blocking scripts injected using document.write() will no longer load over 2G connections.
AudioNode constructors of the form new AudioNode(context, options) are now available, making it simpler to manage audio from scripts.
When the media player is too narrow to show every button, an overflow menu will appear to provide the hidden functionality to users.
Chrome media controls will now display a download button when the playback is associated with a file that can be downloaded.
The Web Share API is available for experimentation as an origin trial.

Deprecations and interoperability improvements

BaseAudioContext will replace AudioContext in the Web Audio API to conform to spec.
CSS Clipping Path properties no longer require the webkit prefix.
The MediaStream constructor is now available without prefix alongside the existing webkitMediaStream.
Non-script MIME types will no longer trigger script execution.
<textarea maxlength=""> and <textarea minlength=""> have been updated to count each line break as one character, instead of two.
The webkit prefix has been removed from the imageSmoothingEnabled property of CanvasRenderingContext2D.

Posted by Dan Ehrenberg, Asynchronous Adventurer

Canary channel for Chrome on Android

Tuesday, October 18, 2016

Chrome supports multiple release channels with varying degrees of stability and support. The Canary channel ships the most bleeding edge version of Chrome possible. It is primarily intended to be used by developers and early adopters to test recent Chromium changes, but anyone can install it and give it a try. Previously the Canary channel was only available on Windows and Mac, and it is now available for Android as well.

Just like the Canary channel for other platforms, new versions are built from the most recent code available and often contain a variety of new features, enhancements, and bug fixes. These builds are shipped automatically with no manual testing, which means that the build can be unstable and may even stop working entirely for days at a time. However, the goal is for Canary to remain usable at all times, and the Chrome team prioritizes fixing major issues as quickly as possible.

Initially, builds will ship every weekday. In the future new builds may also be available on weekends. The frequency of builds means that keeping the app updated will consume a lot of data, typically more than 100MB per week. This is especially important for phones set to update native apps over cellular data.

We hope the Canary channel will be useful when developing and testing changes for Chrome on Android. If you encounter any bugs, please help us by reporting them.Posted by Alex Mineer, APK Administrator & Bug Basher

Chrome 54 Beta: Custom Elements V1, BroadcastChannel, and media platform improvements

Thursday, September 15, 2016

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

Custom Elements V1 Complex user interfaces often require a large amount of HTML. Most languages allow developers to create their own components built on top of language primitives to mitigate this kind of verbosity. Custom elements allow developers to create their own custom HTML tags, and define the new element’s API and behavior in JavaScript. This enables a browser-native way to build reusable, interoperable components.
Chrome 54 provides support for the latest custom elements V1 spec, which is broadly agreed-upon by major browser vendors. Chrome will also continue to support the V0 API until enough developers have moved to V1.

BroadcastChannel It is not uncommon for desktop users to have multiple windows or tabs open simultaneously. Some sites utilize this behavior, such as web editors that open documents in their own tabs. Historically, communicating between those tabs has been difficult. BroadcastChannel is a new one-to-many messaging API between windows, tabs, iframes, web workers, and service workers. It allows scripts to establish named channels to send messages between browsing contexts of the same origin.

Media platform improvements on Chrome for Android Media is an increasingly large and important part of the browsing experience on mobile devices that requires fluidly utilizing the entire screen. Developers can now use Element.requestFullScreen() to trigger full screen mode after a screen orientation change in addition to after a user gesture. This allows experiences like rotate-to-fullscreen for media players.
In addition to fullscreen improvements, Chrome on Android now persists the media notification of a backgrounded HTMLVideoElement, allowing a user to continue playing videos while they aren’t visible. Developers can detect background video playback by using the Page Visibility API.
Playing background videos in Chrome 54.

Other features in this release

Navigations initiated in an unload handler will be blocked and any prior navigation will continue.

The imageSmoothingQuality attribute for CanvasRenderingContext2D allows developers to balance performance and image quality by adjusting resolution when scaling.

Sites can use Node.getRootNode(options) to obtain the root for a given node.

Using PushSubscription.options, sites can track applicationServerKeys without having to store them offline.

The Resource Timing API now supports transfer, encoded, and decoded size attributes, allowing developers to measure cache hit rates and byte usage.

The user-select property enables developers to specify which elements can be selected by the user and how.

Foreign Fetch and WebUSB are available for experimentation as origin trials.

The text-size-adjust property allows sites to control whether font size automatically scales on mobile devices.

Deprecations and interoperability improvements

To match behavior in other browsers, embedded YouTube Flash players will be rewritten by Chrome to use the HTML5 embed style, improving performance and security on Chrome Desktop.
CacheQueryOptions now conforms to spec across all CacheStorage methods.
initTouchEvent has been removed in favor of the new TouchEvent() constructor.
SVGZoomEvent has been removed as it is no longer part of the SVG 2.0 spec.
SVGSVGElement.currentView, SVGSVGElement.useCurrentView, SVGViewSpec interface, and SVGSVGElement.viewport have been removed as they are no longer part of the SVG 2.0 spec.
SVGTests.requiredFeatures attribute has been deprecated since it no longer provides useful functionality in the SVG 2.0 spec.
SVGElement now supports the dataset property.
The KeyEvent.keyIdentifier field has been removed in favor of the KeyboardEvent.key field.
window.external.IsSearchProviderInstalled() and AddSearchProvider() are now no-ops, since they are unsupported in most other browsers.

Posted by Marijn Kruisselbrink, Broadcast Buccaneer

Chromium Blog

Here’s to more HTTPS on the web!

Making Chrome on Windows faster with PGO

Chrome 55 Beta: Input handling improvements and async/await functions

Canary channel for Chrome on Android

Chrome 54 Beta: Custom Elements V1, BroadcastChannel, and media platform improvements

Labels

Archive

Feed

Company-wide

Products

Developers