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
.
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.
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 toCache-Control
response headers)HIT-STALE
: the resource was returned from the cache but is stale and being revalidated in the backgroundEXPIRED
: 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.