The Problem with Legacy Metrics

[00:00:00]
>> Todd Gardner: So what is the problem with these? Because these two metrics used to be the only way we measured performance. It was the only ways we could measure performance, is we would track how long till DOM content loaded, and how long to load? And we would track those over time and that was the only way to really know, how fast our site was loading, the load word didn't have a problem yet.

[00:00:24]
Because load originally meant that the document was ready. In fact, that was so common that early JavaScript frameworks like jQuery, which is still awesome, jQuery, lots of our code that we would write back in the day would say something like this, document ready, and then we would do stuff to it.

[00:00:43]
And it was just so common like, this is what meant is we would download a page, the page would be done, it would be ready. And then, we could start asynchronous tasks, we could start things that needed to happen after the fact. In this case, we would do some ajax, which was the old way we would do fetch.

[00:01:00]
We would fetch the shopping cart, and put some data about how many things were in the user shopping cart. And this was great, and everything was good. But then, 2010 happened, and in 2010, this new fancy idea called client-side rendering happened, which is all you crazy kids know today.

[00:01:19]
Back in the day, we used a bunch of frameworks that you don't even know about anymore, like backbone, and knockout, and jQuery UI, which were the early ways that we did this. And suddenly, applications changed their structure, and a website could now look like this. This might look familiar from more modern JavaScript frameworks, cuz a lot of them still do this.

[00:01:42]
We have an HTML, that HTML is largely empty, it's got a single div that has an ID like app. And then, I'm still using old jQuery syntax here just for connection to the other stuff. When the document is ready, which happens almost instantly because the document isn't doing anything, we start up our application, and we do things to it.

[00:02:04]
This is how client-side rendered React or Vue, or any of those things would do things, where the load event happens almost right away, and then we do all of the work. So, how does that apply if the old GeoCities sites switched to client-side rendering? Well, before, here's where our document content loaded and load event were, and it was great, and they were meaningful events that told us about the performance of the site.

[00:02:31]
But if we rendered geocities.com using a client-side rendering kind of pattern, suddenly those things move up here. DOM content loaded and load happened instantly, and there's no meaningful connection to the user experience. The user experience could be crap slow, the end of this page could be one second, 10 seconds, 30 seconds, a minute, but the metrics didn't mean anything.

[00:02:55]
And so, we needed new ways to measure performance. Specifically, Google needed new ways to measure performance, because Google makes money off search. Google wants to deliver the best search results possible so that more people use Google to search and Google can show you more ads, fundamentally how Google works.

[00:03:17]
So, Google has realized that users think a search result is better if the website is fast, they will stay on that page longer if the website is fast. If they can make more websites faster, they can reward the fast sites, people will see the search results are better.

[00:03:36]
But how do they do that? How could they know that? They need a way of comparing a site objectively. If we look at foo.com and bar.com, how do they know which one is faster? If they're equally good for content and backlinks and all the other things, how do they know which one to rank better than the other one?

[00:03:55]
If they were to look at DOM content loaded and load, it would be largely due to how they were built, a client-side rendered site would look super fast, even if it feels super slow, and vice versa. So, Google needed new ways to measure performance objectively, based on the user perception of the performance of the site, and it works regardless of the frameworks or technologies used to build the site.

[00:04:22]
And that's where the Core Web Vitals come in, which is a new set of measurements that was introduced to try and address these.