Long Story Short
- Designing HTML page caching in practice connected several concepts I had previously understood separately, such as TTL, browser caching, and where cache policies should live.
- In our architecture, where HTML pages are cached with CloudFront, the choice between CSR and SSR also affects whether data can benefit from the HTML cache.
- Starting from the simple goal of “caching pages” made me think more broadly about what should be cached and where, including API responses and backend caching.
Context
Recently, I had the opportunity to design HTML page caching for a web platform at work.
It was my first time designing HTML page caching in practice, and we used AWS CloudFront as our CDN.
I already had a basic understanding of caching.
Store a response once, reuse it later, reduce server-side processing, and improve response times.
At least conceptually, I thought I understood it.
The task also seemed relatively simple at first.
If we cache HTML pages in CloudFront, requests don’t need to reach the application every time.
Then we just need to decide which pages to cache and how long their TTLs should be.
Once I actually started working on the design, however, I realized there was more to think about.
Looking at CSR and SSR Through the Lens of Caching
One of the things I found particularly interesting was the relationship between CSR, SSR, and HTML page caching.
I had previously thought about CSR and SSR mainly in terms of where rendering happens.
With CSR, rendering happens in the browser. With SSR, HTML is generated on the server.
From there, I would usually think about things like SEO and initial page-load performance.
None of that was new to me.
But designing HTML page caching gave me another perspective on CSR and SSR.
In our case, CloudFront caches HTML pages.
This means that when data is fetched during SSR and included in the HTML, the resulting HTML — including that data — can be served from the CloudFront cache.
With CSR, on the other hand, the browser fetches data from an API after receiving the HTML. That data is therefore outside the HTML page cache.
Of course, this doesn’t mean that “SSR is cacheable” and “CSR is not.”
SSR-generated HTML doesn’t have to be cached, and API responses fetched through CSR can be cached at other layers.
But in our architecture, the choice between CSR and SSR affects whether that data can benefit from the HTML page cache.
I had previously viewed CSR and SSR primarily as rendering strategies, so seeing this connection in practice was interesting to me.
Caching Exists Beyond HTML
Thinking about CSR led me to another question:
What about the API responses fetched by the client?
For this project, the scope was HTML page caching with CloudFront. I hadn’t really considered API response caching as part of the same problem at that point.
But while thinking about CSR and SSR, I realized that API responses can also be cached at different layers, such as a CDN or the backend itself.
That made me realize that I had been thinking about caching too narrowly, mostly in terms of HTML pages.
Do we cache the HTML?
Do we cache API responses?
Do we cache something in the browser?
At the CDN?
On the backend?
They are all forms of caching, but each comes with different considerations.
I didn’t design API caching as part of this project.
Still, thinking about HTML page caching made me look beyond HTML and think more deeply about caching across the system. That itself was an important learning for me.
TTL Needs a Reason Too
TTL was another area I hadn’t thought deeply about until I had to design it myself.
A longer TTL allows a cached response to be reused for longer.
But it also means that stale content can remain visible for longer after the underlying page has been updated.
Not every page has the same traffic or update frequency either.
Some pages receive a lot of traffic but rarely change. Others may change relatively frequently.
Once I started thinking about actual pages, I realized that TTL wasn’t simply a matter of choosing a “long” or “short” value.
It was a trade-off involving how fresh each page needed to be.
I used to think of TTL mostly as a configuration value. This experience made me realize that the value itself should have a reason behind it.
Where Should Caching Decisions Live?
Another question was where the decision about which pages to cache should live.
We could define rules in CloudFront based on URLs and other conditions.
But the application often has the most context about whether a particular page is safe to cache.
In our design, we decided to keep information about cacheable pages on the application side and use that information to control caching behavior in CloudFront.
Before this project, I partly thought of HTML page caching as CDN configuration.
Working on the design made me realize that it can also be an application design question:
Where should the responsibility for caching decisions live?
A Clearer Mental Model of Caching
I don’t feel that I learned one particular new caching technology from this experience.
The bigger learning was that concepts I had previously understood separately started to connect.
CSR and SSR.
CDNs.
TTL.
Browser caching.
API response caching.
Backend caching.
I already knew these terms and concepts individually.
But designing HTML page caching myself forced me to think about them in terms of a real system: What should we do here?
The questions I ask about caching have also changed.
What are we caching?
Where are we caching it?
Who can safely share the cached response?
How fresh does it need to be?
There is still plenty I don’t know.
But I now have a much clearer idea of what questions I should be asking.
Designing HTML page caching gave me a much clearer mental model of caching than I had before.
