Understanding how your page composition impacts content platform load

When curating digital experiences at scale, understanding how your decisions impact downstream services is crucial. These services include Arc XP content platform APIs—such as Content API, Site Service, and Author Service—as well as external data providers. As traffic scales to millions, every aspect of your page’s composition, from curation and configuration to underlying code, plays a critical role in performance and efficiency.

Anatomy of a page

Image the homepage your reader sees:

Your homepage features various groups of content—like recent posts, a video gallery, and featured stories—showcasing a mix of Arc XP content and third-party content. Each section is powered by a specific content type and relies on a unique query to the content base, much like different types of database queries driving the displayed content.

When PageBuilder renders your page, it retrieves groups of content by executing your content sources against various content APIs. The rendering layer (React) then uses these content pieces to display the features on the page.

This means that rendering a page requires the system to orchestrate numerous API calls to gather all the necessary content before displaying the page.

For example, the system pulls multiple content feeds, retrieves site navigation data, uses the Google API to identify trending stories, calls the Content API to fetch stories by URL, and loads a weather widget. Even this relatively simple scenario demonstrates how a single page render involves many API calls, far fewer than the complex, real-world cases we often see.

1x Homepage Request

=

5x Arc XP Content API Calls

+

2x Google Analytics API Calls

+

1x Weather API Calls

=

8 Total API Calls

This example illustrates only one render. Imagine hundreds of readers visiting your homepage every day, hour, or minute.

We don’t render your page repeatedly for every request or page view. Instead, we have a sophisticated caching infrastructure to reduce the load on the content platforms. To learn more, see Arc XP CDN and PageBuilder Caching Layers.

And not every page is same. For example, pages like the homepage, section fronts, or other directory pages are structured differently from pages that focus on a single piece of content, such as an article, gallery, or video detail page. Let’s take a closer look at what this means.

Difference between pages and templates

In PageBuilder, there are two ways of curating your experience.

First one is pages. Pages have static URIs (i.e: /homepage, /about, /terms-of-service …). Their content can still be dynamically coming from content platform, but the page identity (URL) is defined in PageBuilder. A single page responds to a single URL.

Second way of curating your digital experience is through templates. Templates correspond to dynamic content URLs, like your article detail pages, that their URLs are defined in the content platform, not in PageBuilder. In PageBuilder these pages rendered by templates and their URL patterns are managed in resolvers (What are resolvers and why we need them? to learn more about resolvers). Each resolver is mapped to one or more templates. For example a resolver configuration like:

/sports/<YYYY>/<MM>/<DD>/<article-slug>

can be defined as a regular expression pattern and be mapped to sports-article-detail template. In contrast to pages, a resolver + template can be responsible to render thousands or millions of URLs. This makes resolver and templates really powerful when building your digital experience at Arc XP.

A resolver’s job is to search this URL pattern in content platform, and find out the content, then use the templated to render the page. This happens in a content source. More specifically, the content source configured in a resolver, is referred as “global content source”.

Another important detail to keep in mind that pages and templates are cached at different lengths at CDN layer. You can read more about the cache timing, defaults and what is fixed, what is configurable in Caching within Arc XP. Generally speaking pages are cached with shorter window, and refreshes faster.

Primary content versus secondary content

When you consider a specific piece of content, such as an article detail (or video detail, gallery, author, or section) page, the journey from the URL to the content on the page is defined by a primary content record. For example, the URL /sports/2024/09/24/wnba-napheesa-collier-lynx/ describes a single Composer story.

Note

The primary content doesn’t necessarily have to come from the Arc XP content platform. It could be sourced from an 3rd party API, like a weather page powered by an external weather API. However, it still represents a distinct piece of content or entry identified by a unique URL. In the weather example, the URL could be something like /weather/new-york to reflect a particular city’s weather data.

Now, let’s visualize the anatomy of an article detail page (URL: /sports/world-cup-2024-finals):

What your readers see:

Content groups on the page (a mock-up of your page):

The main piece of content, highlighted in the green box, is called primary content. All other content pieces on the page, such as articles, author info, stories-by-author, and site navigation, are considered secondary content.

Primary content is implemented as a content source, referred to as a global content source in PageBuilder generally when configuring resolvers. Global content source can also be configured on pages but not required for pages. A global content source is required for a resolver + template to be configured for dynamic URLs.

Primary or global content plays a key role in how your resolvers function and how they interact with Arc XP content platform APIs and third-party APIs.

Now, imagine all the possible URLs on your site (likely hundreds of thousands of pages). The vast majority of these URLs belong to the category of unique content pages. Because this represents a significant portion of your site and domain, they also attract a large share of your traffic. In fact, we see typically 80% of our customers’ traffic flows to these type of pages.

Given that your unique content pages require multiple API calls, the volume of traffic to these pages quickly amplifies the load on downstream APIs.