HTML5 Performance

Tokyo, Japan

June 2013
Philippe Le Hégaret

plh@w3.org

Impact of Slow Website

Time is Money!

80-90% of the end-user response time is spent on the frontend. Start here.

the Performance Golden Rule

Bing experiment

Distinct User Queries Query refinement Revenue per User Any clicks Satisfaction Time to Click Increase
50ms - - - - - -
200ms - - - -0.3% -0.4% 500ms
500ms - -0.6% -1.2% -1.0% -0.9% 1200ms
1000ms -0.7% -0.9% -1.9% -2.8% -1.6% 1900ms
2000ms -1.8% -2.1% -4.3% -4.4% -3.8% 3100ms

Performance Related Changes and their User Impact

Bouncing rate (desktop)

Some Interesting Performance Statistics

Bouncing rate (mobile)

Some Interesting Performance Statistics

Useability

Delay User Reaction
0-100ms Instant
100-300ms Feels sluggish
30-1000ms Machine is working…
1s+ Mental switch
10s+ I'll come back later

Breaking the 1000ms Time to Glass Mobile Barrier

HTTP archive trends

January-June 2013

HTTP Archive

HTML5 Performance Task Force

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

Do we have a problem?

"HTML5′s got 99 problems but performance ain’t one of them."

Paul Bakaus, Zynga

primary reason… the app is running out of memory. It’s not performance issues […] but it’s still a big problem. second reason … is animations …

Kiran Prasad, LinkedIn

So, a problem?

"… HTML5 technologies can deliver as-good-as-native experiences … But the lesson from Fastbook is that it’s hard work"

Matt Vickers, Xero

Challenges

Two main categories:

Load time
From the user request to "above the fold"
User agent speed
Interaction and dynamic changes

Load time

Global Site Speed Overview: How Fast Are Websites Around The World?

Bottlenecks

  • Network layer
  • Crowded main thread
  • Memory:
    • DOM
    • Events
  • Drawing: CSS
  • Low-end phones (Android)
  • tooling support

Network layer

3G
(200 RTT)		 4G
(80 RTT)
Control plane (200-2500) (50-100)
DNS lookup 200 80
TCP Connection 200 80
TLS handshake (200-400) (80-160)
HTTP Request 200 80

Breaking the 1000ms Time to Glass Mobile Barrier

What can we do?

  1. Keep enhancing the Web browsers
  2. Develop more tools
  3. Educate developers
  4. Encourage performance

Improving Web browsers

  • Browser vendors are already doing it
  • Some subset of use cases is really important:
    • Asynchronous scrolling (scroll)
    • Multitab interfaces
    • Animations
    • Caching
    • …
  • We would need to:
    1. Gather the use cases
    2. Prioritize them
    3. Write test applications to highlight the use cases
    4. benchmarking of those test applications?

Develop more tools

  1. At development time: WPT, Speedtracer
  2. Monitoring: See Web Performance Working Group
    • Resource priorities
    • Diagnostics
    • Display performance
    • Asynchronous scrolling monitoring
    • Pre-rendering

Educate developers: Guidelines!

Need to refine and increase the visilibity of performance guidelines

  1. Start from performance tips developed by Google, MS, and Yahoo!
  2. Publish on WebPlatform.org
  3. Publish as a Note?

Encourage performance

The Spotlight Project

  • Shine a light on the end-user performance of Web sites
  • Results will need to public, transparent, and easily understood
  • Methodology axes: geographical distribution, network context, client diversity, user scenarios
  • Need associated infrastructure and operational aspects

So, what can we do?

  1. Keep enhancing the Web browsers: Use Cases
    Approach and methodology for gathering use cases and producing test applications?
  2. Develop more tools: Anything beyond web perf wg?
    Let the market come up with bettern SDKs?
  3. Educate developers: Guidelines
    Approach and methodology for gathering and spreading guidelines?
  4. Encourage performance
    Spotlight Project?
  5. Anything else?

Feedback: public-html5-performance@w3.org