 Ray Brown is the director of systems engineering at 10 Up where he helps companies and organizations scale and secure the board crest. In a previous life, Zach got his master's degree in meteorology from North Carolina State University. He lives in Portland, Oregon with his wife and two kids, and why he's his wife whenever he can. Alright, thank you. Get down to the home stretch here today. I made it. Alright, so I'm going to talk about caching, which is a topic near and dear to my heart. The career out of knowing what caching is and how to implement it on sites. This is no joke, I literally have made a career on mostly this. The purpose of this talk is to talk in basic terms what caching is. So that at the end of it, you understand what the terms are, the different layers you can apply caching, how it's important to help your site, and understand these terms. So when you're going forward and it comes up, you have some base knowledge on how to look at this, what these mean, you can have a healthy conversation on it. We're not going to get into super detailed technical stuff or solving specific problems with caching. When I started putting together this presentation, I was like, oh god, I made a terrible mistake. This is way too broad of a topic. I don't know what I was thinking. I could do eight hours of this, so I'm trying to distill it into the most important kind of definitions and basic concepts that I think everybody should understand. Alright, see if I can like look at your work. So this is me. We have an introduction already. I'm an engineer. I work on high scale WordPress sites for enterprise clients. I live in Portland. It's live review on my website. I'll put that up at the end as well. Alright, so caching. Start with the basic definition. If you Google caching definition, you will get this. Storeway in Hyatt for future use. Not sure that's really helpful for understanding what caching business stands up. So we'll take a look at the word orages. The word orages comes from French Canadian fur trappers. They used this word to refer to the place they would store their gear, store extra supplies, things they would need while they were out in the wilderness for weeks on end. They would travel for days down rivers and cross mountains to get to places. They were trapping beavers, mink, and they would be out there for a long time doing their work. They would need to carry a lot of supplies with them. They didn't want to be carrying this every day. They would be checking their traps. So they would store it somewhere and come back two weeks later. Rather than going all the way back to town. There weren't 7-11s all the way back to the 1700s. So they were storing this material in a place they could get to it more quickly and more immediately. So on Wikipedia there's an expansion of this definition and it talks about how the word is used in computer science. It's a hardware software component that stores data as a future request for that data and can be served faster. The data stored in the cache might be the result of earlier work that was computationally expensive. And it's a copy so you can get to it more quickly. So we see the concept similar to the word origin. It's a place where you can store something and serve it faster. You can do it more efficiently and more conveniently. So what would we have in WordPress? How do we apply this concept to the platform we're trying to build on? To explain this, let's look at how a request is served on WordPress science. So there's a person at their computer. They open your URL on a browser. That request hops across tens of thousands of miles, potentially on cables going under the ocean to the server where your site is hosted. At your daddy or WP Engine or BluePost, the server lives in one place. So this is your hosting environment where your site lives. So WordPress receives that URL. Then it's going to run some subset of the 400,000 lines of Ph.D. code to make up WordPress. This is not including plug-ins or themes. Some subset of that 400,000 lines of code is going to run to figure out what page should be served for this URL. What is this person requesting? How is this page going to look? What data is going to be shown on this page? It makes requests to the database to get the content, all the things you've written, all your data is in the database. That gets returned to WordPress. Ph.D. code runs on this. WordPress builds an HTML page that includes all of the images in CSS with JavaScript and other stuff that goes into the page. Builds this HTML file. Sends all that data back across the wires to a person sitting at their computer who is thrilled because they realize how many complicated things had to happen for that site to look. So, here is how WordPress site happens. We think about our definition here about trying to serve something faster, store some computationally expensive thing in a cache that we can refer to quickly. We can think about where we would put this cache so that it would be quicker to serve this site to the user. So, what if we put a layer of caching right here? This is called the whole-page caching. This is when you put a layer of caching at the very front of your hosting environment so that when WordPress serves an HTML page to that user after it has built the entire thing and done those hundreds of database queries and thousands of lines of code and it has an HTML page, we'll just store that HTML page. And then the next person who asks for that HTML page, we'll just give them that page. We won't have to build everything with WordPress and databases and everything. Now, this is great when you have a publishing site, right? You're a newspaper, you're a blog, you're a marketing site, right? Every page is the same. I get the same page as you get to everybody on all the databases on the same page. Nothing unique going on here. So, there's no reason you have to run all the code of WordPress and all of that logic to build that page. It's the same page. Just send the HTML to them again. So, this cuts out all of this work. This is great because it's super fast. Now we don't have to do all that work. Your website can serve those HTML pages super fast. It's very efficient. You can do this on a really small server with very little resources to serve an HTML page. And it's very skillful. Can you give an idea how scalable this makes something? Imagine this is the amount of data your website can serve at any given time. It doesn't matter how many people are coming to your website. That host is only so big. Those nozzles are only so big. That's as much water as you can push through that website no matter what you do. There's no more pages coming out of there. That's fine if you have a couple of visitors. But, you know, what if you read a popular article with lots of people that are coming here? A really cool page caching turns your website from a host like this to something like this. This is no joke. It is hundreds of thousands of times more efficient to serve just HTML pages than running all over the press. I've worked on some large sites where the host can get across, well, 15 servers, struggling to keep up every time they get lots of traffic. The site goes down. It crashes. They can't keep up with it. They take tons of money for hosting. Enable very simple full-page caching on the site. And you can reserve it in two or three servers easily without any stability problems. It really makes a huge difference in the performance and what your systems can do. All right, so those are the benefits of full-page caching. Now, there are some dodges to be aware of, and this isn't an exhaustive list, but these are kind of the big ones. So one thing to consider is, okay, I'm saving this request after WordPress has created it. What happens when I publish new content? I changed the title of an article because some SEO guy told me I should use a different word. How does that get updated in the cache? There's a saved version of it. I can change it over here, but how does the cache know how to use a new version? Also, I've changed the title. That title is also on my home page, on the archive page. It's in the Related Posts thing over here. I think that's be updated everywhere. And the second question is, what if you go to a site that deals with the need and content? Like, you have a commerce site, and you have shopping carts, or, you know, a buddy press site, and you're logged in, and they're seeing their specific friend activity list, things like that. So the first one, what happens when there's new content? There's two ways to handle it. You could just wait longer. When we set up the full-page cache, the way you do it is you set an expiration time for those pages when they're in the cache, say five minutes or ten minutes. This is a super simple way to set it up. You can set it up to just be, it expires every ten minutes, and after ten minutes a new page will be requested for WordPress, and then you'll get your updates there. So you just have to wait. And this is fun, because this is a very simple thing to do, and really scalable. But people don't really like this. They want to push the button and publish their thing, and they want everyone to see it. They want a tweet about it immediately. They don't want it to be on a delay. The other way to do it is you can throw out the old page and pressure with the new page. This is what happens when you use a cache system that's integrated with WordPress, and this can be integrated using any number of WordPress plugins. And the way they work is when you publish a new post, it hires a hook on saving the post to the caching system. The caching system knows all the places that that post is used, and the title or the metadata shows up, and it clears selectively all of those pages from full-page cache, and now you have a new version, and it's available instantly. So this is a pretty well-solved problem. We have WordPress plugins that do this, so this is definitely something you can expect. When you're working with full-page caching, you will have that intelligent cache clearing. So what if your site deals with unique content for a user? Well, it's not... No, you can't really use full-page caching for this. That's not going to work. It really relies on every page being the same that's served. So if you have an e-commerce site or a buddy press or something where the things served from the server is different for every user that comes. It can be different for a user coming from the page. You'll want to look at something different. So in that case, we will remove the full-page caching. There's still something you can take advantage of here. There's object caching, which exists right around here. It is a place to store the results of database queries or some complicated things that happen in WordPress. You don't necessarily want to have to do an every-page look. So generally, we use a software tool like Memcache or Redis. And those are key value stores, which is illustrated here. They're basically really simple databases. They don't have anything fancy going on. It's just there's a key and there's a value. And so it would say, well, give me the value that's related to key K3. And it would spit that out. Give me the value for key K4. This way, rather than minus QL, where it's like, well, give me things in the post-medit table for this, you know, post-diting. You have to join the post-medit table with the post-table. And don't tell me things from October 3rd to October 5th. And things that were written by Julie. That can be very difficult for the database to figure out and apply all those rules. If you had that value in the cache, it would just be sitting somewhere and saying, well, give me the value for K3. You can spit it out. One place we use object caching a lot is, let's say you have a site that relies on APIs. We work with a financial site that does financial use, talking about stock prices. They go up or go down. These are your dividend stocks. In their articles, they have, when they mention a stock, they like to put the stock ticker name and the current price of that stock. And so that populates all the way through their site in their content. Now, it happens to be fairly expensive to make these calls to this API to get this financial data. So every time you load the page on that site, we don't necessarily want to have to, you know, update that Apple ticker price every single page load. So that's going to be very expensive if they have a popular article. And it doesn't need to be updated every second. So in the object caching, after the first page load where that Apple stock price is loaded, we store that value in the object cache. On the next page load, we don't have to make an API call to get that Apple stock price. It's sitting right there in the object cache. We'll just pull it right from there. When the 15 minutes are up, when that page load, you'll see that value has expired. We'll make a new call to the API and refresh the cache with that Apple stock price. So this way it saves us money for having to make that API call. And APIs, I don't control these APIs. It could be slow. I don't want this page load to come up halfway through waiting for this API to tell me the Apple stock price. If I have it in my object cache, I know I have it somewhere that I can refer to and it's going to serve quickly and reliably the agent I did in the way. Let's see. So the benefits of this are when you turn it on, it's generally pretty invisible. WordPress works right out of the box with object caching. Many popular plugins have good object caching integration. You've got to turn WordPress caching on object caching on if you have it or solve plugins to do it and it looks exactly the same. Great. I guess that's good. It does improve scalability. Right when you turn it on, it's probably not going to make anything do much faster. But at high scale, if you're doing a lot of complex things, it can really improve the scalability of WordPress. And it can be used for full-page caching. There's no reason you can't have both of these things. Okay. So back to the publishing sites where we can do full-page caching. So that puts us here. So this is great. We're serving items out of the full-page cache. We're not doing any of the full load WordPress every time. But we still have all those wires to go across. And that can be sort of slow. Especially if you're hosting a site at GoDaddy and we have a server in Dallas and the person trying to read your site is in Australia. That's a long way for that request to go and even at close to the speed of lightning does take a little while. So what if we did some caching at this layer much closer to the actual user who's requesting that data? So this is called the Contact Delivery Network or a CDN. A CDN is a global network of servers that you can pay company to store your data on their servers and serve it to their local customers. On WordPress site, in general, kind of entry-level way to do this when we do store your images on the CDN. So those are very large. You take a while to download. You store them at CDN and you store them on these servers that are globally distributed that you can use to quickly serve those images to clients, to people browsing the site. So this is an illustration of what that looks like. Let's say there's a... you have your server in San Francisco where your site shows you. And here's two people browsing the site. One in New York and one from Melbourne, Australia. Of course, the person in Melbourne chose to go the long way around the globe or something like that. But you get the idea. It's a big distance. It's a long way away. So if you had a CDN in play here, you would have servers all over the place. And the person in Melbourne would be making their quest to a server in Sydney. And the person in New York would be making their quest to a server in New York. And you would reduce all that latency, a trap of that request across all those wires. And there's... some of the big providers here have hundreds of servers around the globe. So there's going to be one local to your visitors. So there's two main types of CDNs. There's your original pull CDN and reverse proxy CDN. On an original pull CDN, you would have your URL, dot, dot, dot, dot, MySite.com, which goes to your WordPress site. Then you have a separate domain such as CDN.MySite.com, the endpoint at the CDN's company's servers. You would use a WordPress plugin generally to automatically rewrite all the URLs for your images and your CSS or JavaScript files to go to CDN.MySite.com, follow your main requests for the home page and stuff, still go to your dot, dot, dot, dot, MySite.com. So when the request goes to CDN.MySite.com, if the CDN has already cached your image, you would just serve it. That would be the end of it. It would happen really quickly. If it's not there, the CDN makes a request back to your main website and pulls that image in, caches it and serves it to that person so that the next person can get that image. It's really very transparent and it's pretty easy to do. It will make a big difference in how fast these things are served. So the CDN request goes to right there, to the home to CDN, where MySite.com, as I said, goes across wires and tunnels and under the ocean and through local fiber optic or copper cables and finds the WordPress. There's a big difference in what's going on with the request here. The reverse proxy CDN is actually what I see more often and would be what I would recommend using if you were getting started. How this works is that your request to your site, www.mysite.com goes first to CDN. It doesn't go right to yours or it goes to the CDN. Works kind of the same way where it serves files, movies, audio files, things like that. But because all of your traffic is going through the CDN, not only can you do this layer of caching here, you can apply security rules for the web application firewall. You can do things like optimize images on the fly. You can even do voltage caching on the CDN on some of these solutions. Now, some of the CDNs are allowing you to run JavaScript code on their servers at the CDN line, which I've seen applied to really innovative things, things that are changing the content on the page or on the fly during your request, specifically when running a firewall. Let's say you want people to pay a dollar a month to do through your site, but they have to authenticate. You can do that with JavaScript at the CDN before their request ever gets to WordPress, so WordPress doesn't have to know anything about all that kind of stuff. So, yeah, so that's the difference. This is completely between the browser and your site. You just go behind all these wires way, far away, but there's a CDN in between at all times where you apply this caching in different level of rules. Okay, so we're back to our diagram here. So we'll change the labels of this to be a full-page caching as things come out of our hosting environment, and now we have the CDN caching images and possible pages very close to the user. The last caching I'm going to talk about actually happens on your computer in the browser. So this is the best because now we don't have to make requests to you anywhere to get the benefit of caching. Your browser itself will save these files which, you know, that's definitely going to be the fastest way to serve if you don't have to go anywhere. You're going to have to make requests to anywhere else. Your browser already has these files that will just serve them. Browser caching can be used for the same kind of things as CDN can be used for and mechanics of setting these rules are pretty similar. This is the WorkCamp Seattle page load. We're looking at an improved inspector tools. The first part of it is the main request of the site and that actually goes to the server and it loads from the server. The rest of these you can see says from dispatch, from dispatch, from dispatch all the rest of the things load on page, the images, all that are serving from my local browser which means it's super fast. The first time you go to the site these images all load from the server and save in your browser. Now the next time you go to it, your browser already has all these things. It's not loading a new version. It's just loading these from within your browser. You set the rules on this in either Apache or Nginx. There's lots of tutorials about how to do this. How to set up browser caching in the library of Apache if you are using a CDN there's often an interface for setting up those rules from a CDN event and overwrite what's coming from your server. So this is great and there's no reason not to use this if it really does help performance. So one last thing on this slide. Part of the motivation for this talk is that Google is starting to pay attention to these metrics more and more. And especially this summer I've seen a lot of clients a lot of big clients of ours really start to be impacted by this. Google is constantly making changes and what they made this summer really is starting to focus on web page performance. You might have seen there's like GT metrics there's HP that's provided by Google there's lots of HP tools for measuring your website performance. But Google is also measuring your website performance every time somebody loads your site in front of them. They're gathering telemetry data about this. So if you're not using best practice system browser caching or CDN or maybe when you get a lot of traffic and your site is crashing Google has telemetry data about that and knows how fast it is. It's not just serving the site up for the Google bot to be fast, it's serving it up reliably every day to be fast. And only the fastest sites with good content that are stable and reliably online are going to be ranked high in Google. And if you talk to any SEO consultant it will say age performance is important you can keep going like okay, yeah, yeah, yeah what do I need to do these are some of the big tools I use every day to achieve that goal for sites. Alright, so this is the part about how to actually implement some of these recommendations with Microsoft's. So the easiest thing to do is to just use a managed WordPress host. Stop trying to do this on your own and sign up for WPS for a more presentable or even some of the lower cost of a managed WordPress host. Like GoDaddy, DreamPost, you know, who host. If you use a managed WordPress plan and you're not using like CPanel or the absolute cheapest share hosting all of the expensive managed shows that I have on the top include full page caching and most of the ones included on the bottom of this list include caching. This is just a small list there's SiteGround it's a gigantic list of managed WordPress hosts out there. So find what you like and find what it has and put it in. The price of it works for you and you will get built in caching. Not all of them included but most of them do and it's great when it's built in because the strategy for how it works and how to set it up if you've already kind of figured that out you just have to make them the money and host your site there and you will get the benefit of their full page caching and all the systems that they set up. Hosts like Campion well all those on the top have options for integrating a CDN Campion I think all of their clients come with an integrated CDN they even do full page caching on the CDN level. So this really makes it easy. They also most of these support object caching where there's just a button in your dashboard turn off the caching on and off so this takes care of almost all of your problems. If you are more doing it yourself like you have a digital ocean server or you're doing this non-shared hosting there's a lot of WordPress plugins that can also make this easy for you. Full page caching is a pretty solid problem. The WB Super Cache plugin is where I recommend people mostly start as well supported automatic is supporting it at this point it's been around forever and it works on pretty much any site. If you're using managed hosting you don't need all of this but if you're doing it yourself this is a really easy kind of plugin to get started. For the CDN Cloudflare and Secure you both have really nice interfaces it's pretty easy to get started with that once you kind of go through their setup and follow the instruction you'll have kind of automatically the benefit of both firewall and and CDN caching for your images and things like that. For browser caching I think the easiest thing to do is if you're using WordPress or Secure they have button suppressor interfaces you just override it and say I want things to cache in the browser for 2 days or 30 days or whatever so that's pretty easy too. If you want to get more advanced these are the tools that I look at and I use. For full-page caching we use the backcache WordPress plugin or we use Varder which is a totally separate software that you would install on the server but in the absolute fastest most configurable caching setup you can get. For object caching there's a WordPress plugin that integrates with Redis and we use Redis installed on the server. CDN Cloudflare and Secure really work great for all your needs. There's a ton of different CDN providers out there so you can find one that matches what you need. For browser caching the general way you would set this up is you would use internet or patching to define specific headers for when the site loads it tells your browser how long can it cache this asset for. There's lots and lots of tutorials and information online for how to set that up. So the key takeaways here the definition for caching is storing information in an easy to access location to be used later. The data we can store here the results of queries for API calls and object caching we can store the entire HTML page or call page caching or we can store images and JavaScript files and any media assets that might be served like that's the CDN or a browser caching. So you're going to get started somewhere starting with full page caching that's going to have the absolute maximum impact of any of these caching options in terms of speed and scalability and it's also one of the easiest to install and configure and just start with. The second one I think is important if you have a problem with the caching it's not actually very likely that it's the caching plug-in's fault or problem most of the popular caching plug-ins for WordPress work really well there's probably a plug-in or something you could be or some other growth that's doing something wrong that is causing that problem so if you're like, ah it's all caching and it doesn't work and there wasn't something wrong with the caching plug-in it's probably going to take a look at your site to try to really figure out how to not just lay the caching plug-in and turn it off. There are some caching plug-ins out there that try to do 800 things and it's like I installed it now there's 20 different setting screens with 800 buttons and I don't know which button to push if you're not sure what to do get rid of that one and try to get a plug-in they're simpler ones I really like in WordPress to find a plug-in that does the one thing I want to do without many options or settings so WBC Supercache has too many options and it isn't working kind of on the default there's a plug-in called hypercache that's even simpler than that I think there's plug-ins that are even more simpler than hypercache or full-page caching so if you don't like it and you're finding confusing and you don't like the documentation try a different plug-in there's a lot of them and it's important to find something simple that you're confident in that you know is doing just the thing you want it to do and this is my advice for all WordPress plug-ins really try to find something that's focused on doing what you want to solve and isn't the engine scene so this is me, my slides are going to be up there and thank you for coming you got it done to me today I'm going to talk about caching with using the cache specifically with iOS devices it seems like I have to do the the only way to get rid of my iPhone is to do the privacy setting and the terminal set process is there an easy way to transfer from that in there yes and thank you for asking, that's an excellent question, the question was about if you have things that are caching in the browser and you're doing development and changing your CSS or you have new images or something like that how do you get these devices to clear and have these stuff with your old cache programs like this too sometimes impossible to clear that stuff out of the cache so when these items are cached in the browser or cached on the cdn the way that they are uniquely identified as that specific css or js file is the url so if the url changes it's a different thing to do that is to not actually change the url but to change the query parameters that are at the end of the url because that's included in identifying the file as that file so if you were to append something every time you requested your JavaScript like question mark version equals 1 or question mark version equals 1.2 you can change that version number and when you change that version number the browser will see this as a new file and be like oh version you know whatever version 1.3 you can cache that separately from the old one so there's a couple of plugins in WordPress that do this there's one that's called dynamic asset versioning and it automatically does that when any of your files change on disk it changes how WordPress requests those files so you don't have to really do anything it just gets appended a different number at the end every time that's how we solve that problem you can also do this there's ways to do it in a code where when you enqueue it you know add the version number thing at the end of it you can do it manually but I like the way you plug in does that answer your question? it does it seems there are a little bit different things dynamic asset versioning is more aggressive because they're trying to optimize on bandwidth and people might not have all the mobile data or connections you would have at home with broadband so I think it really impressively caches but I think the same trick with app versioning or assets will work dynamic asset versioning yeah explain the difference between memcash and redis there's not really a good reason to use one or the other I would probably go with redis because Gambion has a really nice redis plug-in for WordPress and it's updated it works well but memcash and redis do really the same thing you shouldn't go on code no they're redundant if you happen to be in an environment where you have memcash already whatever you can use memcash it works great there's not many cache plug-ins or memcash if I was starting now I would probably use the redis one just because the plug-in is so good so if you're a webmaster do you use the redis one yes some of that data is from the crawler how the crawler sees it most of that is how the crawler sees it if you go to the google page the insights page and you run a test on your site there'll be two boxes at the top that it will say give you kind of like a performance ranking score and that data is coming from Chrome it's not from the Google crawler and if you don't have a site that many people have gone to you won't give you a performance score you don't have any data on this to really say it's good or not but if you have a popular site it will show you in these two boxes a performance score that data is actually coming from from Chrome and then if you have like a google cloud account you can get in and there's all kinds of data you can inquire about it I think I haven't actually gotten there but I read it there's a google cloud account and there's more data so yeah on the browser cache at what point does the browser start degrading the people we know not everybody is out there is going to use best practices and start shoving large images to the cache from the browser how does the browser handle that at what point I'm not that worried about that in the browser all these images just as files on your disk so the images are just sitting on your disk so you're loading from the disk rather than loading it over the network is there a point I mean people are just continually sending all these images and things like that because they really don't care at some point someone is going to start degrading that you're going to run out of disk space eventually browsers you know I'm not 100% sure how that works with browsers I do think they intelligently have managed that cache based on how often you go to that site if you're running out of disk space stuff like that I haven't found any degradation on performance where I think you get into trouble with degradation of performance of browsers is when you're loading a ton of stuff with JavaScript like you have all these JavaScript ads or it's not the JavaScript files themselves but now you're running all that code in the browser rather than on your server and in the browser not everyone is going to have a brand new Mac with Pro you're going to have people with a 5 year old laptop that's not super powerful and it might work great on your system but not everyone is going to be able to run it that fast so that's more what I worry about about getting browser performance a year or so do different caching tools have like a negative interaction with one another yes sort of it's important not to it's important not to have redundant caching it gets really difficult to manage and you get rules that aren't going to work right and you have things trying to step on each other so if you have one object caching going on don't think oh this isn't doing everything now you need another object caching you can switch to another object caching and don't use it too at the same time don't use full page caching at your hosting provider and then use full page caching at the CDN if you're going to use a CDN like Fastly that you can do full page caching on go to the trouble of setting up full page caching there turn off the full page caching on the hosting provider or at least think about it and make sure that they're not stepping on each other's toes and in the expiration time they're set up to copyright each other rather than why caching for 10 minutes here learning caching for additional 20 minutes here now it's actually 30 minutes and now you can't tell where it's going wrong so just be deliberate about your choices more caching isn't always better find a solution for each kind of layer of that caching that makes sense in the overall concept at what point in the development process do you recommend using caching at the beginning or yeah, I like starting right away with caching in mind and having it in an environment where you have caching enabled is great because you can see how everything works with the caching system I'm not sure I think a local like local flywheel they're putting here I think has caching available they got asking about that but having an environment where you can play with caching and see how it works really helps it makes it easier because you end up at a place where it works with caching and you don't have to go like right here for the most part most sites should be very compatible with full-page caching things that would screw this up are if you're doing day-to-day caches or collecting data on the front end of a site specifically I see this when there's sites that have some plug-in you know, tracking 404s or tracking user data they come to your site I would use an analytics platform for that I wouldn't use WordPress WordPress then you can just cache the page and operate the database and that's where you get into scaling a lot of scaling problems but for the most part or what most people are using WordPress to publish contents full-page caching is going to work it's going to be a very simple thing to be able to make work sometimes I get this message you want to delete your cache on the dashboard and I'm never sure should I delete it or what's the point I'm not sure that's a good question do you know what kind of caching plug-in you're using or anything like that so generally the times we want to delete your cache if you did something like I published an article and for some reason you can't see it when I visit my site possibly there's a thing that has gone wrong with caching and if I cleared the cache the old version would go away and now it would load everything fresh I don't think that in most cases there's no reason you would ever be able to clear your cache all the programming should just do its thing and work fine if you get into a situation like that and there's some weird thing going on sure clearing the cache is a good thing to try to see if well maybe that'll make us like you know turn it off and turn it back on again maybe something weird happened and that'll clear it out so by developing the customized plugins so instead of good practice to maintain the cache or like handling the cache but globally what is the best practice while doing the customized plugins if you're doing custom plugins what's the best practice well don't make breaks to the database do reads and share your content and don't log stuff unless you're doing a plugin that's like WordPress comments or a form or something if you look at the WordPress codex there's a lot of documentation about how to leverage update caching and there's some simple calls in WordPress when you're doing this development that you can say okay we're building this whatever widget for most popular content right so when you do the database calls to figure out all these things you can then cache the results and it's really easy because WordPress gives you a function you can say basically cache the results of all this stuff and cache it for this log and so you built that into the plugin that you were building anywhere you have something like expensive going on you can build that in and if you don't have caching there's no caching going on on the site it doesn't matter it just won't do that it'll just keep doing the database query it'll just ignore that but if they do have caching it'll start using it there are some good resources out there on the WordPress codex they work for 10up we search 10up engineering best practices we talk a lot about it you know our best practices which are open source available for anyone to read yeah so then if you have a site where every single page either has a place to comment or like a mail chip to sign up you full paid caching is not applicable not necessarily it depends how the commenting is set up and your norms are set up in general a form submission if it's a form click the button it submits a post request to the server with all that data and you get like a thanks for submitting a kind of thing or some sort of feedback oftentimes those are built either with JavaScript when it's a post request that's not going to be cached most common stuff like that with comments or just a newsletter sign up is actually cacheable it depends on how it's built it depends on the comment system but the WordPress built-in comments should be very compatible with full page caching and defined and most of the email forms should be defined as well because you don't get a it doesn't change the spirit every user is going to be served the form and they're usually okay with that it's definitely something you would want to if you have no caching and you're enabling it those are exactly the things I would test for making any caching changes test those things and make sure somebody else likes it works and you're not doing the wrong I think all these people putting up their wrists means time is up alright thank you