Content Cache

Configure caching to improve your site's overall performance and can minimize customer wait time.

B2C Commerce uses two caches for different kinds of content, each of which can be configured and invalidated separately.

• Static content cache: used to cache images, icons, CSS style sheets, and other non-dynamic assets.
• Page cache: used to cache HTML pages generated from ISML templates when <iscache> is enabled.

Using page caching can improve your site's overall performance and can minimize customer wait times. The web server caches content to improve response times. Requested pages are stored in the cache and can be presented immediately upon request. You can use caching on portions of pages, which enables you to manage the customer experience while satisfying business requirements related to data changes like pricing and promotions.

B2C Commerce supports the cross-site sharing of static files. You can Configure Time-To-Live (TTL) for this globally cached static content.

For a page on your storefront to be cached, you must add the ISML tag <iscache> to the appropriate template. The tag can be located anywhere in the template. If the <iscache> tag occurs several times in a template, the <iscache> tag with the lowest cache settings (either minimal cache duration or status=”off”), including all local template includes, determines the caching behavior of the resulting page.

When including other templates in a template, make sure that the included template doesn't contain an <iscache> tag that conflicts with your original settings.

Examples

1. Caching is controlled on a per page basis, via the ISML template for the page.
2. Caching duration is specified in the page, typically 24 hours.
3. Frequently changing pages benefit from a shorter caching period.
4. Stored pages are only invalidated and a new one pulled from the Application Server if any of the following happen:
   • the defined caching time is exceeded
   • a replication is performed
   • the merchant triggers an explicit page cache invalidation in Business Manager
5. To see changes immediately, disable page caching on Sandboxes and Staging instances.
6. Portions of pages can be cached separately. You can assemble a page from snippets with different caching attributes using remote includes. Each part:
   • has to be a result of a pipeline request to the application server
   • is included using the <isinclude url="">syntax
   • can have different or no caching tags
   • all sections are assembled by Web Adapter and responded to client
7. In general, don't cache pages that show buyer or session information.
8. If you see certain trends in analytic data, you might decide to alter the time length for caching of static content.
9. If you have a specific type of error in production, you might need to invalidate caching briefly to do a hot fix.

Configure Static Content and Page Cache.

The web server caches static content assets, such as images, icons, and CSS style sheets, in two ways. The global static cache holds content shared among sites at the organization level, and site-specific static caches hold content belonging to private site libraries.

1. Select Administration > Sites > Manage Sites.

   • To configure the global cache for shared static content, click Global Static Cache.
   • To configure the static cache for a site (including the Business Manager site), click the site, then click the Cache tab.

2. Select the instance type.

3. Enter the Time To Live in seconds. The web server holds data for the TTL before requesting it again from the application server.

   • The default is 30 days (2,592,000 seconds).
   • For production instances, the minimum TTL is 24 hours (86,400 seconds).
   • To disable caching of static files, enter 0.
   • Setting the TTL affects both the static content and page caches.

The web server caches HTML pages generated from ISML templates that are configured for caching. You configure page caching per site. The Time To Live (TTL) for page data is the same as the TTL for static content on the site.

The current instance type restricts cache settings as explained here.

1. Select Administration > Sites > Manage Sites.

2. Click the desired site (including the Business Manager site), then click the Cache tab.

3. Select the instance type.

4. Enter the Time To Live in seconds. The web server holds data for the TTL before requesting it again from the application server.

   • The default is 30 days (2,592,000 seconds).
   • For production instances, the minimum TTL is 24 hours (86,400 seconds).
   • To disable caching of static files, enter 0.
   • Setting the TTL affects both the static content and page caches.

5. Check the Enable Page Caching box, and click Apply.

All pipelines in a partition have their page caches invalidated together. As with a full page cache invalidation, the cache is gradually invalidated over 15 minutes. A pipeline can only be included in one partition. You can create a maximum of 10 partitions. Each partition can contain up to 20 pipelines. A partition can get replication tasks assigned, that if chosen for a replication process that has page cache invalidation strategy 'Invalidate Impacted Cache Partitions' selected, causes the partition to be invalidated at the end of the replication process.

Before creating page cache partitions, understand the relative execution time of each pipeline, so that you can avoid putting too many pipelines in the same partition. Also, be aware of what pieces of the storefront are cached.

The page cache for remote includes and iscomponent elements aren’t automatically invalidated when the page cache for the pipeline that contains the rendering template is invalidated. Therefore, if you want to refresh the content on the Home page by invalidating the Home-Show pipeline, and you have remote includes to Content-Show, then you must also explicitly invalidate the Content-Show pipeline.

Pipelines are only allowed in one partition, but you might want to refresh different page types, such as the home page and product detail page. Therefore, Salesforce recommends that you place pipelines used in remote includes in a separate partition. Then, invalidate the main pipelines of the page in one partition and the content or other remote includes in the other.

1. Select Administration > Sites > Manage Sites > site.

2. From the Cache tab, under Page Partitions, click Add Partition.

3. Enter a unique, meaningful ID for the partition. It can only contain characters allowed in URLs.

4. Enter a name that describes the type of pipelines you’re including in your partition. For example: slot configurations and slot content.

5. From the Pipelines tab, add pipeline names or remove existing ones.

   Use the Pipeline-StartNode name, for example: Home-Show.

   Pipeline names can be for the current site or for remote includes. A pipeline can only appear in one partition. Modifying an existing partition by removing a pipeline sets the page cache clear time to the partition clear time, which can invalidate cached content.

   If your storefront is based on SiteGenesis, you should import the partition definitions included with SiteGenesis.

   If your storefront is based on SFRA or SiteGenesis, import the partition definitions included with SFRA or SiteGenesis.

6. From the Tab Replication Tasks tab, choose any Global or Site-specific replication tasks.

   If a replication process that has a page cache invalidation strategy of 'Invalidate Impacted Cache Partitions' is selected, the partition is invalidated at the end of the replication process.

7. Click Save.

Invalidating a page cache partition empties the cache for each pipeline. The cache is only refreshed when the pipeline is called and the appropriate page rendered. To lessen the performance impact on the storefront, the cache is invalidated over a period of 15 minutes.

If you want to use the InvalidateWebCache pipelet to invalidate specific partitions across all of your sites, use the same name for all those partitions. The pipelines included in these definitions can differ, as long as the names of the partitions are the same.

1. Select Administration > Sites > Manage Sites > site > Cache.

2. On the Manage Sites page Cache tab, click Invalidate beside a page cache partition name.

   If a pipeline in the partition is invalid or missing, the other pipeline caches are still invalidated. If you want to minimize impact on storefront performance when you invalidate more than one page cache partition, wait until the 15-minute transition phase is over for each partition before invalidating the next.

   The Other Pipelines partition can be used to invalidate cached pipeline output for all pipelines not included in any partitions.

You can create a pipeline to run in a job that can invalidate one or more page cache partition IDs. It can invalidate partitions with matching names in different sites.

Use the InvalidateWebCache pipelet to invalidate a page cache partition, or a list of partitions.

• SiteID : specifies which site to invalidate. If not specified, the site context is used to invalidate partitions for the current site. Specifying "ALL” invalidates all sites in the organization.

• InvalidateStaticCache : when set to true, the static content cache and the entire page cache are invalidated, regardless of the other parameters.

• InvalidatePageCache: when set totrue, the system invalidates all or part of the page cache, depending on the other parameters specified.

• PageCachePartitionIDs : if specified, only invalidates the partitions that are specified as a comma-separated list. For example, if "Homepage,SlotsContent" is specified, then the Homepage partition and SlotsContent partition are invalidated. Don't include spaces between the comma-separated partition IDs.

You might occasionally need to make unplanned edits to content on the Production instance that must be live within a short period of time. You can configure page cache partitions so that it is safer and has less of an effect on site performance to make these edits and replicate them.

A page cache partition is the page cache for a group of pipelines. If the partition is invalidated, then the page cache for those pipelines is invalidated, but no other page caches are invalidated.

While it is possible to edit products directly in Business Manger on a Production instance to make a quick fix, if the page that shows the product is cached, it might take a long time until the change appears in the storefront. To make the change appear faster, you must invalidate the page cache for the entire site. This makes the change go into effect within fifteen minutes, but has a significant performance impact, because the entire page cache is regenerated.

Changes made directly to the Production instance are outside the normal workflow, which allows for testing and previewing content. It also requires more work to get the Staging and Production instance data back in sync, which must happen before the next replication of data from Staging to Production.

Salesforce recommends that you configure page cache partitions and replication jobs for quick fixes of product or content information for a better workflow and site performance. Configuring partitions requires the permissions and expertise of your administration or operations staff.

1. Configure page cache partitions on your Staging instance.

   Changing your page cache configuration causes a reset of the cache clear time and should be done infrequently. Every time a partition is updated (pipelines added or removed) the page clear time of the updated partition and site is set to the shorter value of the partition or site. When a partition is deleted, the site's page clear time is set to the partition's page cache clear time if it's shorter. The clear time for the page cache can be seen as the last invalidated date for page cache of the site.

2. Replicate the cache settings site-level replication task to the Production instance. This replicates the required configuration to the Production instance. When replicated, you only need to replicate it again if you change the configuration of the partitions.

   Replicating the cache settings causes a full page cache invalidation across all sites.

1. Change Product or Search Information

   Make the quick fix to product information on your Staging instance.

2. Configure Replication Jobs Without Page Cache Invalidation

   Create a replication job for your changes where the Page Cache option is set to Do not invalidate. See New Data Replication Process Step 1 General page.

   Selecting Don't invalidate for your replication process means that the page cache for the entire site is not invalidated, as it normally is when you replicate. Because the entire page cache isn't invalidated you will see no performance effect on the storefront because of the replication. You will also not see any of your changes reflected in the storefront.

3. Invalidate Page Cache Partitions

   After replicating your changes to product or search, you invalidate the page cache partition manually in Business Manager on the Production instance.

   The page cache does not include the static content cache, which must be invalidated separately. The developers in your organization can tell you what pipelines to include in your partition definitions.