Web Performance: The African Case

Hello. So, like you see today, we will talk about web performance and the African case. My name is Eyo Belwen, I'm the CTO of the Academy at Servio. And today we will talk about inclusive technology.

So, before starting our talk, it will be great to have some context in Africa and how the internet penetration is there. So, we'll start with a graph here that shows us the internet penetration by region. We can see in the middle the world average. The world average is between 60% and 70%. And we can see that South Africa and Northern Africa are doing good. When we are talking about Northern Africa, it's generally Morocco, Algeria, Tunisia. In Southern Africa, it's South Africa. But we can see in the middle, Africa and the Eastern one, it's not doing that good. So, we can see that there is no internet penetration there. Okay.

And not only that, we can see here with this graph that the web traffic there is shared by, we can see in this graph, the web traffic shared by device type in Africa. So, here what we can see is that the majority of Africans there are relying on mobile devices. 75% are using mobile devices to access internet. So, why I'm talking about that? What we can see here is there is no fiber optic, for example. So, everyone will use his mobile phone to access internet. And the problem here is that he should pay for each megabyte he will consume. It's not like using ADCEL and limited internet with ADCEL or fiber optic. It's only mobile devices that you should pay for each megabyte you will consume. Okay.

And we can see here, for example, the price for 15 gigabyte per month. So, we'll imagine that everyone will use only 15 gigabyte per month. And when we are talking about 15 gigabytes, I think, for example, one hour video of YouTube, it will take between 500 megabytes and 500 megabytes or one gigabyte. Okay. So, imagine if someone is using 15 gigabytes, it will not take him long. It will consume it maybe in three or five days. And we can see here with this graph the minimum wage also.

For example, we can take Burkina Faso. The price for 15 gigabyte per month, it's nearly the price of the minimum wage there. So, he should pay all his salary to consume only 15 gigabyte per month. You can see with me, for example, the Cap Verde. The minimum wage is three times the price of 15 gigabyte of internet. Togo, it's the same thing. And we can go further. For example, if we see countries like Zimbabwe or Malawi, we can see that the price, for example, in Equatorial Guinea, the price for 15 gigabyte of internet per month is three times the minimum wage. So, to pay 15 gigabyte per month, he should pay three month of salary. That's not good.

So, why I'm talking about that? I'm talking about that because in web performance, sometimes we in Europe or in the United States, we don't care about the internet that we use because it's unlimited. Okay. So, we don't care when we are doing our sites about the JavaScript that we should deliver to the client side about optimization because we don't need that. We have 5G or we have fiber optics. So, we don't need to do that. But in other parts of the world, there is some people that care about every megabyte of internet because they are paying their money for that. And when we are saying paying their money, it's not a small thing, but it's their salary. So, for example, here, someone in Zimbabwe will not consume 15 gigabyte per month. They will only consume maybe 500 megabyte or nothing. So, the way I'm talking about that is that when we are trying to work on our websites, we should think about other people, not only Europe or United States, but there is some other parts in the world that we should care about them when we are working on our websites.

Here, for example, we can see statistics about the phones used in Africa. So, you can see that Apple, for example, is not that used there. So, for example, in Zimbabwe, Nigeria, it's not even 5% or 3%. Okay. And the more usable phones are the affordable phones like Tecno, E-Tel, Xiaomi, Huawei, and affordable Samsungs. That's the majority that people are using there. So, why I'm saying that is because when you're using an iPhone or a Samsung Ultra or something like that, you don't care about the resources because these phones have a good hardware configuration. Okay. So, when you're using Google Chrome, you're using some applications. You don't care about the performance of the phone because you have good hardware.

Okay. But when you are using affordable smartphones, you should not have multiple tabs of Google Chrome because you will consume all the resources that you have and that not will be good. Okay. And if you have in every tab, for example, the websites deliver a lot of JavaScript that will consume more CPUs, more RAM, that's not good.

Okay. So, there's two things. The first thing is the internet connections that is not good in Africa and the hardware. It's not that good. So, we should care about these two things when we are working on our websites.

And not only that, so there's not only Africa. We can also think about web performance in our context in Europe or in the United States. If you are, for example, you want to go to a restaurant, you order a simple pizza, but the waiter told you that you should wait 45 minutes for it and you should pay $100. That's not a good user experience. Okay. So, we will write bad reviews. You will talk to your friends to never come to this restaurant and you will search for another restaurant that will give you the same pizza in maybe 15 or in 10 minutes. And with the paying less money. That's the thing. And that's the same thing in our websites.

If you're using an e-commerce website that took a lot of time to deliver the page that you want to use, you will move on, you will search for another one. You will maybe forget the page that you are using. And that's not a good experience. Okay.

So, and how we are here now. What I'm trying to talk about is the technical things. So, after using PHP, using jQuery, we came with a good invention. It was the single page application. Okay. So, what we should understand is how the single page application works. It's very easy.

In the first time we deliver in our page an HTML that is that contain nothing. Okay. And we wait for our JavaScript to come. We execute the JavaScript, we render the page, and now our page is here and it's interactive. Okay. That's good. But there is a problem.

The client or the user should wait all this time for his page to be delivered. Okay. But what we try to do is to improve this user experience with hydration. So, what we do is that we deliver a big HTML that contain all the page, but this page is not interactive. It appears faster, but it's not interactive. And we should wait for this JavaScript. We should execute this JavaScript and we should do the reconciliation, the hydration, so our page is interactive.

The problem here is what? With single page application, we are delivering all the JavaScript that our website needs to function. Okay. And if you are, for example, in Zimbabwe, you will deliver to the guy a lot of JavaScript that he will not need, maybe 13, maybe 14 megabytes of JavaScript that he will not need. And that's not a good for him because he will pay for this megabytes. Okay. So, what we should do. It's not like, for example, hydration. Hydration is good, but it's only tricking the user. And in the end, he will get all the JavaScript. He will download and execute all the JavaScript. And I'm talking about the download of the JavaScript. It's not good for his internet because he will consume a lot of megabytes. And also the execution. When you will execute all the JavaScript of the website, he will consume more resources of his hardware. And that's not good for him. So, what we should try is to deliver less JavaScript to the client side in order to not download a lot of JavaScript and also to execute the less amount of JavaScript to not impact the resources of our user.

Okay. And that's why we are, we will talk about here, we will talk about, and that's, we can explain that with this correlation, for example, because in our websites these days, we need more interactivity. We have a lot of buttons. We have a lot of graphs. So, when we need more interactivity in our websites, we should deliver more JavaScript. And when we deliver more JavaScript, we download more JavaScript. We execute more JavaScript. So, we will have less performance on our websites.

So, the talk today is about resumability. How we can improve this process. We can improve this process by delivering nothing to the client side. Here, we can see, for example, with resumability, we deliver the same HTML. The page is here and instantly the page is interactive without delivering all the JavaScript and executing it and doing the process of reconciliation.

So, the question here is how we are doing that. It's so simple. In the first HTML that we deliver, we deliver small amount, one kilobyte of JavaScript that's called a global listener, that listens to all the interactions of the client and it goes and searches for the JavaScript needed. For example, if the client clicks on a button, he will go and search for the JavaScript needed for this button and execute it. He will not execute something that we don't need. That's what I'm trying to talk about. And we don't download something. For example, if we are in a home page, we don't need the about page or the e-commerce page. We don't care about that. So, why would we download and execute these pages? That's what about resumability. It's to deliver less JavaScript, execute less JavaScript. And with choosing, with using this paradigm, our pages will appear faster and we will get them interactive faster.

And with choosing, with using this paradigm, our pages will appear faster and we will get them interactive faster. And the correlation here will be we will have more JavaScript, we'll have more interact. If we want, if we have more interactivity, we will need more JavaScript, but we will scale because we will not impact our performance because we will not download all of this JavaScript and we will not execute all of this JavaScript. If you are using SPA framework, you have 500 components. In the first time you will download the 500 components. Okay, but with using resumability, you will only download what you need in your page and you will execute only what the user needs in the page.

Okay, so and not only that, not only about user experience or about Africa, there is also Google that are using a lot of metrics to measure your website. For example, we have the first one is large content pens. It measures the most the most large components in your page. It takes how much time to be shown in the page. We have also the first input delay that will measure the time between a button, for example, is shown in our page and when it's interactive. If a button we have it in our page, but we should wait for it more than 300 milliseconds to be interactive, that's not a good user experience. And we have also cumulative layout shift. And it's a metric used by Google to score the elements that move in your page. For example, if you have a page, but after two seconds of showing the page, there's all the page that moved down, that's not a good user experience because you will click on something that you will not need. And these metrics impact the ranking of your websites in Google.

Okay, so what we will do now is we will go with the simple demo to show how resume ability works. But when we are talking about resume ability, we are talking about QUIC. So this this is a new framework done by the creator of Angular, Evrimishku, and it's about resume ability. It's about delivering less JavaScript and executing less JavaScript in our client side. Okay, so we'll start with a simple thing. We will create a new component and we'll see with me how that's working. So index JSX, here I will create a simple component. Default. Hello, JS Nation. And here, I will go to my JS Nation. I have my components working good. That's good. So, here, what I will do is, like you can see, it's JSX. When you're using QUIC, we're using QUIC.

It's like when you're using React. It's the same thing. If you know React, you know QUIC. It's a new framework, but it's using JSX to be easy for all the developers to access it.

Okay, so here I will create a simple button. I will name it console JS Nation, and I will do a simple on click. Okay, and this on click, it should do a simple console log JS Nation console. Okay, I will save this. I will create a second button, console JS Nation, I will look Amsterdam, and here, I will write Amsterdam console. That's good. Okay, so I created two buttons.

If I'm using an SPA framework here, I will deliver this JavaScript. What you should imagine here is that behind this button, there is a lot of JavaScript that we execute. And if you are using SPA framework, we will deliver in this JavaScript when we access this page.

Okay, so here I have the two buttons, and here I clicked on JS to see the JavaScript that I had in the first load. We can see that in the first load, I have nothing. Here, I did the minus VIT, because we don't use VIT in the production. We will not need the VIT in the production, so I did minus VIT. And here, we can see that we have nothing, we have no JavaScript. So when I will click on this button, I will get the JavaScript needed for it. Okay, JS Nation console. And when I will click on the second button, I will get the JavaScript needed for it. Okay, if you are using, for example, an SPA framework, you will get these two JavaScripts here, because you need them, because you are showing them to the client. So you will need this JavaScript. But with using QUIC, you will not need to do that. You will only have what you want in the first load. So here, for example, you're not consuming, you're not executing all the JavaScript that you need. And the first question that maybe come to mind is that, do we want to wait, and every time I will click on a button, I will send a request to the server to tell him, give me this JavaScript? No, because with using QUIC, you are using a web service broker behind that is doing a simple thing. It's downloading the JavaScript that you need for your page that you're showing here, and storing them, this JavaScript, in your cache. Okay, and it will call and execute. So you will execute nothing in the first load. You don't have the JavaScript needed for these two pages. You have only what you need for your page. And it's even this JavaScript that you need for your home page, it will not be executed. It will be executed, and rendered in the DOOM when you will interact with these buttons.

Okay, and we can go more with that. I will here, for example, create a simple counter. I will create a simple counter, use a signal. And here, I will do a button that increments this. So, one click. That's good. And here, I will show this JavaScript, if and only if this count is more than value, is more than one, two, four. Okay, if it's only one, two, three, it will not work.

So here, I can show my count, count value. And when I will click on this counter, I will get the JavaScript needed. But I will get this JavaScript that I don't need now. And I don't have the counter because the count is only one, two, three. So, but I got some JavaScript that I don't need for now.

Here, I can also do lazy execution of the code. It's very simple. I will create here simple function. And I will call that like this. With using a dollar sign, I can lazy execute my code. Here, for example, when I will click and I will see the button, I will not get the JavaScript for this button. I will only get a hash or a link to the JavaScript that I need. And when and only when I need this JavaScript, now I need it because the count is more than one, two, three, four. I will click, I will get this JavaScript Amsterdam Council and I will attach it to the DOM.

So with QUIC, we can do, it's a built-in lazy loading and built-in lazy execution. And how, this is how we can improve our performance or the performance of our websites, consume less internet and consume less resources of our devices. And thank you.