Learn how to use the BigCommerce Optimizer module.
Deploy the BigCommerce Optimizer by creating a project in your account. Complete the provided steps and when prompted, choose the BigCommerce Optimizer performance module.
While you can use a bare domain with Section, we strongly recommend ensuring you are using a subdomain before deploying the BigCommerce Optimizer module (e.g.
www.example.com instead of
Deploying the BigCommerce Optimizer module will also deploy the required BigCommerce Cache module.
Manage the BigCommerce Optimizer module through the Git config.
Check out the related BigCommerce Optimizer reference to get started with customizing your BigCommerce Optimizer module.
Submit a support request by clicking the Support link in the left sidebar if you need help managing this module.
Follow the steps below to quickly configure the BigCommerce Optimizer module for an environment in your project:
Go to the quick config of the environment you want to quickly configure the BigCommerce Optimizer module for.
Configure your caching for static assets and HTML documents and then click Update:
- Enable Static caching: Whether static caching should be enabled.
- Enforce HTTPS: Whether HTTP requests should be redirected to HTTPS.
- Browser Cache TTL: The amount of time the browser should cache your static assets for.
BigCommerce Optimizer settings
Enable BigCommerce Optimizer: Whether the BigCommerce Optimizer should be enabled.
Strategy: The strategy used for the BigCommerce Optimizer.
The whitelist strategy optimizes all paths provided, whereas the blacklist strategy optimizes all paths other than what is provided.
Paths: The paths to optimize or skip based on the BigCommerce Optimizer strategy.
Consider starting with the following blacklist strategy:
Developer IPs: IP address(es) to exclude from the BigCommerce Optimizer.
HTML streaming uses Varnish Cache ESI and OpenResty to punch a hole in the HTML DOM and streams the HTML in front of the defined HTML tag, which allows the caching of all content that comes before it. This allows parts of an HTML document to be dynamically cached without caching parts of the page that are unique to the user. A few highlighted benefits of this feature can be found below:
- Improves load time metrics and user experience without requiring complex application changes.
- Improves the start render time on applications that are not yet caching their entire HTML document.
- Unlike dynamic content caching, HTML streaming does not require an intensive implementation time or code changes to your origin and can very quickly realize most of the gains of dynamic content caching within hours of enabling it. It is important to note that if the cacheable part of the page has not been cached yet Section will need to pull it from the origin. This means the first request may be slower but all subsequent requests will have performance improvements. Pages that are requested infrequently may want to be excluded altogether.
Configure the split point
Follow the steps below to configure the split point used by the BigCommerce Optimizer module for the HTML streaming feature:
Go to the Git config of the environment you want to configure the BigCommerce Optimizer module split point.
bigcommerceoptimizer.jsonfile, update the
holepunch_tagkey with the HTML tag you want to split the page by to have all preceding data optimized and cached by Section. For example, if
</title>was used all data preceding that closing HTML tag would be optimized and cached.
To determine a split point you will want to find the best place to split your page, like inside of the
<head>HTML tag. A custom split point can be added in your
base.htmlfile if needed (e.g.
A solution can be enabled on almost all pages using the page template setup in BigCommerce, allowing you to pick a consistent split across these pages.
Some page components are uncacheable and need to be fetched from the origin on each request, like those that require authentication. One such component is a CSRF token, which is found in every BigCommerce HTML page in the middle of the
A CSRF token is a unique, secret, unpredictable value that is generated by the server-side application and transmitted to the client in such a way that it is included in a subsequent HTTP request made by the client. CSRF tokens prevent CSRF attacks by making it impossible for an attacker to construct a fully valid HTTP request since they cannot construct it without a user's CSRF token.
Quickly validate the BigCommerce Optimizer module configuration by ensuring the paths in the BigCommerce Optimizer settings reflect the chosen strategy. One way to do this is by checking the page source. If it contains
<!-- ESI Finish --> after the
</body> HTML tag that indicates the BigCommerce Optimizer processed that page. For example, if
/cart.php was blacklisted you would not want to see this HTML comment on the cart page but you would on a product page. Alternatively, you can check the response headers of a page for the
X-Streaming-Debug header. A value of
HTML streaming enabled means BigCommerce Optimizer processed that page.
Follow the steps below to delete the BigCommerce Optimizer module from your environment:
Go to the Git config of the environment you want to delete the BigCommerce Optimizer module from.
In the top of the page, copy the URL next to Clone with HTTPS.
Open a terminal and change the current working directory to the location where you want the cloned environment repository.
Clone the environment repository to your local computer. Type
git clonefollowed by the copied URL and then press Enter:
git clone <copied_url>
In the root directory of the environment repository, delete the BigCommerce Optimizer module directory (typically named
Skip this step to disable the module instead of deleting it.
In the environment's
section.config.jsonfile, delete the module object from the
proxychainarray, which will look like the following:section.config.json
Stage, commit, and push the changes to the environment's remote repository:
git add .
git commit -m "Delete the BigCommerce Optimizer module"