Reviewing PageBuilder performance
The PageBuilder Performance dashboard provides information about PageBuilder Engine, Delivery, and CDN (Edge) metrics to help you understand your public traffic behaviors. The charts and metrics in this dashboard help you understand how Arc XP is serving your traffic in PageBuilder.
When moving your cursor in one chart, the dashboard renders a marker line in each chart that moves synchronously so you can more easily compare data between charts.
We render your deployment activities on every chart because your deployments can directly impact how your pages get rendered and any potential changes your deployments my cause.
To access the PageBuilder Performance dashboard, navigate to Delivery > Dashboards > PageBuilder Performance.
The dashboard contains the following sections:
The Traffic Pattern charts are divided according to the volume of requests (a 1% sample) that come to the Arc XP CDN, which is named Edge, in the top row of the two charts. Arc XP heavily caches your pages and PageBuilder API requests. A healthy cache means that Arc XP can better handle larger traffic swings, which is why you see lower volumes of render requests on the bottom two charts. Render requests are the actual page renders or API calls executed when the cache expires, and fresh page renders or API responses are requested from Edge to Engine Lambdas.
When a render failure occurs, the CDN at Edge has a window (serve stale) that can tolerate possible problems in your page render or API calls. The server stale makes PageBuilder more resilient, allowing Arc XP to serve your traffic even when there is buggy code that gets shipped by mistake or issues start to occur from your content sources.
This trend chart shows a sample of 1% of your public traffic at Edge from all your sites broken down by HTTP response status codes. The total volume of this trend chart is expected to match 1% of the traffic you see on your analytics tools. HTTP status codes explain the outcome your readers see when a page or request gets handled. This chart is a trend chart, which means, aside from the volume or numbers in each group, the change over time is what we’re most interested in. Unexpected changes in this trend chart may occur for various reasons.
This chart shows lines for each group of response codes:
OK (200 and 304)
Redirects (201, 302, 307, and 308)
Not found (404 and 410)
Error (400, 500+)
You can browse each category's line by hovering your mouse on the chart.
OK, Redirects, and Not found are considered successful responses, and their volume over large windows of time (weekly, monthly) should be stable unless an expected change is made in your code or your external traffic changes.
Edge data takes up to 30 minutes to fully aggregate. Traffic in the most recent 30 minutes shows lower than actual levels while traffic comes in.
The scale on this charge is sqrt() because this provides a good balance between high- and low-level values while keeping the chart readable.
This chart includes visits to all domain names on all side IDs in Arc XP except apex domains. Changes to a specific site might produce smaller than expected changes in these charts.
The following table lists common scenarios that occur with this chart and explains how to address them.
Event | Description | Reasons | Solution |
|---|---|---|---|
Success response codes (OK, Redirects, Not found) going down | Overall traffic volume decreasing means your external traffic sources are sending less traffic to your URLs. | A common reason for this can be search engine ranking or algorithm changes, or just daily or weekly cycles in traffic. | For Google, check the Google Search Console to compare trends to search index health. Another rare but possible cause can be checking if search engines announced (or put a change in effect that was announced before just now). Most search engine optimization news sources (blogs) cover these types of changes. |
Error response codes going up or down | These requests mean both:
| If the error volume goes up, this means if a page was rendering successfully, but suddenly started to fail to render, Edge covers this indefinitely. This means the trend chart does not display the starting time of the failure. In either case, Engine Lambdas are failing to respond to these requests. | Check your recent deployment activity to see if a change was recently pushed to Production. The PageBuilder Render dashboard highlights the recent deployment and bundle termination activity as markers on these charts. If a recent deployment caused this issue, investigate your changes, possibly roll back, or if the issue is obvious, apply and deploy a fix and observe this chart to validate your fix. Regardless of the source, the root issue is PageBuilder Engine can't execute the server-side page render or
|
This pie chart is the same sample of 1% of Edge traffic volume by your websites defined by the delivery configuration.
This chart is expected to be very stable if you're not launching new sites or if your traffic pattern is not expected to change. A change in any site here may mean that a specific site's domain and URLs may be losing or gaining external traffic. This is directly reflected in ???.
Render requests are the actual page render or PageBuilder API requests that are needed when the Edge cache is expired and a fresh version of the page or API response is needed. Edge uses render request outcomes to replace cache, recover the edge request by serve stale, or return the render request outcomes directly to the requester (users or crawlers).
The volume of render requests is lower than the public requests, as reflected with a 1% sample in the Edge charts in the previous section. But the breakdown of response codes is different than Edge responses. While Edge tolerates more failure scenarios and stays resilient, render requests in this chart are not sampled, showing all request volumes and reflecting the actual responses coming from these requests.
The following table lists common scenarios that occur with this chart and explains how to address them.
Scenario | Description | Reasons | Solution |
|---|---|---|---|
Abnormal Not Found traffic spikes | A sharp change in Not Found levels usually means that either there is a component/block/include on your pages that is incorrectly calling a resource or that a third party is scraping or attacking your site | It’s common for crawlers to walk your site; however, many crawlers currently try and extract as much URL data from the page as possible by looking for anything that appears to be either a FQDN or a relative URL. This can often trigger crawling of content that doesn’t actually exist just because the text in the page happens to include Changes to library usage that trigger default pages to be request is also a common reason for high request rates. References within pages for missing resource files or default browser behaviors, such as favicon.ico or the apple png icons, also drive Not Found traffic. | Evaluating what actual requests are using CDN logs is almost always the first step in resolving the issue. Finding the top URL or pattern of URLs that are being requested often lead to where it’s referenced in a page. For instance, if a URL that was crawled was a URL present in the If the request is for a file, such as Lastly, if the traffic is due to malicious usage Arc XP often blocks the activity automatically after a period of time with automatic reputation scores and any outright malicious requests are blocked immediately (and should not be making it through to your logs). The distinction between DDoS and overly ambitious scraping is a bit more dependent on the scenario. If you find that either case is happening and Arc XP doesn’t automatically block the activity, contact Arc XP Customer Support to request we block the offending IP or network. |
Similar to the Edge requests by website, this pie chart is the equivalent of the same pie chart showing PageBuilder requests volume broken down by the website.
This pie chart should be very close to the Edge version of this chart.
If this pie chart is drastically different from the Edge chart, your code is resulting in requests not having cache-friendly outputs. This directly correlates with render failures on your code that may be failing to render because of a configuration gap or the content that is curated in PageBuilder or other places like WebSked, resulting in scenarios that your page render (for example, content sources) not tolerating and failing.
The Render Success and Fail section helps you monitor the success and failure rates of PageBuilder and Outbound Feeds (OBF) requests. By tracking these metrics, you can assess your system's health, identify trends, and investigate potential issues.
This metric shows the percent of requests that Engine Lambdas responded to (for both server-side page renders and /pf/ API calls) over failure scenarios.
We expect this metric to have a high success rate over all requests. If you observe this metric going down, we recommend you investigate Engine errors, starting with the Engine logs.
The metric box color indicates the metric health:
Green - greater than a 99% success rate. This rate is interpreted as a healthy success rate for PageBuilder calls.
Orange - between 95% and 99% success rate. A rate in this range is considered as needs review. We recommend you investigate for potential problems in the render stack.
Red - less than a 95% success rate. This rate is considered an unhealthy success rate. A high-risk issue may be occurring and you should treat it as a top priority investigation.
Success rates within certain percentage groups should be considered healthy, needs review, and unhealthy. This chart displays the trend changes over time, and you can use this charge to spot any deployment activities (highlighted as markers) and their impact on the success rate.
We want to see a healthy level (close to 100%) and stable trend line.
The most common trend on this chart is seeing render success changes with the bundle deployment and termination activities. Looking at Engine logs is the best place to start identifying any specific patterns that may be causing pages and /pf/ API calls to fail and bring this success rate down.
This metric displays a numeric error rate during a time window.
You want this rate close to or at zero. As you introduce bugs or unintended failures start to occur, you see the magnitude of these errors in this section.
The metric box color indicates the metric health:
Green - less than or equal to 5 errors per second
Orange - between 5 and 10 errors per second
Red - greater than 10 errors per second
This chart shows your render volume broken down by site week over week. The data correlates with your traffic swings across your sites. You should expect this data to experience swings unless all of your sites are very stable and predictable.
OBF Success
This metric shows success rate for the percent of OBF requests that Engine Lambdas responded to over failure scenarios.
This chart displays a visual trend for the rate of success over a period of time (selected by the user).
This metric displays a numeric error rate during a time window.
You want this rate close to or at zero. As you introduce bugs or unintended failures start to occur, you see the magnitude of these errors in this section.
Because it’s uncommon to make changes to OBF bundles and deployments, you can expect your OBF metrics to remain stable. But this metric still helps you to monitor, identify, fix, and validate render behaviors.
Because OBF configurations are no different than a typical Engine environment, you should investigate any trend changes or issues with similar tools and methods to auditing and investigating regular Engine environments using logs or these charts.
This chart shows your render volume broken down by site week over week. The data correlates with your traffic swings across your sites. You should expect this data to experience swings unless all of your sites are very stable and predictable.
The Render Performance section outlines key data points that provides insights into system behavior, response times, and potential performance bottlenecks.
This metric is one of the most important indicators showing how long PageBuilder takes to render your pages and respond to API calls. This is a combined metric that shows server-side render and HTTP API calls. Note that this time includes any time to process resolvers and also render the pages, and the metric is presented as an average of the time period selected for the dashboard.
It’s important to keep render time as low as possible because, in many situations, you wait for the render to complete to start displaying a page.
The metric box color indicates the metric health:
Green - less than 300 milliseconds
Orange - between 300 and 1,000 milliseconds
Red - greater than 1,000 milliseconds
This trend chart displays the PageBuilder render time (latency) metric change over time.
It’s important to monitor changes in this metric over time, especially when you make new deployments. Changes in the code are a common reason for the render performance, but not the only factor. Changes on your resolvers or editor configuration for key pages (like high traffic, homepage, section front pages) and templates are equally important where the Engine spends more or less time to render your pages.
The following table lists common scenarios that occur with this chart and explains how to address them.
Scenario | Description | Reasons | Solution |
|---|---|---|---|
Render time increased | Your pages are taking longer to render on the server side. | This issue can occur when you make changes in the code, page, template, or resolver. | To resolve code issues, check recent deployments. To resolve, page, template or resolver issues, check editor publish activities. |
Content sources are taking longer to execute. | Arc XP or the third-party APIs you use may be returning slower responses, which is causing the PageBuilder requests to finish slower. | ||
You may not be using PageBuilder Engine cache (fusion-cache) well. This means every render requests is not using some or all cache within Engine that can fail for a few reasons. | Your content sources are not returning simple JSON objects (an Engine requirement), or objects that are failing to serialize. Your content source is returning large objects that do not fit to Engine cache. Engine cache is currently limited to a maximum object size of 1MB. If you are querying an API and returning the response without transforming and minimizing, the content source may fail to write this object to cache, causing every render request to execute this content source; therefore, costing render time. |
This metric is one of the most important indicators showing how long OBF takes to render your pages and respond to API calls.
The expected behavior for feed renders varies based on what is consuming them. Simple cases, such as sitemaps, are often high execution time, but because the consumers are often bots or other crawlers, this can be considered normal.
However, excessively high times for simple use cases can cause problems because crawlers may time out or otherwise fail to read the sitemap if it takes a very long time to render. If direct-to-client use cases are present, such as mobile app feeds, the response time should be treated as it would for PageBuilder Engine pages because the end user is likely waiting for a response.
The metric box color indicates the metric health:
Green - less than 300 milliseconds
Orange - between 300 and 1,000 milliseconds
Red - greater than 1,000 milliseconds
This trend chart displays the OBF render time (latency) metric change over time.
This represents the raw (uncompressed) average size of the responses for both pages and HTTP API calls from PageBuilder Engine.
Although Arc XP uses gzip at edge to deliver compressed versions of files to compatible clients, we recommend monitoring the raw size values because every byte delivered with a page not only must be downloaded, but the browser must also parse it during page load. There is a hard limit at 6MB for compressed content, so if the uncompressed size grows too large, errors begin to trigger for render responses.
The metric box color indicates the metric health:
Green - less than 60 KB
Orange - between 60 and 150 KB
Red - greater than 150 KB
This chart shows your average page output size in bytes over time. As with other trend charts, monitoring changes in your render output size over time and based on deployments or other activities from your team may give insight into what caused an increase in the output sizes or validation of your optimizations if you’re actively working on them.
If no big changes in your bundle code or deployments occurred, you can expect a mostly stable trend on this chart. Keep in mind that your output type may be different depending on your content length and your content sources outputs (that are cached in your page source).
The following table lists common scenarios that occur with this chart and explains how to address them.
Scenario | Description | Reasons | Solution |
|---|---|---|---|
Render size increased suddenly | A sudden increase in render size may mean you introduced a change in the code that produces larger HTML output, including content sources used in the page render to be stored in a JavaScript object that is embedded on your page. | These objects are common areas that may contain unoptimized objects with an unnecessary amount of details that may not be needed for your feature’s render. | Review your content sources' outputs, either in your local environment or by auditing the live page: |
The Fusion Page to API ratio measures the balance between server-side page renders and client-side HTTP API calls that refresh content on your pages. Fusion is another name for PageBuilder Engine.
Client-side API calls are expected behavior because the Fusion contentCache has an expiration based on the server-side contentCache value. It's normal for a reader to request a single web page followed by a few client-side API calls. However, using too many features on the page with the Engine’s default hydrate behavior can trigger excessive API calls, potentially degrading client-side render performance. Monitoring this ratio helps you identify and address such issues.
If extended TTLs are enabled or if Arc XP serves stale content due to a rendering failure, the API ratio may increase. This happens because expired Fusion contentCache entries lead to additional HTTP API calls.
The metric box color indicates the metric health:
Green - less than or equal to 3. This means for 1 server-side page request, you make less than 3
/pf/API calls.Orange - between 3 and 10. This means for 1 server-side page request, you make more than 3 but less than 10
/pf/API calls.Red - greater than 10. This means for 1 server-side page request, you make more than 10
/pf/API calls. Another way to interpret this is that for a single server-side render, your pages make more than 10 API calls. This can slow your client-side render and have a long JavaScript-blocking thread that directly impacts your web vital metrics, like TBT, TTI, and LCP.
This trend chart shows the Fusion Page to API ratio metric over time. This ratio changes depending on your traffic and CDN TTL changes.
The Edge Performance section helps you assess how efficiently your content is delivered to users through Arc XP's CDN. By tracking key metrics, like Time to First byte (TTFB) and response size, you can identify performance trends and take steps to improve page load times.
TTFB is a metric used to determine the responsiveness of an edge server. It indicates the time taken to serve the request content from the edge server to the end-user browser.
This chart shows the average TTFB of the sampled CDN data (1%) for four groups of pages: the home page, all other Fusion pages, all Outbound Feeds pages, and all PageBuilder Engine HTTP API calls.
This metric is a good measure to understand the performance of the page rendering in terms of cache hit ratio. Content served by Fusion that isn’t a cache hit results in the rendering time contributing to TTFB.
Additionally, a page may be in cache in a central region, but consumers who make a request from a widely different geographic region (think of halfway around the world) can see elevated TTFBs even for fetching cached content. This geographic latency can range between 100 and 400 milliseconds depending on where the user and already-cached content is and the size of the object being returned.
A high response time in this chart, or any of the other metrics in this section, can indicate that you should consider a higher TTL for some of the content. Usually this is older content or content that is not actively used on the site.
Arc XP Customer Support can help coordinate setting TTLs on specific or regex paths within a site. We can use our async-revalidate features along with long TTLs to make applying long TTLs easy for both active and inactive content because content is refreshed regularly within the TTL based on user access.
Because this number is an average, it can be influenced by extremely high or low values that pull the average up or down. You can use CDN log delivery to help isolate the extremely high records. Usually these are tied to a slow rendering time within Fusion and Fusion logs, and you can use other developer tools to understand why.
Homepage TTFB is a metric used to determine the responsiveness of an edge server, specifically for the homepage. This metric indicates the time taken to serve the request content from the edge server to the end-user browser.
Normally, this value should be extremely low when a site is active because consumer requests keep the page in cache for the majority of geographic locations.
The metric box color indicates the metric health:
Green - less than or equal to 300 milliseconds
Orange - between 300 and 800 milliseconds
Red - greater than 800 milliseconds
Page TTFB is a metric used to determine the average responsiveness of an edge server for all the pages (other than the home page). It indicates the time taken to serve the request content from the edge server to the end-user browser.
This metric is a good measure to understand the performance of the page rendering when the end-users could be requesting from various geo-locations.
The metric box color indicates the metric health:
Green - less than or equal to 300 milliseconds
Orange - between 300 and 800 milliseconds
Red - greater than 800 milliseconds
Fusion API Edge TTFB is the time taken to serve the API requests that are made by client-side render from the end-user browser. These requests are made by PageBuilder Engine’s client-side render logic and call to retrieve expired content cached in the page, to fetch fresh content for each content source.
The metric box color indicates the metric health:
Green - less than or equal to 300 milliseconds
Orange - between 300 and 800 milliseconds
Red - greater than 800 milliseconds
OBF TTFB is a metric used to determine the average responsiveness of an edge server for all the outbound feed requests.
The metric box color indicates the metric health:
Green - less than or equal to 300 milliseconds
Orange - between 300 and 800 milliseconds
Red - greater than 800 milliseconds
This metric indicates the total size of content rendered for Home page, other pages, API and OBF. This metric is important for measuring the overall rendering performance, especially after a bundle deployment.
This metric indicates the home page size across all your sites.
This metric is a good measure to understand the performance of the page and to make sure it's within the permissible limit for optimal performance.
The metric box color indicates the metric health:
Green - less than or equal to 100,000 bytes (100 KB)
Orange - between 100,000 and 200,000 bytes (100 KB to 200 KB)
Red - greater than 200,000 bytes (more than 200 KB)
This metric indicates the average page size across all your sites (other than the home page).
This metric is a good measure to understand the performance of the page and to make sure it's within the permissible limit for optimal performance.
The metric box color indicates the metric health:
Green - less than or equal to 50,000 bytes (50 KB)
Orange - between 50,000 and 100,000 bytes (50 KB to 100 KB)
Red - greater than 100,000 bytes (100 KB)
This metric indicates the average fusion API response size across all your sites.
This metric is a good measure to understand the performance of the page and to make sure it's within the permissible limit for optimal performance.
The metric box color indicates the metric health:
Green - less than or equal to 50,000 bytes (50 KB)
Orange - between 50,000 and 100,000 bytes (50 KB to 100 KB)
Red - greater than 100,000 bytes (100 KB)
This metric indicates the average outbound feed size across all your sites.
This metric is a good measure to understand the performance of the page and to make sure it's within the permissible limit for optimal performance.
This section contains charts that show your Deployer actions, which can help you understand changes in traffic or performance and if they are correlated with any of these actions that directly impact your public traffic.
When you move your cursor in any chart, each chart mirrors your position on the timeline. Comparing that point in time with some trend change matches the deployment events that may answer the question if a change was made in the bundle that may have caused the trend change you’re observing.
This chart displays bundle actions as red marker lines so it’s easy to spot a change that impacts your traffic and performance trends.
This report lists any PageBuilder bundle events you promoted, including the source, title, and date of the event.
This report lists any PageBuilder bundle events you terminated, including the source, title, and date of the event.
This chart displays page or template publishes as red marker lines so it's easy to spot a change that impacts your traffic and performance trends.