Hello.
My name is Nick Jansma.
I work at Akamai and I'm one of the co-chairs of the W3C Web Performance Working Group.
Thank you for coming to the session.
Today, I'm going to be talking about the goals of the Web Performance Working Group.
What we build, some of the latest happenings and features that we're working on, and how you can participate.
So, what is the so-called W3C Web Performance Working Group?
Well, let's break down some of those words.
So the W3C is an international community that works together to build web standards, which are really the features that go into browsers and web servers that we use today.
Each working group within the W3C focuses on specific aspects of the web and the Web Performance Working Group is focused on performance.
Yoav Weiss and I are the two co-chairs of the working group and we help facilitate the discussions and focus the group and the specifications that we're working on.
You can learn more about the group at the two links on the slide, or by reaching out to either of us directly.
The Web Performance Working Group was founded in 2010 to provide methods, to observe and improve aspects of application performance of user agent features and APIs.
Basically this means that we work on things like navigation timing, paint timing, resource timing, and the other timing APIs that allow apps and libraries to observe the end user experience.
We do this as a group by collaboratively designing technical specifications that browsers or web servers implement.
These specs evolve over time as new ideas or requirements arise, and the group discusses any need to changes, edits the specs and tests.
And then the browser vendors go off and implement those changes.
We've also designed API APIs to help web applications build more performative websites, such as things like resource hints, requestIdleCallback or the Beacon API.
And building new web browser standards is a challenge.
We need to find the right balance between performance improvements and insights that we want to add, with ensuring the end user still maintains their security and privacy.
Our group is responsible for a large number of technical specifications.
You can see the currently maintained list here, but we've designed everything from the Navigation Timing, to Resource Timing, and User Timing APIs, PerformanceObserver, HighRes Timestamps, Beacon and Reporting APIs, Long Tasks, Resource Hints, Preload, and more.
A lot of these APIs enable observability.
In other words for the site to be able to measure the user experience and then capture aspects of the browser internals so that they can find areas to improve.
Other APIs like Beacon Reporting and Network Error Logging, help websites collect their performance data, and then monitor for any problems with applications.
And finally, we built a set of API is that give control to the website to help prioritize the fetching of pages components through Preload and Resource Hints.
All of the specs here had been around for awhile and generally have the support of the major browser vendors.
We build these APIs thoughtfully and collaboratively, so that browser vendors can be confident that the new API is providing value with minimal risks.
There are many companies that are involved directly in the Web Performance Working Group, some of which are listed here.
We have participation from all the major browser vendors, alongside large websites, analytics companies, and others.
We also have a panel of invited experts.
In other words, like individuals that are passionate about Web Performance and that want to help shape the future of the web.
So if after everything that we discussed that you would like to participate, there are many ways to do so.
We generally have bi-weekly video conference calls, where members present new ideas that they have, or we triage the issues that the community has filed it to get help with their questions and concerns.
We required videos of these meetings.
So if you wanted to see what we have been talking about in the past, or if you are interested in joining you can head over to GitHub to do so.
All of the specifications have their own GitHub repositories.
So you can see the work that is involved and the changes that are occurring.
You could also file GitHub issues, which we use to track feedback and tasks.
If you or your company have ideas for how to improve the performance of the Web, we regularly have ideas pitched during these meetings.
And a group is generally good about constructive feedback.
Many of these proposals turn into full fledged incubations which are kind of like a lightweight design document that some browsers may partially implemented to gather feedback.
My co speaker, Nicholas will soon be going into some of the cool incubations that are happening right now.
If you or your company, you want to join these meetings regularly.
You will need to be covered, become a member of the W3C details of which are on the w3c.org homepage.
But today, what else would like to briefly highlight some of the noteworthy improvements we've been adding to these APIs.
For example, if you've ever looked at any of the timing APIs, like Navigation Timing, Resource Timing, User Timing, Paint Timing, Event Timing, et cetera, you've interacted with the performance timeline.
This API gives you a standardized way of creating two performance events via the getEntries interface, and a way to listen for new events in a performant way via Performance Observer.
We've made a few ergonomic changes to the API.
For example, you can provide a buffered `true: flag` when creating a PerformanceObserver to look back into time at previous entries that were fired, and this could be especially useful if you have any libraries that loads asynchronously, it could look back at the history of events before it was on the page.
Similarly, there's a droppedEntriesCount attribute that we've added that lets you know, if there are how many entries were dropped because the user agents reached its limit of the buffer.
For example, if you saw a non-zero value of droppedEntriesCount, you would know that you have missed some of the history.
There's also a new supportedEntryTypes attribute, which allows you to easily feature detect which performance timing types are supported in the current browser.
That gives you a way to know whether an event should be firing or not.
For example, until PaintTiming is supported in all the browsers, this can help, you know, if the paints events will ever be fired or not.
Moving on to ResourceTiming, which allows you to get details of all the sub-resources fetched for a page.
We're just wrapping up on a huge refactoring of the spec to make it better integrated with the Fetch spec.
This is probably a relatively boring detail to everyone except for the spec editors, but what it means and why it may matter for you is that we have a long delayed adding new features to Resource Timing until this was complete.
So now that we're approaching a good clean slate, we're starting to discuss additional feature requests for the spec, and if you have any ideas, please bring them to us.
One proposal, for example, for Resource Timing is having some sort of initiator dependency tree available.
When you're in the developer tools today, you could often see the exact HTML or script element that is triggered for each resource download.
Having the ability to retrieve that same information for resource timing would give analytics a lot more power in figuring out the root cause of particular requests, especially for third parties or other slow fetches.
There's also a proposal for resource timing for exposing the render blocking status of resources, which can give an indicator about a resource's priority.
or how important it is for it to be fast.
Both of these proposals can help websites build faster user experiences by analyzing how the websites actually behave in the real world via real user monitoring.
The other two specs that I want to talk about that have some recent updates.
One of which you may have used is called User Timing.
User Timing allows you to mark and measure particular points in time or durations in a standardized way that developer tools and analytics packages can pick up from.
Recent improvements to user timing include the ability to specify the exact custom timestamp you want to be placed for the particular marker measure, and a new detail field, which gives you the ability to include any additional metadata that you want as part of the mark or measure that your analytics could later capture as well.
Finally, some good news on the interoperability front- PaintTiming into recently shipped in Safari which added support for First Contentful Paint.
So I want to talk about incubations briefly with Nicholas, we'll go into further.
Before a proposal turns into a full-fledged specification that the working group supports it may be incubated in the web platform incubator group, the WICG.
So after discussions and possibly implementations within the WICG it could be adopted by the working group.
And Nicholas, we'll talk about this more.
Before I hand it over to him.
I just wanted to thank you for your time today with me.
I also want to reiterate that if you have any questions or would like to participate more, please reach out to the web page above or to one of us on Twitter.
Thank you.
