 Okay, perfect. So today for the most part, I just want to touch briefly upon some internet trends which has evolved over the last decade or so. Briefly touch upon what is this content delivery network, how do they work, and what's the use of the CDN? How are they going to help your site? And finally, I just want to again talk to you about if you want to set up a content delivery network and start delivering content for your site over the CDN, how do you go about it? What are the different options available today? And how do you go about evaluating them if you have more than a simple choice? So quickly, we've known that the internet has changed over the years, but to put that into perspective of folks who are creating content and maintaining sites, you know, we can take a look at it in terms of what's really changed and fundamentally what's different today. So if you look at how the internet or how the web operated a decade ago, those HTML, CSS, JavaScript, you put out simple websites, it was primarily delivered to your desktop because that was a device which was most popular form factor. And your networks were pretty much fixed lines, mobile internet penetration wasn't prevalent and even in pockets where they were, it was not used as a primary mechanism to consume content. But, you know, even as, you know, late 2018, which was a couple of years ago, internet had changed significantly. There were a whole bunch of devices that you could use to consume content. There were different operating systems, browsers to complicate matters further. There were different networks. Now, fixed line networks and mobile networks behave very differently. I think we've had a geo revolution which is sort of brought about good changes. It's made mobile internet very accessible to a lot of Indians. And today we consume content over mobile without, you know, thinking too much about it. But if you look at what's changed on the tech stack, a lot has changed. You're able to access using the web stack, touch input, zoom pretty much works on the web stack today. There's, you know, a lot of improvements in the way CSS, JavaScript and some of the other technology work. And users also sort of expect a richer quality of content to be delivered on both mobile and desktop. Your screen sizes have increased. You cannot deliver the same kind of images on your content websites anymore. To put that into perspective, if you look at how, you know, the internet, the web pages on the internet have evolved. You know, back in 2011, if you look at the size of websites because of how they were made and how they were delivered, they were fairly small. And today, a median size of a web page delivered on a desktop is about two MB. And that's a lot of content to be delivered. And if you look at the mobile pages, it's not too far behind. The median size is about 1.8 MB and that's fairly large. So it also... Satya, so you're saying that this is, this is a number includes all media or is there anything that it excludes? It actually includes just the pages. So that's your HTML, CSS, JavaScript and images. That's, and you know, everything that goes into building out the page forms. And in some cases, audio and video as well. So this data set actually is, I picked this up from Web Archive. They've sampled about 5 million websites. They're currently sampling about 5 million websites across the internet. And it's a constantly growing database. They also use the Chrome user experience report to sort of put out some of these trends and data points. I'll, you know, talk about how you can use some of these data sets to figure out your content strategy in later part of the talk. Now, if you look at content sites, they're not too far behind. In fact, the content specific sites actually have more content in the sense that they're heavier than your median pages. Content specific pages can have content of about 7.4 MP. And that's a lot of content, a lot of information which gets delivered to end users. And this is primarily because the expectations have changed. You want high quality videos, high quality images to be delivered. A lot of people, you know, even if they're in pockets, have increasingly higher screen resolutions, retina display or large form factors. And irrespective of how, you know, your users consume the content you want the experience to be consistent. And essentially what that does is, as content owners or content creators, we're creating content which is heavier. And, you know, that's sort of the expectation. But on the flip side, if you look at some of the statistics, or even, you know, as a consequence of this increase in content size, your pages start to sort of degrade. Now, the expectation is internet is fast today. So even if I deliver seven megs on, you know, a single page, it should get delivered fast. But that's, you know, a very small fraction of users who are on high quality internet or they have really good mobile connectivity. For a majority of people, internet is average. And you want to ensure that your pages load consistently, irrespective of how good or bad the internet is. That's one aspect of it. And if you look at some studies, right, these studies are put out by different organizations. I think Chrome has, or Google has put out a study which says that if your page load increases, your page load time increases from one to three seconds, you're likely to see a 32% reduction in, or increase in the bounce rate. Basically, I think a lot of these studies, what they're trying to say is faster pages are good. If your page is slow, people are not likely to be, you know, wanting to stay on to your page loads, or they're just going to move on. And that puts a lot of pressure as a consequence of that. You want to make your pages faster. And you see this all around. SEO rankings are based on how quickly your page loads, even, you know, for example, if you're dealing with videos, if your video is buffering users' complain and with the social media penetration today, it's fairly common for complaints to reach a dose step pretty quickly. So given all of that, there is a lot of pressure on content creators, people who are building out and, you know, maintaining these sites to be very efficient in delivering the content. And, you know, there are many ways to improve the performance of the site. I think in the last session, you spoke about web performance, how, you know, developers can focus on optimizing, you know, the websites or the web pages. Now, outside of those optimizations, there are, you know, some other things content creators can do. That is leverage infrastructure which specializes or will aid you in improving the performance of your site. Now, I always, you know, when I talk about content delivery networks, now content delivery networks are that special infrastructure or these are networks or service providers which help you deliver content, improve performance of your website. So a good way to sort of get started on the concept of a CDN is, you know, to think of the e-commerce problem today. Now, instead of looking at this as, you know, some server with a lot of people, if you reimagine this as your Amazon e-commerce, you know, problem, think of Amazon having one central warehouse in India, put it anywhere in Mumbai, Bangalore or one of the big cities, and you have people from across the country placing orders. Now, if Amazon had just one warehouse, all of those orders would go to that one warehouse and it has to cater to all of these, you know, orders that are coming in. And the other thing is, you know, you might place the order from Kanyakumari and if your warehouse in Mumbai, it's further away. So that's a logistical problem. And the way you would go about dealing with this problem on an e-commerce or a logistic use cases, you know, set up warehouses in tier two, tier three cities or even other tier one cities and stock up the items and tell over the items from there whenever an order comes in. So when the order comes in, they'll figure out, okay, you know, I placed an order for probably a non-perishable item. If it's there, you know, deliberate, that's how you get your one-day delivery or same-day delivery. So we've seen that working really well in day-to-day lives. I always tend to use my one-day delivery. It's always good when things come home faster. And the same concept actually applies to your content delivery network as well. Now, over the internet, you're running your web server either in a cloud or data center and it doesn't matter if it's a web server or just a system that delivers static content, like for example, some storage system. You will be, you know, in the simplest format, you're going to be delivering a lot of this content directly to your end user. So, you know, and all of these requests will go back to your server. Now, we can take the Haskeq example. I spoke to Zainab, asked Zainab if I can use the Haskeq site as an example. Now, based on what I could find, Haskeq does not use a CDN today. And it's posted out of any 2E network data center. So, when all of us, you know, go to submit proposals or come to, you know, see what sessions are there on Haskeq next week, we're actually making a request to that web server in E2E cloud. All of those requests go to E2E cloud and that looks somewhat like this. And this is users from across the country. Now, if Haskeq was to use a content delivery network, by a lot of content delivery network have multiple points of presence. And this is true across the board. What they essentially do is they bring content closer to the end user and by virtue of content being closer and a couple of other things, it sort of improves the performance of, you know, your website for end users. So, in this case, if Haskeq were to use a CDN, all of the content would be served or some of the content would be served from these points of presence and that would speed up the site. So, you know, we spoke about what a CDN does. It's a delivery network that focuses on bringing content closer to you and delivering content from there. But why is that important? Why should you use a CDN? Now, for starters, I think it does a few things straight up the back. It ensures that your site loads quickly. Again, you know, because they're specialized infrastructures or platforms, they ensure that your site is available all the time. And I'll get back to, you know, this point in just a bit. Also on the internet today, there are a lot of malicious requests. There are a lot of hackers who are trying to exploit vulnerabilities in your site, either to gain access to accounts that don't belong to them or just bringing down infrastructures. That falls in the category of application where malicious requests or DDoS attacks. Again, you want to use a CDN as one of the mechanisms to sort of protect your sites or systems against this class open attack. So, you know, that gives us a good understanding of what are the different use cases of CDNs and how they are useful to you. But CDNs have actually changed over, you know, the last decade or so. Similar to how the web has changed, CDNs have sort of had to keep up with, you know, the changing demands. Initially, or, you know, back in late 90s or early 2000s, CDNs primarily delivered static content. So, you would, you know, if all of your site was being delivered on Haskeek.com, you had a couple of other domains, images.haskeek.com or static.haskeek.co.in. Those are actual domains that Haskeek uses. You know, back in the day, you would simply say that, okay, I can use a CDN to deliver images. I can use, you know, a CDN to deliver static content. That should improve the overall user experience for my users. That was true. But over the years, I think the CDNs have changed strategy. They can actually now serve dynamic content. Basically, they proxy all your dynamic content. If it's not catchable, it goes back to your web server. The content is fetched and delivered to the end user. And there is an inherent improvement in performance by doing that. And I'll quickly touch upon why there is an improvement in performance. And CDNs today actually do a lot more. They can actually transform your pages, improve, or, you know, compress your images on the fly, provide a lot more in security in terms of bot management or protection against script injection and other sorts of attacks that you usually see on the internet. Different CDN vendors have different capabilities. I'll not speak about specific capabilities, but I'll touch upon large things. In the last slide, could you, because we are talking about people who would be fairly new to this or people who have not gone so much deep into the technology. So could you explain the now bit where how does it work with? Because we have no one CDN to be something that takes dumb static content and simply serve it. But dynamic content, how does that bit work? You talk something about proxy and going back to the origin. If you can spend a few minutes just explaining how that works, that would be great. Okay, perfect. That's actually my next slide, right? All right. So if you ask about how static content is delivered, that's in fact, you know, what I've put up on the screen right here. This is actually without a CDN. So today, again, using Haskeek as a reference, we'll make a few assumptions for this conversation. We'll assume that Haskeek, all the HTML pages are indeed dynamic because, you know, there can be a situation where it's a marketing site, so the HTML page is also static. And just to clarify, when I talk about static content, I'm not specifically talking about CSS, JavaScript, or images. Basically, static content is something that does not change either because, you know, there is a difference between who's accessing it or where the request is coming in from. Like for example, if you and I go to the Haskeek page and it's the exact same site that's delivered, the exact same HTML snippet that comes down and that HTML snippet is static. So dynamic HTML would be when you log in. You're an editor on Haskeek, so you would have additional dashboards and fancy charts and comments and other features. So that is not available to me when I log in, and that makes that particular HTML snippet dynamic. So, and there can be more factors as well, right? So anything that, as you said, changing content or versus everyone getting the same content, that should be the qualifying factor and not just logging in. So even if you have something like a different content being delivered to say people coming in from different geographies, as an example, or different content being delivered to different devices, types of devices, then that also qualifies, am I right? Yes, yes it does. In the simplest terms, it does. Now, I'll just set some context. A lot of general purpose CDNs are able to sort of cache content based on where the end users are coming in from. Like for example, if you have two pages, one for India and one for the rest of the world, and both of them don't change, but the URL is still the same. Like for example, Haskeek has a homepage. It shows different content when people from outside of India visit, and it shows the content that we see on Haskeek today when everyone from India logs in. It's still considered static. It's just treated a little differently because fundamentally it's not changing with individuals. We can still leverage the benefits of caching because you don't have to make personal decisions. So I would still use the personal differentiation of content as a qualifier for static, but that gets into some nuances. To keep it simple, in this conversation, we'll make the assumption that if the content changes at all, we'll treat it as dynamic, but otherwise it's static. So in this workflow, we'll talk about what happens when dynamic content is requested from the Haskeek service today. So when I go ahead and make a request for Haskeek.com, essentially what happens on my browser. First, the browser makes a request to DNS. There is an IP that's returned from the DNS resolution, and my browser goes ahead and makes a get request on Haskeek.com to index.html, and that's what is returned and displayed on my browser. Now, if you use a CDN, there are a few things that happen slightly differently. For starters, and I'll talk about this in a little more detail in one of the latest slides, but when an end user makes a request, and if your site is using a CDN, you're most likely, again, I'm taking a use case, which is common for most CDN use cases. There are exceptions. In most cases, what your site is going to be pointing to is a CNAM DNS record. What that means is typically when you have a DNS record, it's pointing to an A record, which is directly an IPv4 or an IPv6 record. But when you're using a CDN, in most cases, you're pointing to a CNAM record, and the reason for that is a CDN has to figure out what is the nearest location to that particular end user, and send you the IP address for that particular end user. Or in different strategies, either the IP is different or based on, for example, you would send one set of IPs for all of the users using a CDN from India. If they're using it from some other location, let's say Singapore or Australia, they would send you a different location. But the concept is pretty similar. There is a CNAM record. That CNAM record eventually gets resolved to an IP address, and your browser still makes a request for an IP address, and this time, it actually makes a request to the CDN. Now, I'd mentioned that in the past, or in early CDN days, CDN colony handled static content. But today, almost all CDNs are fairly intelligent, they're rule-based, in the sense when a request comes in, they are able to identify, using some qualifiers. In this case, you could say that HTML pages are all dynamic. So the CDN would say, okay, fine, this is an HTML page, it's dynamic, so I cannot return this response, or I cannot cater to this request from cache. So let me go ahead to the Haskeek server, fetch that home page, and then return it back to the end user. And that's essentially what happens. Now in this workflow, if you look at this, I've mentioned that CDNs have multiple points of presence, and that's one of the reasons for CNAM record is used, and you're always pointing, or you always request content from a CDN location, that's closer to you. Now, what that means is, it's going to give you performance benefits, like the e-commerce use case that we spoke about, that nearest CDN location is in network terms, much closer to you than the Haskeek web server, which is running nginx in E2E networks. And by virtue of that, the time it takes for a request from my browser, on my Wi-Fi to go to the CDN location is lower than the time it takes for me to go directly to the web server. And it boils down to some key metrics. In this case, it boils down to round trip times, and almost all of the internet is running HTTPS these days, so it boils down to the time it takes for a TLS connection to be set up. And almost all CDNs use some form of TCP optimizations. They also reuse this connection. So in the previous slide, I was talking to you about how the CDN would go back to the origin server or your web server and then fetch the homepage from Haskeek.com. Now, that CDN location is already set up this TCP connection to make a request. Now, when I first make the request, if this TCP connection wasn't set up, the CDN would initiate a connection, respond to that request. Subsequently, if you go ahead and make the same request and you land up on the same CDN location, what happens is that connection is still open. So there is no time lost in establishing that connection. You're quickly able to fetch that content and serve the end user. So that improves the performance and that's for dynamic content. It's no longer static content. Similarly, it also matters where you are. Now, we explained that CDNs have multiple locations. Let's actually quantify that, right? Again, I've used some simulations to sort of demonstrate or it's a little bit of a stretch. It may not be the best way to measure this, but it will give you an idea why you need to serve content from closer to end users. Though it makes sense intuitively, we can look at some metrics and see how that plays out. So again, to sort of go over why content should be closer, what I did was, and a quick trace out from my laptop to Haskeek Server. It takes about 45 milliseconds and that's really, really good. Haskeek site loads up, I think, under two seconds on my laptop and that's actually a very good experience, but Haskeek also caters to users across the country. I use ACT broadband as you can see. Other people who are going to the Haskeek site may not use ACT. They might be on your... Sorry to interrupt. For the benefit of the users, can you explain what is TraceRoot? Yes. For the audience? So what I've done is, yesterday I was putting these slides together and I wanted to understand, okay, where is the Haskeek server? I know it's on E2E network, but how far is it in India? Is it very far away in terms of network hops? Again, even though I can have a web server in Bangalore, physically, it's very close, but in terms of network, it could actually be pretty far away. And that boils down to what ISP you're on, or in this case, what ISP I have in my house. What is the ISP connection that the Haskeek server has and what's the best route between my house to the Haskeek server? And one of the ways to figure out when you make a request, how it actually traverses the internet and goes to its destination. There are basic tools available. It's available on Windows and Linux and Mac. That's called TraceRoot. I think the command differs from Windows and Mac. On Mac, it's just TraceRoot, and you just enter either an IP address or the domain. And it eventually results through the IP address and tries and figures out, okay, from my Wi-Fi connection to the Haskeek server, what are the different hops, how long does it take, and what are some of the bottlenecks? Here you can see that I have a Wi-Fi set up. So that's my Wi-Fi IP. ACP gives me dynamic IP, so having my IP published is not an issue. I think every time the router resets, I get a different IP, I actually check that. And finally, there are these different hops between ACP broadband to the Haskeek server. And these are essentially for all, these are essentially network elements or routers which route the traffic. And all of that actually adds to the latency. If Haskeek server was closer, for example, if Haskeek server was deployed on ACP broadband, the trace routes would probably stop right here in the sixth row. And if you add all the times up, it could be in the order of 30 milliseconds or probably lower than that. And that's a factor of distance. Now, to sort of quantify this, what I did was I used web page test. Now, web page test is a tool, I think you spoke about it last time. Everyone is fairly familiar with it. And I ran a web page test from different locations. I took Mumbai, Singapore, LA and London. And I just wanted to see what happens if end users are coming to Haskeek from all of these different locations. Now, you can take any metric you want that depending on what you're trying to measure, you might want to look at just DOM complete or fully loaded. But for this discussion, let's use DOM complete. DOM complete is basically when all the resources are pretty much delivered to the browser, at least on the Haskeek site, there's nothing that loads beyond DOM complete. And if you look at DOM complete, from Mumbai, it's about three seconds. That means it takes three seconds for the entire resources to be delivered to your browser. And after that, it's painting and executing some background scripts and making some analytics calls. From Singapore, it's roughly the same. It's in fact much faster. So Haskeek servers are more accessible from AWS Singapore than AWS Mumbai. But I'll get to why you shouldn't take some of these metrics at face value. I'll touch upon that briefly. But it gives you a good idea. If you go to LA or London, you'll see something strange happening. From LA, the time it takes for DOM complete is about six seconds. And London is seven seconds. Now that's a little counterintuitive, but internet is strange. So what it tells you is, if users are in India, Singapore, for them the site loads pretty fast. And that's already significantly different from the experience I had when I measured it on my local system, DOM complete was quicker than three seconds. So there is already a little bit of a trend there. What you can take out of this data point is performance varies and it varies significantly when location varies. You can also, I went ahead and just get a quick breakdown of the content on Haskeek site. It's got a lot of images, a lot of scripts. Scripts actually constitute a bulk of the traffic. And the homepage, at least, is about 1.2 megs. Now, if you look at the median for websites, Haskeek homepage is actually lower than the median, so it's great. And still takes about three seconds to load. There are a bunch of things we can do to optimize that. And if you go to webpage test and see what are some of the optimization that you can do, straight up the bat, if you do an image analysis, you'll see that 96% of images can be compressed. By size, you'll get a benefit of 96% offload or improvement. What that means is if all of the images were compressed and delivered in an optimal format and it was compressed for the optimal quality, that number 417 kilobytes can go down significantly. Scripts, you tend to see most benefit in just compression. And the same thing goes for CSS. I think 42 kilobytes is pretty conservative. Scripts, I think, in most cases, it's already compressed. So we'll not try and look at additional optimizations here. Images, yes. And if we were to put a CDN in front of Haskeek in this scenario, you can look at performance optimizations which will come in from having a CDN which is delivering all of these images. First of all, closer to the end user, from a location that's closer to the end user. And that will remove some of the variability. And it sort of stems from some of these metrics that are some of these numbers that you see here. If you look at the content breakdown, images, CSS and JavaScript constitute a bulk of the content. We wanted to experiment and we categorized all HTML content as dynamic content. So 17 kilobytes of about 1.2 megs is actually dynamic. Everything else at least is static for the most part. And images, CSS and JavaScript, it's static for almost all use cases. So you can definitely leverage a CDN at least for this section. And if you go back to the numbers, right, there is a lot of variation in the DOM complete time when location varies. If all of these assets were served from location which is very close, you would not see that significant difference. You will see some difference because we still have this HTML page which is dynamic. You still have to come back to the Haspeak server. But that's just about seven requests out of a total of 55. So that will vastly improve the variance in performance. Each end user sees when they come to the Haspeak server. So that's an improvement. Okay, what are the other things that CDN can give? And when we were talking about capabilities of CDN, we definitely said it adds to your reliability and it makes sure that your sites are always available. What does that really mean? Because all of us have redundancies built into our cloud or our data center. We have monitoring for our web server. If it goes down, we know that there'll be an alert triggered, there'll be a restart script or if it runs over capacity, there's auto scaling in place. So why should we worry too much about reliability and availability? That's already a given. It's true for the most part, except when things go horribly wrong. Like for example, you can take any variation of this. Let's say you're running a web server and that web server erred out, there was a memory leak or that instance had an issue and it crashed. Or your data center had connectivity issues where I'm making a request, your servers are working just fine, health systems are great, but when I'm making a request, it does not reach the data center. So what would you do in these scenarios? If your servers were working fine, you can always set up a custom error message. I think customizing error messages from your own servers has always been straightforward and can be handled seamlessly. But if it's an infrastructure problem and the problem is with your infrastructure, which is serving the content, that infrastructure cannot handle the availability and fail over in consistent manner simply because it's not reachable. So as an end user, when I go to the Haspeak site and if the data center itself was down or the engine server was having issues, I would get no response. And if Xenob decides, I don't want the Chrome's default error message, which is a connection timeout to show up, I want a fancy message. And we've seen a lot of these in the past. We've seen the fail veil, the magical unicorns for GitHub. We've seen the rusty break for Google. Some of these are the error messages which tell you that, okay, what things have gone wrong. And that happens, but we are looking at it and we'll be back out. So that's important both from a branding perspective and to give your end users some assurance. If it's a business that's critical for your end users, you just want to give them the feeling that it's important you're looking at it and there are other ways to contact you. You can put in either a Twitter handle or an email address for them to reach out if the site is not available. CDNs can also similarly handle automatic failover to another data center. Almost all CDNs have some capability to do that. And finally, when it comes to security. Now, security, again, it's best handled in a distributed manner. I think I didn't put an image here, but if you go back to the original distributed setup that I was talking about, CDNs have multiple points of presence and each of them can cater to the demands that's coming in locally. Similarly, if there are malicious requests or attacks against your site, it's handled in a distributed manner or at least in almost all cases, it's handled outside the perimeter of your data center. That ensures that at least, you don't have to deal with the bad traffic in addition to the regular traffic that you're already catering to. In almost all cases, whether it's a static site or whether you have some logic running, it's going to take up some compute. You have DB lookups and other things going on. You don't want all of these malicious requests to add to that particular server load. So security, again, is something CDNs do very well. And the CDN capabilities have actually kept increasing over the years. So we've gone over caching and developing static content, proxying dynamic content and content acceleration, web security. Additionally, a lot of CDNs do video streaming, image optimizations and edge compute. Edge compute is, again, an emerging trend. We're all used to AWS and the big cloud providers providing some compute capabilities or even serverless capabilities. Those capabilities are slowly trickling down to the CDNs as well. But it makes a lot of sense. Similar to how you bring content, if you can bring compute closer to the end user, it just makes it more distributed, more faster, you can respond much quicker. So that would be great if you can explain each of the terms very briefly. Not in much, I mean, in the interest of time, not in much detail, but some of these terms like proxied dynamic content might be a little difficult to understand. Yeah, yeah. So proxied dynamic content, it's actually, you know, it means exactly what we went through in the use case. We said, okay, Haskey, the homepage for Haskey is a dynamic content, but I want to deliver that through a CDN. What I want the CDN to do is accept the request, but not cash the page, go back to the data center, fix the right resource and deliver it back to the end user. So in that situation, a CDN is acting like a proxy for your service or your server. And essentially, that's what it means. And by virtue of being a proxy, it's able to accelerate content as well. That is, you know, by reducing the RTT is being closer to the end user, reusing some TCP connections. Different CDNs use different techniques, but at the end of the day, there's an element of acceleration that's provided. Same goes for web security. Now, there are different capabilities. Now, web security is fairly complex. Different providers and vendors have different capabilities. At a high level, you have two major threat categories and I'm not being comprehensive at all. I'm probably touching on two that comes on top of my head. It's DDoS protection and attacks against your application or application layer attacks. You use a web application firewall to protect against that application layer attacks. And you use the entire CDN platform to sort of protect you against DDoS attacks. Both of these are, you know, fairly detailed topics. So I'll just leave it at that. Yes, that's good. Video streaming, again, is a problem of delivery at scale. Video content is heavier than your image in CSS. So there is no way you can deliver all the videos from a single location. You would have to use a delivery network to stream videos. Whether it's live streaming or on-demand content, you're more or less relying on CDNs to handle that workload for you. Now, image optimization is an interesting one. Now, you know, until I think Safari is in tech preview or beta of supporting WebP and once that supports maybe across all browsers, we have generic support for WebP. But as it stands today, different browsers have different image formats that are optimized. Chrome is a big proponent of WebP. And those, WebP as a format is more compressed than your JPEGs and your PNGs. And that essentially reduces the amount of bytes that needs to be transferred. And that sort of makes it more optimal and by virtue of being more optimal, more performant. We had also covered the entire image optimization as a topic in one of our sessions. So something that we have discussed in great detail so far. Okay, perfect. Then there's finally Edge Compute. Edge Compute, you know, it's, there are a lot of capabilities that CDNs are providing. At a high level, you can think of some or all of Lambda like capabilities being available on different CDNs. The advantage is it's, you know, it's more distributed than big cloud providers. Okay, well, I know I'm probably a little short on time. So I want to get through this really quickly. Now, if you want to set up a CDN for your site, it's actually fairly easy to do it today. You just need to take care of two things. One is you need to have control over your DNS and domain. What that means is if Xenobones to set up a CDN for Haskeet.com, now Haskeet.com uses Outfit P3 as our domain name registrar. So I would need access to the Outfit P3 port. I would also need access to or control over the server that's currently delivering Haskeet.com site. That's, you know, we know that it's running on E2E network and it's an engine X server. So if I have access to that, it's great. Once you have these two things, all you need to do is a CDN config where you need to set up a CDN config. Almost all CDNs provide a portal and a UI to set this up. And different vendors have different capabilities. You can today, in almost all cases, use an API to set them up as well. And once you've set up the CDN config, they're likely going to have to make a DNS change. Now we spoke about the CNAME that points to the CDN. So as a final step, you'll point your site to the CDN CNAME. And from that point on, your sites are getting delivered through a CDN. So what are the different options that you have a CDN? There's after my, before I get to the different options, there are generally two classes of CDNs, right? One of them is a generative of a CDN which basically means that they cache all of your content. They'll proxy your entire site APIs or services and they're able to deliver it. And you're most likely going to use them in your commercial projects or your personal blogs and sites like that. There's another class of CDNs which is specifically catering to the requirements of free and open source projects. So if you have a free and open source project that's hosted at a GitHub, you would choose from one of these CDN options. They work really well. So quickly over to the general purpose CDN. So there are a bunch of them available. All of them have the three basic capabilities that we spoke about. That is a performance element, a security element to it. And all of them offer some improved reliability for your sites. So you would most likely be picking from one of these options here. And if you have an open source project and I want to make that distinction a little clear, you would be using one of these free CDNs that's specifically catering to open source projects. But what you deliver over the CDN and how it's delivered slightly differs from the workflow that we spoke about. And essentially in all of these CDNs, in all of these CDNs, the goal is to deliver your library, your open source libraries in most cases to other websites, not particularly your site, to other websites in a fast and efficient and a reliable manner. So that's generally the use of these CDNs. You've seen a lot of these. A good example is jQuery hosted on the Google CDN and it's actually hosted in multiple different places. It's a very popular library. Now, some of these open source CDNs, you cannot choose to opt in. You might have to get elected or you might have to reach a certain popularity before it gets published on these CDNs. But that's essentially the nature of how they operate. But these options are definitely there. I wanted to step in over here, but to our audience, the reverse use case might be useful, which is not that you're hosting open source project, but if you're using an open source project, then you might want to tap onto these CDNs rather than hosting it yourself. Yes, yes, absolutely. So, in a lot of cases, if you're not using a CDN, there's a lot of benefit in at least getting all your JavaScript and your fonts from one of the hosted CDNs that cater to those specific libraries. But if you're using a CDN of your own, there are different benefits to getting them delivered through your infrastructure. Your own CDN, yeah. It primarily is to just use the connection that have already been set up. And in almost all cases, the general purpose CDNs have a larger spread compared to some of these CDNs. Okay, so there are a bunch of different CDNs. How do you go about selecting one that's right for you? There are three goals that you might have. And that's essentially common across all CDNs, security, performance, and off-load. The first thing you need to do is figure out what's relevant to you. Once you've figured out what's relevant, you can go ahead and figure out, okay, what are these different CDNs? What capabilities do they have? And is there a specific capability that really is important to me? If there is a differentiating capability, then it's a slam dunk, just go ahead and use it if you have just one CDN having that capability. If capabilities are fairly similar, you wanna figure out which of them is good for the performance of my site. You have to run a benchmarking exercise in most cases. And my recommendation for running benchmark is don't use webpage test as a mechanism to benchmark simply because they're point-in-time tests. They don't accurately represent the capabilities of the CDN simply because internet is fairly chaotic. You might not get consistent results and it doesn't really matter how many times you run these webpage tests. It does not accurately represent how your users are going to see the performance of your site. The easy thing to do is use RUM data. RUM data is your user performance metrics that's collected from the browser. There are tools that you're probably already using like Google Analytics, Boomerang, Impulse. There are a lot of vendors which provide capability around real user monitoring. So real user monitoring data as a simple way to figure out what is the performance of all of these different options in the real world and how are your users being impacted positively, negatively by using some of these options. And that pretty much brings to most of what I wanted to talk about. There are some useful tools. So I think you've gone through some of these already. So I'll just keep it brief. In most of my conversations, I tend to use Google Lighthouse and webpage test a lot. If I want to understand the latest trends on specifically about how websites are built, the HTTP archive is a great resource. Akamai puts out a state of the internet report that talks about a general internet overview and security trends across the internet. So that's a good resource again to get some information on what are some of the recent trends in both internet space and security space.