HTML5 Performance

From W3C Wiki
Jump to: navigation, search

Getting involved

Join the public-html5-performance@w3.org mailing list.

The Problem

Problem Definition

W3C works on individual components of the web architecture, driven by the functional needs of the W3C participants. This particular focus may lead us to miss system-level considerations such as the overall performance of typical implementations. While performance suffers for a variety of reasons, Web standards could be part of the problem. In the past, when we looked at performance we instrumented the architecture to allow performance to be measured. This is quite different from a system level focus on addressing and improving performance.

As we mature to take a platform level view of our work, we should address performance issues to grow the acceptance of our standards.

What are the indicators that show that there is or is not a problem?

Every week, there is a news article appearing indicating performance issues with HTML5. Recent examples are:

What are the risks?

Any development platform critically needs developers; developers are less likely to pick the Open Web Platform to develop their applications if there are performance issues with it.

Is the problem real?

  • Do we have examples of slow Web applications?
    • maps.google.com
  • Should we and can we compare the performance of native applications with Web applications?
    • Performance depends on the device and browser used of course.
    • "... HTML5 technologies can deliver as-good-as-native experiences ... But the lesson from Fastbook is that it’s hard work" Making Mobile Work

Identifying the performance issues

  • Where are the bottlenecks?
    • Poor, incomplete or simply missing GPU acceleration for CSS effects
      • We need performance testing for CSS transitions and animations.
    • Slow DOM interaction performance
      • CSS reflows?
      • Enabling the browser to optimize animation via polling the pointer position rather than using move events (e.g. when using pointer position to update CSS transformations)
      • Measuring the rendering lag and allowing apps to provide estimate of the pointer position rather than using what is essentially a historic position by the time the frame is rendered
    • Crowded main threads that result in stutter for things like fast infinite scrolls
      • Better worker support for multi-core processors
      • Shared memory access by workers (synchronized with UI thread)
    • Developers coming from web 1.0 backgrounds with rudimentary programming skills who cargo-cult their AJAX apps with resulting poor performance.
      • Best practices and better tooling.
    • Some new low end phones have terrible browser performance across everything
      • performance testing. Are those phones poor for native apps as well?
    • The browser on this brand new high-end phone is very sluggish doing content animation in general.
      • performance testing.
    • offline support
      • this is common to native and web apps. Several are doing poorly at keeping data on the client side.
  • Are there common patterns/usages where performance becomes an issue?
      • scrolling
      • animation
      • synchronizing rendering to pointer position during movement
  • Are performance gaps similar on desktop and mobile? Are those gaps specific to an implementation, set of devices, or OS?
    • some browser don't perform as well. Firefox takes more than 10 seconds to load the boston.com website, where Chrome takes 3 seconds. (site was loaded in both browsers, the device was rebooted, then loaded again).
    • low end devices

Solutions?

Is there something we can do to help the performance of the Web Applications?

  • Should we advise groups to include a performance considerations section in their specifications?
    • Might be better to focus on performance testing
  • Should we create a "Performance Community Group", similar to our Privacy Interest Group, to provides guidelines and advice for addressing performance in standards development.?
    • Would need to identify individuals interested in contributing to it
  • Should we produce more guidelines/best practices?
    • Within the Web Performance Working Group?
    • On webplatform.org?
      • Yes, any propmotion of best practices, tooling, etc. will help.

Proposals:

1. Produce the best practices on webplatform.org and package them once per year as a Working Group Note and get them published by the Web Performance Working Group: - having the source on webplatform.org allow more individuals in the community to contribute - having the practices published once a year increase the outreach, and is more likely to get attention and review from other Groups

2. Start a performance test suite.

3. Build a showcase app (to illustrate performance best practices)