Designing HTML Page Caching Changed How I Think About Caching

Designing HTML page caching for a web platform at work opened my eyes to the broader impact of caching on a system. This was my first practical experience with HTML page caching, and AWS CloudFront served as our CDN. Initially, I thought I had a grasp on caching by understanding the basic concept of storing a response once and reusing it later, reducing server-side processing, and improving response times. However, putting theory into practice revealed a more intricate picture.

One of the most interesting aspects was how caching interacts with client-side rendering methods such as Server-Side Rendering (SSR) and Client-Side Rendering (CSR). I had previously considered these approaches mainly in terms of where rendering took place. With CSR, rendering occurs in the browser, while SSR generates HTML on the server.

Yet, my understanding deepened when I realized that in our setup, CloudFront caches the HTML pages. This meant that data included in the HTML—especially when it comes from SSR—could be served from the cache. Conversely, in CSR, the browser fetches data from an API after receiving the HTML, making that data outside the HTML page cache.

This distinction highlighted the fact that not all data benefits from the HTML cache. It made me appreciate that the choices between CSR and SSR could influence how data could leverage the HTML page cache. This perspective broadened my view beyond just caching HTML pages. It made me consider API responses and backend caching as equally important facets of the broader caching strategy. I had previously overlooked these layers in my understanding of caching.

Another critical insight came when considering the concept of Time-To-Live (TTL). Previously, I viewed TTL as a simple configuration value, a binary choice between long and short durations for caching. However, designing the caching system highlighted that TTL wasn't a one-size-fits-all solution. It required a careful balance, considering how fresh each page should be.

Pages with higher traffic but lower update frequency could afford longer TTLs compared to frequently updated pages. This realization made me see TTL not just as a number, but as a strategic decision that needed context-specific reasoning.

Furthermore, I questioned where within the system the decisions about which pages to cache should be made. My initial thought was that this was a CDN configuration issue. Yet, as I delved deeper, I realized that the application often had the most relevant information about cacheability. By keeping cacheability rules within the application and using them to dictate caching behavior in CloudFront, we could leverage the application's context to make more informed decisions.

This shifted my perspective from viewing caching as a purely CDN configuration problem to recognizing it as a broader application design question.

Overall, this experience profoundly changed my mental model of caching. I no longer saw it as isolated concepts like TTL, browser caching, or CDN caching, but as interconnected elements that could shape the performance and user experience of a web application. While there was still much to learn, I now approached caching with a clearer understanding of the questions to ask.

How should we cache this data? At what layer should it be cached? How fresh does it need to be? These questions guided my thinking, leading to a more comprehensive and nuanced approach to caching in our system.