Skip to main content

Launch Gate Review

This document provides a list of tasks that both Arc XP and you must complete before your launch.

Tip

See the Getting Started with a Launch: Launch Checklist for more details on the Arc XP recommended tasks before launching your site.

Arc XP’s Review

Launch Gate

This launch gate checklist is intended to protect Arc XP and your infrastructure. Arc XP must evaluate these items before launching a new site.

The scope of Arc XP’s Launch Gate Checklist is limited to the sections in this document. Be advised the following items are out of scope for this review:

  • Features/blocks functionality

  • Status calls in the PageBuilder Editor

  • Site information and configuration in the code

  • WebSked configuration and collections

  • SEO & Performance Audit (You can request an audit after launching by contacting Arc XP Customer Support)

Failure to execute the items in the following sections correctly can block your planned launch.

Security

Are all sensitive environment variables and site properties encrypted?

Note

Unencrypted environment variables and site properties (also called secrets) visible in client-side code threaten the customer’s site and Arc XP’s infrastructure.

Resources

Are any internal-only APIs being used?

Notes

  • Using Draft API calls from the front-end code (regardless if server side or client side) is a huge security risk. You should call Draft API only behind a Kinesis Consumer, webhook, or Lambda. You should not trigger Draft API calls from end user-behavior calls. The Draft API is a back-end API to create, update, and delete documents. It should not be called from PageBuilder Engine or other front-end or rendering systems.

    • Search the repo for /deployment , /draft or /media-url calls

  • Internal endpoints used through content sources should not be publicly accessible.

Resources:

Draft API - Production

Content Source Performance

Are there any cache busting methods in the content sources?

Notes

  • In content requests, you can use token= with timestamps or random values to bust the response's cache. token= is used for debugging content sources but should not be used in Production.

  • Additionally, no other methods of cache busting are allowed in Production, such as/rand()/ or similar unique path creation.

  • User-specific or dynamic values (timestamp, random-ids) should not be part of the parameters for content sources. Content source caching is based on the parameters, and those values either prevent caching or make caching user-specific, which is not efficient caching.

  • User-input or free-entry values forwarded from the UI to the parameters of the content source are impossible to cache and are a large risk to rate limits, specifically for Content API. The Content API is not intended to serve as a site search replacement. Customers are encouraged to use Queryly to power open-ended site search experiences. If you attempt to leverage the Content API for open-ended queries, you quickly reach your rate limit and begin seeing 429 HTTP error codes.

Resources:

Are there other content source concerns?

Notes

  • Are too many requests being made in one call?

  • Are Arc XP endpoints being used correctly?

  • Is correct error handling applied?

  • Is the payload larger than 1MB, which will break caching?

Resources

Are the content sources returning only published content?

Notes

For debugging, you can set a flag on Content API to return unpublished stories. For production, only published stories should be returned from the content sources.

Resources

Content API published flag

Are there unnecessary console logs?

Notes

Arc XP recommends removing any console logs you aren't actively using for debugging before deploying to production. This is to protect from any malicious actors using these logs for negative outcomes.

General Configuration

Are all images (including the ones in the resource folder) using Resizer?

Note

There are two reasons for using the Resizer:

  • To prevent huge images from being loaded

  • To reduce the amount of data that the user needs to download and not call CloudFront/S3 directly, which means there is no caching.

Images in the resources folder should go through the deployment function

Resources

Client’s Responsibility

We recommend you check the following items before the launch. These items are not Arc XP’s responsibility to check and are not included in the Launch Gate Review.

Importance Level

CRITICAL: Doing this task wrong may have a heavy impact on the functionality of your sites and could bring down services.

PERFORMANCE: Doing this task wrong may have a heavy impact on the user experience of your page, but it has no impact on the functionality or the services.

IMPROVEMENT: This is a suggestion to follow Arc XP's best practices. Doing this task wrong results in code that may still work, but is much more complicated than necessary or could cause minor issues.

Arc XP Best Practices - PageBuilder

The objective of the items in this section is to correctly use all the PageBuilder features for optimal performance.

Issue

Importance Level

Description

Resources

Is Output Type used correctly?

CRITICAL

It often gets overlooked that output types are server-side render only. Ensure nothing is happening that requires client-side render. Ensure that the different output types are set up correctly and are also being utilized correctly in the components.

Are Layouts used correctly?

IMPROVEMENT

Usually every Page or Template uses a Layout, so ensure that everything in the layout corresponds to the output you need.

Layout API

Are Custom Fields used correctly?

IMPROVEMENT

Is the code unnecessarily complex to predict a value where a Custom Field would easily set it and it is reasonable for the Editor to set, or can you use a global substitution to simplify the code?

Is the PageBuilder Engine static component used in all the possibly components?

PERFORMANCE

  • It’s recommended that any feature that does not require user interaction has its static property set to true. Turn off JavaScript in your browser and manually look at a few key pages on the client's site, and see if the content is being loaded server-side.

  • Having most components be .static excludes some JavaScript code from the bundle delivered client side.

How does PageBuilder Engine log look? Any errors or warnings?

PERFORMANCE

  • Sandbox and Production logs are harder to access and also suppress warnings and errors. Check the local PageBuilder Engine log for a selection of pages.

  • With log-forwarding enabled, add measures to alert you to large increases in errors in your environment. Be familiar with the data received and use it regularly to check on the state of your server-side code.

How To Read Engine Logs

Is the code-breaking occurring on the first render because of useContent/getContent?

PERFORMANCE

  • On the first-render cycle, the result of useContent or getContent is undefined. Are the results treated accordingly? Are they easily detected in the PageBuilder Engine log with the Cannot read field from undefined?

  • When the server-side render breaks, it might prevent the server-side render from caching.

  • Another easy way to detect SSR is by disabling JavaScript in the browser and reloading the page. The page must fully load without issues. The features that require user interaction are disabled but render correctly.

Is window or localStorage being called without checking and breaking on server-side render?

PERFORMANCE

You can easily detect if window or localStorage are being called by checking the PageBuilder Engine log with arc.fusion.render.error. Note that errors like this break server-side render, potentially break caching, and slow down the client-side render.

None

Arc XP Best Practices - Content Sources

Implementing best practices in content sources can make a big difference in your site’s performance. Remember to keep content sources simple, understandable, and always with performance in mind.

Issue

Importance Level

Description

Resources

Are you using content sources correctly?

IMPROVEMENT

  • You should split content sources by logic. Avoid a “one content source solves all” scenario as that has other negative implications, like bad performance and insufficient filtering

  • You should do all fetches to APIs through content sources to hide secret keys and tokens, hide the endpoints, and add caching. Exceptions should be rare, but are reasonable for any live content that relies on uncached real-time data.

  • The returned data from a content source should be lower than 1MB. If larger than 1MB, it will be excluded from cache. If larger than 6MB, it will not be returned. Filters or transform can help downsizing the data.

  • If parameters are directly forwarded to Content API, a risk exists, specifically if the content source is combined with a resolver, allowing users to spam Content API with large numbers of unique requests, triggering rate limits.

  • Too generous or unrestricted parameters can be a danger of breaking caching, especially if the input can be shaped in different forms, causing inconsistencies in the front end.

  • For most Arc XP APIs, a website is required. Do not set that value on the content source query because Engine adds it automatically. Exceptions are reasonable if multi-site clients want to fetch from each other's side; otherwise, use the Engine-provided field.

How to Define a Content Source

Content source with multiple calls?

PERFORMANCE

If a single content source uses different Content API calls, could these calls be improved using partial caching?

Is cache: false being used? Is there a good reason to be doing so?

PERFORMANCE CRITICAL

  • Never use cache: false to fetch content sources, but rather use it to run code or hide credentials. This applies only to PageBuilder Engine Cache, not for other caches, which are still in effect.

  • cache: false will be deprecated with Engine 4.0

Do content sources resolves without throwing errors?

PERFORMANCE

You must handle errors correctly. It is crucial for caching that content sources are responding correctly. If any errors are being encountered, appropriately handle them. Ignoring errors or blocking them and returning with a successful empty request can cause empty blocks on the client side.

Are you using TTLs? Are you using them with performance in mind?

PERFORMANCE

  • The default TTL is five minutes. TTL has an impact on the caching time of whole pages, as the page uses the Global Content Sources TTL for its caching time.

  • Adding the new Extended TTL to the page cache extends the page cache from two minutes to a maximum of one week. Pages with this functionality return cached content immediately on any request in the set TTL timeframe.

Arc XP Best Practices - Code

In the following document: Best Practices - Performance and Lighthouse Score with Arc XP you find all our recommendations regarding Arc XP Best Practices. In this section, you find more details of some of those items that are important to implement and have in consideration in your code, but check the entire document for the complete information.

Issue

Importance Level

Description

Resources

Are resources preloaded, preconnected, or prefeteched where applicable?

PERFORMANCE

Preloading the article featured image improves the Largest Contentful Paint and overall Core Web Vitals.

Are resources async or defer where applicable?

PERFORMANCE

  • You should flag any script that is not crucial to the initial render but should still run as soon as possible with potential render impact as async.

  • You should flag any script that is not crucial to the initial render and can be executed after page load as defer.

Are scripts dynamically included or static?

PERFORMANCE

  • This is for additional scripts, for example, video libraries, which should be loaded only when there is a need for them. You should have access to a list of all features on the page within the props provided by either Consumer or useFusionContext as renderable (it contains a list of the highest-order features and their props).

  • If applicable, some integrations aren't always needed on every page. For example, The <script> for the PoWa video player is inserted only if a video is used on the page. That involves checking the .globalContent and .contentCache for a video before putting the tag in.

Script dependencies

Are images being lazy-loaded?

PERFORMANCE

Ensure the article featured image is not lazily loaded. Instead, it should preload to improve performance.

Are you lazy loading your off-screen content?

PERFORMANCE

Most clients lazy load images, but on bigger pages, it is unnecessary to load all the content that is not visible on the first screen right away. Items like Youtube Embeds can greatly slow the performance.

Lazyload large client-side implementations

Are all resource links wrapped in deployment()?

CRITICAL

The function is available on the props provided by either Consumer or useFusionContext and wraps the path in it with the current deployment parameter to ensure a caching link to the current deployment.

Context Component API

In this section: