Performance APIs and you

background-image: url(media/fast.jpg)
layout: true
class: center, middle
---
# The WebPerf WG and You

.center[Yoav Weiss  |     @yoavweiss]

???

Hi, I'm Yoav Weiss
I work for Akamai, I work on browsers and Web standards and as a member of the WebPerfWG, I'd like to tell you a bit about what the WG does and mostly, how it
impacts your life! How can you use the work being done at the web performance working group to make your site faster, your users happier,
and hopefully, make your life a little bit better as a result.

.right[![](media/Akamai-Logo-RGB.png)]

---
## What is a working group?

???

Since I'm guessing most of you were never involved in Web standards, what is a working group?

---
background-image: url(media/group.jpg)

???

Some of you may have a mental image of a working group as a group of the industry's elders, sitting in our ivory towers and making decisions for the commoners down there.

---
background-image: url(media/webperfwg.png)
class: center

##.medium[![](media/ilya.jpg)] .medium[![](media/todd.jpg)] .medium[![](media/rniwa.jpg)] .medium[![](media/nate.jpg)] .medium[![](media/shubhie.jpg)] .medium[![](media/nolan.jpg)] .medium[![](media/yoav.jpg)] .medium[![](media/philippe.jpg)]
???

But in reality, things are quite different. Ilya Grigorik and Todd Reifsteck are co-chairing the WG, both engineers and both working on
performance issues in browsers. We have members from various companies including Google,  Microsoft,
Apple, Facebook, Twitter, Akamai, and others.

We meet up online every couple of weeks, we meet face to face once or twice a year, and the bulk of the work happens between those
discussions and GitHub issues.

And as you can understand from the WG's name, our work is focused on making sure that you can easily optimize your sites and make them as
fast as they can possibly be.

---
# What did we do?

???

What have we been working on?

In the last few years we worked on several APIs that enable you to tackle a couple of performance related
goals:

---
background-image: url(media/gauges.jpg)
layout: true
class: center, middle
---
# Measure

???

The first goal is measurement, and the first set of APIs enable you to measure your site's performance *in the wild*.
You can't speed up what you can't measure, so being able to track real-life performance of your sites is critical to improving
it.

Your favorite browser dev tools as well as WebPageTest contain a lot of performance info. And both are great.
But getting that information from real users is invaluable. There a limit to the number of devices, network types and
user scenarios you can test on your machine or in the lab. Getting performance data from users gives you incredible insight into how your site is used
and where are your performance bottlenecks.

APIs include
---
#Navigation Timing

???

which enables you to measure the current page's loading metrics

---
# Resource Timing

???

which enables you to get per-resource loading metrics.

---
#User Timing

???

enables you to measure critical points in your application logic and create custom JS-based metrics.

---
# Beacon

???

sendBeacon enables you to send all that data back up to your server in a performant and reliable way.

---

#How do I use it?

???

Now, I realize that I've just said many, many words, but those of you who are not familiar with these APIs, may not have a clear mental image
of what they do. So let's look
at an example.

Say, I have this site:
---

background-image: url(media/velocityconf.png)

???

I want to know how fast is my site loading in the wild, and in particular, how fast are users clicking on a conference "button", which are
my main "call to action".
---
background-image: url(media/gauges.jpg)
layout: true
class: middle
---

```javascript
var timing = performance.timing;
var navStart = timing.navigationStart;
var ttfb = timing.responseStart - navStart;
var dclStart =
    timing.domContentLoadedEventStart - navStart;
var dclEnd =
    timing.domContentLoadedEventEnd - navStart;
```

???

First we can use Navigation Timing in order to figure out important milestones in the page's loading, such as the HTML's TTFB, how long it
took us to get to DCL (which we may have hanged JS functionlity of) and how long it took for DCL event handlers to run.

---
```javascript
var resources =
    performance.getEntriesByType("resource");
var delayDCL = resources.filter(
    function(res) {
        return (res.responseEnd < dclStart);
    });
```

???
We can also dive into deeper per-resource analysis using resource timing, for example figure out which resources finished loading before
DCL, since these resources are likely to also be the ones stalling DCL.

---

```javascript
document.querySelectorAll(".conference").forEach(
    function(el) {
        el.addEventListener("click", function(el) {
            performance.mark("user_clicked");
        });
    });
```

???

Then we can use User Timing in order to mark an event when the conference "buttons" are clicked.
---
```javascript
document.addEventListener("visibilityChange",
    function() {
        if (document.visibilityState !=
            "visible") {
            performance.measure("user_click",
                "domContentLoadedEventEnd");
            // Gather more data
            navigator.sendBeacon(reportURL, data);
        }
    });
```
???

And finally, we can use the beacon API when the page is changing visibility in order to send that data up to the server.
And beacon continues to send that info up even if the user navigated away.

Then on the server we can see how long it takes for users to click our conference "button", we can correlate that with our other site
metrics, We can create waterfalls and analyze the ones that are particularly slow, and we can also test how our conversion speed changes when
we move the button up and down. We can then match all those metrics up with our conversion rate and see if they're related. Chances are
that they are.

And we can use all that data to figure out bottlenecks and then try to solve them.

---
background-image: url(media/hint.jpg)
layout: true
class: center middle

---

#Hints

???

How can you solve them? By hinting the browser what's about to happen. The two major hints are:

---
#Preconnect

```html
<link href="https://3rdparty.com" rel="preconnect">
```

???
 enables you to tell the browser to preemptively preconnect to a certain host, because you know that the browser would need to, as this host
 is used to fetch 3rd party content.

---
# Preload

```html
<link href="1.js" rel="preload" as="script">
```

???
enables you to do the same for a certain resource, and tell the browser to download it ahead of time

by using the preconnect and preload hints,
you can help the browser discover those resources earlier, and have them ready by the time they're needed.

And if you're interested in preconnect and preload, I'll talk about them a lot more at 11:50 today at G102.
---
layout: true
background-image: url(media/fast.jpg)
class: center, middle
---

# What's next?

???

OK, I hope that clarifies the work we've done, but potentially more interesting is the work we're about to do. What are we working on next?

---
layout: true
background-image: url(media/future.jpg)
class: center, middle
---

# Visual metrics

![](media/visual_progress.png)

???

Well, one big thing that's missing from current performance metrics is visual metrics. Dev tools and WPT give you various insights as to how
a page looks as its loading. WPT goes a step further and gives you a score: SpeedIndex that indicates the visual progress of your site towards
it being "visually complete". RUM does not have that today. And this is one area where a lot of work is planned to change that.

---

# First Paint & First Contentful Paint

???

Are two proposed APIs that would give you the time it took for the user to see something on the screen. The first is mostly related to
background painting, and the second relates to actual content paints. In some pages the two will be identical, while in others there may be
a difference between the two.

---
# First Meaningful paint??

???
There were attempts inside the Chrome team to define a "First Meaningful Paint" API, but apparently it is very hard to define an accurate
heuristic for what's meaningful in a standard way.

Instead, we decided to explore something called the

---
# Hero Element API

???
which enables you to declare a certain element so that its painting would be registered as a kind of user timing. The User
timing API that we've seen earlier is only for JS events or for things that happen inside your JS code. The Hero API would enable us to apply
user timing to a larger set of use cases, and in a way, let you determine *your* first meaningful paint.

---
background-image: url(media/timeline.png)
#Runtime metrics

???
Runtime performance is also an area where current APIs have been lagging. two interesting new proposals on that front are

---

#Long Task Observer

???

indicate that your browser's main thread has been busy for over 50ms with either long JS tasks, long layout operations, or
something of that sort. Basically, your users' browser was unresponsive during that time, so you should take note, and further analyze your
site to improve its runtime perf.

---
# Input Latency

???
The other API for runtime measurement is Input Latency - it's there to indicate that the user has actually tried to interact with your app,
and saw a significant lag in operation, because the browser was busy doing something else (likely a long task, or many short ones).

These are all still early proposals, but they're all on their way to be implemented and shipped in browsers, and hopefully will be part of
your toolkit a few months from now.

---
background-image: url(media/fast.jpg)
# How can you chime in?

???

The last thing I want to talk about is how you can influence the direction in which we're going.
Like I said at the begining, we're not sitting in our ivory towers.
// Back to old men photo

---
background-image: url(media/group.jpg)

???

But, many of us are working for large companies, working on browsers or very large sites, and we don't necessarily know all of your day to
day struggles with performance. Which is why we need your help. We need your feedback.

---
background-image: url(media/webperf_github.png)

???
Discussion on these proposals happens on Github repos and issues.

---
background-image: url(media/discourse.png)

# wicg.io

???
All the new proposals are discussed and worked on as part of the Web Platform Incubator
Community Group, discussed on the discourse instance (rather than mailing lists, as it once was).

All the tools are there to make it as easy for your to participate as possible. So my request from you:
Go to check out new proposals on the WICG's discourse, watch repos for proposals that you care about on
Github, and above all, don't be afraid to provide us with feedback regarding the proposals.

If these proposals are great and they're everything you ever dreamed of, we want to hear it.
If they won't help you one bit, we want to hear it even more.

So please, get involved. and in the immortal words of Jerry Mcguire

---
background-image: url(media/fast.jpg)
# Help Us Help You!

---
background-image: url(media/thanks.jpg)
#Thank you!

.lower.center[Yoav Weiss  |     @yoavweiss]
---
background-image: url(media/thanks.jpg)
## Acknowledgements
* Gauges - Ky https://www.flickr.com/photos/61555160@N00/2825311303
* Delorian - William Warby https://www.flickr.com/photos/26782864@N00/9637975771
* Schedule - Dan Lurie https://www.flickr.com/photos/67396912@N00/440470493
* Hint - Pavel P. https://www.flickr.com/photos/59852454@N03/14140667377
* Fast - fhirArt https://www.flickr.com/photos/64252494@N07/7573429776
* Group - Kheel Center https://www.flickr.com/photos/kheelcenter/5278042253
* Thanks - Emily McCracken https://www.flickr.com/photos/80845533@N00/1112627704