Chromium Blog

Saving data with Google’s PageSpeed Modules

Thursday, May 12, 2016

The web is a rich and diverse ecosystem, but sometimes that diversity comes at a price. Authoring a website that works quickly and correctly for all browsers, devices, and connections can be a time-consuming task. Google’s PageSpeed Modules, launched in 2010, enable web servers to automatically speed up sites as content is served. Two new features are available in the latest stable release of PageSpeed to accommodate the diversity of screen sizes and data connections.

Screen resolutions are a common difference among devices. Users with high-resolution screens on fast connections will love crisp, detailed images. Sending those same images to users with small screens on slow connections will unnecessarily delay the page load and waste their potentially expensive bandwidth. The HTML srcset attribute attribute allows developers to specify alternative versions of an image for the browser to use depending on screen size, but they must manually add this to every image on the page, and also encode the images in several sizes. Fortunately, the latest release of PageSpeed Modules can automate this process. For example, imagine a page containing the following image element:
<img width="500" height="500" src="Beach.jpg">

When PageSpeed's responsive_images filter encounters this, it will automatically create resized versions of the images, then rewrite the element as :
<img width="500" height="500" src="500x500xBeach.jpg..." srcset="750x750xBeach.jpg... 1.5x, 1000x1000xBeach.jpg... 2x, 1500x1500xBeach.jpg... 3x, xBeach.jpg... 3.4x">

PageSpeed inserts 1.5x, 2x and 3x variants which provides coverage for the most common devices. It also includes the original full-size image and calculates its effective multiple — 3.4x, in the above example. The original will be used by high-density displays or when zoomed in.

For users that want to save as much data as possible, PageSpeed Modules can take this one step further. Chromium-based browsers send the “Save-Data” header when the user has indicated a desire to conserve bandwidth. Supporting this typically requires site developers to re-encode low bandwidth versions of all images and serve these just to the clients that send this header. The latest release of PageSpeed understands the Save-Data header and will automatically compress images more aggressively for these data-sensitive users.

Mock storefront without PageSpeed (left), and with PageSpeed and the Save-Data header (right). Even though there are no apparent visual differences, without PageSpeed the page is 350KB and takes over a minute to load on our simulated 2G connection. With PageSpeed and the Save-Data header the page is 120KB and loads in less than 30 seconds.
These new features, along with many others to make sites smaller and load faster, are available in the latest release of PageSpeed Modules. Developers interested in trying it out can download the modules from the Google Developers site.
Posted by Steve Hill, PageSpeed Engineer and Reducer of Bytes

New APIs to help developers improve scroll performance

Tuesday, May 3, 2016

Speed has been a top priority since Chrome's first release, and it's only gotten more important as developers continue to push the boundaries of interactive web experiences. While there are many performance optimizations Chrome can make without involving the developer, sometimes it's impossible for Chrome to execute as quickly as possible without more information. In Chrome 51 we've introduced support for passive event listeners and Intersection Observer, two emerging web standards that help developers create engaging, efficient experiences.

Touch event listeners are often used on the web for custom scrolling experiences and user engagement analytics. They allow developers to register JavaScript to run when the user touches the screen, and give web apps the opportunity to cancel scrolling altogether. Without knowing in advance if the web app will cancel scrolling, Chrome needs to wait for this JavaScript to finish before scrolling the page itself. Over 80% of touch listeners don't cancel the scroll and unnecessarily delay scrolling by up to several seconds. This results in a large amount of jank where the page doesn't seem anchored to the user's finger.

Chrome 51 allows developers to proactively declare that an event listener won't prevent a scroll. While developers should continue to avoid long-running script to reduce all forms of jank, this change eliminates the need to delay scrolling until the JavaScript completes. To learn more about passive event listeners and how to use them, check out the in-depth EventListenerOptions explainer.

Touch scrolling on cnn.com unmodified (left) and with a planned site update to make touch listeners passive (right).

Another way web platform improvements can help developers reduce delays is take common operations that can't be implemented efficiently in JavaScript and instead build them natively into the browser. One prevalent example is heavy Javascript used to calculate whether an element is visible in the document's viewport or other scrolling container. This is useful for knowing whether a certain element was seen or when to dynamically load more content at the bottom of a page, but can cause annoying jank and unnecessary battery drain if run frequently on user interactions.

Chrome 51 includes support for Intersection Observer, a new API to provide viewability information in a more efficient way. Sites can receive a callback whenever any element intersects a watched element or its children. The site no longer needs to implement this functionality with its own custom JavaScript, and gains the benefits of improved page load and scroll performance. For more information and implementation details, see the Intersection Observer explainer.

Studies have shown that an increase in performance leads to happier, more engaged users. Performance is something for everyone in the web ecosystem to care about--not just browser implementers, but also web authors. As developers of both top-level sites and embedded content make use of these new APIs, the result will be a faster web for everyone.
Posted by Rick Byers and Stefan Zager, Professional Jank Busters

ES6 & ES7 in the browser

Friday, April 29, 2016

JavaScript is a continually evolving programming language standardized over time by a committee of browser vendors, developers, and community members. In the past two years, this committee has introduced ES6, the largest update in the history of JavaScript, and ES7, the first of more frequent annual releases. Together the two versions add hundreds of new features to help developers write expressive, concise, and fast applications. After a long, collaborative journey of design, specification, and implementation work, the V8 JavaScript team has reached a major milestone in language support. Chrome Canary now runs both ES6 and ES7, which will ship to all users in Chrome 52.

ES6 and ES7 support in Chromium provides JavaScript developers with many sought-after features common in other programming languages, but previously missing from the web. These features include ways to simplify common programming patterns, make code easier to write, and customize low-level JavaScript behavior. Classes, for example, allow developers to easily write object-oriented programs and safely extend built-in JavaScript objects. Arrow functions, default parameters, and array convenience methods make common idioms simpler to program and reduce the need to copy and paste boilerplate code between projects. It can be difficult to reason about JavaScript’s asynchronous execution flow and nested callbacks, so ES6 introduces promises, iterators, and generators to simplify asynchronous code, make control flow more expressive, and make writing bug-free code easier. Powerful features like proxies and well-known symbols also give advanced developers the ability to customize language behavior to better match their application’s needs.

In order for websites to take full advantage of these new JavaScript features, multiple browsers must support the latest specifications. Fortunately, cross-browser support has rapidly improved in the past few months. The latest development versions of all modern browsers now support more than 90% of ES6, with polyfills and transpilation available to add support to older browsers as well. Adoption will continue to expand over the coming months, given that the ability to load JavaScript modules from HTML was recently standardized with the <script type="module"> tag. Chromium has already started implementing this new tag, and module support will be available soon, making it even easier to write and ship websites with ES6 and ES7 code.

For more details on the JavaScript standards process, features still under discussion such as proper tail calls, and a deeper dive into the technical side of spec conformance, visit the V8 blog. Check back soon to hear more about upcoming JavaScript features and continued performance optimizations.

Posted by Seth Thompson, Product Manager and ECMAScript ESsayist

Chrome 51 Beta: Credential Management API and reducing the overhead of offscreen rendering

Friday, April 29, 2016

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows. Credential Management API Many sites allow their users to sign in to receive personalized content. Today that requires remembering and typing credentials, which lowers account security when users reuse passwords across multiple sites. Modern browsers have credential managers that remember and autofill saved passwords, but these managers cannot account for custom login flows or remember federated identity preferences.
The latest version of Chrome now supports the Credential Management API, allowing sites to interact with the browser’s credential manager to improve the login experience for users. The API enables users to sign in with one tap and lets them automatically sign back in when returning to the site.
Screen Shot 2016-04-28 at 13.56.55.png

Signing in with one tap using the Credential Management API

Reducing the overhead of offscreen rendering Modern websites commonly embed cross-origin content like videos, social widgets, and ads. Embedding these resources allows sites to offer compelling content experiences, but it also creates a lot of overhead that can jank the page in ways the embedding site can’t control. The latest version of Chrome no longer runs the rendering pipeline or requestAnimationFrame() callbacks for cross-origin frames that are offscreen. This eliminates unnecessary work and reduces power consumption by up to 30% on several popular mobile sites without affecting the user experience. Additional features in this release

The Intersection Observer API allows sites to detect element intersections as an asynchronous event, eliminating the need for costly document monitoring.

The latest version of Chrome supports passive event listeners, which allow sites to run JavaScript in response to touch and wheel input without blocking scrolling.

Blobs are now constructed and transferred to the browser asynchronously, allowing large data files to be moved without janking the page.

The SameSite cookie attribute allows sites to restrict cookies to requests from the same domain.

Support for the AES_256_GCM cipher on TLS improves security on servers that choose cipher by key size, where legacy 256-bit ciphers were used over more secure, but smaller, ciphers.

Array.prototype.values() makes it easier to iterate over the elements of an array.

The function name property now infers useful names for properties and methods with computed property names, making debugging easier with clearer labels and error messages.

Iterators that are part of a for-of loop that terminates early now call a developer-provided close() method, making it easier to respond to the end of an iteration.

Symbol.species makes subclassing built-in classes such as Array and RegExp more powerful by allowing custom constructors to be called for derived objects.

RegExp subclasses can overwrite the exec() method to change the matching algorithm, making it easier to write custom subclasses.

Sites can now can implement their own Symbol.hasInstance() method to customize behavior of the instanceof operator.

Sites can now retrieve a service worker’s Client object using Clients.get(id).

ServiceWorker.postMessage() now fires an ExtendableMessageEvent on ServiceWorkerGlobalScope, allowing the message to extend the service worker lifetime and provide more accurate message sources.

The HTML referrerpolicy attribute allows sites to control what information is sent in the referrer headers of <a>, <area>, <img>, and <iframe> elements.

The UIEvents KeyboardEvent |key| attribute allows sites to reliably determine the meaning of the key being pressed.

Sites can now detect the duration of batched offline audio contexts using the OfflineAudioContext.length attribute.

SPDY and ALPN support has been removed in favor of the standards-based HTTP/2 protocol.

Other changes

The ability to customize the message shown in the onbeforeunload dialog has been removed to protect users from malicious websites and align with other browsers.

Chrome on Android now uses the same media pipeline as desktop Chrome, improving WebAudio support and allowing sites to interact with the playback rate on <audio> and <video> tags.

The latest version of Chrome improves web animations interoperability by supporting lists of values and removing dashed-names in keyframes.

Chrome now requires a border style to paint border images, improving spec compliance and interoperability.

Percentages can now be used for the sizes of flex item children.

DHE-based ciphers have been deprecated and will be removed in Chrome 52 in favor of ECDHE ciphers to improve TLS security.

Posted by Sabine Borsay and Mike West, Authenticator's Apprentices

Ensuring transparency and choice in the Chrome Web Store

Friday, April 15, 2016

Updated 7/12/2016: High submission volume has led to review latency that is longer than normal, so we've extended the grace period. The new policy will be enforced beginning September 6th, 2016.
Today we’re updating the User Data Policy for the Chrome Web Store. Principles of transparency and choice over how users’ personal data is handled have long been key parts of Google’s philosophy. Since early on, Chrome has included privacy-protecting features to give users control over their browsing experience, including incognito mode and granular privacy preferences. Now, we’re consolidating and expanding our policies about user data to ensure our Chrome Web Store developers follow similar principles.

Chrome provides robust APIs that empower developers to create compelling extensions and apps, and users often need to provide access to their data to allow these services to run. The new User Data Policy extends existing policies to ensure transparent use of the data in a way that is consistent with the wishes and expectations of users. Some of the new requirements for developers are:

Be transparent about the handling of user data and disclose privacy practices
Post a privacy policy and use encryption, when handling personal or sensitive information, and
Ask users to consent to the collection of personal or sensitive data via a prominent disclosure, when the use of the data isn’t related to a prominent feature.

The policy also has other requirements, including prohibiting the collection of web browsing activity when it’s not required for an item’s main functionality. The full text of the policy is available in our Developer Program Policies and more information is available in the FAQ section.

We'll notify developers when we discover items that violate the User Data Policy, and they'll have until July 14, 2016 to make any changes needed for compliance. Starting July 15th, 2016, items that violate the policy will be removed from the Web Store and will need to become compliant to be reinstated.

Protecting our users is our key priority, and we believe this change will make sure users are better informed and allow them to choose how their user data is handled.

Posted by Teresita Perez and Athas Nikolakakos, Chrome Policy Team

Chromium Blog

Saving data with Google’s PageSpeed Modules

New APIs to help developers improve scroll performance

ES6 & ES7 in the browser

Chrome 51 Beta: Credential Management API and reducing the overhead of offscreen rendering

Ensuring transparency and choice in the Chrome Web Store

Labels

Archive

Feed