 All right, so we are talking about website caching. Real quick, who knows what website caching is? What does that mean? OK, a couple of you. This talk's going to be a little bit higher level. We're sort of gearing it more towards the non-technical Drupal users, maybe the site builders, project managers, those kinds of people. But how many developers or maybe technical Drupal users do we have? Probably the same people that already raised their hand. I get it. All right, that's all right. We're going to fill in some little things here and there for you to watch out for as well, so no worries. Let's go ahead and move on. Quick agenda. So we are talking about, we're going to do some introductions, of course. We're going to get into what is caching. We'll go through a couple of sort of common scenarios with respect to website caching to sort of illustrate the things that we're talking about. Then we'll go through a couple of tips and tricks just to give you all some tools to use later and sort of wrap up with sort of a quick recap of the things that we've covered. So that's it. What does Simon want to introduce? Hi, everyone. Simon. I'm working as a director of technology for evolving web. So my background, I've been 15 years. I've been doing Drupal stuff at virus level, being Drupal gone, building Drupal website. And I have more focus on the back and side of thing. I used to call myself a headless Drupal specialist until I realized it might be perceived in a wrong way. So I'm not calling myself a decopal Drupal specialist. I'll switch to Jesse. Yeah, OK. And so I'm Jesse. I am a solutions architect with evolving web. I have about 10 years of various web development experience, sort of as a full stack developer across a couple of different platforms, of course, including Drupal, and of course, as a Drupal agency. So who is evolving web? We are a full service digital agency. We help a lot of our clients bring their digital experience to life, so setting meaningful stories of motion through digital platforms designed for growth. We've been working with Drupal for about 15 plus years. Maybe it's 16 or 17 now. We're about 85-ish people between designers, developers, content strategists, and a whole bunch more. These are just a handful of clients that we've worked with over the years of various institutions. So what is caching? I'm supposed to sit here for the recording. Yeah, so what is caching? So essentially, for people that are wondering, so probably a little bit less than half that room, it's literally storing a copy of the result of a computation so that you don't need to redo that computation again. So think about the multiplication table you learned in your youth, and you're not having to recompute those small multiplication. You just know them by heart. It's kind of the same thing. You're basically going to store a file or a piece of data in a storage so that if the same request needs to be executed again, you're going to be able to serve the result right away without having to recompute it again. So of course, it's going to bring more performance to the overall system because you're going to be able to reduce the amount of time you spent computing the result of a web page or styles or images. And white matters where right now for web properties performance is key at almost all levels. Of course, primarily for user experience, users are not going to be akin to keep navigating your website. They have to wait a couple of seconds each time they navigate from one navigation point to the other. And like courage to that, then of course the SEO, your overall SEO of your website is going to be way better if the website answers quickly. It's actually one of the metrics that Google and other search engine are monitoring. And they use that to promote or demote your website position in this search results. So it's actually key. So caching comes into like, there's different type of caching when it comes to using those techniques to speed up, to bring more efficiency to a web project. So the first layer we can talk about is what happens on the client side. So by that, we mean the browser. So the actual Google Chrome or Firefox or Microsoft Edge. Something like that. So basically, at that level, the browser is going to store some of the data so that when a navigation happens from page to page, there's no need to refage those data again. So going to be like the different styles, the different fonts, the different images, like for example, the logo, stuff that are on all the pages. So the first access to a page is going to be a little bit slower, but then all the subsequent navigation steps are going to be faster because the data is just local to the user computer. Then one step further, there's everything that happens at the network level. So basically between the user and the server that hosts, for example, your Google site. And so at that level, it's the same thing. So instead of being actually stored on the local computer, it's still somewhere on the network. So why is that interesting? Well, first, it means that if there is cash data at that level, the request that wants that data back is not going to need to hit your hosting infrastructure so that hosts the websites. So it's going to be quicker. And then you're going to save on the computational need that that infrastructure requires. And on top of that, one type of those network level caches that I call CDN are actually multiple copies of your content that I store virtually everywhere on the planet. So for any user, instead of their requests having to travel all the globe to the actual location where your website hosted, the content is going to be much more closer to their geographical location. So it's going to be faster. That's what's happened on the client side and on the network side. But there's also a type of caching that happens on the server. So inside the tool application itself. And then it's in case it's not possible to cache that on the client side or on the network layer. Then the application that is hosted on the server that runs there is going to be able to cache maybe partially the results of some computation so that it can be reused much faster. So typically what that means, I'm going to just skip that straight animation that was supposed to go over my discourse, but you got the idea. That means basically you can think of it as two different kinds of caching. The one that are external to your Drupal project and the one that are internal to your Drupal project. The external one are interesting because, as I said, you're basically moving the storage and the competition lead away from your infrastructure and you can serve that content much faster and closer to the user. It comes with a drawback which is it's only capable of caching full pages of content or the assets that are linked to those pages, so invades, tide sheets. But it's not going to be able to be really efficient if the pages changes. They need to be the full pages. And then when it comes to more dynamic content, then you have the internal side of things, which is basically it can be completely customized. That means the developer that built the website is going to be able to leverage the cache in the way they want. So they're going to be able to cache things that can be reused for a longer period of time and recompute the things that change all the time. But obviously that means that the requests are going to hit the infrastructure. So if there's something you want to remind, it's like basically caches break down between what's external to the website and that's what's internal to the website of the Drupal instance. And I'm going to switch over to Jason. All right. So I mentioned we wanted to actually walk through a couple of scenarios because this is all can get into some kind of technical stuff. So it's helpful to sort of break down what this actually means when you're looking at a website. So let's start with what is basically a simple static page. This is the Drupal.org home page as of just a couple of days ago. And it's basically there's nothing really dynamic happening on this page right now. It's just a static page with a bunch of content, nothing interactive. Everybody is seeing this same page. If you all go to this website, today you would see the same page. And this is kind of the best case scenario, like Simone was saying, we can cache this in a very external way from Drupal. So it's sort of the most external way actually where we can really leverage the caching the most in such a way that it basically avoids Drupal completely in most cases. And so because of that, it might be the simplest cache, but it's also maybe a little bit more difficult to control. We don't have as much control over it. There is ways that it can be controlled, but it's just not quite as easy. But because of that, again, it's probably the most performant to cache these pages. So zooming in on this page a little more, let's sort of pick it apart a little bit because there's a bunch of things on here that are cache at different levels. Something like maybe the font files on the site. So if I'm remembering correctly, I think Drupal's using Ubuntu. So that's not a common font. It's not part of everybody's operating system. Your computer, when you visit the site, is going to have to download that from an external location. And we don't want to download that again when you go to the next page. Maybe you go into the wire Drupal page. Why do we want to download that font again? And so this is where browser caching comes in. The browser has that ability to hold onto that, those font files that's going to tell your browser how to render that font. So there's no need to re-download it again. It's just going to get it straight from the browser. We have a whole bunch of images, too. Those are the same, like the icon in the navigation bar is the same across every single page for the most part. So we don't need to download that when you go to other pages. We also have another image there that is just on the home page. Well, that's not going to be cached for other inner pages by the browser, but it is going to be cached by some of those other layers like the CDN, where maybe you can get that image from a much closer location than having to go much further geographically to get that. There's also some videos. You can sort of see the video controls there. So maybe those also could be something that's cached. Videos might be a bit of a different subject, but the same idea as apply. We can bring them closer to a user, do some things to make that happen faster for those users. Additionally, maybe more difficult to see, but the page is obviously styled in a very certain way. It's not just a white background. So there's some style sheets happening. There's some JavaScript probably happening. So those files are all things that we would otherwise have to deliver to a user every single time if there is no caching involved. So this is where caching is really helpful to make that operate a lot faster and a lot smoother. There's also a bunch of code that gets generated behind the scenes. And this is what we're sort of talking about when we mean like caching a whole page. It's all this code that was generated when you visited that website. Drupal did a whole bunch of work to calculate all that, figure out what to display, and we don't even do that every single time again, because it's just everybody seeing that same page. So why bother spending a bunch of time that is going to make the page load slower? Just want to talk briefly about what is a CDN. We've mentioned that a couple of times, and we've kind of alluded to it, but just to go a little bit deeper into that. So we're here in Lille, and you might be visiting a website that's hosted maybe all the way in North America somewhere. That might take time to actually get over there. Surprisingly, the speed of light isn't that fast when it comes to a website. So we want to bring those files closer to the user. But doing that ourselves as developers, or as agencies, or as content editors is kind of complex. So we bring in a content delivery network that's going to handle a lot of that for us. But it mainly only supports things like the images and all those other supporting files that we looked at, as well as that full page output, which you could imagine there's a scenario where a user never actually goes back to the web server wherever it may be, and they just get everything from a CDN, which is just a couple of kilometers away in some cases. So that's kind of the principle of a CDN. It's just to bring things closer to the user so that things work a lot faster. And that CDN sort of can work sort of on the user's behalf to retrieve all those files from the original server, hold on to them closer, and deliver them to the user in the end. And that sort of takes us onto the more complex example. So I'll send that back to Simone. Yeah, so as Jesse said, when the page is mostly static, I mean, entirely static, the same content getting searched to all users, it's pretty simple because you can cache that entirely and then serve it like from the server cache or the CDN or even for the broader cache if you know that it's not going to change for a while. But what happens if we have something dynamic? For example, we have elements of personalization or it's an e-commerce website and the prices are dynamic and computed by depending on the currency you selected or the geographical location you are in, or like most simply, if you're using a search feature, obviously the search result page is going to be unique and not truly cacheable. In that case, for example, if we're logged in, then it's the same web page but the exception of that little avatar that is displayed on the top right corner. So in that case, if we take a closer look at the page, I mean, most of the elements are not going to change from page to page, like the navigation is still going to be the same for everyone, that header here that provides another level of navigation is still going to be the same, the images are also going to remain the same but that very specific avatar is going to be different. So if we're looking at the page, Drupal is basically able to kind of poke a hole in a page and instead of caching the whole page globally, Drupal is going to be able to identify which blocks, which elements, which components of the page can actually be cached for a long time, just be reused and which one are going to be dynamically generated for every request and then reassemble the page from the cached element and the one that needs to be recomputed every time in a way much more efficient way than if the whole web page would have been completely recomputed. Of course, in that scenario of having elements of customization that are introduced, we're going to be forced to leverage the internal cache Drupal and we're not going to be able to leverage like CDNs or broader cache for the page output itself because at that level it needs to be different for every users. So that said, we're going to switch to some tips and tricks section when it comes to caching. All right, so a couple of things that are helpful to know when you're dealing with website caching. There's a couple of ways that we can sort of like work around it basically and the first way is just through what we often call a hard refresh. So there's a few different ways to do that but basically it's just, it's a way to tell your browser to ignore its own cache and go directly back to the network to the server to wherever it needs to go to get those files all over again. So you can either do that through one of these methods depending on your operating system. Mobile browsers may have like a in private or incognito mode. Kind of does the same thing. It'll help you to not use that cache. And yeah, so that'll really help to get around that just by hitting that, you know on a Fusing and Mac, it's that Command R, Windows, Control Shift R. For those of you using Linux, I did actually update this earlier but I guess it's still stuck in the cache so I haven't updated it. I might have to wait until tomorrow to see that one. But that's, you know, the first way that you can really try to get around a cache. The next thing you can do is using a query string parameter which is basically this ugly thing at the end of the URL. A lot of you've probably seen those when you're sharing URLs around. That string for the most part tells a web server or something along the line like the CDN that this is gonna be a unique resource that we're requesting. And so it's sort of a way to tell the server to vary that resource but that the important thing is that it's telling you everything else in between that it's unique. And so that tells the CDN for example not to cache that resource. So you can use that for the page. You can also use that for an image like I have the logo there. If an image is sort of showing you the old version and you wanna see, okay, is it actually the real version. This isn't gonna fix it for everybody though. It's just for your computer again. So there's still sort of an underlying question of why are we seeing the old image that maybe needs to be sorted out if this is something that's happening commonly. All right, and then the last stage if you clear the cache locally or you're interested, you're instructed all your user via Twitter to all clear the cache. It didn't work. Or you like use that techniques or you flush the CDN cache via their UI and it's still not working. Then the last result measures obviously to try to clear the Drupal cache itself. So two ways of doing that that most of the developers already know for non-technical users that if you don't know there's an actual button in the admin UI of Drupal that allows to do that. The equivalent trash command that is here. So obviously if, what I wanna say for that, again it's obviously a debugging method. You can't really rely on that on a day to day operation basis because what that is actually going to do is that it's gonna flush the entire cache. So meaning if you're trying to say, hold, I have that single page that each time we're updating it it doesn't get refreshed for the user or they need to wait a long time before seeing it. So I always need to clear the cache. So what happens here is like basically because you're clearing everything you're virtually rendering your website super slow for all the web pages for a while which on heavily loaded website might actually cause a complete breakdown. So just saying that we just saw three different tips to kind of assess if there's a caching issue at various stage of the various layers of the infrastructure. But it shouldn't happen as I said previously to pull this capable of like even managing very dynamic caching scenarios. If you have to resolve to that that means you need to put your developers back at work because there's something they're not doing correctly. So in order to kind of wrap that up what we learned today. So basically walking away from that room I want to remember that there's actually two different kinds of cache. The external ones that are very efficient because you're basically moving away from your infrastructure a lot of the conditional burden but they're universal they're not specific to Drupal they're basically based on the foundational HTTP layer for the web. But they're like all or nothing. So in some case you need to result to using the Drupal internal cache to achieve great performances. And Drupal is really good at that. Actually the whole Drupal caching API are built around the semantics of HTTP which means Drupal is natively compatible with any external caches between the browser cache or a CDN. And it also provides for the developers a powerful fine-grained internal caching API that they can use for as we said like caching various components of the page but also if there's a development like an integration to an external API or any kind of computational requirements that same API can be leveraged for that eliminating the burden of having to actually handle the cache. They can just cache and say I want that to be cached for an hour or for a day or forever. And in terms of like the overall architecture we learned that performance and throughput of a website are really key and it's important to keep that in mind and to constantly optimize it. And then when you end up in a case where it's getting harder and harder and caching is not helping maybe it's time to maybe rethink the user stories or the UX to bring that down to a more simplicity so that it's easier to cache and maybe even more understandable for the end users. So with that said, thank you for your attention. Thank you.