⚡️ Speed Week: Web Analytics

Hi, everyone. Welcome to Cloudflare TV. I'm João Sousa Botto. I'm a PM here. I'm the PM for Web Analytics, amongst other products, and this is my colleague. Young, do you want to introduce yourself? Yeah. Hi, my name is Young Park. I'm a systems engineer. I work for Web Analytics products here at Cloudflare. And he's the mastermind behind one of the products that we've announced just today. So this is exciting. Well, for those of you that may not know, at Cloudflare, our mission is to build a better Internet. And that also goes through Web Analytics. We believe that analytics being free and being available to everyone, whether they're already a customer of Cloudflare or not, is super important. Our focus is slightly different from most analytic products that you see out there. The focus with Cloudflare Web Analytics is really developers, is really helping you build a better Internet, helping you build a better website. And so we do things very differently. First of all, we're privacy first. So as most things with Cloudflare, we really care about privacy and we really make sure that we don't identify or that we don't profile your company website visitors. And most companies that do that actually do it because they're trying to run user acquisition, make it easier for you, run targeted ads. And so they need to know who is visiting your website. On our side, we believe in really helping people improve their websites. And so we do things very differently. You don't need to have a cookie pop up when you use our analytics solution because we don't do any of that. And what we do is we use a small, very lightweight JavaScript beacon. Yong, do you want to tell us how that works? What data do we really collect as part of this product? Yeah, so the JavaScript beacon is very lightweight. And the data that we collect is mostly from the web API. So what that means is any developer who has access to the developer tool, they can also get it from the web API easily just by querying, typing in the API names, and then you can get all those data. For example, the navigation timing data that we use to measure the page load time, like DNS, TCP, requests, response time, etc. Those can be queried from the performance API's navigation timing API. Similar to that, there are ping timing API, resource timing API, etc. So we collect metrics from the web API's directly, and basically reporting back to our beacon endpoint. On our edge, we try to process as minimal, but we do parse the user agent to see what type of browser the user is using and what country they are connected from. But other than that, we don't store any IP address, or any sort of like cookie session data, related data. Yeah, that's really helpful, because we really do measure it from the user perspective, right? This is real user measurements. We're not just doing synthetic requests on our browser or on our infrastructure. What we're doing is, we're looking at what each user, the experience that each user is really having when visiting your web property, or using your web application. And so, you mentioned a lot of API's, those API's are part of the browser, I'm assuming. Is that correct? Yeah. Yeah. Most of the API's that are available for many other browsers too, not just for Chrome, or like, you know, those popular browsers. Got it. So, these measurements, they apply to virtually every browser that is widely used on the Internet today. Right. Those are very standard API's. And how do people install that JavaScript beacon? Like, we talked about it being very lightweight, but where does it go? And where does it run? So, basically, there's two ways to install the JavaScript beacon. And this is really interesting, because, you know, not other providers provide this, but you could grab the JavaScript snippet from our dashboard, and then install it yourself. So, basically, you put it right before the ending body tag, and that's it. But if your DNS is through Clutter, then you could actually use the coolest injection feature of the beacon JavaScript. So, what that means is, like, if you have a zone, you could choose your zone and enable the beacon JavaScript, and the beacon JavaScript will be injected for all the existing web pages under your zone. So, if you say, like, I have, like, 100 websites, and I don't want to install beacon.js manually for every, you know, source that I have, you just need to, you know, use the injection feature, then boom, you know, beacon.js will be installed for all your websites. That sounds super convenient. So, if you're already using DNS infrastructure from Cloudflare, you can just set it up for automatic installation. All websites on your zone, they just get it automatically, and they start pulling this information for you. Is that right? Yeah. But not just that. I mean, if you want to, you know, use the automatic setup installation for specific websites, if you're, if you have, like, pro and above plan, then you can use the rules to control those as well. What do those rules allow you to do? Does it allow you to exclude certain pages? How are customers using those? So, you can include or exclude the beacon.js JavaScript. So, we accept a wildcard for those hostnames. So, if you want to exclude, like, you know, for example, like, API dot whatever your domains, you could do, like, API, and then, like, you can use, like, you know, wildcards. Then all the subdomains under APIs will be excluded if you want to do it that way. Or if you have, if you want, like, only the single website to be injected, then you could just, you know, give a specific hostname and to make it include. Got it. So, that's a much more powerful way of managing which websites get the Web Analytics, are enrolled into Web Analytics. So, you mentioned that you can have automatic installation if you have your DNS through Cloudflare. Then you have another option that is if you have pro or above, then you can go and exclude certain areas of your website. But even if you don't have pro or above, or if you don't have DNS, you can still go to the Web Analytics website, grab the beacon that was generated exclusively for you, right? I'm assuming that has some sort of unique identifier for identifying me as a customer. Yes. So, that's what we call site token. And this is very secure because although, you know, the site token, if you install it in your source, that's going to be exposed to everyone. So, everyone can see your snippet, but they cannot actually use that snippet on a different domain because we do a validation check on a backend. Fantastic. So, even though we're collecting the information and the token is available there, no one can really impersonate and upload analytics data or query my data when I'm using this solution. Yeah, exactly. Fantastic. And so, even if I'm a free customer, if I want to enroll only certain portions of my web properties, only certain pages, and for instance, skip API, even if I'm on a free plan, I just put it in manual and I copy that JavaScript snippets and I put it on my website header and that's it. Yeah, that's it. Fantastic. Fantastic. It looks super, super easy. Do you want to show us what it looks like? What kind of data we can see there? Yeah, of course. I think some of our viewers may be really interested in this. I must warn everyone that some of our customers are initially surprised by the fact that our approach, our privacy -first approach, really prevents us from looking at certain metrics that are at table stakes when you're doing the marketing analysis that we mentioned. For instance, a lot of people care about unique visitors. So, knowing whether it's the same person that came into your website five times this week, or if it's the five different people that came once to our website. We don't measure that because we don't have actually any way of identifying one person and knowing that this same person came in today and comes in tomorrow. We don't have a way of doing that. But we also don't feel that it's absolutely necessary for the purpose that we're serving here. That is helping you know how many people are visiting your website and what do they do, what pages do they navigate to, and where they spend most of their time, and where they have the biggest challenges, which is what we're going to talk about later. Do you want to give us that little guided tour, Yong? Yeah, sure. So, web analytics right now you guys are seeing for our awesome blog, Cloudflare.com. So, we show like, you know, this information. And on the site navigation, you see those like clickable, you know, sections. You can click on page views, visits, and we have page load time, and also core web vitals. Do you want me to like, you know, show users on what we have for each pages? We can look a little bit into the main page, but one thing that is worth noting is core web vitals wasn't available to everyone, right? It's somewhat of a new thing for some of our customers. Oh, yes. So, core web vitals, we launched last year sometime around this time, but also we have a huge improvement on the core web vitals as well. Do we want to talk about that now? Yeah, why don't we shift gears and we talk a little bit about the core web vitals, the vitals explorer that we just launched today, right? That's exciting. Yeah. So, for those users who don't know what core web vitals is, so it's an essential metrics to provide the best user experience. So, it is initiated by Google, and there's there's actually a lot more than what we actually showed here using the core web vitals. And how this worked for us is we actually integrated Google's web vitals library directly into our beacon JavaScript. So, and also we are, you know, trying to keep it up to date. So, the latest version is what we currently have, the version 2.1. And among those web vital metrics, there's largest content from paint, FID, which stands for first input delay, CLS for cumulative layout shift. Those three are among the most important metrics, and those are core web vitals. So, the screen that we are showing here, so we have this above sections where we show all the measurements for each, like, core web vitals. So, here we are showing the largest content from paint where we show some of the percentages, whether it's good or not. And then scrolling down, we have the first input delay, and then cumulative layout shifts that's there. So, the speed week, during the speed week, we are introducing what's called vitals explorer. It's labeled as debug view. Basically, this is more for, like, developers. So, before we had this, when you land on this page, you know what's good or not. But then you can't really take any actions because we show these, like, dimensions for these core web vitals performances. But we don't actually show what you can do with these. So, with the debug view, we actually added we are collecting additional metrics. So, we collect additional for example, for LCP, we are collecting these object names. So, before I click it, let me actually briefly explain what the data that we are showing here. So, yeah. Just I know you're on a roll. Just for those in the audience that may not be as comfortable with this. So, when you mentioned that you're using the core web vitals APIs, that means that this is information that is created, that is generated by the browser, right? So, there's a debug view in your developer tools on Chrome, for instance. And it will give you this sort of information. But in a way that is unique to you. And so, it's not something that you that you would know for all other users. It's something that you could run locally and see how your web page performs. And you can see even some breakdowns of what are the sections that are taking the longest. So, here what we're doing is we're bringing this information from the user perspective. Again, this is real user measurement. It's not just us. As you can see there, we're seeing hundreds of counts for some of these things. This is something that literally just launched. But still, we're seeing hundreds of counts and we're at a very high confidence that this initial element is the largest thing that is painting on our website. And so, if it's showing as red, it means that it's so big that it's actually took a very long time to paint. Or longer than we would expect. And so, here what we're doing is we're capturing this information that is generated by your browser. Once again, this is privacy first. So, we have no way of matching this back up to a user. All we do is this sort of aggregation where we can see what country it is, what operating system, what browser. Because those are the things that you want to tackle. Maybe, I don't know, maybe in Sweden, the performance is completely different from the UK that is in turn completely different from San Francisco. And so, this allows us to see how users in different locations, those that are farther away from your origin. Or if you're using some sort of distributed system, then you can see the performance according to those locations as well. And so, here you get all of this information. You can see performance data that is extremely important. Even for marketers, something that a Google study actually mentioned is that the page load time, if it increases from one second to three seconds to load the page, that just increases the bounce rates. The people that just leave your page as soon as they hit it, it increases the bounce rates by 32%. And if it increases from one second to six seconds, it increases the bounce rates by 106%. It's awful. Performance really, really matters for users to have a good experience and in turn for them to feel compelled to stay at your web property and to explore more, to read more about your products or to look at more of the merchandise that you have to sell. So, this is critical. And this is where we want to make the life easiest for our users. So, essentially for developers, for people that want to optimize their webpages and that want their users to really, really have a great experience. And so, Jan, if you want to click on one of those and drill down and show us a little bit more how you would hunt for this impactful thing, how you would pick whether you want to address this as an issue or decide whether this is actually okay, that would be fantastic. Yeah. So, the debug view, we are showing the latest five items that falls under needs improvement or poor. So, you won't see actually a data that falls into good categories. But those are not the ones you want to improve, right? The ones that are already good. Right. You don't want to tackle those. But Google, they suggest to look into 75 percentiles of those metric values. So, these values that are listed on this data table, if you put your cursor over to this info icon, you can see that this is 75 percentile. Just by looking at this, you know, this one's really bad. So, let me just click on this. And then this expands and shows more detail what these objects mean to you. So, this object is actually posted on our site. And, you know, the path, just by looking at the path, you can see that it's an image. It does have a size of 120 kilobytes. And then the metric section here, we show, like, P50, the quantiles, different quantiles for those values. So, P50, P75. So, what this means is, like, the medium value seems to be way less. But then, you know, if you see, like, P99, this is... 20 seconds? Wow. Some people are over a really poor Internet connection. Especially for us serving these big images on desktop clients over slow Internet connections. Right. Fortunately, we're announcing a bunch of optimizations today that we're going to be able to apply here. Oh, yeah. Exactly. Yeah. Buffler images. There's a plug. Yeah. And then you could also, you know, filter by the country or, like, you know, path to see, you know, whether these objects performs well or not in other countries or, you know, other, like, dimensions. But, yeah. Do we want to, like, you know, go to this blog page and then try to see what object this actually is? Do you want to? Yeah. Why not? Show us how it works. Yeah. So, let me copy this path. So, just clicking on this small icon, it's going to be copied onto your clipboard. Let me go to blog .software.com. Yeah. Software images are here. And let me paste the path here. So, now we're onto this page. I'm going to open up the developer tool. You're seeing the developer tool, right, Joel? Yeah. I'm seeing it. Yeah. So, now I will go back. And then I'm actually going to copy this element name. So, this is very useful because we are actually storing the CSS selector name. So, you can come back, go back to the blog site, and you can just type it in, like, document. And then query selector. And then just paste that name there. Yeah. Then. That big boy. Yeah. This is that image. So, if you just look at the size, this size is tremendously big. I don't know why, but we should optimize ourselves, too. We really want these to be pretty. We definitely need to load them on Cloudflare images. Yeah. So, we definitely need to, like, optimize these images. So, this is how you want to, for the LCP. That's fantastic. That's super helpful. Again, this is a tool for developers. You can see the biggest offenders. It's pretty easy to read for most of us that have a little bit of technical expertise. But to go really hunt for it, it's up to the person that actually created that website. Or that is managing that website. Right, Young? This is a tool for developers to really improve your websites. To really give your users the best possible experience. And then, below, you have kind of the same thing for first input delay, right? That's when the user tries to click on something or type something in a box. But nothing really happens for a bit. Is that the case? Yeah. I mean, if you see any, like, delays once you click on something, that's gonna provide, like, bad user experience. So, this mainly is focusing whether, you know, with the first input, is there a delay or not? So, as you see it from here, you're seeing, like, you know, user has been clicked on the body element. And it's somewhat it's creating some delays. The response is not getting back to the user. So, yeah. That's how you need to interpret this. But also, like, we'll keep trying to think about these. And then, we'll, you know, add more improvements and add more data. So, that user can have, like, more meaningful data. Yeah. The count on the right, it means that we have about a dozen not about, but really a dozen measurements for this event. Is that correct? No. So, because, you know, this is only showing whether this first input falls into, you know, these bad categories. Yeah. It's not the all counts. But, yeah. So, we're saying that 12 times this has fallen under the poor category. Right. Or needs improvement. Fantastic. I think this is super helpful, also, because right here, you're seeing a little glimpse of the direction for Web Analytics. Not only is it focused on developers, as I've said way too many times already in this recording. But also, something interesting is that we're trying to give you the full loop. So, you get a measurement, then we grade that measurement. We tell you whether your current performance is actually satisfactory, if users are having a good experience, if their experience is kind of meh, or if your experience is actually pretty poor. And so, we grade it, we measure it, we grade it, and then we give you the information so that you can act upon it. Or at the very least, decide whether you want to act upon it. And this is the powerful thing. If you decide to act on it, then you're already measuring it again. Because we're constantly collecting this from every single visitor, pretty much, to your website. Obviously, we don't keep every single measurement. We keep a good sample of them. But you're getting real user view over this. And let's cover cumulative layout shift real quick. And then, you can tell us also where we can see if these things are improving over time or not? Yes, sure. Of course. So, CLS, let me actually just show you guys a really great example what this is about. So, this is like 12 seconds of video. The user is trying to click on go back, but then, you know, suddenly the layout shift happened. And they clicked on the submitting the order. So, the button moved, right? Yeah. So, they were trying. Yeah, they tried to press go back. But instead, they ended up clicking on submit order. That's pretty terrible. Yeah. It's also terrible when even when you're just looking at the web page and a banner shows up and everything shifts around. So, it's also not great. So, let's look at one of those real quick. And then, we can just look at page load times before we end this segment. We're almost done. Yeah, exactly. So, yeah. So, for this, the element name is just P, which is not that clear which element. But then, actually, if you expand this data table, you can actually see the whole layout information before it shifted and after it shifted, right? So, you can actually see the red colors showing like the top. So, it was 950 pixels from the top and 950 pixels on the y-axis. And then, all of a sudden, it shifted pretty drastically to 1300 on both sides. Yeah, exactly. Is that right? And so, you see the last five measurements here. Last five users that have had this shift. Yeah. You can also click refresh to get the latest. Yeah. Shall we look at page load times real quick? We have about a minute. But I want to make sure that people see this because it's so cool. Yeah, I know. And then, we added this paint timing summary. This has been like, you know, a lot of like feature has been, you know, customer were asking about this a lot. So, we actually added first paint and first content paint here. Do you know the difference between the first paint and first content paint? Tell us about it. One of them has text and the other one doesn't. Is that correct? Well, I can explain more, but if you don't have enough time, you guys can read from the blog post. Awesome blog. Awesome blog. Sending people to our blog post. Yeah, that's really cool. So, essentially here, what you see is when did people see the first stuff on their screen, like the first stuff coming up on their website. Fantastic. So, thanks everyone. Thanks for tuning in and listening to Web Analytics from Cloudflare.