Leverage Caching to Improve Performance
Delivery of content items, digital assets, and sites should take full advantage of a visitor’s browser cache to improve performance of content delivery and rendering in the browser.
Sites, themes, content items, and digital assets are cached for an amount of time in the visitor’s browser cache. After a site, theme, content item, or digital asset is updated, a cache-buster key in the URL is changed so that the browser has to fetch a different URL and get the new item.
The cache key helps to manage usage of the browser cache by referencing only current resources. Although the cache key is included in the URL, it is a logical element, not a physical location (folder) as is often the case. A change in the cache key does not point to a different physical location to find the resource; it simply notifies the server to fetch the current version of the resource.
Resources can be static, like CSS, JS, and image files, or dynamic, like page data, site data, and content item data. There are five categories of resources for building a website:
-
Product resources – Resources that are part of the product that gets updated whenever a new version of the product is released or patched.
-
Site Resources – Resources that are part of the site, like
structure.json, page data, and images. These are updated when the site is published. The controller is described in the following text. -
Theme resources – Resources that are part of the themes, like layouts, CSS, and images. These are updated when the theme is published.
-
Component resources – Resources that are part of custom components. These include HTML, JS, and CSS, and image files that make up the component. These are updated when a component is published. If one component changes and is republished, then the cache key changes for all components because it’s a single key for all components.
-
CaaS resources – Resources that serve content items and digital items. These are updated when content items are published or republished or the collection target is changed.
The following topics describe caching for the Oracle Content Management runtime and Site Builder:
Runtime Caching
For runtime, the Oracle Content Management Cache-Control header is set to 15 days. A cache key is added to the URL for all resources.
As long as the URL is the same, the browser will serve the resource from its local cache if available. When the resource is updated, the cache key is updated in the URL, which forces the browser to make a new request to the server and update the local cache.
The controller, which contains the cache keys, is also cached for 1 minute. Because of this, any updated cache keys will not be seen for up to 1 minute.
At runtime the server returns controller.html with the latest cache keys for product, site, theme, components, and CaaS resources. A script with keys is added to controller.html; for example:
<script type="text/javascript">
var SCSCacheKeys = {
product: '123',
site: '456',
theme: '789',
component: '012',
caas: '345'
};
</script> These keys are used by controller.js to construct URLs like the ones in the following table.
| Type of Resources | Examples |
|---|---|
| Product Resources | |
| Theme Resources | |
| Component Resources | |
| Site Resources | |
| CaaS Resources | |
By inserting the cache key into the URLs like this, Oracle Content Management can force the browser to load updated resources by effectively changing the URL so the browser thinks it’s actually a new resource.
Note:
For secure sites, only the product, theme, and component resources are cached, not the site or CaaS content.Site Builder Caching
In Site Builder, static resources are cached for 15 days.
When you use Site Builder, caching happens for product, theme, and component resources. (It does not happen for site and CaaS resources.) Theme and component cache keys are regenerated when Site Builder is launched or refreshed.
If you make a change to a theme or component and want that change to appear in Site Builder, you need to refresh Site Builder (F5).