Cache-Control

Since version 3.6

Cache-Control headers are implemented to improve user experience by instructing browsers to store parts of the webpage in their internal cache. By default, Front-Commerce already applies Cache-Control headers to several important routes:

• Products pages
• Categories pages
• Home page
• /robots.txt
• /sitemaps.xml

How to use Cache-Control headers in Front-Commerce

In Front-Commerce, adding Cache-Control headers to route is done by leveraging the CacheControl service, available from FrontCommerceApp.

note

To learn more about available services in Front-Commerce, see our documentation

In this example, we'll add Cache-Control headers on a "Acme" route.

app/routes/_main.acme.ts

import Acme from "theme/pages/Acme";
import type { LoaderFunction } from "@remix-run/node";
import { json } from "@front-commerce/remix/node";
import { FrontCommerceApp } from "@front-commerce/remix";
import { AcmeDocument } from "~/graphql/graphql";

export const loader: LoaderFunction = ({ context }) => {
  const app = new FrontCommerceApp(context.frontCommerce);

  app.services.CacheControl.setCacheable({
    sMaxAge: 60,
    staleWhileRevalidate: 21600,
  });

  const response = await app.graphql.query(AcmeDocument);

  return json({ acme: response.acme });
};

export default function Index() {
  return <Acme />;
}

This snippet will inform the browser that the data resulting from requesting this route can be safely cached for 60 seconds, and that the cached version can still be served for 6 hours while the data is being fetched again in the background.

Useful commands

You can take the actions below to verify that proxy caching is working as you'd expect.

First, you must ensure that your application sends correct Cache-Control headers for what you want to cache.

Check with the following command:

$ curl --silent -I http://localhost:4000 | grep -i cache-control
cache-control: public, max-age=32140800 # <-- cache headers defined!

Then, check the same headers on a deployed environment. Production and development environments all support this feature.

If Cache-Control headers are also detected, you can then check the X-Cache header value:

$ curl --silent -I https://example.com/ | grep -i X-Cache
X-Cache: HIT

Possible values are:

• HIT: the resource was returned from the proxy cache (i.e: it didn't hit the NodeJS FC server)
• MISS: the resource was not in the cache (it will be cached according to Cache-Control response headers)
• HIT-STALE: the resource was returned from the cache but is stale and being revalidated in the background
• EXPIRED: the resource was in the cache but has expired and needs to be revalidated

A bash script to automate validation

Copy and adapt the script below to analyze several pages of your sites on different environments.

Try to list all types of pages available in your project.

#!/usr/bin/env bash

BASE_URL=$1
NOW=$(date +"%c")

echo "## Cache test for $BASE_URL ($NOW)"

getCacheOf() {
  local url=$BASE_URL$2
  echo ""
  echo "### $1"
  echo "*$url*"
  echo ">" $(curl --silent -I $url | grep -i cache-control)
}

getCacheOf "Home Page" "/"
getCacheOf "PLP" "/venia-dresses.html"
getCacheOf "PDP" "/petra-sundress.html"
getCacheOf "CMS page" "/about-us"
getCacheOf "Contact page" "/contact"

echo ""

Usage: ./test-cache-headers.sh https://magento2.front-commerce.app

💡 You can pipe the output into a markdown file and have a report to share with teammates.