 Hi everybody, I am Prosper Atemi, you are the co-founder and the lead engineer at Eden. Eden is a startup based in Lagos, Nigeria, that provides home services for Nigerians, just really into improving quality of Nigerians and Africans in general. And we'll be talking about media performance at scale, so let's get started. So, let's look at some statistics from smartysize.com. You can see the total population of people as against the total number of Internet users you have here. And if you look at the social media used around the world, you can also see the total number of people using their mobile phones to access social media and access the Internet. I want you to just keep this in mind because it's going to be useful as we just keep talking about media performance. So let's look at the world's most used social platforms, Facebook, YouTube, WhatsApp, FB Messenger, Instagram, TikTok. So this should give you a general idea of how people interact with media files across the Internet. Like people upload a lot of YouTube videos, people send files, media files all over Instagram. TikTok is the new sensation. People send a lot of videos over the wire on TikTok. People send videos to your friends. People put videos on the Internet, funny videos, videos that teach people how to do things. And the same thing with Snapchat and Twitter. So this just gives you an idea that a lot of media files are transferred across the Internet. Right now we're in a pandemic era and a lot of things have come online. People that used to do work physically now just submit these every day. People video call your parents. People video call your loved ones all the time. So there's literally a 1000X increase in the media files that's shared across the Internet. And this is a call for concern because all these platforms, Zoom, Snapchat, Instagram, YouTube, House Party, TikTok, FaceTime, billions of media files shared, you know, video streams, images, different types of files. So you can imagine, it can give you an idea of how, like, all these media apps at scale are literally handling performance, you know, handling performance on their servers and handling performance on the client, which is the device that the user is using. So one thing I need you to know is that when you're talking about media performance, media performance is user experience, media performance is optimization, media performance is speed, media performance is also accessibility. And when you look at the media bottlenecks for performance in a general web app, especially a modern web app, you talk about JavaScript, CSS, fonts, and media files. But today we're not talking about JavaScript because that's an entire talk on its own. We are just going to focus on media performance, right? How do you take care of images, your videos, your gives on your web app in a way that provides a very intuitive and fast loading experience for the user? These are some of the major bottlenecks for media performance, you know, large images, loading tons of images at once, inconsistency in the video format, large video files, blunted disregard for the user's hardware network, inefficient video catching and also failing to measure video performance. So this is, what you're about to see right now is how customers painfully experience some of these products. Yeah, so your customer loads your web app or customer loads your app and is trying to just like go through all the images and videos and they are either waiting for the images to load or for some reason the video buffers every five minutes. I'm thankful that in 2020, this is not like experience for a lot of people, but you know, a couple of years ago, this was pretty common. And then you had to have like a very strong, you know, internet connectivity for you to enjoy whatever you're watching on the internet or you just download, you download and watch it later. Yeah, your users are really suffering. So we are going to talk about some techniques and tips that you can use to mitigate all of this. It's crazy, but it doesn't have to be. So how do you scale media performance in your own apps? Things to consider. Number one, leverage CDNs for globally distributed catching. OK, so what you should not do is save images from your server. You know, you should have different types of server for everything, your database server, your ready server for catching and then your file server. So you do not have to host these files and your images and your self. Just put it in the CDN. And the good thing about CDNs is that they catch your files. So if a user has requested a file before in the client, if he's trying to request that file again, it just has a catch copy. And a CDN like library has what you call the multi CDN strategy, which means for your users, you know, spread across different parts of the world. For example, if I'm trying to access your file from Lagos, it serves the file closer to the edge when I mean closer to the edge. I mean, it looks for a server that is closer to me in Lagos and just serves the media file to me, right? If somebody is in San Francisco, it looks for the server that is closer to the person in San Francisco's years and serves that file. So these, in essence, makes file retrieval very fast. So your images are downloaded on the client very fast. Your videos play very fast. You can also use Tombor. Tombor is an open source CDN that you can host yourself if you don't want to use Cloudinary or Cloudflip. Number two, ensure you always compress your files. You know, one thing I see a lot is people upload files and then the platforms do not compress, you know, as much as possible. Or I look at media news sites, you know, when an editor is, you know, writing something, they attach a file, those files are not compressed. So you see a file of two MB, 10 MB, 15 MB, just sent across the Internet. Why do you have to do that? You don't have to do that. When you look at these two images, for example, the first image by the left is two MB, uncompressed. Look at the image by the right, 918 kilobytes. Now, if you look at these two images, you cannot spot the difference. They look the same. So what does this say about compression? If you compress, there are a lot of bytes. You literally save your users, you know, you save your users. You shave off a lot of bytes so that your users can download the file faster and also your users can save data, very, very important. So always compress your image files. And what are the tools you can use for image file compression? You can use ImageMean, this is a JS conference. So I didn't bother talking about putting all the other tools that you can use. But ImageMean is an MPM module that you can use to compress your files. You can also use Cloudinary. Cloudinary also does this stuff that I really like. It's very amazing. If you're not trying to use the SDK, you can just do this on the fly. So the URL that retrieves image, just putting what you call Qo2. Qo2 automatically compresses the files on the server so that by the time the user is accessing the file on the client, it is compressed by default. Number three, normalize lazy loading your images. If you look at Instagram by the left, you can see when you scroll, the images do not appear at once. Some images appear and then when you scroll to the end of the feed, there is another set of content that is being pre-bashed so that, you know, you can just have a seamless experience. So what you should do in your apps is load only what the users will see first and then lazy load the rest. Now, some of the tools you can use before now, we didn't have this attribute, but now we have a native loading lazy attributes functionality on your browsers from Chrome 76. You can start using it. And if you do not, if you are trying to accommodate this for all your users, you can use a polyfue, a polyfue, loading attribute polyfue. We ensure you have this for older browsers or for older mobile browsers. You can also use these libraries, the user library, your other gears, Cloudinary, JS SDK and all you need to do is just assign a loading attribute with a lazy value to your images and boom, takes care of it for you. You can also do that for your videos. In fact, you should do that for your videos, for the videos, for the off-screen videos, always, you know, lazy load them so that they don't just appear at once because the user is not trying to watch it at the same at the time they come to your site, they are at the top. So if the videos come underneath, you do not have to load those videos first. Let the user get to the end of the field before you load those videos. So please, lazy load everything. Also, do not image resize on the browser. Honestly, don't. I see folks use CSS to adjust the size of images and browsers. Now, for the user, this, the user does not feel anything. The user is just like, oh, wow, this is amazing. But what is happening under the scenes is that the large file in the high quality file and, you know, high resolution file is downloaded already to the browser. So you've already wasted the users' data by downloading the original size and then now you're using CSS to resize. No, all of that should be done on the server. The resizing should be done on the CDN so that it just fetches the exact size that is needed for the user. Don't hide images with CSS. Please do not. This is this is pretty common if you go to five in 10 websites. You see this image display. No, but then this is just aesthetics because on the website, you don't see the image. But if you go to Chrome DevTools and see the images, as literally been downloaded, the image was downloaded already from the server and you're just using CSS to hide. So what are you accomplishing really? It's just aesthetics. The user cannot see it. But then the image file was already downloaded. That means if we study users that are. So please do not hide images with CSS. Another thing that our advice you to do is I know your PA. I know you love your PNGs. Oh, my goodness, PNG is a very quality file. It's also provides transparency. The images are sharp. Please. Do well to use web P file format where P and JPG is in, you know, in place of PNG. You probably don't need that PNG file on that new site. You probably don't need that PNG file on that app. You don't need it because JPGs can literally give you the same good quality that is closer to that PNG. So you shave off these bites and give your users a good experience whilst they're saving their data. Because with web P, web P is a file format that gives you a good quality, but with a very small size. And if you look at the case study here, YouTube switched to web P thumbnails and they got 10% faster pay load Facebook to do the same thing. And they discovered their site became 25% faster. People could load Facebook, you know, easier and in less time than before and it also reduces data consumption. Let's not forget that. So please try to use web P and one of the ways you can do this is right now you're already probably thinking, man, this is a lot of conversion I have to do. You probably have to set up a build script. You have to come up with a whole module that converts these files. With Tradinary, you do not have to. Tradinary has a feature called FOTO. You know, the other time I talk about QOTO that reduces the quality of the file. FOTO automatically fetches the most optimal and efficient format for the file that is being retrieved on the client. So this is what happens. You have a URL for the image. Immediately you put the FOTO, as you can see on this slide. It looks at the user's browser and also looks at the strength of the user's internet connectivity to determine the type, the most efficient format to serve the user. So it doesn't matter if the file was already in PNG or JPG or whatever, as long as it's serving it on the client, it serves an optimal format. So if the user is using Chrome, it will serve a WebP, if the user is using Internet Explorer, it serves a JPEG XR format. And what you can do is, if you try to save on the, try to save a file, you discover that the file, format that you're seeing originally, it's not the same file format that it tries to save. You know why? Because even though you put PNG, crawl in and say, yeah, that's great, but then that's not really efficient for this user. So we're just gonna save it as WebP, which is totally amazing. I've not seen this in any other place before. Prites. You know, there is a popular saying that a picture is what a thousand words. And I said it. And I just wanted to say, if CSS image spreads, it's what a thousand images. A very good example of this is, you're opening a sidebar. A sidebar here components that loads a lot of icons or loads maybe like company logos. You do not have to load several company logos. You can literally load one image file, an image file that contains all these images. It is called a spread. So it's an image spread. You have an image file that contains about 10 images and you have a CSS file that helps you to load them. So create a CSS image spread instead of using several multiple images. It shapes us a lot of bytes for you. And one of the ways you can easily, you know, produce this, you can use a top-down CSS spread generator. If you Google this, you'll see this. When you go to MPM, there's a module called Spritty that you can just use to, you know, convert these files to one file. One file will hold all of this and provide you CSS. Clanary also automatically does this for you on the fly. If you upload a lot of files to Cloudinary, and you tap them. For example, I will upload 10 files and I tap them with Prosper. Once I just write this URL and say, slash spread slash Prosper.png, you grab all those files, create an image spread and also automatically generate CSS from it. So all I need to do is just include CSS in my web app and boom, I have an image file that contains a lot of other similar images. Very good for performance. Another thing that you should do is also respect the user's hardware. This is very important. The user trusts you, all right? And when you respect the user's hardware, you can also leverage that. A very good example is what you see on the screen. You can check the user's battery level and say, hey, this guy's battery or this woman's battery level is very low. Go ahead and surf high quality, no, low quality images. But if the battery is very high or the battery is charging, surf high quality images. Another thing that you can also do is to preload the video for video performance. If the battery is high, just preload the video so that the user can get a very nice experience. Also check the user's network connection. Is the user connected to Wi-Fi or is the user using the normal cellular? Is the user using the normal cellular display resolution images, else display? There's just so many things that you can do with this. But I'm just giving you an idea of where you can try out your own apps. Another thing that you should do is set up performance budget for images. Oh my goodness, it's very, very important. Agios Money talks about this a lot, especially for JavaScript. And one thing that you can use for your teammates so that all of you can be performance aware is set up performance budget. Say, hey, all the images on our platforms should not, when they are rendering on the client, should not be more than two MB. Should not be more than three MB. In fact, should not be more than one MB. So of course you have put in build script in place that compresses all of that. But compression can be very funny. Sometimes it compresses, but doesn't compress enough so that it doesn't lose quality. But with this performance budget, all of you on your team can get notifications on the way that we're, when there's an image or a group of images that are exceeding the set amount of bytes that you put for it. A very good example of the app that you can use to measure this is the Calibur app. You can set it up and then you're good to go. Gives, Gives are very popular on the internet. We use Gives on Twitter. It is everywhere else to express our opinions. Look at this GIF right now. This GIF is 10 MB on the left. I converted it to video and boom, it just opened for MB. This is an MP4 video. So you can imagine 10 of these GIFs on your web app. The user is rendering 10 GIFs, 10 times 10, that's 100 MB. But look at, when I change it to MP4, it literally gave me more than 50% reduction in the size of the file. Now this is ironic because I've used GIFs in the previous slides. But then when you're sending this to the user, the client needs to save data for the user. So instead of sending GIFs, maybe you can consider converting it to MP4 to provide a very good experience and also make it load fast and save the user's data. They are very expensive. So try and convert your GIF to videos. Another thing you can do, which I didn't put in code for this but I talked about preloading, always preload your videos again. If the user is not going to see that video immediately, if the user is going to do something else, preload your video so that by the time the user gets to loading the video, there is no buffering. It is already like working. It's already loading the video very quickly. So another thing you should do is for your videos, ensure that your video players employ adaptive bitrate streaming. Adapting bitrate streaming is a video delivery technique that makes sure your video starts faster with fewer buffering interruptions. And what happens is this, there is a master playlist file that comes with your video files. It depends on the, that comes with your video player. It depends on the type of video player you're using. And what that does is it contains metadata about some different video streams. And what those video streams contain, they contain like information, different types of file with different types of resolutions. And what this does is you have all these different types of file quality and resolution so that based on the user's internet connectivity, it can start loading the video with a low quality video. And then once it sees that the user's CPU is less utilized or the user's internet connectivity is better now, it just switches to a high quality video. But because you already have metadata about all these different video files, it's easy for you to switch from a low quality streaming video to a high quality video. And some of the players I've seen that include this by default is the Shaka player. The Google Shaka player is an open source. It's on GitHub. It's an open source video player you can check out. You can also check out the Cloudinary video player. They are very good for the HLS and impact that adaptive feature streaming. And if you use this for video files, you are ensuring that your videos are being played faster on the media app that you're serving your users. As Adios Mani will say, improving performance is a journey. Small changes can often lead to big gains. So one thing you should take away from this talk is remember more. As you are ensuring that you put all these tips and tricks into places, always measure, optimize, and monitor. And some of the tools I use, the very good tool I use is the WIP speed test from Cloudinary. It does an image analysis of all the images on my website or my app. This is our EdenLeft.com, for example. We have a Pisco of A, which is pretty excellent, right? And then if we scroll, I scroll through all the images that it checked on the website. It gives every image an image score. Also checks the size of the image and also offers room for improvement. That's kind of really fantastic, right? And then I can see, hey, this file is too large. This is not the right format that should be serving. And I can just take all these recommendations into, note these recommendations and then just fix it and then go ahead and then test it again to ensure that it is very fast. Other tools that you can also use is, you can use Think with Google, page speed inside, speed curve, your lighthousemetrics.com, and then it gives you a lot of statistical analysis about all the images on your website and allows you to optimize and go ahead and measure again. And the more you measure, the more you are sure that you can give your users a very optimal experience. So I've got it to the end of my presentation today. Thank you very much. And I hope that you can put some of these things into work in your next media project or you can look at your existing website and say, hey, based on the recommendations plus past said right now, I am going to put these things and I'm not just going to do it now, I'm just going to keep doing it every day, every week to ensure that my users load their web pages fast and I can save users data. So thank you very much for listening to my talk. You can find me everywhere on the internet on UnicoDeveloper, on GitHub, on Instagram, on Medium and on Twitter. So thank you very much.