DEV Community

Victor Basumatary
Victor Basumatary

Posted on


Cache Everything

Static websites are great. Here are some of the great things about them:

  • They're fast
  • Can be updated and maybe maintained by a web dev beginner
  • Can be cached
  • Won't cost you an arm and leg to refactor or redesign

Ok maybe the last point is the result of how well you write and design your codebase and not so much it being a static website.

A lot of people don't seem to like the idea of building static websites. I was once that person because building static websites meant writing the entire website by hand (and I did that a few times). The reason(s) could be different for different people however.

What do we mean by a dynamic website anyway? A lot of times it means having a database and the website/web page being generated using the data in the database. We'll go with that definition.

Let's take a news website for example. What's dynamic in the website? The landing page? Yep. The advertisements section on each page? Yep. The news article itself? Most of the time, no. Anything else? Most probably not. No.

How about an e-commerce website. Landing page? Definitely dynamic. Ads section(s)? Yep. The product details in the product page? Usually no. The reviews section in the product page? Yep.

And I could go on and on. If you still don't get my point, it's this - most content on most websites is static.

How often does the data in the database change? It depends. A news website is probably churning out anywhere between 10s and 100s of articles every day. A really successful news website may be churning out thousands.

A general e-commerce website will probably be adding thousands of new products and reviews to the store by the hour.

A blog may be updated with a new post maybe only once a week.

It depends.

At a glance it does seem like data is changing pretty often but that observation is incorrect. Once a news article is published, it can be updated but how often does that happen? Once a product is added to an e-commerce site, the product details can be updated but how often does that happen? Once a post is written in a blog, it can be updated but how often does it happen?

Do you see it now? Most content is static. At least until it is updated. Which means we can cache most content indefinitely. At least until it is updated.

Why is this observation important? Because money. And performance.

It takes far less resources - mainly CPU cycles and memory - to serve static content than to generate that content. Lesser resource usage spent responding to requests means more resources spent doing actually useful things like generating content that wasn't previously cached. Better resource utilization means your money is being spent efficiently. It may also have the side effect of your web servers being able to serve more requests more quickly.

How can we take advantage of this? I propose this workflow:

  • Serve cached response for request
  • If cached response doesn't exist make it, serve it and cache it
  • Purge cache every time you deploy
  • Automatically purge cached content when content is updated

Let's use the news website as an example again.

  • "I want to read XYZ news article". I have a copy of it lying over here. Take it.

  • "I want to read XYZ news article". I have a co... Actually no I don't. Let me get that news article for you real quick and keep a copy in case you or someone else might want it again.

  • Oh it seems like the news website is updated. Let's get rid of all our copies of news articles because we don't know if we changed styling or something.

  • "Oops I've made a typo in this article. Edited." Ok got it thanks. Oh it seems there was a copy of this article lying around. Let's get rid of that.

So essentially what we really want to do most of the time is build a dynamically updated static website rather than a dynamic website.

Victor this is all fine but content lives within HTML documents and all these examples you used have dynamic sections within those documents! News article pages will have ads and maybe comments. Product pages on an e-commerce website will have personalized recommendations and reviews and again, ads. Blogs will display related articles. We can't cache those.

Static content lives within HTML documents that may house dynamic content. Correct.

We cannot cache the HTML document because there are dynamic content sections. Incorrect.

HTML by nature isn't dynamic. But we want dynamism and so we have JavaScript. Any time you see the need for dynamism in your web page, JavaScript is probably the right answer. Probably.

Will the JavaScript that fetches and displays dynamic content on your web page change often? Probably not. So you can cache it, along with the HTML.

Well Ok. But my website is served worldwide and the content differs depending on locale and other variables.

Use HTTP headers like Vary and Accept-Encoding to cache and serve cached content. CDNs are really smart you know.

Victor this requires a lot of effort. All we want to do is make a website and get it done with.

Who doesn't? But I suppose you would like to charge your customers lesser to give yourself that competitive edge and also have a lower running cost, no?

Top comments (0)

Need a better mental model for async/await?

Check out this classic DEV post on the subject.

⭐️🎀 JavaScript Visualized: Promises & Async/Await

async await