 All right, all right. Hello, DrupalCon Amsterdam. Love that energy. Austin C. Dreese this morning on this stage, obviously a privilege to be here. Thanks to Jay Batson, the other founding team of Aquia for the Beats before. My name is Matthew Cheney. I work at a lovely company called Pantheon. And in what's going to be 20 minutes of action-packed high-volume energy, we're going to talk about mastering the CDN past, present, and future. Because this is a topic near and dear to my heart. It's a topic that I think is necessary for the open web and for everything that comes after. And it's something, hopefully, I can drop some basic knowledge on you, some intermediary knowledge, and then hopefully blow your minds a little bit. And that's 20 minutes, and we'll jump into some more really awesome stuff and keep this DrupalCon rolling. But for the CDN, let's talk about what we all probably want our websites to do, which is we want to make our websites fast. I don't think I necessarily need to emphasize the importance of that to the folks in the room. I think we spend a lot of time working on our own custom code to make sure it's fast. We spend lots of good time picking our hosting providers to make sure those are fast. And that we do a lot of testing to make sure that we're regularly delivering fast website as part of our larger web apps kind of process. And this is something we want to happen for people all around the world. One of the privileges of being part of the Drupal community is that you have access to a global audience of developers that you can understand. Make websites all around the world. For those that have website users, if you look at your analytics, they're also all around the world. And this is only more true. As Rhys mentioned in his keynote, we have billions of more people coming online. They all need their websites to be fast and they all need their websites to snap to it. But we got this problem. And the problem is the speed of light, which is an unfortunate problem because it's not actually that easy or physically possible to go faster than it. We also have a problem that servers are going to operate much slower than the speed of light. And that probably is not a surprise to you. But overall, I think, and this is where I think CDNs come into the equation, that if we start to look at the simply the time that it takes for light to go from somewhere in Australia to here in Amsterdam, for example, from Adelaide to Amsterdam, we've got 300 milliseconds worth of time. Now that's not like in the grand scheme of things a ton of time, but that's something that's simply going to happen because we have to go through the underwater fiber optic cable from Australia and make our way into central Europe somehow, somewhat. And the problem with this is that this is a time that we spend for every single packet that we transmit from our website to our user no matter what. This doesn't have anything to do with the server responding. It doesn't have to do with how fast PHP is working. It doesn't have to do anything with Drupal. This is literally the geographic tax that we pay to go between different areas of the world. And this is just the time it takes for one piece of light to go one time. When we start talking about the web, we start talking about TLS connections that maybe you have to negotiate multiple times, then these are times that we're paying over and over again. And so in a world where we don't have a CDN, this is going to be the reality. We have to pick our servers to be somewhere, be it over in Silicon Valley in America, be it here in the Netherlands, Pantheon. We just have a new data center a few hours east of here. You have to pick me at somewhere in Asia. You have to pick an origin without a CDN. And that means that everywhere else in the world is going to pay that tax to get there. And even if you're running a site that you think, oh, this is only for people in my country. This is only for people in this city, that the reality of the global internet is that these are actually things that require people to have global presences. People travel, people's servers are in different places. And that really needs to be fast. So the CDN, just to sort of get that baseline down, the CDN, which stands for Content Delivery Network, of course, it's the idea that says, look, we're still going to have our hosting platform or our servers somewhere, our origin. That's where we're pushing up our authoritative code, keeping our authoritative database. But instead of having just a single place around the world that we have to go to every single time we want to access the website, we can actually create local caches of that in different places around the world. That means that if we're smart with our caching, we can take it so that we can go down to South America one time with our website, store it in a cache, and then anyone else who wants to access it can access it quite quickly. Because the time, for example, within South America, way faster than having to go across oceans and things like that. And this is something that allows us to sort of, in a technical sense, create speeds because we can cut out a meaningful part of our actual delivery of the websites. That's sort of the magic of this CDN. You want millions of people to come to your site and see your front page content, to see your press release, to engage with your content. You're probably not going to want to have them all go to the same place, all Bootstrap PHP, all run through Drupal's whole runtime Bootstrap, and then send back files all the way to where people are. Instead, we can cheat. We can realize that most people want the same thing from our website. Fubar.css is going to be the same for everyone. It doesn't need to be automatically generated and minified every time that it's sent. We could just do that request once on the first person in the whole world that wants to see it from our particular area, and then every subsequent person, we can just give them that right back. And that's true for CSS files. That's true for video and image assets. It's also ultimately true for HTML. If you just go to one of your favorite websites, view source, see all the different HTML, that's something that if you just want to see that same experience a million times for a million people, if you're not customizing any of that or only customizing part of it, the stuff that's the same can be delivered quickly and efficiently using a content delivery network, and that's really, I think, at the heart and soul of what makes a CDN awesome. It's also a technology that you can put all around the world that where people are, we should have more and more points of presence for them. All a CDN is doing out of baseline is caching content, and so as the internet expands, as people have more points of presence around the world, the time to actually access these resources becomes less and less because we have more local and local access to it. And this is how we can beat the speed of light. This is how we can get around physics, not by going faster, but by having the experience of someone be faster because the website that I want, if it's cacheable locally, I can just access it directly from that cache. And that's really excellent. And now that may just seem like ground stakes to folks. If you've used a CDN, okay, now it speeds up my site. But if you haven't used a CDN or you're wanting to sort of set it up, I would definitely recommend to do this on all of your sites. I think it's an important part of making a modern web, and it creates also a lot of other benefits, like things like putting on HTTPS certificates, for example, things like invalidation around the world. These are problems that are easier to handle in a centralized, standardized CDN kind of environment. And setting it up is awesome because we're just making the smart pipes faster. We're taking the different tubes that are otherwise the internet, and we're making, having skips, we're having caches, and we're really dialing it in. And that may seem like a lot of magic and a lot of cool stuff that's happening just to make that work, but lots of companies are providing this as a service. You don't have to fly around the world and put servers everywhere to make this happen. Plenty of folks, including Pantheon, bundle a CDN with every site. It's a great way to get up and running with that, but it's not crazy hard to set up on your own. Configuring it does take some work, but ultimately what a CDN is doing on a technical level is it's the first thing that people access. You are part of the setup process of getting it to work is you point your DNS for whatever domain you have, and you point it at your platform that has a CDN or one of these CDN companies and you say, look, anything to my website, go to those people first. And then on the CDN side, you basically say, okay, where is my origin? Where is my backend server? Where is that authoritative database going? And that could be hosted wherever you want because the point of the CDN is that you need to have an origin that responds, but it doesn't have to be all around the world. It just has to be one place the CDN can access, and then you're in this rainbow world of getting at least the basic stuff set up. And hopefully that's not like a crazy amount of technical work for you. If you're not actually running a CDN now, I totally encourage you to try to dial one in after this talk because you will have faster speeds for your site. You also have, once you get that CDN sort of established, you can do a lot of really cool things that are hard to do otherwise, things sort of that get into that mastery of the CDN, stuff that really excites me, not only now, but I also see so in the future because the possibilities are endless on the edge, that a lot of the best stuff for the internet is gonna happen at the edge, and a lot of the stuff that Drupal is gonna make happen is gonna be even better when you have corresponding and complimentary CDN delivery services. And what are the stuff you can do? Well, so the first thing, of course, performance. The CDN allows you to cache everything on those local points of presence and distributed out. Now, the problem with caching, as we probably get from computer science or just our own web development life, is that cache invalidation is a really hard problem. If we actually make a change on our origin server, post a new blog post, change a user profile, the ultimate cache that results is now gonna be invalid in certain ways. But being able to selectively invalidate the cache, I think it's a critical feature of a CDN, that instead of saying, I made a change to my website, make every page of my website now not cached and has to be regenerated, can be a very bad plan, especially when you have large websites with tens of thousands of pages. You don't want that cache stampede, you don't want that overrun, you wanna be smart about your cache invalidation. Luckily in our Drupal 8 world, we have one of my favorite features, the cache API, specifically the cache tag system. If you haven't played around with this in Drupal 8, like no big deal, like it's there for you, Drupal's already really smart about how it handles content, and so this is something that you can leverage to do selective cache invalidation. Because you can take sort of a webpage, this is an example of a webpage, front page of a web, and these are the cache tags that actually make that up. So you'll see that Drupal is telling us that these are the different nodes that exist on that front page. These are nodes obviously put on there. It says we've got a few views that actually generate that content. We have a user profile of the user that created them, and then we have some individual files that are all there. And those are all of course entity ID numbers that are referenced in the Drupal backend, but the important part of this is that when we wanna make a decision, like we've changed node 10, we've changed some location data, or we've changed some post, that we wanna make sure that the environments and different pages that are now different are gonna be regenerated, but the rest of the site can still remain in cache, and that's what the cache tag lets us do. It lets us say if we change a view, only invalidate the pages for which that view appears, and nothing else. And that's something that we have tons of awesome capabilities inside of Drupal already that can make our CDNs even smarter and even better. That because we have our entities and our configuration types, these are things that we can hook into, and when they change, we can go ahead and invalidate those pages that use them and only those pages that use them. And the cache tag system is really smart and extendable, that you can create your own cache tags for your own custom stuff. If you're using the entity system, in standard Drupal kind of objects, this stuff is just gonna work for you because Drupal knows how to make it work. You start building your own stuff, awesome, but it's no big deal to just extend the cache backend because you wanna make it so that when a change happens on your site, those pages get re-done and nothing else. This is the fastest pathway to a fast website. And that's something that's in Drupal Core now will of course remain in Drupal Core for Drupal 9 and is something that works very well with the CDNs. And I think part of mastering that process of using a CDN with your Drupal site starts with making sure that you're getting that select cache invalidation right. And it's easy to work with, you can easily invalidate the tags on your local, you can also test it on the CDN and more truth, beauty to you with a fast website. And this is some of the debugging stuff when you get into it. Drupal kicks this out each time, x-drupal-cache tags. So if you've ever been playing around with the headers and saw that, this is what's going on. And there's specific tags for any kind of configuration or entity content that you might have in the CMS. And so I'm into that. And I think if you're in a CDNs, you should be in a selective cache invalidation too. Second thing you can do in a CDN, and this may be stuff that you're not as familiar with because it's still performance, but it's not just like blind caching. And this is a concept of optimizing images. So Drupal has had a very strong strength in being able to take things like image styles or image cache and redo images. And some people have done some very clever things with changing image sizes and quality depending on the device that you're talking to. And that's awesome, right? A mobile user is gonna want a different quality of image than somebody on a nice laptop with nice internet. And now this is work that you can do on the Drupal application side. I mean, you can detect their connection, you can try to figure out how fast they are, you can change the different image sources to reflect that in the JavaScript, you can lazy load images depending. You can do a lot of work yourself, but why do that? The problem of optimizing images is a pretty solved one at least for the general use case. CDNs now offer the ability to say, look, I'm gonna make design my Drupal site with the most quality images and let me have the CDN figure out how fast the user is, automatically rescale them down and do so all without touching your origin or your server at all. This is something that just works. And in the context of configuring and working with your CDN, something I would recommend to all of you to do. It's a huge level up for not only the performance but just like the straight up experience of working with your site. Same thing's true with actually doing AB testing, personalization and some of this awesome stuff that's possible using the HTTP very header. So if previously you wanted to maybe have like different tasks, try two kinds of homepages or two kinds of titles for a post, that might be something that you could have Drupal do, like oh, Drupal can randomly pick one of two pages and serve it, but in the world where we wanna cache that stuff, we don't necessarily want to have Drupal making a random judgment every time we ask a page because now we're taxing the CMS. Instead, we can just use this very powerful header, HTTP very, we can provide multiple variants for any asset on our CDN and we can have the choice happen on the edge layer between which group goes into which thing. And this can just be a 50-50 split or this can be something smarter and better. This is totally possible on the CDN. Of course, load balancing and uptime really important. It's not just being fast, it's also being available. Even the best clouds have weather and things can change. You wanna have redundancy in your infrastructure. A CDN is a great place to actually be able to have multiple backends and multiple cache settings so that when people go to your site, the CDN is smart so even if it can't find one origin, you could have a backup origin and you could always be generating and balancing between the different sites that you have. This is a critical component of most modern web hosting platforms and something that CDNs make easy for you to do. So the worst thing you wanna do is spend a lot of time making this great website, get a bunch of traffic to it and have it fall over. That's no good, load balance it all the way. You can also do some great stuff on the security front. A lot of security attacks look the same. We're already filtering all the traffic coming to us, all the requests. Let's just put in some spam type filtering for web attacks. If we see malaligned queries, the CDNs can block them. If we see common attack signatures, the CDN can block them and putting those web application firewall smarts in there are possible. And maybe just maybe the Drupal association will get this Drupal steward operation out to the CDNs where when a security release for Drupal comes out, instead of just getting a patch file to make your site faster, the CDN could also hopefully ahead of time get access to a firewall rule so that attacks that affect people are blocked on the origin and don't even have to take anything out of Drupal. And this just improves a safer and better web for everyone. And it's possible because when you control the origin, when you control the CDN pathway, you can make smart judgments about what's acceptable and not, and you can dial in your security. Well, the final things I think is great. That's probably my favorite feature of a CDN. It's something that Varnish offers. It's called Grace Mode. And it's basically an option that says, in the world of websites, it's better to have an old copy of my site than to have a 404 page. And so if I create this rule, if I turn on Grace Mode with my CDN, all of the pages will be cached. And hopefully it works the first time or subsequent times. If something crazy happens, let's say tomorrow, and the server goes down, Drupal blows up, the server blows up, not good, of course. Normally, if I tried to go to that server, it would say, page not found, error, not responsive. One of these error codes. And that's obviously not good. So how do you fix that? Well, of course, try to keep the server up. But beyond that, what you can do is you can tell the CDN, look, if you have a cache good copy, keep that copy. And if this origin doesn't reply for some reason correctly, just give them the last known good copy. Because the last known good copy often is good enough, and this will keep your sites rocking no matter what. Couple of final things. You can use the CDNs also to do really fancy stuff with domain masking. You can have your D8 site be your main domain, but have a forum site still live in D7. You can have a WordPress site all mixed into the same domain. So the user experience is consistent, but the different back ends for the different URLs work with the different CMSs that you want to work with. And that can be a great way also to do migrations, bringing over parts of your site and putting it inside of Drupal while the other site is still there. And then, of course, for the future of this stuff, if you can use things like HTTPS2, which is a way better technology for working on the web, instead of having to have those round trips happen for every single connection, you can just multiplex that stuff and just throw assets down the pipe. This can turn on the fire hose of the web and make yourself even faster. And this is something that the CDN lets you do into, you don't have to do a bunch of configuration on your website to do this, just pick a modern CDN and you're gonna go. And this is the kind of performance stuff you can get. Instead of like almost a four second page load, if we pull on a standard CDN, we can really drop down the actual response time because it doesn't have to generate that. And then if we put on HTTPS2, we can cut down even some of the TLS negotiation and deliver pages in like sub seconds, which is ultimately where you wanna be. Because search rank matters based on page speed, user satisfaction makes on page speed. There's a study here that probably mirrors reality in a lot of ways, which is if one second delay on your page time, 100 millisecond delay, you know, you're losing conversions, you're losing page views, you're losing people liking your site, and like we spend a lot of time making great websites. We pay people money, we work late, we spend all this time building expertise, we want our stuff to be awesome, so why not do something cool at the CDN and make sure that your websites are performing at the best? Because the future should be very fast, there should be really great stuff on the edge, and hopefully you'll join me in embracing CDNs as the awesome thing that they are. Thank you very much. Pause, speaker coming up.