How content refreshes when using Arc XP cache defaults

The time it takes for published content to appear on your website depends on several factors: the corresponding page, resolver, template, and your PageBuilder Engine bundle code. This document breaks down these layers to help estimate your total time from publishing content to its appearance on a page.

As a reminder, Arc XP caches content to ensure that users don’t have to wait several seconds. Instead, the link a user clicks loads in milliseconds, providing a fast and smooth browsing experience. If you haven’t read, we suggest reviewing Caching within Arc XP first.

When content refreshes a page

The Arc XP Experience platform integrates with the Arc XP Content platform to monitor specific publishing activities and automatically refresh your pages, regardless of when the page was cached. This process is called automated cache clearing. To learn more about when automated cache clearing is triggered, see Automated cache clear: how your page gets updated when content is published.

Even with automated cache clearing, multiple systems work together, and with baseline fixed caches (such as web origin’s 10-second cache), the time from publishing to page re-render can take up to one minute.

Not every publish triggers automated cache clearing

It’s important to understand that automated cache clearing doesn’t occur with every publish. In some cases, content on a cached page must wait for the related cache objects (in the CDN and PageBuilder cache) to expire. In these scenarios, you need to know the expected time frame for a specific page or block on a page to refresh.

Formulating how long content stays in the cache

If automated cache clearing doesn’t refresh a page, the content appears when the two layers of cache expire and refresh according to their natural lifecycle.

In simple terms, you can calculate the total time it takes for content to appear on a page after a publish (referred to as time-to-refresh) as:

In practice, the two layers of cache work independently. If one layer has a longer TTL then the other, it can act as a longest pole, making the total time from publish to content appearing on a page more difficult to estimate. We’ll explain why this estimate can be complicated by visualizing how the alignment or misalignment of the two layers affects the time-to-refresh, using both best-case and worst-case scenarios.

You may have noticed that in the Arc XP CDN layer, the TTL defaults differ for pages and templates. Therefore, we explain pages and templates separately and provide examples for each.

Visualizing renders and cache objects in timeline views

Let’s start with pages as a simpler example. We’ll visualize a timeline, with a reader’s request represented by boxes stacked vertically from top to bottom.

Example: if a CDN object is valid, the CDN cache object responds to a reader request. If the cache is expired, the vertical lines represent when a page render occurs, which uses the PageBuilder cache objects to retrieve the content for that page. A page typically has multiple content sources to render.

We’ve color-coded the cache objects in these diagrams: expired objects are represented by gray boxes, active objects by green boxes, and future cache objects by dashed-line boxes.

Page render and cache object lifecycle

Let’s look at two scenarios in this diagram:

• Request at minute 7 - A reader request at this time is served by the CDN cache object, as it’s still valid. This means your downstream APIs don’t need to execute, and the reader doesn’t have to wait for content to load.
• Request at minute 8 - This request checks the CDN cache validity and finds that it’s expired. The request then goes downstream to PageBuilder to render the page, and PageBuilder retrieves content from all content sources. Content Source A returns content quickly, as its cache is still valid. However, if Content Source B’s cache has expired, there are two possible scenarios:
  • Scenario 1: Only used on this page - If Content Source B is used only on this page, it calls the Content API, or a third-party API, to fetch fresh content and then cache the response for the next five minutes. The cache timer starts from minute 8 in this example. This creates a time gap after the Content Source B cache objects expire.
  • Scenario 2: Used on other pages - If Content Source B has already been used on another page with the same query parameters (before this page’s re-render), it will have been re-executed and re-cached. This is demonstrated in Content Source C in the diagram. In this case, Content Source C’s cache is valid, and it responds quickly. For example, if the Recent Articles in Sports section is a content source used on all sports article page, and another sports article page was requested at minute 7 (or shortly before minute 8 ), it may have already re-executed and cached Content Source C before the page re-render happens. This creates a scenario where the cache is frequently updated.

Template render and cache object lifecycle

A key difference in this diagram compared to the previous diagram is the global content source, which is responsible for retrieving the primary content. You configure the global content source in your resolver settings, while all other content sources are considered secondary content sources. We’ve already covered the composition of your page and the difference between pages and templates in Understanding how your page composition impacts content platform load.

This timeline diagram represents a longer time frame, as template-powered pages are cached for a longer period. Therefore, the content source boxes appear smaller, even though they still represent the five-minute default TTL for content sources, which applies to both pages and templates. It’s important to note that a content source doesn’t distinguish between being used as a global or regular content in PageBuilder. It simply operates within a defined TTL.

Automated cache clearing

Now that we’ve covered the template cache lifecycle, let’s introduce content publish activity into the timeline and examine how each cache layer picks up the updated content.

In the following diagram, we’ve introduced several new visual indicators:

• Pink dashed boxes and pink vertical lines represent the render that picks up the updated content and finally displays it on the page.

• Red lines and red text indicates where a cache clear event drops valid cache objects in the CDN and global content source, forcing the next request to render with fresh content.

• The purple line measures the time from publish to when the fresh content appears on the page.

• At minute 15, an editorial staff member clicks the Publish button in Composer.
  1. The Content platform immediately queues a cache clear request in Delivery.
  2. The Delivery Cache Clear app drops the cache at the CDN layer and notifies PageBuilder.
  3. PageBuilder retrieves the same URL from the resolver configuration and clears the cache object for its configured global content source.

This process typically takes only a few seconds but can extend up to a minute, depending on overall platform activity.

As a result, within one minute or less, readers see the updated content on the article detail page.

Note

• Only the article detail page and its global content are cache-cleared and refreshed.
• Currently, only Composer stories trigger automated cache clearing. Other content types, even if set as global content sources in templates, do not refresh automatically.
• Any page other than the content’s canonical URL continue using its valid caches. Content updates appear only when the related content sources and CDN cache expire. For example:
  • A newly published story added to a collection or section is not fast-tracked to appear on a homepage or section front.
  • A Recent Articles block in the right rail of another article detail page continues using its cached content until its TTL expires.
  • A non-story content type, such as a video detail page, does not trigger automated cache clearing because only Composer stories support automatic cache clear.

Best-case and worst-case scenario for pages

When considering time-to-refresh under Arc XP’s default TTLs, timing plays a crucial role. Let’s examine both ends of the spectrum.

In the best-case scenario, the time-to-fresh is minimized due to ideal timing between cache expiration and automated cache clearing.

1. A story is published to Composer.
2. Automated cache clearing triggers, immediately dropping the CDN cache and the global content source cache.
3. The next reader request after cache clearing triggers a re-render, fetching fresh content from the Content API and updating PageBuilder’s cache.
4. The updated content appears on the page within seconds to under one minute.

In the worst-case scenario, content takes longer to refresh due to cache expiration misalignment.

1. A story is published, but automated cache clearing does not apply.
2. The page remains cached at both the CDN and PageBuilder layers until their respective TTLs expire.
3. A reader request arrives right before cache expiration, serving stale content.
4. Only after both layers of cache expire and a new request is made does the page fetch fresh content.

Both of these scenarios assume either perfect timing (best case) or worst timing (worst case). In reality, most pages fall somewhere in between, with refresh times varying based on cache configurations, traffic patterns, and automated cache clear behavior.

Best-case and worst-case scenarios for templates

Templates introduce a wider range of time-to-refresh scenarios compared to individual pages due to their longer cache durations and more complex dependency on multiple content sources.

In the best-case scenario, the template cache expires or is cleared in perfect alignment with a publish event, ensuring minimal delay.

In the worst-case scenario, misaligned cache expiration leads to significant delays in content updates appearing on the site.

What happens here:

1. A story is published, but automated cache clearing does not apply.
2. Global content was cached seconds before the publish event happens, so the previous content cache is still active for the next ~5 minutes
3. CDN cache expires right before the global content cache expires, and the new page render still uses global content cache object that is not including our updates.
4. CDN page is now cached for the next 15 minutes. Even though global content is executed and cached again, the server-side-rendered page still misses the new updates.
5. The full cache refresh happens 15 minutes after that period. Adding absolute total together [up to 5 minutes] + [up to 15 minutes] = 20 minutes maximum time to refresh in server-side rendered page.

Note

In this scenario, even though we are looking at 20 minutes maximum timeframe, PageBuilder’s client-side rendering logic will detect the server-side render cached content is expired and it will start refreshing the content after 5 minutes. Your readers will see the fresh content no longer than 5 minutes. But crawlers (search engines) may not render your page with client-side Javascript and it may take 20 minutes to see the updates.

Another scenario if your developers made the component statically rendered, it will need to wait out 20 minute window to see fresh content.

Impact of changing content source TTLs on time-to-refresh

In Arc XP, most TTLs are fixed and managed by the platform, except for content source TTLs, which developers can modify. Adjusting these TTLs directly impacts how long it takes for published content to appear on pages, influencing the time-to-refresh.

Default and adjustable TTL ranges:

• Default TTL - content sources are cached and refresh every five minutes
• Minimum TTL - two minutes (120 seconds), any setting below this resets to two minutes
• Maximum TTL - no upper limit, can be extended indefinitely

You can modify content source TTLs to balance freshness, performance, and API load. Here’s when you might want to lower or increase TTLs:

Lower TTLs (more frequent updates)

Lower TTLs help ensure content is fresher, but they come with trade-offs:

• Fresher content - updates appear more frequently
• Potential page load impact - more frequent uncached requests can slow down rendering
• SEO considerations - crawlers may hit more uncached pages, increasing render time (for example, 2 seconds versus 400 milliseconds), which could affect Web Vitals scores

Example use cases for lower TTLs:

• Breaking news updates that need to appear in real time.
• Stock market data, sports scores, or live event coverage.

Higher TTLs (better performance and stability)

Increasing TTLs improve performance by reducing API calls:

• Reduced API load - less strain on Content API and third-party services, avoiding rate limits.
• Faster page rendering - cached responses speed up both page loads and client-side refreshes.
• Slower content updates - changes take longer to appear on pages.

Example use cases for higher TTLs:

• Static content (for example, companies policies or evergreen articles)
• High-traffic pages where performance is critical
• Third-party content sources with strict rate limits

Best practices for optimizing TTLs

• Lower TTLs for time-sensitive content that requires frequent updates.
• Higher TTLs for stable content where performance matters more than freshness.
• Use partial caching strategies to control API load while keeping critical content updated.

Let’s look at a scenario if you decide to lower your global content source TTL to two minutes:

If Content Source A was left at a five-minute default, the green bar for Content Source A, this example would be longer (five minutes) and this example would take approximately minutes to refresh rather than one minute.

In the opposite example, if a customer developer decides to extend Content Source A’s TTL to 30 minutes, the update to a content that is supposed to be picked by Content Source A would take more than 30 minutes to appear on the page.

Content refresh timing FAQs

The general timings listed in this section assume your sites are using the default Arc XP settings and that your development team has not modified the content source TTLs.

When publishing a new story in Composer

• How long until the new article is available on its own URL?

  The automated cache clear drops the cache and refreshes the canonical URL in under one minute.

• How long until the new article is available in Content API feeds on the website?

  In the worst-case scenario, it takes up to 15 minutes for the content to refresh.

• How long until the new article is available in OBF feeds?

  In the worst-case scenario, it takes up to 15 minutes for the content to refresh.

Updating an existing story in Composer (for example, changing the headline)

• How long until the content is updated on its own URL?

  The automated cache clear drops the cache and refreshes the canonical URL in under one minute.

• How long until the story is updated in Content API feeds on the website?

  In the worst-case scenario, it takes up to 15 minutes for the content to refresh.

• How long until the story is updated in a Collection on the website?

  In the worst-case scenario, it will take up to 15 minutes for the content to refresh.

How long until the story is updated in OBF feeds?

Different feeds have different TTLs. Most feeds have a TTLs of five minutes, though some may be longer. For more details, see Caching within Arc XP.

Adding or a removing a story to a collection in WebSked

In the worst-case scenario, it will take up to 15 minutes for the content to refresh.

How long until the collection is updated everywhere it appears on the website?

In the worst-case scenario, it will take up to 15 minutes for the content to refresh.

Making a change and publishing a PageBuilder page or template

Changes to pages or templates do not immediately clear the cache. Cached content remains until it expires and is re-rendered. For pages, it takes two minutes, and for templates, it takes 15 minutes.