Mastering Laravel Caching: A Case Study with Laravel News

Welcome back to the Laravel Creator Spotlight. With me today is J-Mack and uh if you tuned in before, we've been working on the Laravel news website trying to get better caching and uh and he's got a new a new app or a new ebook out. It's called Fast Laravel and it goes through like how you can start doing this for your own apps. So, we thought this would be an awesome use case. So, welcome to the show. Yeah, thank you. We started this a while back. I'm glad we're glad we're coming back to it. I know we had some other other things pop up. I think you, Flair, Connie, you and then of course the Larball 13 launch, you know, making sure I'm heads down on that. And then uh spring break, all sorts of stuff. Yeah, kids prom. It's just everything. Kids prom. Nice. I'm not there yet. That'll be that'll be a weird a weird time for me, I think. Oh, yes. Yes. Um so so just to kind of fill us in uh for those that didn't watch the previous one, what all have we done up to this point? Do you do you sort of have the highlights? Yeah. Yeah. Off the top of your head. Yeah. I think so. The goal here is that because you have kind of this news site with, you know, theoretically you have articles that are the homepage is changing to have like the latest articles and sponsors and links that are submitted by the community and and so it's it's a very dynamic site in the fact that the content is changing. And so the reason I kind of wanted to use it as a case study is that, you know, to prove that like you can have a a very dynamic homepage. It's easy to say, "Oh, my little brochure course landing page can be cached, right? Nothing's changing on it once I launch the course, more or less." Um, and if it is, it's not a big deal if someone gets stale content. But, you know, as you get into other sites, even Laravel shift, like not a big deal if the counter at the bottom's a little delayed, like it's not like the prices are changing on a daily basis or anything like that. Um, so, you know, you kind of move up the ranks. So I think as you get up to like a news site or an e-commerce site like these are very content heavy sites that maybe a lot of people on the surface would say well you you can't cash that. So I just thought Laraveville News was like a great um you know a great case study to kind of do that. So, I think when we jumped in last time, again, this was this was probably like February, so a couple, you know, two months ago or so when we jumped in. I think the first thing we realized that kind of was the blocker wasn't so much the content, but the way the site was kind of originally built was it was using LiveWire components in in a lot of different areas of the page. But the funny thing was the LiveWire components weren't reactive in any way. They were never like refreshing their content or updating after the page had been loaded. They they were really just built for convenience because you know it's easy to make something in LiveWire and it feels very Laravelesque with the with its own blade components and stuff. Um you were using some computed properties that had a cache though. So basically what we did was we made all of those livewire components just straight blade components and anything that was a computed property we pushed to like a service class that now just caches it underneath directly with Laravel the same way that the computer property was being cached in in LiveWire. So we probably changed you know maybe a dozen components but it was really just a lot of search and replace. It was a very straightforward refactor and that ultimately made the page cachable. I think the only other thing that we found along the way is your newsletter signup on the homepage just needs to be a little bit it was actually a little bit reactive. Um, so we just turned that into like a very simple Ajax request. I think I did that on one of my own live streams. I got the guy who made Alpine Ajax. Um, it's like a it's like an add-on for AlpineJS to be able to make like Ajax requests and kind of resubmit a form. And for for those simple use cases, you can just plug this in and add like one attribute and it works much like HTMX does, which I cover in the course. But anyway, that was that was kind of the only catch was that there was one little component, the newsletter component that did have some reactivity in in the fact that it allowed you to submit the form and said, "Okay, you've been added in the newsletter." So, yeah. Yeah. Exactly. Yeah. the whole site's kind of textheavy and not a lot of like you said not a lot of reactivity but uh so this made sense as a refactor for sure. Um so so we've got um we've been working in a staging branch and we think we've got it ready. Um and today you we're just going to merge it and push it and cross our fingers. We're we're going to go for it. Yeah. I mean it's kind I mean we can go ahead and get started but yeah there's kind of like a two-phase thing. First of all, we want to make sure that our refactors feel good in production. And then once they do, we'll we can jump into Cloudflare and actually enable caching for the site. And the pages that we have deemed to be cachable uh through some middleware would then start being cached through Cloudflare's page cache. And we will be able to check that in the browser as well. But I think first is really just deploying and making sure we didn't break the site with our refactors. It should with any refactor, it should look exactly the same on the surface, right? We're just kind of changing around the underlying um implementation, not the behavior. Yes. Yes. All right. So, let me I'm just going to share my screen and that way let's see. I think I can do this entire screen here and then I can open up GitHub desktop. Let's see if I can remember how to do this. Uh uh I think I'll have to do Yeah, I think I have to switch to main and then uh and then Well, no, that's not it. Now I'm going to have to do it through the through the terminal, I guess, cuz I cannot remember. I know it's easy. Okay, I'll just do it through the thing. Origin fast Larbell. Boom. All right, let's see if this works. I'm just going to get push it now. I mean, if GitHub's having problems, it might crash everything. Seems like they accepted it. And once this finishes, All right, we are deployed. Sweet. All right. So, everything's working. Um, so yeah, if you go to the homepage and we inspect and we go to the network tab on the inspector. Yeah. Get rid of just reload the page. Uh, switch the filter. Right now it's on all. If you go to doc. Yeah. And if we click that. Cool. So, yeah, we're getting headers here now. Um, okay. Yeah. Cool. So, see the cache control header is max age 600. So this is our custom header. So basically what we're saying is the browser can cache this for 10 minutes. Uh Smax age or the um static shared proxy cache, meaning Cloudflare caches it for a day, but we're still getting dynamic in the CF cache status header because we probably have not gone on Cloudflare and enabled um that specifically. So, ah, so do we need to go do that? Um, so that would be the next step. But I think first before we do that, I think we want to basically just make sure that like clicking around in here feels right. Maybe sign up for the newsletter one more time. You can close the inspector. We'll come back to it later. All right, let's see. I mean, there's no glaring errors. We'll just join for free here. Boom. That one worked. Yeah. Um, we'll try the homepage one. Okay. Oh wow. So to me that means we either have a JavaScript error now. Does your deployment rebuild npm stuff or no? Um probably not. Let me do that real quick. We might need to do that locally. That's probably the issue. So we might actually need Yeah, let's do npm install. Make sure we got the latest cuz I did probably bring in a package. Okay, there we go. Yeah, let's commit all those up and go from there. That should fix the newsletter sign up on the homepage. There we go. Switch back over here. Wait for it to finish deploying. Also, I have a typo in my header. So, I'm going to fix that, too. I think I left a dash in the max age, but the shared one is is just sax all one word. Say um fix header name. Get pull-r get push. Okay, got another deploy we just triggered. We're fixing it live. There you go. Yeah, fix header header name. Um, the JavaScript says it has fixed. So, we can test that, I guess, while that other's deploying. Let's see. Boom. All right, there we go. Okay, cool. Perfect. So, that one works. Yeah, crushing it. Love it. So, yeah, once this other one goes, we could we could check the um check that name again, and if it looks good, then yeah, we could go try to get Cloudflare respecting our our cache header as well. go to. And now when you deploy, I assume it like clears the routes and all those kinds of things or no. Um I think so because I think I'm pretty sure we're caching the routes. I can double check that. Um yeah, s max age all one word. Okay, cool. That should be correct. That's right. Okay. So we've got that. And then so you're caching at the browser level right now, no matter what, without Cloudflare. We want to turn on Cloudflare because it creates an an extra edge cache. So, we're still not even hitting the server. Because right now, if you like hard refresh this page, then it's going to go all the way to your web server, reload, and then send it back. Otherwise, we're going to keep getting like these 304s because it's cached in your browser for 10 minutes, like perpetually, so long as you're browsing the site, right? But we want Cloudflare to be in the middle because Cloudflare can cache it longer um and serve it from its edge which will also be very very fast save you the requests and traffic on your web server. But what's nice of why we would do that and never just cache in the browser alone is you get control on Cloudflare. So we can actually purge its cache just like we can flush the cache in our Laravel app as well. Wait, that'd be awesome. Okay, so switch over to Cloudflare I guess now. Yeah, I mean it seems like the major parts are fine. And that's not to say some internal component on some deeper page of the site is incorrect, but nothing glaring is broken other than our forgetting to rebuild JavaScript. So yeah, if you go to caching, uh Oh, yeah. We'll want to make sure that your um configuration Oh, no. I'm sorry. You were right. Um Oh, cache rules. Cache rules. Yeah. So, we're going to create a rule and we'll say uh yeah, cache rules. And you can turn on cache everything. Just create from template there. And you can kill the template part in the name. just leave the cache everything. So, this is going to say all incoming requests. That's good. And we got to say they're they're eligible for cash. And then we could more heavily configure this if we want to, but because we have a pretty elaborate um cache header, we shouldn't need to set anything in here. If we were doing more complex caching or we wanted to configure some defaults at the Cloudflare level, we could hit those add settings buttons. But I feel like because of our pretty strict explicit cache it this long on the browser and cache it this long on a shared cache, we've already kind of differentiated some of the stuff that you would do here. So it's really just telling Cloudflare that you have a rule to cache everything that has a cache header. Okay. So so we're good. Yeah. And you can easily disable this um with like a click of a button. So I think you're cool to go ahead and deploy. All right. Only things that set a cache header would have this. And we should only be setting those for your homepage and your article detail pages. Okay, perfect. So if we go back now and we refresh again, I guess you can't. So notice our CF cache status now is hit. Ah, okay. Right here. And so instead of refreshing with the browser, if you just start to navigate and we can accumulate some request traffic in our network tab. So, if you look at Laravel Sluggable here before, um, notice that it's a 200. If you click that Laravel Slug Sluggable, so it's dynamic, but I think if you were to go and like reload this page, we should see the second request being a hit. Oh, okay. Still a miss. Let's hit it one more time. I think that first time it thought it was dynamic 304. There we go. Cash. Yeah, there. There you go. So, it takes a little bit to warm the cache, but now that it's in Cloudflare and it's local, you've got kind of this Russian doll caching aspect. It's going to stay super fast on your machine. Basically, you see the disc cache there on size. 2 milliseconds. That's how long it took for the page to load. No request across the network, no server traffic, nothing. So, yeah, you can have a super fast server and all that cool stuff, but like you're never going to beat the browser or an edge network or that's always going to be super super fast. So, I like that things could be caching. So I think the next the next thing is like 2 3 days from now you know you look at Cloudflare your overview page with like the metrics and you'd want to see that that percent cache you know really starts to tick up here in the next few hours. And then we'll go Yeah. So it'll take like you said what 6 12 hours and then hopefully we'll see. would see I would like to believe that you should see a pretty significant hockey stick over the next you know 6 hours that that percent cashed and then 24 hours from now you'll be at pretty consistently at whatever lay level that is. Mhm. And I think we looked at it like your homepage and article pages are like a majority of your requests. So yeah, like once that cache starts to warm and and and get all the different articles from the homepage on there, again, I I would expect definitely 70 80% cached, maybe even in the 90s, which means 90% of your requests of your quarter of a million requests a day are just served straight from Cloudflare. They never even touch your web server. Yeah, that'll be nice. and then and then I can go into cloud and actually bring down the services that that cuz I probably don't need that as I don't need them as big as what they are right now once this is in place. Yeah. I mean you yeah you could definitely like that would absolutely allow you to kind of like reassess how much you know we don't want to go like Ian Lansman childlike uh you know web server necessarily but you know you might be able to move from you know a four a four CPU to a 2 CPU or or a one you know um if this is the only site on there because again 90% of your c 90% of your requests um are going to be cached and and we can we can keep ticking that up like there's more pages on this site we get cash. Uh, so I feel like confirm confirm the hockey stick. Let that stay stable for, you know, a week or two. Make sure you have the, you know, let's make sure we have all the right pieces in place where like when you change an article, it it flushes the Cloudflare cache, you know, and all those kind of things. But yeah, I was I was seeing if I could drill down into like quick like last 30 minutes, but it's Oh, this is last 30 minutes. So, you do notice um on that last one it was saying served by origin which is your web server. I mean you're already Yeah, it's already kind of flipping. Yeah, look at that. So, yeah, as again as as you're getting traffic, given the amount of traffic you have, I I would really think within a few hours of data points, you're going to see some very inverse graphs happening. And it's not just about server costs, too. I mean, it's your users, right? Like people reading the articles are going to get snappy article pages now, right? I mean, they click and they're going to see the article. There's no there's no delay really whatsoever. Sure. I was I was looking at this one. You can already see I want to say that hit the green, but that might not be accurate. I don't know. Pro I'm probably trying to jump ahead too quickly. Yeah. No, I mean, it's exciting. It's exciting. So, yeah. And you're gonna, you know, the discount might be big at first because we just enabled um caches, you know, caching, but again, as the cash warms and you're caching stuff for a day, you know, I think all of these metrics are going to are going to change. Dynamic should go way down. Well, that's the one I was just looking at. The dynamic is almost uh let's see if I can hide all these except for the dynamic cuz it looked like it was uh jumping way down. Yeah, which it should because what happens by default in a Laravel application is a is a Laravel application is built for the web and so basically out of the box they give you sessions and cookies and things of this nature and because of that Cloudflare automatically considers that response dynamic. Even if you set cache control headers and you have enabled caching, it's going to bypass it or it's going to consider the content to be dynamic because the cookie value is dynamic. But your site might not be using cookies, right? You're not using cookies for your homepage. Um, no, you might when you log into the back end of course, but not not your public pages there. There's no cookie that's that's being used there. So, what we do is we basically disable Cloudflare's cook or or sorry, your Laravel application cookie that you get by default because you just don't need it. There's nothing wrong with Laravel giving it to you. It it it wants you to have like batteries included, you know, ready to use framework, right? It's fullfeatured. Um, but it's a little nuance when you get into this page caching that you kind of have to be aware of, like, am I using cookies? Do I have truly dynamic pages? Where where can I make that line a little gray? Right. Um, even on a large site like this news site, like it's pretty clear like your article pages don't change unless you edit them. you have a clear point where you could flush the cache when you edit uh which we've added and then otherwise just show that show that page forever like it doesn't change right. Yeah. Yeah. Exactly. Yeah. It's it's this like this sluggable it's always there until we decide hey whoops we forgot something or we we need to make a change but yeah that's and once you do we can we can invalidate it and you know theoretically the change we we are caching with the browser for 10 minutes. So there is a lag potentially if someone was on this page and there was a typo and you did edit. There is a there is a crossover but I think that's an acceptable trade-off. And of course if you have a a more important site you can there are things you can do which I cover in fast lavel to get even more complex where you make it re even though you're caching with the browser you can make it revalidate to make sure that like the content hasn't changed using additional tags and so forth. Um, I don't think that's needed here because you're never going to publish an article that's like blatantly ridiculous that you have to like retract. You know what I mean? Like there might be a typo, but it's not worth busting that person's cash for a small typo. Right. Yeah. Exactly. And even if it were some kind of major typo, the whole system will just kind of naturally flush itself, you know, in just a few more minutes. So, picks itself. I love that. This is awesome. Yeah, I think I think this is going to be cool because you know that's having a content heavy site. You know, if you ever do like just like the random times like you get featured on like hacker news or it you know you'll get just hammered on one page and it's like you know it takes your whole system down. It's it's so annoying. So now you never even have to worry about it. Yeah, that wouldn't happen. And and it it you know it it doesn't it's not even going to hammer I mean Cloudflare can take it but it's not even going to hammer Cloudflare again because of that 10-minute um browser cache. you know, if someone's sitting there reading the article or they're bouncing around your site, they're going to just use their own browser cache as they navigate around for the length of their session. You know, again, most people aren't on sites for very long to be honest. I mean, even when you're ordering stuff on Amazon, you're not on there for 10 minutes, you know, maybe maybe five. I mean, you know, so yeah, you're reading a large article, we chose 10 minutes, but I think for the most part, that'll that'll definitely cover things. But yeah, that'll be very interesting to see. And and again, it's it's the whole stack, especially a site like this. Like when you're hitting the page, it's not just loading the page and the components and all the Larbell framework and the code, but you're hitting the database to get that one article record. You might be pulling links from sponsors and and all that kind of stuff. So, it's, you know, it's fast, but it it's heavy, you know, definitely compared to two milliseconds. Like, yeah, no way. No Laravel app top to bottom is going to run in two milliseconds. So unless you're I love that. That's perfect. Uh well, is there anything else we need to check while we're here or you think I mean it's pretty to me we've our changes are here. They're present. They're working as intended. Um you know I think the thing to do would just be sit back, calculate some metrics, make sure you don't get any error reports coming in in your and you know, however you're looking at that nightw watch or whatever. Um, just keep an eye on it for 24 hours and then, you know, ping me. I'd like to see what your your stats look like in 24 hours. And we should probably just make sure that, um, managing the cache is a smooth thing for you. I know we added some code when you added an article to automatically flush not only your application cache, but also now the Cloudflare cache. Um, right. So, we should just make sure those things work and they feel good. And if you find any other places where it's like, "Oh, I changed this over here and we need to make sure that flushes the cache, too." Like those will be the tricky little rough edges, but your users never see those. That that's more for you, like site maintenance, right? Yeah. Yeah. We want it to be as automated as possible, right? Exactly. That's awesome. All right. So, let me go to We got to shout out the course. Everybody watching, you got to go here. You're you're level but fast. So, this is the new course that JMac has launched and that's what we're going through here with this and uh I think it's amazing and you know if you have any site any app that actually gets a lot of traffic you should definitely check this out because I think it's going to be hugely useful. Yeah. Well, I'm glad I'm glad we did the case study. I want to do more for the community. Uh but of course, you know, if you have your own apps um you know this this little graph here was actually taken from laralshift.com. you know, I started at 6%, I got it all the way up to 99%. Uh, and basically just put everything I learned along the way in this course. Um, and now it's kind of just a matter of like proving and educating and and showing you the power of it, right? Um, I'm kind of doing it a little bit backwards. I know some people are better at doing that before they launch. Um, you know, me, I like I get these ideas in my head and I kind of just end up turning on the camera because I think they're useful and I I don't market them properly. Um, so I'm kind of doing this a little bit backwards. Uh but yeah, hopefully hopefully it helps uh gain some awareness because these these are just really really simple age-old honestly age-old tactics that have been around the web forever and they're going to stay around the web forever and if you're building any kind of website or app or whatever it is, not even Laravel. Um you know these cache headers are baked into HTTP like this is all part of it. Yes, for sure. All right. So, let me I'm I'm gonna I'm gonna stop my screen share and um I think I think we're we're set. We're golden. So, um like like you said, yeah, we'll we'll let this run for a couple days. Um I'll report back to you and let you know what we find. Um yeah, don't hesitate to ping me like if you see any kind of errors or anything come across. Um but I feel like based on what we just looked at, like there's nothing obvious, right? So there might be a subpage of a subpage we forgot the component was on and you know maybe we got to fix it. But it seems like your main pages are functional and those status headers like show me that it's working. See? Yes. Perfect. Perfect. Well, Jac, I want to say thank you for, you know, taking the time to help me through this. I'm so happy you picked me as a case study because, you know, I feel like I get a bigger benefit than you're getting out of this. So this is this is exciting. It's all fun, dude. And I know I know we go way back and we're kind of in similar boats as far as just trying to eek out our eek out our business in the Laravel world as long as we can. So, um, exactly. I'm glad we finally merged it. And, uh, yeah, do keep me posted. Um, don't hesitate to hit me up. Um, if anything at all is weird with the caching, you feel it is, um, you can look at that header that I changed or whatever, um, in that last commit, just go and comment out that line and redeploy. Okay. And it'll Okay. It'll it'll it might take a minute again because people have browser cache, but I would think within 10 minutes you would see that resolve itself. Sweet. Gotcha. If there's anything bigger than that, then of course again um, ping me. But other than Thursday, I mean, I should be available this week. Um, awesome.