Performance Observer

[00:00:00]
>> Todd Gardner: Problem with the performance API is that, when you want to interrogate it for something, we have what's called the observer effect. The observer effect is like a scientific term, it's most famously known in terms of like quantum mechanics, if you're a science nerd, where you change the results by measuring them.

[00:00:21]
This is definitely a problem in the web space, is if you get involved in logging and you start interacting with the performance API a lot, you're slowing things down by how you're choosing to interact with it. You might decide, I wanna get a bunch of logging information when the browser is busy trying to do the thing that you're trying to log.

[00:00:38]
And so that's where the performance observer comes in. The performance observer gives us a tool to get information about the performance of the page, when the browser's idle. When it's not doing anything else pass me some information about performance and get outta the way. So here's an example of a performance observer.

[00:00:58]
We can use these things to observe different kinds of entries which represent like the core web vitals or resource requests or navigations. Here's an example of how we could observe layout shifts. So I create a new performance observer, and that performance observer takes a callback, we get a list of things that have been observed.

[00:01:20]
That list of things will give us an array of entries, and then for each one, we'll have information about it. That information is essentially that object I was just playing with in the console. It's all of those properties, and those properties are different based on what thing we're measuring, so you have to kind of experiment with it.

[00:01:36]
In the case of layout shift, we get a thing called value, so this just prints out. Here's a layout shift at this particular value, once we start it up, we've called performance observer to observe we grab the kind of thing that we want. So you need a performance observer for every different thing you wanna measure.

[00:01:54]
And then buffered is important, because what this lets us do is it lets us be informed of events that happened before I started observing. So if you're building a performance agent of some kind to look at your page, you probably don't want it to load at the beginning.

[00:02:11]
You probably want it to load at the end, and then attach its listeners at the end, and you want buffered listeners that get information about all the things that happened before you were on the page. That's what that property lets you do.
>> Todd Gardner: A way more simple way if you care about the web vitals specifically, which chances are that's what you care about, is there's a package from Google called Web vitals js, and it's out on Github and the sources in the slides.

[00:02:39]
And what that basically lets you do is it lets you subscribe to particular events and handle all of the other weird intra idiosyncrasies about adding things together. Finding the biggest one, knowing when it's time to capture it, handling changes if the document got like tabbed away and all those sort of things.

[00:02:58]
That's all abstracted away in this library called web-vitals which is great, and you can just subscribe to events called onLCP, onCLS, onINP, and get the data that you need, which is super interesting. I'd say 99% of the time you never need to interact with this stuff directly, you're probably going to be using a reporting tool or a monitoring tool of some kind that interacts with these things for you.

[00:03:22]
But if you're trying to diagnose a page yourself, these can be interesting to know that they exist so that you can grab the low level details.
>> Student: Would you just fire these up in the console or something, or what event would you tie them to when the page loads for the performance observer.

[00:03:40]
>> Todd Gardner: Sure, so let me show you just a quick example. Discard that.
>> Todd Gardner: So if I want to,let me just reload this page here, which will take a second. So if I was to put this in code, what I might do is I'd be, window.addEventListener load. And I would don't really care about the event, so in a bit of code like this, I would attach a performance observer.

[00:04:14]
Now, I'm not gonna put it in an addeventlistener in the console because obviously load has already fired in this case, but I would could create an observer. So const observer equals new performance observer.
>> Todd Gardner: And I'm gonna listen to a list of things.
>> Todd Gardner: And List.getEntries.forEachentry.
>> Todd Gardner: Console.logEntry.

[00:04:57]
>> Todd Gardner: Then I need to say observer.Observe, what was it?
>> Todd Gardner: Type, layout, shift buffered, true.
>> Todd Gardner: So if I just do this, I'm gonna get nothing, because no layout shifts are happening now, I just attached this event observer. And so, unless I trigger a layout shift to happen, nothing's gonna happen.

[00:05:30]
But if I do this again and I say buffered true, I get all the layout shifts that happened. And so it gives me like the full details of them. So here's a layout shift, here's the sources, here's the things that actually shifted. So this text node, this H two element and this text node all shifted.

[00:05:54]
The total value of this shift was 0.002155, and it started, the shift start at 4.278 seconds. So that's how you would go about attaching these and the data that you get off of them. And there's the same sort of thing, instead of listening for layout shift, which just gives you individual layout shifts, right?

[00:06:17]
There's no one to listen cumulative layout shift, you'd have to attach these and then just add all of them together as you get them. That's one of the things the web vitals library does is it adds things together for you and figures that stuff and when you should actually report stuff.

[00:06:31]
But you could listen to other things like give me an observer every time a fetch event goes off, so you can monitor how long every one of your fetch calls takes. You could use a performance observer for that.
>> Todd Gardner: Okay.
>> Todd Gardner: All right, let's talk about browser support, yeah.

[00:06:55]
>> Student: Quick question on the performance.time origin, where in the waterfall does that start?
>> Todd Gardner: That would be start, that's the most left hand side, time origin is the full date object of when start time is when the access begins. So everything else is relative to get, usually all the other times are measured relatively.

[00:07:24]
So it's like 200 milliseconds since time origin or whatever. If you want to switch it from that relative time to the absolute timestamp of this thing happened on September 30th at whatever time, you just add your metric to time origin.
>> Student: So, it's when the browser makes the HTTP GET request?

[00:07:47]
>> Todd Gardner: It's when the browser makes the first HTTP GET request in response to a user navigation. So, if I open up a browser window, a fresh- browser window and I type in something and hit enter, it's measuring the time I hit enter. Now, if that request bounces through a bunch of redirects, all of those count and the time origin is when I hit enter.

[00:08:12]
If I'm Googled for something and I click a search result, it's time origin represents a short time after I clicked on something, it doesn't really count of how long the Google page took to unload and garbage cleanup. But when that navigation happened, it counts all of the movements from that point forward, that's when time origin happens.