Making RUM Responsive
Vereecke, Tim
Categorizing device types by desktop, mobile and tablet no longer works in 2021. It is oversimplified, meaningless and likely breaks your current performance analysis on a modern responsive website. As #perfmatters we need meaningful monitoring that takes into account the modern web: - Screen dimensions - Device pixel ratios - Image and CSS breakpoints - Connections Keeping it both simple and meaningful is however not easy! Learn about the different approaches and how to apply this to your existing RUM monitoring solutions: be it free (Google Analytics), open source (Boomerang) or commercial.
 Hi, thank you for joining. This session is all about responsive run. This is a very simple technique all of you can apply to get more value out of your run data. My name is Tim and I'm a web performance architect at Akamai and I also run the largest scale modeling website in the world and on a day-to-day basis I'm in touch with real user monitoring and I really like run or real user monitoring. Why? Because it gives me very valuable insights in the performance of my website under real-world conditions. No matter if my visitors are using their cell phone on the train or if they're sitting at home in the sofa using a tablet, I can see how my website behaves under these conditions. So that's great. So I love run. Now my love is not endless and the main reason why it's not endless is it is not responsive. Real user monitoring, all the tools, open source or commercial are very modern and still they don't support responsive design. They support core web vitals. They support single-page apps or some of them can even measure service worker startup time. So all modern techniques, still responsive design, which is not new, is not supported. The closest we can get is this very simplistic classification, desktop mobile tablet. You see this everywhere. Now from my perspective in order to measure, to analyze performance, this is too simplistic. It might have worked 10 years ago when devices looked like this. Today, where large phones can be bigger than small tablets or where large tablets can be bigger than small desktops and where some people have big screens like this, this very simplistic classification no longer works. So in order to get most of your run data, we need in a responsive world, responsive run. And there are two things I will share with you how you can get there and it's actually quite easy. But before we get there, we need to fix a first bias, bias, the device type bias. What do I mean with that? If you're looking at your data, you see every tool has this classification. So 48% of my users are mobile. Now when I zoom in on mobile, in my mind, I make this automated connection that mobile corresponds to cellular. And when I zoom in on desktop, it corresponds to broadband. Now we all know that this is not true. Still in day to day discussions, in day to day blog posts, when we talk about mobile, hey, how is your mobile performance? You will answer in a talk about a phone on a cellular connection. Oh, my mobile performance is much, much slower than desktop. Desktop meaning desktop in combination with broadband. And this is everywhere. Google page speed insights, awesome tool, love it. Here we have two classifications, mobile and desktop. Mobile, if you read the documentation, it's a mid-range phone using a cellular connection. While desktop is a big screen on a fast connection. So it's really everywhere. Now why is this a problem? It's a problem because it can really ruin your analysis. Let me share two examples. This is the connectivity of mobile devices on my website. Now suppose you look at the medium, largest contentful paint or any other timers. What would you look at in this case? Here you see that almost 70% of the users is using a cable connection. That's somebody sitting at home connected to the Wi-Fi. That's still a broadband connection. Now if you're looking at, if you're just focusing on mobile and you're looking at all the data and you think you have no performance problem, you might be wrong. Why? Because you're actually looking at a mobile device on a cable connection at the medium levels. Same for desktop. Many of my customers, they like to look for desktop at the higher percentiles. For example, 90th or 95th percentile. If you do that and you wonder why is my performance on desktop so slow? Look here, 15% is using a cellular connection. What is that? In a world where we could still travel, that's people on the train using their work laptop and connecting to the Wi-Fi of their cellular phone, which remains a cellular connection. Or some of my visitors are really living in the middle of nowhere and the only way to get internet is a cellular modem in their homes. So first thing is before we go into the next steps is make sure that whenever you zoom in on your performance, don't make the mistake to just look at the device type. Take at least into account the device type and the connection. Now, screen quality. The very simplistic classification does not take into account screen quality. And again, 10 years ago, 8 pixel was 8 pixel. In 2021, we have retina screens, some screens on some phones having even 3x or 4x. What does it mean? That the amount of image pixels you can ship in order to have good quality needs to be increased. How do you do that? This is an example from my website, a very simple thumbnail. 10 years ago, that was 160 pixels big. In order to have a good quality on a retina screen, I need to add the source set element. So I specify if you're a retina screen, don't ship the 160 pixels image, ship the 320 pixels image because that's 2x. Now, why does that matter from a performance perspective? You might ask. Here, it's a thumbnail. Who cares? Here is for this thumbnail default, 6 kilobytes, one and a half X is 10 kilobytes and the 2x version is 22 kilobytes. Now, performance difference between 6 and 22, who cares? Now, this is a thumbnail. Suppose you have a search with 50 thumbnails. 6 times 50 is 300 kilobytes. 6 times, sorry, 50 times 22, it's more than 1 megabyte. Will that impact the performance? Does that impact your performance budget? Likely yes. Maybe not on a desktop connection, but on a cellular connection, potentially yes. So how do you get that extra information in RAM? It's very easy. In JavaScript, if you type in window.devicepixelratio in your console, you will get the DPR or device pixel ratio of your screen. So what do I do on my website? I read that variable on every page and I send that to my analytics, both the marketing analytics as well as RAM. And what information do you get? Something like this. So 1x, 2x, 3x, but also more strange values like 2.625. That actually a very popular Samsung phone and many other verres. Like here you even see 4x. Crazy big. Now, if we zoom in on mobile, what do we see? Two things. First, where do you spot 1x? It's not on the screen. And then you see that very strange value 2.549999. You see the craziest DPR values. It also depends on the resolution people set on their screen. So on my screen, I'm looking at now, depending on the resolution, it goes from 2 to 2.2 or a very strange value like 2.14x. So this also brings me to the biggest issue. If you capture the DPR, there's so many different variations. It's a bit complex. So the cardinality, there's so many different variants makes it almost impossible to really analyze. Now, what we need to do here is, is this important information? Yes. But from a website perspective, we can actually simplify this and really make it usable. Let me show you how to do this. So by default, I put, I say that my data layer equals 1x. On my website, I know I only have a 1x, a 1.5x and a 2x versions, meaning a screen of 3x, 4x or 3.75, all the special things. If it's bigger than 1.75, the browser will decide to pick the 2x versions. So the browser picks the DPR, which matches closest to the one you provide, meaning a device pixel ratio of 1.4 will pick the 1.5. A device pixel ratio of 1.622222 will pick the 1.5. So all these different variations, here is a slight reminder. If I take into account this formula, I get this. Because in the end, I don't care about the exact device pixel ratio. I care about how many bytes do I ship, which images do I ship? And they're basically just three variants. So my home page has three variants, the 1x version, the 2x version and the 1.5x version. Now, DPR is, if we zoom in on mobile, what do you see? All these variations on the left become this very simple 2x version. So what did I learn from this? That 1x on mobile is dead. Now, that will allow me to do two things on my website. First is all my hero images, the current 360 pixels variants of my hero images. I will remove them. There is no need for them. So that will, I have two million different product images on my website. So that means I can remove two million images times 360 pixels. That's one thing. The other benefit is that the chance that the 1x version is in the cache of my CDN is actually low. Why? There is so few traffic. So I can actually make the trade off. Isn't it faster to serve the 1.5x version from cache? Which is, yes, a little bit bigger versus sending the 1. So those are the analysis you can do. Why? Because you have the data. Now, screen quality is one thing. Another thing we need to look at is screen dimensions. My first idea was, you know what, we have desktop tablet mobile, too simplistic. You know what, let's look at the screen dimensions. And this is a screenshot from Google Data Studio where I look into my Google Analytics and put many other tools to give you this. So very detailed, great. Now, again here, first problem, way too many values to make it easy to consume, to make it easy to do some performance analysis. Another issue with just looking at the physical device with is resizing windows. What if on a large screen, somebody puts two screens next to each other? Are you downloading the big version of your website or maybe the smaller version of the website? Same is when you pick your phone in Portrait Mode or in Zoom Mode, that might be a different version of the website you brought. And purely looking at the physical width doesn't give you the full picture. And then a third thing is Enforce Desktop. People on the phone, they use the mobile version. People on the desktop, they use the desktop version. And then you have all these different tablets and they're sitting somewhere in between. And many of my users, I have a feature where they can enforce the full desktop version and some people prefer the full desktop version, some people prefer the mobile version or something in between. Again, there, if you're just looking at the physical width, I can't detect it. So good thing is the solution is again very, very simple. Let me explain. This is my website. It doesn't matter, don't look at the content, but this is, I have 500,000 of these product pages. And from all these hundreds of different device widths or device screen sizes, from a performance perspective, we can actually simplify this. This is now a screenshot from a very large screen. If the screen is a little bit smaller, what happens? You just have the margin which becomes a little bit smaller. Make it a little bit smaller, the same. The content in the middle stays the same. It's still the same image, the same amount of images, the same content, everything. So all these different variations, in the end, I serve the same version. And I give these versions a name. So that's 720 pixels. That's for the main content area and a large sidebar. Same here. That's still the 720 pixels with a large sidebar. So it's the same variant I ship to the end user. It's only at a certain point in time that there is not enough space for the large sidebar. So I have a 720 pixels. That's still the same content with a small sidebar. And what are some differences is I will serve different ads, different sizes, different types of ads. So I want to look at the performance there. If we make the screen a little bit smaller, at a certain point in time the sidebar will go away. If you make the screen a little bit smaller, then the picture element and the world kick in. So I will no longer ship the large 720 pixels image. I will ship a 540 pixels image. And then if you make it even smaller, you'll be at the 360 pixels version. So if you look, if you take into account all these different device types and you flip that into what version of my website, what breakpoint of my website am I actually shipping, then it becomes much, much easier. Let me show you how I did that on my website. So I take into account, I call that the design breakpoint, and it looks at the scroll width. So not the device width, it looks at the scroll width. Next, what do I do? I take that value and I put them into buckets. So every screen larger than 1080, I ship the same version 720 large between 767 and 700s, that's 70, 20 small, et cetera. And at the end, if it's smaller than 500 pixels, it's a 360 no version. Key here is don't exaggerate. Or take the key breakpoints where you actually ship other data. For example, I have a 360 and a 400 breakpoint in my CSS. And the only difference is that I changed a bit the font size. I didn't take that into a, I didn't use that as a design breakpoint. Otherwise, you just have way too many variants. So how does that look? This screenshot from my Ramp tool. And you see that 54% of my users uses the full version. I don't know which screen, large, very large, super large, resized, that's the version. So it allows me to look at what is the performance of my website in this specific version. If we then zoom in on mobile, just out of curiosity, what do we see? 94% uses a 360 pixels no version. But still here, suppose you're looking at the 95th percentile on mobile. Why is that so much slower than the 75th percentile or the medium percentile? What do you see here? In this case, it's likely because you ship 700, you ship the 720 pixels image variants because this is users enabling the desktop motors. So if you don't have those insights, you can be really on the wrong foot with your analysis or even come to the wrong conclusions. What is also tells me is that all the work I did on the 720 no and the 720 large on for mobile does not matter. This is the last screenshot before I want to finish. This shows you ampulse around where I use this in action. So I zoom in on mobile and cellular because I want to look at what interests me. And then I can zoom in on, in this case, you're looking at the deep design breakpoints, but I can do the same for DPR, the earlier thing. And I can validate how many bytes do I ship to the 720 pixels version? How many bytes do I ship to the 360 pixels version? Because it will differ. Your performance budget might be perfect for the 360 pixels one, but you might have, you might exceed that on another design breakpoint in combination with DPR. So to conclude, responsive run is an easy way to get much more value out of your data in a responsive world. What do you need to do? You take the device classification, which is available everywhere. You take the connection, which is likely available everywhere. And then on top of that, you add two additional dimensions. One is your image breakpoints, one X2X3X. And the design breakpoints, what versions or variants of the image of the website am I serving to my end users? So with that, I would say thank you for your time. After any questions or feedback, we should still have around three minutes to do that. Thank you.
 Hi, thank you for joining. This session is all about responsive run. This is a very  simple technique all of you can apply to get more value out of your run data. My name is  Tim and I'm a web performance architect at Akamai and I also run the largest scale modeling website  in the world and on a day-to-day basis I'm in touch with real user monitoring and I really like  run or real user monitoring. Why? Because it gives me very valuable insights in the performance of  my website under real-world conditions. No matter if my visitors are using their cell phone on the  train or if they're sitting at home in the sofa using a tablet, I can see how my website behaves  under these conditions. So that's great. So I love run. Now my love is not endless and the main  reason why it's not endless is it is not responsive. Real user monitoring, all the tools, open source  or commercial are very modern and still they don't support responsive design. They support  core web vitals. They support single-page apps or some of them can even measure service worker  startup time. So all modern techniques, still responsive design, which is not new, is not  supported. The closest we can get is this very simplistic classification, desktop mobile tablet.  You see this everywhere. Now from my perspective in order to measure, to analyze performance,  this is too simplistic. It might have worked 10 years ago when devices looked like this. Today,  where large phones can be bigger than small tablets or where large tablets can be bigger  than small desktops and where some people have big screens like this, this very simplistic  classification no longer works. So in order to get most of your run data, we need in a responsive  world, responsive run. And there are two things I will share with you how you can get there  and it's actually quite easy. But before we get there, we need to fix a first bias, bias,  the device type bias. What do I mean with that? If you're looking at your data, you see every  tool has this classification. So 48% of my users are mobile. Now when I zoom in on mobile,  in my mind, I make this automated connection that mobile corresponds to cellular. And when  I zoom in on desktop, it corresponds to broadband. Now we all know that this is not true. Still  in day to day discussions, in day to day blog posts, when we talk about mobile, hey, how  is your mobile performance? You will answer in a talk about a phone on a cellular connection.  Oh, my mobile performance is much, much slower than desktop. Desktop meaning desktop in combination  with broadband. And this is everywhere. Google page speed insights, awesome tool, love it.  Here we have two classifications, mobile and desktop. Mobile, if you read the documentation,  it's a mid-range phone using a cellular connection. While desktop is a big screen on a fast connection.  So it's really everywhere. Now why is this a problem? It's a problem because it can really  ruin your analysis. Let me share two examples. This is the connectivity of mobile devices  on my website. Now suppose you look at the medium, largest contentful paint or any other  timers. What would you look at in this case? Here you see that almost 70% of the users  is using a cable connection. That's somebody sitting at home connected to the Wi-Fi. That's  still a broadband connection. Now if you're looking at, if you're just focusing on mobile  and you're looking at all the data and you think you have no performance problem, you  might be wrong. Why? Because you're actually looking at a mobile device on a cable connection  at the medium levels. Same for desktop. Many of my customers, they like to look for desktop  at the higher percentiles. For example, 90th or 95th percentile. If you do that and you  wonder why is my performance on desktop so slow? Look here, 15% is using a cellular connection.  What is that? In a world where we could still travel, that's people on the train using their  work laptop and connecting to the Wi-Fi of their cellular phone, which remains a cellular  connection. Or some of my visitors are really living in the middle of nowhere and the only  way to get internet is a cellular modem in their homes.  So first thing is before we go into the next steps is make sure that whenever you zoom  in on your performance, don't make the mistake to just look at the device type. Take at least  into account the device type and the connection. Now, screen quality. The very simplistic classification  does not take into account screen quality. And again, 10 years ago, 8 pixel was 8 pixel.  In 2021, we have retina screens, some screens on some phones having even 3x or 4x. What  does it mean? That the amount of image pixels you can ship in order to have good quality  needs to be increased. How do you do that? This is an example from my website, a very  simple thumbnail. 10 years ago, that was 160 pixels big. In order to have a good quality  on a retina screen, I need to add the source set element. So I specify if you're a retina  screen, don't ship the 160 pixels image, ship the 320 pixels image because that's 2x. Now,  why does that matter from a performance perspective? You might ask. Here, it's a thumbnail. Who  cares? Here is for this thumbnail default, 6 kilobytes, one and a half X is 10 kilobytes  and the 2x version is 22 kilobytes. Now, performance difference between 6 and 22, who cares? Now,  this is a thumbnail. Suppose you have a search with 50 thumbnails. 6 times 50 is 300 kilobytes.  6 times, sorry, 50 times 22, it's more than 1 megabyte. Will that impact the performance?  Does that impact your performance budget? Likely yes. Maybe not on a desktop connection,  but on a cellular connection, potentially yes. So how do you get that extra information  in RAM? It's very easy. In JavaScript, if you type in window.devicepixelratio in your  console, you will get the DPR or device pixel ratio of your screen. So what do I do on my  website? I read that variable on every page and I send that to my analytics, both the  marketing analytics as well as RAM. And what information do you get? Something like this.  So 1x, 2x, 3x, but also more strange values like 2.625. That actually a very popular Samsung  phone and many other verres. Like here you even see 4x. Crazy big. Now, if we zoom in  on mobile, what do we see? Two things. First, where do you spot 1x? It's not on the screen.  And then you see that very strange value 2.549999. You see the craziest DPR values. It also depends  on the resolution people set on their screen. So on my screen, I'm looking at now, depending  on the resolution, it goes from 2 to 2.2 or a very strange value like 2.14x. So this  also brings me to the biggest issue. If you capture the DPR, there's so many different  variations. It's a bit complex. So the cardinality, there's so many different variants makes it  almost impossible to really analyze. Now, what we need to do here is, is this important  information? Yes. But from a website perspective, we can actually simplify this and really make  it usable. Let me show you how to do this. So by default, I put, I say that my data layer  equals 1x. On my website, I know I only have a 1x, a 1.5x and a 2x versions, meaning a  screen of 3x, 4x or 3.75, all the special things. If it's bigger than 1.75, the browser  will decide to pick the 2x versions. So the browser picks the DPR, which matches closest  to the one you provide, meaning a device pixel ratio of 1.4 will pick the 1.5. A device pixel  ratio of 1.622222 will pick the 1.5. So all these different variations, here is a slight  reminder. If I take into account this formula, I get this. Because in the end, I don't care  about the exact device pixel ratio. I care about how many bytes do I ship, which images  do I ship? And they're basically just three variants. So my home page has three variants,  the 1x version, the 2x version and the 1.5x version. Now, DPR is, if we zoom in on mobile,  what do you see? All these variations on the left become this very simple 2x version. So  what did I learn from this? That 1x on mobile is dead. Now, that will allow me to do two  things on my website. First is all my hero images, the current 360 pixels variants of  my hero images. I will remove them. There is no need for them. So that will, I have  two million different product images on my website. So that means I can remove two million  images times 360 pixels. That's one thing. The other benefit is that the chance that  the 1x version is in the cache of my CDN is actually low. Why? There is so few traffic.  So I can actually make the trade off. Isn't it faster to serve the 1.5x version from cache?  Which is, yes, a little bit bigger versus sending the 1. So those are the analysis you can do.  Why? Because you have the data. Now, screen quality is one thing. Another thing we need  to look at is screen dimensions. My first idea was, you know what, we have desktop tablet  mobile, too simplistic. You know what, let's look at the screen dimensions. And this is  a screenshot from Google Data Studio where I look into my Google Analytics and put many  other tools to give you this. So very detailed, great. Now, again here, first problem, way  too many values to make it easy to consume, to make it easy to do some performance analysis.  Another issue with just looking at the physical device with is resizing windows. What if on  a large screen, somebody puts two screens next to each other? Are you downloading the  big version of your website or maybe the smaller version of the website? Same is when you pick  your phone in Portrait Mode or in Zoom Mode, that might be a different version of the website  you brought. And purely looking at the physical width doesn't give you the full picture. And  then a third thing is Enforce Desktop. People on the phone, they use the mobile version.  People on the desktop, they use the desktop version. And then you have all these different  tablets and they're sitting somewhere in between. And many of my users, I have a feature where  they can enforce the full desktop version and some people prefer the full desktop version,  some people prefer the mobile version or something in between. Again, there, if you're just looking  at the physical width, I can't detect it. So good thing is the solution is again very, very  simple. Let me explain. This is my website. It doesn't matter, don't look at the content,  but this is, I have 500,000 of these product pages. And from all these hundreds of different  device widths or device screen sizes, from a performance perspective, we can actually  simplify this. This is now a screenshot from a very large screen. If the screen is a little  bit smaller, what happens? You just have the margin which becomes a little bit smaller.  Make it a little bit smaller, the same. The content in the middle stays the same. It's  still the same image, the same amount of images, the same content, everything. So all these  different variations, in the end, I serve the same version. And I give these versions  a name. So that's 720 pixels. That's for the main content area and a large sidebar. Same  here. That's still the 720 pixels with a large sidebar. So it's the same variant I ship to  the end user. It's only at a certain point in time that there is not enough space for  the large sidebar. So I have a 720 pixels. That's still the same content with a small  sidebar. And what are some differences is I will serve different ads, different sizes,  different types of ads. So I want to look at the performance there. If we make the screen  a little bit smaller, at a certain point in time the sidebar will go away. If you make  the screen a little bit smaller, then the picture element and the world kick in. So  I will no longer ship the large 720 pixels image. I will ship a 540 pixels image. And  then if you make it even smaller, you'll be at the 360 pixels version. So if you look,  if you take into account all these different device types and you flip that into what version  of my website, what breakpoint of my website am I actually shipping, then it becomes much,  much easier. Let me show you how I did that on my website. So I take into account, I call  that the design breakpoint, and it looks at the scroll width. So not the device width,  it looks at the scroll width. Next, what do I do? I take that value and I put them into  buckets. So every screen larger than 1080, I ship the same version 720 large between  767 and 700s, that's 70, 20 small, et cetera. And at the end, if it's smaller than 500 pixels,  it's a 360 no version. Key here is don't exaggerate. Or take the key breakpoints where you actually  ship other data. For example, I have a 360 and a 400 breakpoint in my CSS. And the only  difference is that I changed a bit the font size. I didn't take that into a, I didn't use  that as a design breakpoint. Otherwise, you just have way too many variants. So how does  that look? This screenshot from my Ramp tool. And you see that 54% of my users uses the  full version. I don't know which screen, large, very large, super large, resized, that's the  version. So it allows me to look at what is the performance of my website in this specific  version. If we then zoom in on mobile, just out of curiosity, what do we see? 94% uses  a 360 pixels no version. But still here, suppose you're looking at the 95th percentile on mobile.  Why is that so much slower than the 75th percentile or the medium percentile? What do you see  here? In this case, it's likely because you ship 700, you ship the 720 pixels image variants  because this is users enabling the desktop motors. So if you don't have those insights,  you can be really on the wrong foot with your analysis or even come to the wrong conclusions.  What is also tells me is that all the work I did on the 720 no and the 720 large on for  mobile does not matter. This is the last screenshot before I want to finish. This shows you ampulse  around where I use this in action. So I zoom in on mobile and cellular because I want to  look at what interests me. And then I can zoom in on, in this case, you're looking at  the deep design breakpoints, but I can do the same for DPR, the earlier thing. And I can validate  how many bytes do I ship to the 720 pixels version? How many bytes do I ship to the 360 pixels  version? Because it will differ. Your performance budget might be perfect for the 360 pixels one,  but you might have, you might exceed that on another design breakpoint in combination with DPR.  So to conclude, responsive run is an easy way to get much more value out of your data in a  responsive world. What do you need to do? You take the device classification, which is available  everywhere. You take the connection, which is likely available everywhere. And then on top of  that, you add two additional dimensions. One is your image breakpoints, one X2X3X. And the design  breakpoints, what versions or variants of the image of the website am I serving to my end users?  So with that, I would say thank you for your time. After any questions or feedback, we should still  have around three minutes to do that. Thank you.
webperf_making_rum_responsive_0_167.png webperf_making_rum_responsive_168_575.png webperf_making_rum_responsive_576_2411.png webperf_making_rum_responsive_2412_3431.png webperf_making_rum_responsive_3432_3587.png webperf_making_rum_responsive_3588_4079.png webperf_making_rum_responsive_4080_4463.png webperf_making_rum_responsive_4464_6059.png webperf_making_rum_responsive_6060_8903.png webperf_making_rum_responsive_8904_8951.png webperf_making_rum_responsive_8952_9107.png webperf_making_rum_responsive_9108_12587.png webperf_making_rum_responsive_12588_13775.png webperf_making_rum_responsive_13776_13895.png webperf_making_rum_responsive_13896_14291.png webperf_making_rum_responsive_14292_16463.png webperf_making_rum_responsive_16464_18659.png webperf_making_rum_responsive_18660_18743.png webperf_making_rum_responsive_18744_21311.png webperf_making_rum_responsive_21312_23075.png webperf_making_rum_responsive_23076_23735.png webperf_making_rum_responsive_23736_24803.png webperf_making_rum_responsive_24804_28571.png webperf_making_rum_responsive_28572_30935.png webperf_making_rum_responsive_30936_31665.png
Hi, thank you for joining. This session is all about responsive run. This is a very simple technique all of you can apply to get more value out of your run data. My name is Tim and I'm a web performance architect at Akamai and I also run the largest scale modeling website in the world and on a day-to-day basis I'm in touch with real user monitoring and I really like run or real user monitoring. Why? Because it gives me very valuable insights in the performance of my website under real-world conditions. No matter if my visitors are using their cell phone on the train or if they're sitting at home in the sofa using a tablet, I can see how my website behaves under these conditions. So that's great. So I love run. Now my love is not endless and the main reason why it's not endless is it is not responsive. Real user monitoring, all the tools, open source or commercial are very modern and still they don't support responsive design. They support core web vitals. They support single-page apps or some of them can even measure service worker startup time. So all modern techniques, still responsive design, which is not new, is not supported. The closest we can get is this very simplistic classification, desktop mobile tablet. You see this everywhere. Now from my perspective in order to measure, to analyze performance, this is too simplistic. It might have worked 10 years ago when devices looked like this. Today, where large phones can be bigger than small tablets or where large tablets can be bigger than small desktops and where some people have big screens like this, this very simplistic classification no longer works. So in order to get most of your run data, we need in a responsive world, responsive run. And there are two things I will share with you how you can get there and it's actually quite easy. But before we get there, we need to fix a first bias, bias, the device type bias. What do I mean with that? If you're looking at your data, you see every tool has this classification. So 48% of my users are mobile. Now when I zoom in on mobile, in my mind, I make this automated connection that mobile corresponds to cellular. And when I zoom in on desktop, it corresponds to broadband. Now we all know that this is not true. Still in day to day discussions, in day to day blog posts, when we talk about mobile, hey, how is your mobile performance? You will answer in a talk about a phone on a cellular connection. Oh, my mobile performance is much, much slower than desktop. Desktop meaning desktop in combination with broadband. And this is everywhere. Google page speed insights, awesome tool, love it. Here we have two classifications, mobile and desktop. Mobile, if you read the documentation, it's a mid-range phone using a cellular connection. While desktop is a big screen on a fast connection. So it's really everywhere. Now why is this a problem? It's a problem because it can really ruin your analysis. Let me share two examples. This is the connectivity of mobile devices on my website. Now suppose you look at the medium, largest contentful paint or any other timers. What would you look at in this case? Here you see that almost 70% of the users is using a cable connection. That's somebody sitting at home connected to the Wi-Fi. That's still a broadband connection. Now if you're looking at, if you're just focusing on mobile and you're looking at all the data and you think you have no performance problem, you might be wrong. Why? Because you're actually looking at a mobile device on a cable connection at the medium levels. Same for desktop. Many of my customers, they like to look for desktop at the higher percentiles. For example, 90th or 95th percentile. If you do that and you wonder why is my performance on desktop so slow? Look here, 15% is using a cellular connection. What is that? In a world where we could still travel, that's people on the train using their work laptop and connecting to the Wi-Fi of their cellular phone, which remains a cellular connection. Or some of my visitors are really living in the middle of nowhere and the only way to get internet is a cellular modem in their homes. So first thing is before we go into the next steps is make sure that whenever you zoom in on your performance, don't make the mistake to just look at the device type. Take at least into account the device type and the connection. Now, screen quality. The very simplistic classification does not take into account screen quality. And again, 10 years ago, 8 pixel was 8 pixel. In 2021, we have retina screens, some screens on some phones having even 3x or 4x. What does it mean? That the amount of image pixels you can ship in order to have good quality needs to be increased. How do you do that? This is an example from my website, a very simple thumbnail. 10 years ago, that was 160 pixels big. In order to have a good quality on a retina screen, I need to add the source set element. So I specify if you're a retina screen, don't ship the 160 pixels image, ship the 320 pixels image because that's 2x. Now, why does that matter from a performance perspective? You might ask. Here, it's a thumbnail. Who cares? Here is for this thumbnail default, 6 kilobytes, one and a half X is 10 kilobytes and the 2x version is 22 kilobytes. Now, performance difference between 6 and 22, who cares? Now, this is a thumbnail. Suppose you have a search with 50 thumbnails. 6 times 50 is 300 kilobytes. 6 times, sorry, 50 times 22, it's more than 1 megabyte. Will that impact the performance? Does that impact your performance budget? Likely yes. Maybe not on a desktop connection, but on a cellular connection, potentially yes. So how do you get that extra information in RAM? It's very easy. In JavaScript, if you type in window.devicepixelratio in your console, you will get the DPR or device pixel ratio of your screen. So what do I do on my website? I read that variable on every page and I send that to my analytics, both the marketing analytics as well as RAM. And what information do you get? Something like this. So 1x, 2x, 3x, but also more strange values like 2.625. That actually a very popular Samsung phone and many other verres. Like here you even see 4x. Crazy big. Now, if we zoom in on mobile, what do we see? Two things. First, where do you spot 1x? It's not on the screen. And then you see that very strange value 2.549999. You see the craziest DPR values. It also depends on the resolution people set on their screen. So on my screen, I'm looking at now, depending on the resolution, it goes from 2 to 2.2 or a very strange value like 2.14x. So this also brings me to the biggest issue. If you capture the DPR, there's so many different variations. It's a bit complex. So the cardinality, there's so many different variants makes it almost impossible to really analyze. Now, what we need to do here is, is this important information? Yes. But from a website perspective, we can actually simplify this and really make it usable. Let me show you how to do this. So by default, I put, I say that my data layer equals 1x. On my website, I know I only have a 1x, a 1.5x and a 2x versions, meaning a screen of 3x, 4x or 3.75, all the special things. If it's bigger than 1.75, the browser will decide to pick the 2x versions. So the browser picks the DPR, which matches closest to the one you provide, meaning a device pixel ratio of 1.4 will pick the 1.5. A device pixel ratio of 1.622222 will pick the 1.5. So all these different variations, here is a slight reminder. If I take into account this formula, I get this. Because in the end, I don't care about the exact device pixel ratio. I care about how many bytes do I ship, which images do I ship? And they're basically just three variants. So my home page has three variants, the 1x version, the 2x version and the 1.5x version. Now, DPR is, if we zoom in on mobile, what do you see? All these variations on the left become this very simple 2x version. So what did I learn from this? That 1x on mobile is dead. Now, that will allow me to do two things on my website. First is all my hero images, the current 360 pixels variants of my hero images. I will remove them. There is no need for them. So that will, I have two million different product images on my website. So that means I can remove two million images times 360 pixels. That's one thing. The other benefit is that the chance that the 1x version is in the cache of my CDN is actually low. Why? There is so few traffic. So I can actually make the trade off. Isn't it faster to serve the 1.5x version from cache? Which is, yes, a little bit bigger versus sending the 1. So those are the analysis you can do. Why? Because you have the data. Now, screen quality is one thing. Another thing we need to look at is screen dimensions. My first idea was, you know what, we have desktop tablet mobile, too simplistic. You know what, let's look at the screen dimensions. And this is a screenshot from Google Data Studio where I look into my Google Analytics and put many other tools to give you this. So very detailed, great. Now, again here, first problem, way too many values to make it easy to consume, to make it easy to do some performance analysis. Another issue with just looking at the physical device with is resizing windows. What if on a large screen, somebody puts two screens next to each other? Are you downloading the big version of your website or maybe the smaller version of the website? Same is when you pick your phone in Portrait Mode or in Zoom Mode, that might be a different version of the website you brought. And purely looking at the physical width doesn't give you the full picture. And then a third thing is Enforce Desktop. People on the phone, they use the mobile version. People on the desktop, they use the desktop version. And then you have all these different tablets and they're sitting somewhere in between. And many of my users, I have a feature where they can enforce the full desktop version and some people prefer the full desktop version, some people prefer the mobile version or something in between. Again, there, if you're just looking at the physical width, I can't detect it. So good thing is the solution is again very, very simple. Let me explain. This is my website. It doesn't matter, don't look at the content, but this is, I have 500,000 of these product pages. And from all these hundreds of different device widths or device screen sizes, from a performance perspective, we can actually simplify this. This is now a screenshot from a very large screen. If the screen is a little bit smaller, what happens? You just have the margin which becomes a little bit smaller. Make it a little bit smaller, the same. The content in the middle stays the same. It's still the same image, the same amount of images, the same content, everything. So all these different variations, in the end, I serve the same version. And I give these versions a name. So that's 720 pixels. That's for the main content area and a large sidebar. Same here. That's still the 720 pixels with a large sidebar. So it's the same variant I ship to the end user. It's only at a certain point in time that there is not enough space for the large sidebar. So I have a 720 pixels. That's still the same content with a small sidebar. And what are some differences is I will serve different ads, different sizes, different types of ads. So I want to look at the performance there. If we make the screen a little bit smaller, at a certain point in time the sidebar will go away. If you make the screen a little bit smaller, then the picture element and the world kick in. So I will no longer ship the large 720 pixels image. I will ship a 540 pixels image. And then if you make it even smaller, you'll be at the 360 pixels version. So if you look, if you take into account all these different device types and you flip that into what version of my website, what breakpoint of my website am I actually shipping, then it becomes much, much easier. Let me show you how I did that on my website. So I take into account, I call that the design breakpoint, and it looks at the scroll width. So not the device width, it looks at the scroll width. Next, what do I do? I take that value and I put them into buckets. So every screen larger than 1080, I ship the same version 720 large between 767 and 700s, that's 70, 20 small, et cetera. And at the end, if it's smaller than 500 pixels, it's a 360 no version. Key here is don't exaggerate. Or take the key breakpoints where you actually ship other data. For example, I have a 360 and a 400 breakpoint in my CSS. And the only difference is that I changed a bit the font size. I didn't take that into a, I didn't use that as a design breakpoint. Otherwise, you just have way too many variants. So how does that look? This screenshot from my Ramp tool. And you see that 54% of my users uses the full version. I don't know which screen, large, very large, super large, resized, that's the version. So it allows me to look at what is the performance of my website in this specific version. If we then zoom in on mobile, just out of curiosity, what do we see? 94% uses a 360 pixels no version. But still here, suppose you're looking at the 95th percentile on mobile. Why is that so much slower than the 75th percentile or the medium percentile? What do you see here? In this case, it's likely because you ship 700, you ship the 720 pixels image variants because this is users enabling the desktop motors. So if you don't have those insights, you can be really on the wrong foot with your analysis or even come to the wrong conclusions. What is also tells me is that all the work I did on the 720 no and the 720 large on for mobile does not matter. This is the last screenshot before I want to finish. This shows you ampulse around where I use this in action. So I zoom in on mobile and cellular because I want to look at what interests me. And then I can zoom in on, in this case, you're looking at the deep design breakpoints, but I can do the same for DPR, the earlier thing. And I can validate how many bytes do I ship to the 720 pixels version? How many bytes do I ship to the 360 pixels version? Because it will differ. Your performance budget might be perfect for the 360 pixels one, but you might have, you might exceed that on another design breakpoint in combination with DPR. So to conclude, responsive run is an easy way to get much more value out of your data in a responsive world. What do you need to do? You take the device classification, which is available everywhere. You take the connection, which is likely available everywhere. And then on top of that, you add two additional dimensions. One is your image breakpoints, one X2X3X. And the design breakpoints, what versions or variants of the image of the website am I serving to my end users? So with that, I would say thank you for your time. After any questions or feedback, we should still have around three minutes to do that. Thank you.
about responsive run. This is a very simple open source or commercial are very modern and simplistic classification, desktop mobile tablet. like this, this very simplistic classification no longer works. So in order to get most of your run data, we need in a responsive world, responsive least into account the device type and the not on a desktop connection, but on a cellular how to do this. So by default, I put, I say that into my Google Analytics and put many other tools make it easy to consume, to make it easy to do some performance analysis. Another issue with different ads, different sizes, different types