HTMX - Caching

Quiz

HTMX is designed to work well with standard HTTP caching methods. This section will look at how HTMX uses these techniques to improve performance and reduce the load on the server.

HTTP Caching with HTMX

HTMX fully supports HTTP caching methods right from the start. Here's how it interacts with different HTTP headers.

Last-Modified and If-Modified-Since

When your server includes the Last-Modified HTTP response header for a specific URL, the browser will automatically add the If-Modified-Since request header to future requests for that URL. This lets the server send a 304 Not Modified response if the content hasn't changed, saving bandwidth and processing time. An example of a server response is as follows.

HTTP/1.1 200 OK
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
Content-Type: text/html

<html>...</html>

Subsequent request from the browser:

GET /page HTTP/1.1
If-Modified-Since: Wed, 21 Oct 2020 07:28:00 GMT

This makes the cache depend on both the response URL and the HX-Request header, instead of just the URL alone.

Vary Header

Vary header is important when your server can deliver different content for the same URL based on certain headers. For example, if your server provides full HTML when the HX-Request header is missing or false, and a fragment when HX-Request is true, you should include Vary: HX-Request in your response.

Example

HTTP/1.1 200 OK
Vary: HX-Request
Content-Type: text/html

<div>Partial content for HTMX request</div>

ETag

HTMX works with Etag headers as expected. However, if your server can produce different content for the same URL (for example, based on the HX-Request header), it should generate a unique ETag for each version of the content.

Example

HTTP/1.1 200 OK
ETag: "abc123"
Content-Type: text/html

<html>...</html>

Alternative to Vary: getCacheBusterParam

If you can't or don't want to use the Vary header, HTMX offers an alternative. You can set the configuration parameter getCacheBusterParam to true.

htmx.config.getCacheBusterParam = true;

When this option is enabled, HTMX will add a cache-busting parameter to GET requests. This prevents browsers from caching HTMX and non-HTMX responses in the same cache slot.

Client-Side Caching in HTMX

HTMX provides built-in client-side caching features that help reduce server load and improve response times. Here are a few important features to consider.

HTMX hx-cache Attribute

The hx-cache attribute allows you to cache the response of an HTMX request on the client-side. When set to "true", HTMX stores the response in memory and reuses it for the same requests.

Example

<div hx-get="/api/data" hx-cache="true">
    Load Data
</div>

In this example, the first click retrieves data from the server, while subsequent clicks will use the cached response.

Cache Duration

You can set how long to cache a response by using the hx-cache attribute with a specified time value.

<div hx-get="/api/data" hx-cache="30s">
  Load Data (Cached for 30 seconds)
</div>

This will cache the response for 30 seconds before sending a new request to the server.

Server-Side Caching Considerations

While HTMX manages client-side caching, it's important to implement proper server-side caching as well. Here are some helpful tips:

Use the right HTTP cache headers like Cache-Control and Etag to manage caching behavior.
Implement server-side caching solutions such as Redis or Memcached for frequently accessed data.
Consider edge caching or CDNs for static assets and API responses.

History Cache in HTMX

HTMX automatically caches pages in the browser's history, enabling instant back and forward navigation without extra server requests. You can manage this behavior with the hx-history attribute.

Example

<div hx-get="/content" hx-history="false">
    Load Content (Not added to history cache)
</div>

Setting hx-history="false" prevents the response from being added to the history cache.

Best Practices

Using good caching strategies is important for improving performance and saving resources. Here are some simple suggestions to follow.

Use Last-Modified and ETag headers effectively to take advantage of browser caching.
Implement the Vary header properly when your server provides different responses based on request headers.
If you can't use the Vary header, consider using getCacheBusterParam, but note that will prevent all caching of GET requests.
Ensure you generate accurate ETag values for different content variations of the same URL.

Print Page