WebPerf WG roadmap

igrigorik@chromium.org 

• https://www.w3.org/webperf/
• https://w3c.github.io/charter-webperf/ 
• https://github.com/w3c/web-performance/blob/gh-pages/meetings/2016/06-westcoast/agenda.md 

Level 1 “performance pack”

Brief overview and history of the L1 pack

1. Navigation Timing L1 was the first spec produced by the working group.

1. It is self contained and does not contain any dependencies.

2. High-Resolution Time L1 introduced a high precision monotonic clock.

1. Time origin is defined as from navigationStart defined in Navigation Timing L1.

• Performance Timeline L1 was introduced as base infrastructure for new performance entries:

• It defined the base PerformanceEntry object and methods to retrieve said objects from the timeline.
• PerformanceEntry depends on High Resolution time for its timestamps.
• By itself, this spec does not offer any new usable API’s to developers.

• User Timing L1 allowed developers to create own “marks” and “measures”

• The resulting PerformanceMark / PerformanceMeasure interfaces inherit from PerformanceEntry.

• Resource Timing L1 surfaces individual resource fetches to developers.

• PerformanceResourceTiming inherits from PerformanceEntry and extends it with custom attributes.
• It defines the Timing-Allow-Origin header for cross-origin resources.

Level 2 “performance pack”

History and changes from the L1 pack

1. Refactor of L1 specs

1. Many interfaces are shuffled between specs to bring conceptual coherence and simplify authoring.

2. Performance Timeline is now exposed on Worker.
3. “Time origin” is moved to High-Resolution Time L2 and is compatible with Window and Worker contexts.
4. New PerformanceObserver interface defined on Performance Timeline

1. Resource Timing, Nav Timing, User Timing integrations with PerformanceObserver.

5. Resource Timing extensions and clarifications:

1. Uses new “time origin” definition (High-Resolution Time L2)
2. secureConnectionStart is a mandatory attribute.
3. New attributes: transferSize, decodedBodySize, encodedBodySize, nextHopProtocol, workerStart
4. Processing algorithm clarifications on how to deal with failed resource fetches

6. Navigation Timing is redefined as an extension to Resource Timing:

1. Navigation Timing entries are exposed via Performance Timeline
2. Legacy interfaces are preserved

7. User Timing: minor processing clarifications and timestamps are with respect to new “time origin”.

Q3~Q4 deliverables … SHIP ALL THE THINGS!!! Maybe?

1. Publish notes / move to WICG…

1. Server Timing
2. Frame Timing
3. Reporting
4. NEL

2. Snapshot “L2 performance pack”

1. What’s new: refactored, consistent time origin, exposed on worker.
2. AI’s:

1. P0: resolve translation issues for HR-Time
2. P0: resolve presence of requests that don't return a response on Resource Timing
3. P1: review and/or contribute tests for all L2 specs
4. P2: security and privacy reviews
5. Publish CR’s

3. Page Visibility L2 CR

1. What’s new: fire on unload; processing clarifications.
2. AI’s:

1. P0: land tests
2. Publish CR

3. Beacon L1 CR

1. Depends on Page Visibility L2
2. AI’s:

1. P0: land tests
2. Publish CR
3. Move to REC in Q4

4. requestIdleCallback L1 CR

1. AI’s:

1. P0: land tests, security review.
2. P1: Resolve interop with HTML spec, integrate Edge feedback
3. Publish CR

5. Preload L1 CR

1. AI’s

1. P0: Tests & security review
2. Publish CR

Q4+ deliverables

6. Fetch all the things?

1. Resource Timing, Nav Timing L3’s?

1. Multi-request fetches
2. …

2. Preload

1. Define preload cache interop with Fetch

7. User Timing L2?

1. Declarative marks
2. Richer payloads
3. …?

8. Beacon

1. L2:

1. GET, custom headers, etc.
2. Expose as fetch() primitive?

9. Preload

1. Define preload cache interop with Fetch

10. Resource Hints

1. AI’s

1. Build tests & interop data
2. Security review
3. Publish CR… REC?

Process

1. Create milestones for each spec

1. E.g. https://github.com/w3c/hr-time/milestones/Level%202 

2. Assign all open issues to milestones
3. Assign editors for each next-milestone issue
4. Update dashboard to track next-milestone

---

1. Organizing the agenda

------

• It would be nice to have a way for developers to mark what content is important; allows browsers to optimize.
• We can have  “default” implementation + mechanism for developers to hint us

• TTI might be tricky

• Milestone 3: Nav Timing

• First Paint, First contentful Paint
• Starting a navigation
• Visually complete
• Network quiescence

• Long task

• Delay latency between user interaction and next paint

• Bandwidth efficiency
• Battery efficiency

Performance Observer

• Extend filter options to support filter by “type AND name”
• Option to receive buffered entries as first invocation callback

• Q: should we clear at some point?

Resource Timing extensions

• Recreate resource dependency graph ala Polaris/Scout

• URL of the resource initiating
• AI: Yoav will investigate costs in various implementations
  

• Multiple initiators

• We need to explain the magical memory cache
• AI: add a note explaining that some browsers may have a magical memory cache and that sometimes you may not get a new event when such a thing is hit.

https://docs.google.com/document/d/1DNRGhlYbMYdBkKsy7z9Bg--83KHa6r9-THurzBNLqTE/edit#