CDN Caching, Static Site Generation, and Server Side Rendering

welcome back to another remix video we are going to talk today about cdn caching which we talked about before but we're going to get a little bit more in depth this time static pre-rendering or static side generation and server rendering we're going to kind of talk about different approaches and how how we're how we're generally building websites these days uh especially in the react community um there's a lot of talk about static sites and server rendering and static pre-rendering and incremental static regeneration stuff like that so let's start with static site generation we're going to talk about what it means where the work happens what parts cost money what the effect is on the user who's visiting your page and then we'll talk about servers and other ncdns and things too so static site generation this is like gatsby or next when you're doing uh get static props um so it's just you and your computer you've got your website and it's time to build so you say yarn build npm run build and so what happens well your computer's fans spin up first of all and then you're probably going to make some network requests you're going to go off to a database somewhere a cms somewhere something that's got the data that you're going to use to build pages out of so there's work happening over on that server as well when you're building so it's not just your computer that's that's doing work here there's there's stuff out in the cloud stuff out on another server somewhere of course maybe you have stuff that's all just local on your machine but most most sites you're going off to some api somewhere and getting the data to to build the static site so it sends the data back to you and now you've created a document and then you do it again because you've got to make your next document so we're going back and forth and building documents and we do it again and again and again until we build every single document every single page in your website and then both of these places cost money it costs your it costs your time sitting there waiting for your build to finish um and it also costs money over on those servers um if they're yours anyway uh for them to process those requests so you can build the data so so there's compute that's happening locally maybe you're doing a build in the cloud somewhere something like gatsby cloud you're paying for that too um but anyway whenever there's compute happening whether it's some server or it's your local machine when you're building a static site that costs money now you got a cdn over here and you upload everything to the cdn so what's really great about static site generation is now that all those documents are pre-rendered they're pre-built they're just static they're just sitting there on a cdn waiting for somebody to come and visit your website to get one of those documents so they make a request and the cdn doesn't have to do any work at all it doesn't have to build the page doesn't have to render anything you can just send it right on back to the user and the user's super happy so you're going to see this emoji a few times we'll call it the smiley emoji you get a smiley when it's a fast response and it was a cached response so the user's happy because it's super snappy now let's say you edit some of the data what does that mean for static site generation well something in your database changed but your cdn still just has all those documents from the last deploy so if a user visits the page they're going to get a fast response but it's stale it's not it's not up to date yet sometimes that's fine so we're going to have this the sweaty guy for for a stale response so in order for us to turn that sweaty smiley into just a smiley we have to rebuild the website again so it's you and your computer and the server that's got all your data we've only got one little change document in there but the way the static site generation works is you've got to rebuild every single one of those things so that's going to cost money and then you upload everything again to the cdn and now this means that you build every page for every deploy for any edit server side rendering let's see what the difference is here so server side rendering with no cdn involved uh we don't have a big build step there's there's no build step at all you just upload your your website to the internet and then you build the pages on demand so when somebody asks for a page you build the page on your server and then you send that thing back but we got the yawner because it's kind of slow the user had to wait for the page to build so static sites it's nice because you built it before you sat there and waited for the build so that your users don't have to wait for the build every single visit cost you money you're you're running compute on every single one of those things uh however if you have some pages that are never visited you never build them with static side generation you're building every single page whether people visit them or not so um with the server you only build the pages that people visit if no one visits the server never builds it and never sends it so let's throw a cdn into the middle here so first visitor shows up they actually make a request to the cdn not to your server it's to the cdn cnn goes oh i don't have that document yet and so it goes over to your origin server that's you've maybe heard that term the origin server that's like your your actual web server and the cdn asks for that the user's still waiting your origin server builds the page sends the page to the cdn cdn caches the page sticks it right there and then sends it to the user we still got a yawner because we had to wait for the whole cycle this is just the first person ever to visit this url cost you money over there to build that page and send it to them however with a cdn the second visitor they request the page from the cdn cd and goes ah i know this i've already gotten this from the origin server so it can leave the origin server alone and send a response right back to the user so we got a smiler because it was fast and it was cached and it was fresh it was accurate um saves you money too because you don't do anything over you're not building the page now this isn't just the second visitor this is the third the fourth the fifth the hundred the millionth visitor so then there's this idea of max age when you have a cdn there's these static headers that we talked about last not static headers there's these cache headers cache control that we talked about last time and max age is one of the values in there that says hey this is this is how long you should cache this thing so it's in seconds so you can say it caches for 60 seconds cache it for a day cache it for a year so let's say that we were caching this for like a day and that time has passed well what's going to happen is a visitor shows up and says hey i want that page and the cdn goes oop this thing's stale this is old i was told to rebuild this or to go to the oregon server and have it rebuild it after a day so it's been a day so cdn goes to the origin server and says hey i want the page you build the page on your origin server comes back to the cdn cdn puts the new fresh one in and then sends it to the user and of course we got a yawner and then we had to pay money for our server to build that page but every visitor after that they now have the fresh page so what's interesting about this is uh when we have an edit we don't need to rebuild the whole website like static side generation it's just the pages that change that need to get rebuilt and with max age you can just kind of put it on a timer and you say you know what just every day if someone comes to this page again rebuild it but everyone else for the rest of the day just give them that version or maybe you decide this page is good for a week and so um you can just make an edit anytime during that week uh it's not going to show up on your website yet but after the cdn is like oh hey this thing's expired i'm going to rebuild it then everyone will get the fresh link so you kind of get to decide how often do you want it to get built rather than having to build every single page a here's a little graph for us to think about um how this works so you can see we've got the legend over there the ship is you're shipping your website you're going to deploy it uh the edit the data changed yawners user waving smiley is the cash response sweaty is cached but stale so it's fast and then the max age expired so if you don't have any caching you don't have a cdn you ship the site and everybody's a yawner but everybody gets fresh data too so this is kind of what this is what we want to avoid it's expensive for you because every request you're you're building a page for that user but what's good about it is everyone gets something fresh if you say max age three one blah blah blah that's a year that's as long as it can be basically that means forever so you ship the website and the first person ever to visit a url on that on that website they get a yawner because they've got to wait for the page to build but then everybody after that gets a smiler until you edit once you edit you get the sweater because we said hey this thing lasts forever so even if you edit it the cdn's never going to go back to the origin server and say rebuild this you can even deploy your website again nothing's going to change because you told the cdn hey this thing's good for a year so no one will ever get a new version of that document this is actually perfect for static assets for the javascript that you build and your css assets all that kind of stuff you've probably noticed in a webpack build or a rollup build that in production it adds this fingerprint this like this hash to the name of the file and then any time that file changes it gets a new hash that you deploy so that's great because because the url changes the cdn's not gonna we'll never seen that thing before so if the url never changes we can just cache these things forever unpackaged.com also it's it's uh you can't you can't change a package once you've published it to mpm and so unpackaged can has this very simple case where it can just assume hey version 2.5 of some library can't change ever so once unpackaged builds that page it can just cache it as for a year forever but this doesn't work for your normal urls your about page your contact page an article a blog post anything that has a url that doesn't change when the content changes a url that does not change at the content changes so it's it's the urls that the browser is displaying that like people are typing right not stuff in the network tab but stuff up in the address bar so this doesn't work for those max age 60. this is interesting we're saying this is good for 60 seconds one minute so you ship the website you get a yawner for the first visitor and then for the next 60 seconds everyone's a smiler fast cash responses you edit the page you get a sweater because it's fast but it's stale that's fine it's only going to be stale for another few seconds maybe another 10 seconds and so once the timer hits then the next visitor is going to cause the cdn to go over to the origin server and then come back again with with the fresh copy so they get a fresh version of the page but they're yawning it took a little while but then everyone for the next 60 seconds after that person they're going to get fast responses um and so and so it goes every every 60 seconds somebody's gonna have a longer response time than everybody else but everybody gets fresh data at least for the last 60 seconds so one strategy to mitigate against having so many yawners in there is to say you know what let's set a really long max age there's this other cache control value called s max age and that's for the surrogate that's for the cdn so far we've been talking about max h max age is just in the browser and the cdn will use it but if you say max age and s max age then s max h the cdn will say hey i'm not going to cache it for max age i'm going to cache it for s max age this is great because you can now tell the cdn to cache it differently than the browser which allows you to go in and purge so we got that like red cross out right there so what you can do is you can have these targeted purges you can say okay on my cms whenever i change one of these articles i know what the url is and so now i can go over and i can purge my cdn of that document and so you make an edit you write little script little cms scripts uh that say okay this url when i change this article we gotta go purge it over there and now the next visitor is the honor but they get the up-to-date thing that everyone else is happy after that so this is a really cool strategy it takes more time takes a little bit more code takes a little bit more planning ahead but if you can automate it it's a great approach a targeted purge and a long s max age you don't want max age long right here because you cannot purge the user's browser if you don't use s-max age with this strategy if you have a visitor who goes to your page they're going to have that page for a year there's no way when your cms edits a page to go to all your users browsers and say purge this thing so you set a smaller max for the browser like 60 seconds or a day and then set a big s max age for the cdn and then you can set up targeted purges to purge the pages that you're changing so how does static site generation fit into this well we've got a new icon here a new emoji the the tools the build that's the big build where you've got to create every single page on your website before you can deploy it so we've got the big build first but now everybody's a smiler because you're getting super fast fresh responses you edit the page now everybody's getting stale stuff until you do the big fat build again and then you can deploy and then everybody gets it gets happy stuff again so you're basically saying like any time any data changes you have to redeploy um some websites that's great other times that can be just way too expensive uh and remember it's not just your machine you might offload it to some cloud machine either way some machine somewhere is doing that work whether it's your origin server or your build server you're paying for a computer to build those pages one way or the other you may have heard of next js's incremental static regeneration so the idea here is hey you know what it's kind of a bummer that in static site generation we kind of we're kind of forcing dynamic data to be static data we're we're saying all right to get fast responses we kind of have to pretend like our data doesn't change or at least not very often but data does change often um so next solution here which is really cool and and um and i i think it's i think it's awesome is incremental static regeneration so what happens is you do the big build so you're still going to build the whole site every single page in the website and then you're going to deploy it everyone gets fast fresh responses then we got the little we got the little um tools in there that represent rebuilding just a single page so the way the uh static site regeneration works is when someone visits a page they get it triggers a a build of just that page and then it sends the the current version of that page or the stale version um might not be stale but might be as well but it just sent them what it's got already built and then builds it in the background and so now the person after that first sweaty sweaty emoji they're gonna get the result of the last incremental build and then someone else visits the page and it kicks off the regeneration again in the background sends them the current version of the page builds the new one and now that new pages are sitting there waiting for the next visitor next visitor shows up it gives them the current version of the page and then sets up a build in the background again so this way everyone's getting fast responses everyone's getting a pre-rendered document and everyone's getting something pretty fresh it's probably just off by a little bit so let's say if someone requested the page at 3 p.m they'd get a fresh one and then they requested at 305 pm they're going to get the 3 o'clock version and then the person who comes at 306 they're going to get the 305 version so everyone's just going to be just just one off but by by shifting it by one everybody gets a fast response we're going to see another little graph here that i think will help that that makes sense but the point here is someone visits the page they get the current version the current built one and then static regeneration kicks off build for just that little page so that the next person can get it so you're always off by one but it's always fast incremental static site regeneration from next is inspired by a cache header called a cache control value called stale while revalidate so let's look at what still while revalidate is just what the browser has nothing to do with static side generation nothing to do with next or any of that kind of stuff it's it's just a it's just a part of http caching so ssr with stillwell revalidate this is our first visitor after the max age is up you remember last time when the max age is up visitor asks for it it's expired the cdn would go to the origin server to build it but not with stillwell revalidate still while revalidate says hey you know what i'm just going to give you what i've got right now this this document's expired but i i really want to just give you what you want right now so it's stale but it's fast and then the cdn once it's done with that request that says okay i'm going to go over the origin server i'm going to revalidate this thing so it starts building on your origin server if somebody shows up in the meantime maybe you've got like a visitor right after another visitor while you're origin service you're building the cdn is going to go hey yup here have the stale one again i'm still figuring this thing out so they're they're good with their request and then finally our origin server is done since the new document at the cdn so you then cache that new fresh one and now anybody who shows up afterward they're gonna get the new fresh one it's pretty cool so if we have that one in we say a max age of one so we're saying hey this thing expires every second because our data might be changing every second we we think that this page is is highly dynamic uh but but we don't want the user to have to wait for the server to build that page every time we want to give them a fast response so we just shipped it by one so after the deploy uh we first get a honor that's just the very first time ever never again even after we deploy we're not going to get a yawner at this url um when the max h hits we get a sweater because it's fast but it's stale we're revalidating and now the next person who shows up is going to get it so we got a smiler and then the clock ticks again so then we send something that's stale we could deploy in the middle uh doesn't affect anything if we deploy in the middle and we don't have to wait for that big static build either and we don't have to build all those pages again we're only building the pages that people visit so you can kind of look at the two incremental static regeneration and swr you can see they're actually the same for the user right everyone's getting fast responses except for that very first very first person after the initial deploy of this url ever and that could be you right you make a new post go visit the page that was you you're done it's already it's already built so really none of your users are gonna get uh gonna get a yawner i think that this one kind of helps think about a little bit more so max age 60 we're saying every 60 seconds go back to the origin server so if we got a bunch of requests coming in everyone's going to be getting a nice fast response and it's going to be pretty much up to date and then once the 60 seconds is up the next visitor is going to have to wait for that new response so with max age 60 you can see here we've got a yawner every single time that this thing expires and we don't want that we don't want a whole bunch of our requests to be slow we want them all to be fast so incremental static site regeneration is saying hey why don't we give them the one from a second ago right if it if we're at the 60 second mark and this thing just uh is like we're saying hey this thing's probably stale now there's no reason we can't give just one more person that old copy they're only one second off if they were there a second earlier they would have gotten the same thing that we're giving them a second later so you can see the clock hits and instead of waiting to build we just send them what we've got new stuff shows up after that request and now everybody gets uh new fresh responses so everyone's smiling no one's yawning now you can see underneath that with max age one and stale while revalidate without incremental static site generation just server side rendering and a cdn and um and and your origin server that knows how to build pages on demand that's that's all uh that's all a web server is a web server is an incremental static site generator a url comes in it builds just that page and then you throw a cdn in front of it and now you're hanging on to that so you're building static pages just on demand instead of all at once but you can see here it's the very same where everybody gets a fast response we're just we're just shifting it over by one we're trading sending someone something stale that's only a second or two stale so that everyone gets a fast response really really cool stuff so really it's this question if you're using cache headers in a cdn and server side rendering how often do you want to rebuild max age one you're saying i want to rebuild every second so you got to think about what kind of a page is this is this uh well hey in the united states we just had an election and there's all the websites like every single news website ever had a whole team probably dedicated to building the election graph to show how many votes were coming in and all the different places and so when a user goes to that page we don't want them to be yawners we don't want every single one of them to be waiting for that new data however we do want them to have up-to-date data right we don't want to cache this thing for like an hour because people want up-to-date data so with with stellar we validate we kind of get a bend that trade off and we get to say you know what everybody gets a fast response it's just gonna be one second late or one second off it's gonna be early because it's gonna be a fast response so so what we're saying is like if you show up at 359 and one second you're going to get what you would have gotten at 359 and 0 seconds so we're just off by a second but now everything is fast and we build in the background instead of build while the user is sitting there waiting for it here's a way to think about it you go to a restaurant and you or a fast food place and you order a burger and you have to sit there and wait for them to build the burger and then come and hand it to you that's like having no cashing no static site generation no static site regeneration it's every time someone asks for a burger that person has to wait for the burger to be made well the restaurant knows well you know what it's almost lunch and a bunch of people are going to be ordering burgers so let's let's make a burger before we open just one burger it's going to be sitting here and then you walk up and order it and they can just hand you that burger that they already made and while you're ordering that burger they're making another one and so the next person comes up and it's like oh hey here's here's another burger for this person so these burgers are getting pre-made every second but they're not old they're they just barely got made so by doing this max age one stale while revalidate this isn't really stale content it's just we're not making the user wait for it we're we're using the last visitor oh it's not even really the last visitor all that much all we're saying is let's rebuild this page every every second and while we're figuring that out let's just send them what we've got right now so everybody gets a fast response everybody's burger is warm but it's just one second off but probably not because they would have had to wait a second for the page to be built so it's just it's such a cool such a cool technique so yeah so if you had an election page this would be great everyone's getting the fast responses and then your servers just every second going to the origin and saying hey what do you got now hey what do you got now hey what do you got now but then the responses can all be handled really fast have i have i explained that enough times so the next one is max age 86 400 i think that's a week and so what we're saying you know this this page is good for a week so we deploy it the very first time i want to check out the page i'm the owner and now everybody gets a fast response i might go edit my cms go edit my database whatever but i don't care this isn't like that important of a page that it needs like updates like that um you know maybe it's a i was going to say privacy policy but that's probably not quite right it's like an about page right like about us it's not a big deal if the about page doesn't update if you edit it on thursday it's okay that the update doesn't show up till monday so what's cool about this is everyone's getting fast responses you can go and edit the data um you don't have to rebuild the whole website and deploy it uh just when that week is up then the next person is going to visit the page they'll get the stale version and then the cdn is going to go after your origin server and rebuild the page and then serve a nice fresh copy to everybody else so really cool technique there too for for pages that don't have that dynamic of data but you don't have to rebuild the page every time you deploy now looking at that calendar icon you can see that there that's like saying okay let's say that nobody visited the about page for like three months what this is going to do since our stale while revalidate is really long since it's a year is after no one's been to that page for three months and someone shows up we're still gonna give them the three month old page they still get a fast response and that's probably okay for an about us page that's fine um and then everyone after that is going to get a fast one but there might be pages where that's not okay and you're saying you know what yeah as long as as long as people are requesting this page and we're triggering rebuilds of it so it's pretty fresh that's fine but but maybe you're like if people quit visiting this page i don't want to give someone a really old page that's like you made the burger and it sat there all day and then someone shows up to buy it this is like the donuts at the grocery store right you don't want to buy the donuts at the end of the day they're no good and so maybe you have pages like that where you're like you know what if it's really stale i don't i don't want to serve that i'd rather have them wait for the page that's this next one uh we're saying max age of a week still will revalidate 60 seconds so it's saying hey if this thing is expired and it's been more than 60 seconds since it was expired right you're like these donuts are only good until lunchtime and then like 60 seconds after if someone shows up 60 seconds after lunchtime all right we'll still sell them the donut but after those 60 seconds don't don't give them the crappy donut let's make a fresh new one for them and so that's what this last one is saying cache this thing for a week we can make edits if people are visiting every week the thing's getting rebuilt once a week in the background everyone's getting a pretty fresh document but like if it's been three months and someone shows up let's rebuild the page for them so what i love about stillwell revalidate uh as a cache control a header value is that you only build what's visited you don't build the whole website when you deploy you just build the pages that people are going to and that's like i said earlier that's what a web server is a web server is an incremental static site generator that's that's how that's all how the whole thing is designed since we had cdns is someone visits the page let's build it and let's store it then everyone else can just get that thing from the cdn all right you want to see an app let's check out an app that implements some of this stuff okay i built this little app to show how a lot of this stuff works out in practice so uh it's up here deployed it to amazon aws and i've got uh fastly as a cdn in front of it so uh check this out i'm gonna search for a github repo like let's say react router hit enter that was fast i'm going to click react training react router and then this is going to give me this one's taking a little bit longer this one's going to give me all of the releases so i can click on a release and then it shows me the release notes pretty cool so i could come back and i could look at like um i don't know 5.1 i can come over here and let's search for something like reach ui and uh let's go here version 0.11.2 oh that one's tiny uh maybe this one's got some more stuff cool chance strickland does a great job with these releases and just reach ui in general um okay check this out so over here i've got my app and uh what's what's interesting here is each here's each of our routes so this is the index and here's our cache control you know what we can actually just we can just look at these let's just look at these right inside of the browser so let's come to network tab here's the document pull this up and notice the cache header here says public max age 600 so 600 that's 10 minutes so what i was thinking on this page was you know this this this home page it's it doesn't really have a whole lot of dynamic data in it um i expect the user to be here for maybe 10 minutes at most and so this max age is saying browser you can cache this page for 10 minutes so if i'm like clicking back and then clicking forward to this page you can see here it just comes from the disk cache so i told the browser just just hang on to this for 10 minutes if i make a deploy right now in the next 10 minutes i don't need the user to see that for this page the page is going to work great for them so they don't even have to go to the cdn they don't have to go and then the cdn doesn't have to go to our origin server or anything just keep it here locally then this next one xmas s max h i don't even know how long that is i probably figured it out at some point so 60 4 800 divided by 60. and then i don't know divide by 60 again and divide by 24 7 hey all right seven days so what we're saying here is cdn caches for seven days so if i visit this page and then somebody else visits the page let's um let's just kind of look at what it looks like here if we do it actually i'll just hit reload and we're going to see down here x cache hit so excuse me somebody else already visited this page within this week and so when i come to visit it now i get it straight from the cdn and i didn't hit my origin server so browser cache for 10 minutes the user session i don't care if i deploy and then i'll get an update s max age for a week now if something changes i can go and purge like if there's a really important change for this page i can go purge my cdn and i know within 10 minutes every single user is going to get the new page and so that's why i've got the max age and the s max age so it gives me that ability i can't purge the browser cache but i can purge the cdn cache if i've got a really important fix or change to this page for them then i've got this stale while revalidate of a year so i'm saying hey you know what if someone shows up um so it's been a week so let's say it's it's saturday night at midnight and uh and that's when it's gonna expire and someone shows up at 1201 after it expires just send them what the page looked like at midnight don't make them wait and then go and rebuild the thing for the next people so kind of cool i have a bunch of control here i can say browser cache it for 10 minutes i expect the user session to just be about 10 minutes so i don't need to change it on them if there's an important change i can purge my cash and i'm not going to be rebuilding this page any more than once a week so i'm like yeah this page might change once a week and if it does cool everyone will get those updates within a week unless it's important then i'll purge it so now let's look at uh so if i come in here to reach ui let's look at this one so this one's cache headers are different max age 600 so once again oh sorry this is this is the results it's the same page so let's actually look at one of these and so i come in here this one is max age one still will revalidate a year so this is the case where we're we're making the burgers ahead of time but we're giving everybody nice fresh burgers think about why i picked that for this page it's like door the explorer for web developers this so so imagine imagine you are the one cutting a release for reach ui and you're using this website you like this website for seeing what your what your release notes look like so you just cut a release and you come over here and you want to see that release right here right so we're saying hey we want really fresh data here the data here uh people are expecting to see this if someone launches a new release of something and they announce it on twitter people gonna be like oh i'm gonna go check out the github releases thing and and read it over there and so people are gonna expect really fresh stuff right here and then since we did max age one and still revalidate a year everyone's gonna get something super fresh but it's gonna be really fast too no one's gonna have to wait for us to go off to get up see each one of these loaders if i come over here into these routes it's right here org repo like we're actually we're actually fetching from github a couple of things here and so we don't want the users to have to wait for that we're saying hey yeah we'll we'll just we'll just rebuild in the background every second is really what this says rebuild once a second give everyone a fast response and then when we come here look at the headers on this page public max age 300 so that's like five minutes s max age 1800 divided by 60 divided by 60. um oh crap i'm not good at math 30 minutes 30 minutes so we're saying this is good for 30 minutes um kind of interesting so we're saying so five minutes for the person looking at this page in the browser right they might come back here in the next five minutes and 30 minutes for the cdn but this is a recent release okay so hang with me here for a second this this is this is the punch line with remix and why we think our our our our headers api is really cool um imagine you are the one who made this release um well let's say i'm just making the website i'm not that person yet i'm not that person yet um let's come and look at an older release look at this one s max age 26 8 i don't even know what that is that's like i think that's like a month i think that's a month so what we're saying is hey these release notes are good for a month and that makes sense release notes should have a really long max age because they're not going to change we don't need to rebuild this page when people come it's we could probably cache it even longer than that because of their release notes but this other release the one that's more recent we only catch it for i can't remember what that was 30 minutes so let's check out the caching over here so we go and we fetch the release and then we go and we hit the github markdown api to build the markdown so kind of an expensive request that's why it's nice to cache it but look what we did for the max age we said get max age pass in the published at so down here in get max age we're saying if it was recently published let's give the author a chance to make edits but after the first day we'll aggressively catch this for a month so saying oh here's how long one day is date.now minus when it was published if it was less than a day just 30 minutes so lots of people are hitting this page when something gets released so we do want to cache for 30 minutes for people so that our origin server isn't super busy um but if you're the author you're like i want to be able to make edits to this thing and have it show up on your website that's cool so normally when you think about how long should you cache something it's like what kind of website is this right people think oh what what's a good what's a good website for static site generation well that's that's a good question but a whole website you're saying the whole website is going to have the same caching needs the same caching strategy and so then you come down a level you say well these specific urls a lot of a lot of cache headers um you get to define with like this kind of an api and it's like what's the source and it's like oh docs whatever and then um and then you say like uh headers um and then you can put the cache control so so you gotta you gotta define that stuff a lot of hosts do it this way you get to define the cache headers um per url and that's another great way to say it right so you're thinking you're thinking the whole site well that's not quite enough so then you come down to just urls it's like okay that's that's a good spot to decide cache headers and how long you should cache how long you should rebuild whether it's static site generation or whether it's it's server-side rendering but with remix you can come down one more level and you can say what about my data i want to change my caching strategy based on my data because if you are the one writing these release notes and you're making edits and those edits aren't going to make it there for a month that's annoying so instead we can say hey you know what we'll give you a day we'll give you a day to go and fix those release notes and then we're going to aggressively cache it for a long time after that super cool all right so how did we actually accomplish this in remix so if we look at this right here um we returned json from our from our loader so all right here's here's the data for this page and then here are the headers and those headers made it up to the route so this is the actual like markup the the react stuff and the export the headers export we tell we give you the loader headers and so then you can say oh hey you know what um i'm just going to use the headers from the loader for this html page and yes i'm still doing that thing where you may have noticed on the network tab we don't have any javascript on this page uh because i couldn't justify it i couldn't think of like why do i need uh here let's go to yeah let's do react router again like why do we need javascript oh there is one line of javascript actually right here this thing to select it this is my favorite are you ready script type javascript dangerously set in or html and so after we do this and we just go select that so you can do another do another search you wouldn't even notice that there's not javascript you think that this was all client-side rendered with how fast it is with the cdn let's let's uh let's let's get two users let's get two users on the page and then we're gonna we're gonna say goodbye on this on this video all right now we've got two users here and uh let's watch how um i'm gonna go to i'm gonna reach ui again that's super fast for both of these users because it's already cached um i should probably tell you when i'm clicking search and now i come over here i click on this click it's i mean it's a media because this is already cached on the cdn um i don't think we have clicked on 0.5.2 so i'm going to click this click but that was what like a half a second or something like that now watch over here immediate let's go back and do another one this time i'm going to go 054 took about half a second come over here 054 click immediate so we can see so we can see in the network pane when we click this it says cass cash miss so i come over here and i do 0.62 we can see super fast cache hit so there you go your website your web server is already a static incremental static site generator you just got to get a cdn in there and the right cache headers and you can decide how often do we want to rebuild this page and we only want to rebuild the pages that are visited okay so i've actually just got one more door of the explorer question for you can you even build this website with static side generation

Channel: Remix

Views: 14,560

Rating: 4.9695587 out of 5

Keywords: JavaScript, Web Development, React.js, Node.js, Gatsby.js, Next.js

Id: bfLFHp7Sbkg

Length: 43min 49sec (2629 seconds)

Published: Mon Nov 23 2020

Reddit Comments

[u/tomdohnal]

I think it's basically two different approach to achieve a similar thing. Remix gives you more control. But it comes with a cost imho—you need to decide what caching strategy to choose for every page and you need to know more "low level" API. +there is a risk that you can accidentally set the cache-control header to cache your page on a browser level for too long and make it impossible for the user to ever get a fresh version of that page.