Configure the Fastly service ID and API token. You can use runtime environment variables, or you can edit the settings form found at /admin/config/services/fastly:
A site ID is required, the module will generate one for you when you first install it. The idea behind the site ID is that it is a unique string which is appended as a cache tag on all requests. Thus, you are able to purge a single site from Fastly, even though multiple sites may flow through the same service in Fastly.
Set the purge options
Cache tag hash length: 4
Purge method: Use soft purge
A 4 character cache tag is plenty for most sites, a 5 character cache tag is likely better for sites with millions of entities (to reduce cache tag collisions).
Soft purging should be used, this means the item in Fastly is marked as stale, rather than being purged so that it can be used in the event the origin is down (with the feature 'serve while stale').
Fastly admin UI for purging
Set the Stale Content Options
Set the options to what makes sense for your site. Minimum 1 hour (3600), maximum 1 week 604800). Generally something like the following will be fine:
Stale while revalidate - on, 14440 seconds
Stale if error - on, 604800 seconds
Fastly admin UI for stale
Optionally configure the webhooks (so you can ping Slack for instance when a cache purge is sent).
Fastly admin UI for webhooks
Configure the Purge module
Visit the purge page /admin/config/development/performance/purge
Set up the following options:
Drupal Origin: Tag
Fastly: E, Tag, URL
Queuers: Core tags queuer, Purge block(s)
Processors: Core processor, Late runtime processor, Purge block(s)
Fastly Admin UI configuration
What this means is that we will be using Drupal's built in core tag queuer (add tags to the queue), the queue will be stored in the database (default), and the queue will be processed by
Late runtime processor
In order for the cron processor to run, you need to ensure that cron is running on your site. Ideally every minute. You can manually run it in your cli pod, to ensure that purge_processor_cron_cron() is being executed without errors.
[notice] Starting execution of purge_processor_cron_cron(), execution of node_cron() took 21.16ms.
The Late runtime processor will run in hook_exit() for every page load, this can be useful to process the purges nearly as quickly as they come into the queue.
By having both, you guarantee that purges happen as soon as possible.
Optimal Cache Header Setup
Out of the box, Drupal does not have the power to set different cache lifetimes in the browser vs in Fastly. So if you do set long cache lifetimes in Drupal, often end users will not see them if their browser has cached the page. If you install the 2.x version of the HTTP Cache Control module, this will give you a lot more flexibility on what caches and for how long.
For most sites, a sensible default could be
Shared cache maximum age : 1 month
Browser cache maximum age : 10 minutes
404 cache maximum age: 15 minutes
302 cache maximum age: 1 hour
301 cache maximum age: 1 hour
5xx cache maximum age: no cache
*Note: this relies on your site having accurate cache tags represented for all the content that exists on the page.