Application Foundations/PerformanceAndTuning

Introduction

From Application Foundations for the Open Web Platform

Open Web Platform functionality has moved steadily to the client side, which creates a variety of new challenges related to security, application lifecycle management, but especially performance. JavaScript engines have improved dramatically in the past few years. But for high-end games, media streams, and even some simple interactions like scrolling, we still have much to do so that developers can monitor application performance and code in ways that make the best use of resources. This is the focus of our Performance and Tuning Foundation.

Today we are working on APIs for performance profiling such as navigation timing and resource hints. In various discussions and Workshops, people have asked for a number of enhancements: for understanding load times, enabling automatic collection of performance data, providing hints to the server for content adaptation, improving performance diagnostics, managing memory and garbage collection, preserving frame rates, using the network efficiently, and much more.

The responsive design paradigm mentioned in the Core Web Design and Development Foundation also plays a role in the world of performance: we can make better use of the network and processing power if we can take into account screen size and other device characteristics.

Who

• Xiaoqian Wu
• Philippe Le Hegaret
• Mike Smith

Resources

Relevant specs

• List of specifications from web performance group
  • Timing Information
    • Navigation Timing 2
    • Resource Timing
    • User Timing
    • High Resolution Time Level 2
    • Server Timing
    • Entry Type
  • Resource Loading
    • Beacon
    • Resource Hints
    • Preload
    • Resource Priorities
  • Events
    • Efficient Script Yielding
  • NetWork
    • Network Error Logging
  • Animation
    • Timing control for script-based animations
    • Frame Timing
• CSS Will Change
• http2?
• Responsive Images?

Reading list

• Resource Loading
  • Why we can’t do real responsive images with CSS or JavaScript , Bruce Lawson, 21 January 2015
  • Web, Hybrid, And Native Mobile Apps All Have Their Place, Forrester Research, December 2014
• Timing Information
  • Smartphone Browser Performance Test Case Guideline
  • This is Success: Why 1000/100/6/50ms?, nduca@, dglazkov@, May 2014
  • Perf Audits: CNet, Time, Google Play, Paul Irish, February 2015
• Animation
  • Libraries for JavaScript and CSS3 plus Performance Tips

Goals

• Identify the most important bottlenecks related to lack of responsiveness in Web Applications in order to help developers provide a great web experience
  • Identify a subset of applications as target, such as tweetdeck.twitter.com and reach out to their developers
• define a prioritization framework for these various bottlenecks
• evaluate how much of these bottlenecks are currently addressed with existing techs
• for bottlenecks that are unsatisfactory, determine which technologies or strategies are needed
• among those that are needed and in progress, determine how to accelerate their development
• among those that are needed and not in progress, determine how to get them started or focused

Under consideration: provide some sample cases/web pages to help evaluate the performance optimization.

Progress

In the past two years, the Web Performance Working Group has been trying to identify the potential performance bottlenecks of the Web, and specify UA features and APIs for developers to observe and improve their application performance.

We believe that a large part of these bottlenecks are currently addressed with existing techs. Still, we need to invest more on this topic.

• Enhance performance diagnostics: Navigation Timing 2, Resource Timing, User Timing, High Resolution Time Level 2, Server Timing;
• Make better use of the Network: Beacon, Resource Hints, Preload;
• Improve Rendering and Compositing: Timing control for script-based animations, Frame Timing.

For bottlenecks that are unsatisfactory, we managed to offer Web developers tools to gather detail information about their Web application, so that they can further the optimization.

One of our major concern was to the lack of responsiveness in Web Applications. To identify the most important bottlenecks in this area, we have started the work on Server Timing, which enables the server to communicate performance metrics about the request-response cycle to the user agent. Frame Timing, from another aspect, provides a new ability to measure page smoothness (i.e. Frames per Second and Time to Frame).

For most of the various known bottlenecks, we believe a prioritization framework would help to provide a better picture of the future works. The WG will publish primers or Best Practice documents to support this plan.

Among those specs that are needed and in progress, we will make sure the documents are moving the REC track properly. In some of the special cases, we’d like to continue our work in a second edition (f.ex. High Resolution Time, Performance Timeline, User Timing and Navigation Timing), so that we can meet the new changes of the Web. For those that are needed and not in progress, we managed to identify the difficulties and provided solutions accordingly. The GitHub issues and the Mailing List of the WG are active. We believe these open discussion helps to keep our specs moving forward.

Outreach

• reach out to UI library developers
• survey developers
• look into browser vendors' unspecified optimization features

Potential milestones

• February 1: start outreach
• March 15: proposed framework for prioritizing bottlenecks
• April 3: list of prioritized bottlenecks and application targets
• April 15: Map of technologies and strategies to Web technologies
• April 20: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment
• April 24: Report for progress on application foundation due for AC meeting
• May 5: AC meeting starts