Chromium Blog: maggio 2016

The Mobile Web Is Open for Business

giovedì 19 maggio 2016

Posted by Rahul Roy-chowdhury, VP Product Management, Chrome
One of the virtues of the web is its immense reach, providing access to information for all internet users regardless of device or platform. With the explosion of mobile devices, the web has had to evolve to deliver great experiences on the small screen. This journey began a few years ago, and I am excited to be able to say that the mobile web is open for business. Hear the recording from Google I/O where I discussed the state of the union and how to take advantage of new experiences like AMP and Progressive Web Apps (PWAs) to deliver a best-in-class mobile experience.

If you don’t have time to watch, here’s a quick recap of the four aspects to focus on while building a great mobile web experience:
Accelerate Expressiveness has always been a strength of the web, but sometimes that expressiveness can come at the cost of loading time or smooth scrolling. For example, event listeners allow developers to create custom scrolling effects for their website, but they can introduce jank when Chrome needs to wait for any touch handler to finish before scrolling a page. With the new passive event listener API, we've given control back to the developer, who can indicate whether they plan to handle the scroll or if Chrome can begin scrolling immediately.

Speed also goes beyond user experience gains. Studies have shown that 40% of users will leave a retail site if it takes longer than 3 seconds to load. To get a blazing fast web page in front of users immediately, we've introduced Accelerated Mobile Pages (AMP). With AMP, we have seen pages load 4x faster and use up to 10x less data. AMP is already seeing great adoption by developers, with more than 640,000 domains serving AMP pages.

Engage Progressive Web Apps (PWAs) let developers take advantage of new technologies to provide users with an engaging experience from the very first moment. Thanks to a new API called service worker, all the important parts of a web app can be cached so that it loads instantly the next time a user opens it. This caching also allows developers to continue to provide a fast and meaningful experience even when the user is offline or on an unreliable network. PWAs provide elements of polish too: an icon users can add to their home screen, a splash screen when they open it, and a full-screen experience with no address bar.
image 9.gif

JalanTikus Progressive Web App
Convert Logging in is a ubiquitous pattern on the web, but 92% of users abandon a task if they've forgotten their password. To alleviate this pain, Chrome's password manager enables more than 8-billion sign-ins per month, and we're expanding support with the Credential Management API. Using this API allows web apps to more closely integrate with the password manager and streamline the sign-in process.

Even once logged in, checkout can be a complicated process to complete. That's why we're also investing in capabilities such as the Web Payment API and enhanced autofill, assisting users by accurately filling in forms for them. We've found that forms are completed 25% more when autofill is available, increasing odds for conversion.

Retain Once the first interaction with a user is complete, re-engaging on the web can be tricky. Push notifications address this challenge on native apps, and now the push API is available on the web as well. This allows developers to reconnect with their users even if the browser isn't running. Over 10 billion push notifications are sent every day in Chrome, and it’s growing quickly. Jumia found that users who enabled push notifications opened those notifications 38% of the time and recovered carts 9x more often than other users.

Jumia Mobile Web Push Notifications

Success Stories As developers begin embracing these new technologies, we're seeing success stories from around the world. AliExpress, one of the world's largest e-commerce sites, built a PWA and saw conversion rates for new users increase by 104%. They've also found that users love the experience, spending 74% more time on their site per session.

Another great example is BaBe, an Indonesian news aggregator service that was app-only until they developed a PWA with feature parity to their native app. Since launching they have found it to perform even faster than their native app, and have seen comparable time spent per session: 3 minutes on average on both their mobile website and their native app.

Even developers who have only begun implementing certain PWA technologies have seen success. United eXtra, a leading retailer in Saudi Arabia, implemented push notifications and saw users who opted-in returned 4x more often. These returning users also spent 100% more than users returning from other channels.

These are just a handful of businesses that have begun reaping the benefits of investing in Progressive Web Apps. Learn more about our how partners are using PWA technologies to enhance their mobile web experience.
Screen Shot 2016-05-17 at 6.06.16 PM.png

Screen Shot 2016-05-17 at 6.06.16 PM.png

Subscribe to our YouTube channel to stay up to date with all the mobile web sessions from Google I/O, which we will continue to upload as they’re ready. Thanks for coming, thanks for watching, and most of all, thank you for developing for the web!

Saving data with Google’s PageSpeed Modules

giovedì 12 maggio 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

martedì 3 maggio 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

Chromium Blog

The Mobile Web Is Open for Business

Saving data with Google’s PageSpeed Modules

New APIs to help developers improve scroll performance

Etichette

Archive

Feed