Configuration Overview

Prerequisites

Your website must be connected to Pantheon’s Advanced Global CDN (AGCDN) via the supported module and be assigned a required Terraform configuration for personalization features to work on your instance. Typically, this configuration is applied on a per-environment basis. This guide doesn’t cover Fastly setup and assumes that it’s already working and has been tested.

Edge Integrations setup for Drupal requires intermediate site-building skills. If you plan to extend the conditions beyond the ones that are provided by the modules, back-end Drupal module development skills are required.

To set up WordPress, back-end WordPress development skills and familiarity with WordPress hooks (making use of existing actions and filters) is required.

Why AGCDN?

Many personalization solutions rely on front-end personalization, many of which utilize JavaScript to determine decisions and render personalized content. The challenge with this approach is that content is delivered after the main page load and appears later, which negatively contributes to the page performance score and overall content layout shift. It also doesn’t work for users with strict script permissions or disabled JavaScript.

When you personalize with AGCDN, the content variant generated by the set of conditions is stored in the CDN level and is delivered without the CMS layer via Varnish cache. In this case, the delivery of content and decision-making process is significantly faster and doesn’t negatively impact performance score.

Your CMS processes the original content, makes a determination, and displays a first-time rendering of the content. Once the content is rendered for the first time, it’s being saved in the CDN cache layer alongside the conditional header; your CMS isn’t involved until the cache expires, content is updated, or the conditional variant doesn’t exist in the cache layer.

Cache Overview

A Vary response header tells Pantheon's AGCDN cache that a particular header, or headers, from the request should be used to construct a secondary cache key. This secondary cache key must match the primary cache key in order to use the cached response to answer subsequent requests.

For example, when the Vary header is set for Interest, the server produces versions of the same webpage with different Interests and serves them to visitors' browsers based on their locally-defined interests.

If the Interest object is not in the cache, a request is sent to your website's origin server. Your website sees that the request does not include an Interest header, which stops your Interest-personalized code from firing, and you will serve visitors the default content.

There are a few header options for Vary: Audience-Set, Audience, and Interest. If you need to configure these headers, please reach out to your Account Manager for more information.