In Part 1: The road to HTTP-caching Liveviews, we’ve succeeded in caching the initial rendering of Liveviews.

For this we had to:

• disable CSRF token check, using a modified version of Phoenix
• disable sending the CSRF token when establishing the websocket connection
• configure a Plug that sets the cache-control header
• and eventually configure PlugHTTPCache

So far we succeeded in caching Liveviews that render public content. Caching private content with plug_http_cache or a CDN makes little sense, as the goal of a shared cache is to reuse response generated for a user A to all other users.

…

Since I release of HTTP caching libraries for Elixir and particularly plug_http_cache, the most frequent question has been if it’s possible to cache Liveviews.

Why caching Liveviews

The first reason is SEO, that is to speed up page loading to get a better page ranking. Search engines take into account many parameters, including the Time To First Byte which is why caching is important for some Phoenix apps. Although you can theoretically develop some pages with Liveview (not cacheable until today) and some others, with no interactive, in plain old Phoenix views (cacheable - but they’ll never have Liveview’s interactivity), developers tend to choose only one option. I’ve heard that the lack of cacheability has been a obstacle to adopting Liveview in some projects.

…

In the previous article, we discussed how to setup plug_http_cache to cache Phoenix’s response.

In this article, we’ll take a look at the specific case of caching when doing A/B testing.

A/B testing consists in presenting 2 different versions of a page (page A and page B) to users and comparing the users’ behaviour to determine which version performs better.

Usually, a user is randomly assigned a group (A or B) when first visiting the site implementing A/B testing and sticks to this group. The value of the group is stored in a persistent cookie.

…

One year ago I released the http_cache Erlang library along with 2 Elixir libraries (plug_http_cache and tesla_http_cache) that make use of it.

When I started writing these libs, I thought it would take a few weeks of work to have them completed. HTTP caching is harder than I though, and it took way longer. Why, then, bothering writing them when other HTTP caching systems already exist? In this blog post, I intend to explain my motivation and show what features they support.

…