Performance Analytics

[00:00:00]
>> So let's look at some performance. So in our hypothetical example, we now deploy our website with some performance analysis in it. And we can produce some charts based on that. I can show you how we did that. If we look at this log file. Yours probably doesn't have as many entries as mine.

[00:00:25]
But if you just reload Chrome a bunch more times, you'll get you'll get more entries. We can chart this pretty easily. I have a document all set up for you already. If you look in the readme of this repository, there's a link out to both documents. Both the performance worksheet that we played with in part one.

[00:00:47]
As well as this example performance dashboard that we're going to look at next. If you pop open the performance dashboard and again, make a copy of this. So that you can edit the numbers here is some very simplified reports based on your field data that we captured. This works through a dashboard and a data sheet.

[00:01:15]
The data is just hate you took the CSV contents of that log and you paste it in. So we'll do that together. I'm going to go into my perf.log.csv. And I'm going to select it all and copy it. And then I'm gonna to go to my performance worksheet.

[00:01:45]
I'm gonna delete the sample data that's already in here. I'm gonna paste it in the stuff I just pulled in. Now it might not properly figure everything out for you, and so you'll need to go to Data, split text to columns. So that's going to be the field data that we pulled from our perf.

[00:02:15]
JS agent as we've loaded it here locally playing, flipping back to the dashboard. This will then Chart the data that we were looking at. So based on what you put in what you paste into your data, here is your load times. First contentful paints, largest contentful paints, kimito layout shifts, and first input delays.

[00:02:48]
With them charted here below. So being that we haven't made any changes. What we're looking at right now is just the natural variability that happens in small datasets. So we only have a few points of data to work with. We really need to get up into the hundreds before like things start to make sense here.

[00:03:10]
But it looks like we have some normal levels of data. Let's move back in to our slides and our hypothetical. So if we deploy this and start gathering data for some days, some weeks a month, whatever. Here's some field data that we pulled in. And there's a couple interesting things in this data over time.

[00:03:38]
There's a couple of LCP issues here. Where at least in these two different times the LCP has spiked up quite a bit higher than what it would normally be at. And here we had some sort of layout shift issue that spiked that up considerably higher. Now in isolation, we don't know what these mean, we know they got worse.

[00:04:01]
But we don't know that that's bad or that that's anything to care about. So we need to compare it with real business data. And that's where our, the justification for our time and our efforts are going to come into play. So if we overlay our business analytics that we captured before with our bounce rate and our session time.

[00:04:27]
We can see a correlation here. We can see that the stuff happened weird. At the same points in both charts. On the far left, we see that hey, when CLS got a lot worse, the session time fell and on the right. We see that that happened the same way.

[00:04:51]
When CLS kind of freaked out session time fell. But also that when first contentful paint got slower bounce rate went up. Which kind of intuitively makes sense. If it takes a long time for your page to load, then the users are just gonna leave, they're not gonna wait for it.

[00:05:12]
And so these kind of patterns in the data teach us some things, we can arrive at conclusions based on it. And the first is that commutative lot layout shift is inversely correlated to session time. As our layout shifts get worse, the sessions are going to get shorter. And that the largest contentful paint is inversely correlated to bounce rate.

[00:05:39]
The time it takes to paint our screen gets slower, the more likely it's going to be that our customers leave. Now, it's important to remember is that this is for our example. This is based on this data that I've showed you right now. That correlation, is not universal and it might not exist for your customers, for your application.

[00:06:05]
It's important to look at your performance data, and correlate it against your business metrics. So that you can see what if any correlations exist, that you can use to drive your efforts. To improve your data, because if you're not focused on what the customers. What the users are actually doing, you don't know if you're improving the right things.

[00:06:29]
So let's move on to improving the right things. So there's a pretty simple rule to how to improve performance. This is general, whether you're talking about application performance, database performance, web performance. There's really just one thing you need to do. You need to do fewer things. You can't really do it faster, but you can do fewer things.

[00:06:59]
And I mean that in every possible layer, so you can send fewer bytes, you can send fewer documents. You can send smaller documents, you can have less overhead. Ultimately, all that we can do in any part of web development is figuring out a way to do things. So that's it.

[00:07:21]
That's how I would do it. The end let's go to the bar. No, growing up.