Check out a free preview of the full Web Performance Fundamentals course

The "Data Beyond Spreadsheets" Lesson is part of the full, Web Performance Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Todd revisits the web business objectives to project what affect these optimizations will have on session time and bounce rate. Flame distribution charts can create a better visualization of page performance and web vital metrics.


Transcript from the "Data Beyond Spreadsheets" Lesson

>> Let's look overall, did we improve performance? We made a whole bunch of changes. We made server changes to simulate a faster network on a CDN. We made a bunch of asset changes deferring stuff we didn't need and optimizing stuff we did. We compressed assets, we specified the layout, we did a whole bunch of things that improved the different metrics, but how did that actually work?

Well, if you were capturing any of the field data along the way, you could take that and paste it into the dashboard. When I did it before and after this course, as I was making changes, here's roughly what I saw before and after. Before we had a really high LCP.

And a really dynamic commutative layout shift. Lots of stuff was happening. The first input delay wasn't really relevant for the site, we didn't load obnoxious amounts of JavaScript. And the first contentful paint was pretty fast. We got a little bit faster. We saw huge dramatic improvements when we fixed LCP.

We greatly reduced the time it took to deliver all of the assets to get to that important metric. And we crushed CLS down to almost 0 by specifying those sizes. Now, based on our earlier examples of how we tie this together with business analytics, well, there was a strong correlation between the largest contentful paint and what was it?

The largest contentful paint and the bounce rate and the cumulative layout shift and the session time. And so if we improve these things, what would we forecast for the future of those metrics? Well, the session time should go up. They'll spend way less time being frustrated by layout shifts.

And the bounce rates should go down, we should be delivering the core content way sooner than they were before. And this is how these sort of efforts need to be pitched to the powers of your organization. If you're trying to justify time to spend improving the performance of your app, you can't necessarily sell it by saying hey, we need to spend some time making the site faster.

You need to sell it by saying hey, we're gonna try and improve the session time, we're gonna try and reduce our bounce rates. You're gonna do it by improving performance. But these are the metrics that most business people are going to care about more. Now, we can authentically say how much we're going to improve session time or how far we're going to reduce bounce rate.

Because just like pirates don't actually cause global warming. We don't know how tightly these things are correlated. But we do know that there is some correlation and that we would expect these numbers to improve in the same general trajectory by making performance improvements. That will make your business people quite happy.

Now, there's a lot of data that you'll gather, especially from field data. If you've been looking at the field data from our project and pasting it into the spreadsheet, there's a lot of reports and those reports are pretty high level roll up of the data, but they're representing every single hit.

So every single time somebody hit your page, you get something in there. And so there's a lot of ways that we can show data about performance that's more helpful that reveals more characteristics about it. And so I wanted to show you some more real charts from real sites and what those things look like.

So for example, this is what's called a flame distribution, which is what a number of different tools will do. This is what it looks like on request metrics. A flame chart will show you the relative performance of how each user experienced the page. And the size of it indicates how many users had that experience.

So, blue is fast, everything is great. Red is slow. They're having a whole lot of problems. We want big lines, because we want lots of users to visit our site. And we want most of it to be blue. We want most users to have a great experience. Now you can project that same data over here on the right side and say well what was the median and 75th percentile in 95th percentile over that time?

And see what these actually users are across the entire time or you can project that data over time and see how does the median change how's the 75th change? How's the 95th change? Each of these will give you a different kind of perspective into what the data means.

Because field data is very noisy and you need to look for the patterns. Here's another example of web vitals specifically. Now web vitals largely are driven by what Google thinks of them. This is one of the most common and objective measures because Google is this gatekeeper. And you need to make sure that Google is happy.

So, Google has good, okay, poor ranges. We can roughly define those and show you how you're doing over time. How many of your users had each of these experiences? You'll never have 100% of your users good. Very unlikely, and you'll never have 100% of your users bad. But as long as 75% of your users are having a good experience, you're doing awesome.

But don't worry about making sure that every single session is not poor. You can't control everybody's device. So in this case, we have a cumulative layout shift, which is fantastic for this particular data set. But the LCP is honestly not good. The median looks like it needs improvement most of the time.

And so this site could obviously use some work. One of the other pieces of data that's really interesting to capture over time, is what makes up that time. So if a page is taking a lot of time to do its work, we can use some of that entry information that we talked about earlier in the course.

And we can chart that. So how long did the browser spend doing a DNS lookup? How much did it spend doing an SSL handshake? How long did it spend downloading JavaScript and then rendering JavaScript? We can chart this information over time to see when something starts going bad, what was the culprit?

All right, this was our part 2. We talked at the beginning about some business objectives and why we did this. We looked at each of the web vital metrics and some tactics on how to think about them and how to improve them. And we did a bunch of code demos, and exercises.

In part 3, we're gonna talk about planning for a more performant organization. How do you incorporate some of these ideas so that you're not constantly fighting to build a more performant website.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now