The time it takes from an initial click on a link (request) to when a page can be seen and used is important. Too long and a person may get frustrated and leave. BigCommerce typically takes over half a second for its first response to a request (the HTML), which gets worse on slower networks. Then further requests are required to build the page (CSS files, images, fonts etc.). This can all add up to a poor page experience for a user.

For BigCommerce stores the most critical resources is the large CSS file used to style the page. This file has to be loaded before the page can be shown (painted) as it would look ugly without it. Normally a users browser will know about the CSS file and load it once the HTML is returned. Like this:

What does is speed up that initial HTML response (Time to First Byte, TTFB). They use their CDN to respond very quickly with a small bit of HTML that gives the users browser a heads up on what resources the page is going to need. So the CSS file start loading a lot earlier, and that speeds up the showing of the page:

And the same goes for any other important resource that are required for the page to look good. e.g. Web fonts and the main images. achieve this by caching the small bit of HTML in their CDN servers all around the world. If a server close to a user has the cache (a cache hit) that user gets the faster experience. If not, they get the normal experience and the cache is set up on their server for future use.

We analysed one client using and found that about 40% of page views hit the cache and got the speed boost. We also analysed TTFB for all their users to show how much a boost it is. When the cache was hit, the response time was around 100ms. When missed the response had to wait on the BigCommerce servers which typically took 800ms.

This article explains how to set up with BigCommerce to get those speed gains.

How Much Will It Cost?

Your BigCommerce customer success representative, or your sales representative, can provide pricing on BigCommerce Optimizer which is sold via BigCommerce.

Getting a BigCommerce Optimizer Account

You can set things up yourself following their instructions and then asking them to configure it for BigCommerce. However, probably the easiest way to get started is to contact and ask for them to set up a BigCommerce Optimizer account. They will need your email address and the stores domain name. They will then send you a link to set your password and login.

The account should then be configured specifically to work with you BigCommerce store. Just a few more things to do…

Configuring the Hole Punch needs to know how much of your HTML to cache. They do this by looking for a specific piece of text in the HTML of the page. This will be the point where the cache ends. They call this the hole punch.

You can find and edit the hole punch in Advanced Config->bigcommerceoptimizer->bigcommerceoptimizer.json

I recommend setting the hole punch to:


Using this means that all the existing BigCommerce template layouts will have a safe cache by default. They always place the title tag near the top of the HTML. We don’t want a page to not contain the hole punch, because it then caches everything.

Placing Resources in the Cache

For resources to load early they have to be placed above the hole punch.

We also have to be careful. Everything above the hole punch has to be considered static for a specific page. Nothing should be above it that can vary per page view, like user specific information.

The main benefit of the cache is to start loading static resources early, so focus on placing those above the hole punch.

Most pages use the layout/base.html template file to define the top of the HTML including where the hole punch is. Here’s what the standard Cornerstone one looks like:

You can see that the hole punch text is at the top with no resources above it. Let’s move things around a little. I’m going to move the title tag down so that the hole punch is after we load all the key resources, and before head.scripts as we don’t know if that may contain user specific stuff. I’m also going to move the consentManagerTranslations down to after the hole punch as I think that does change per users language.

Changing Your DNS settings

Time to go live. To do that your stores DNS settings need to point to the version of your domain and not directly to your domain. The DNS section provides instructions on how to do that including the domain you need to change your settings to.

In BigCommerce you typically edit your DNS settings via their admin. This is what my settings looked like in the end:

Once you have verified the new settings it may take some time for the changes to show up and settle down in the real world. In my case it also took a while for the SSL certificate to work. So do this at a quiet time.


Once things have settled down make sure the website is still working as normal. Do things look right and function correctly.

A good test to make is to open the developer tools for your browser and look for new errors in the console or network tabs.

The networks tab is also a good way to see if your resources are now being loaded early. It should look like this:

Updating your Theme and Cache Flushing

If you edit any of the html above the hole punch, then the cache will be out of date. This includes any template file that uses the partial called “head”. Also, a new theme build can cause changes to URLs in the cache. When you do that sort of change you need to flush the cache so that it gets re-created as people visit your pages.


This setup alone should improve the speed of your site to about 40% of your page views.

Our Tag Rocket app provides you with the ability to track and report on speed metrics based on the real users that visit your site. Use it to find out if and when your visitors are getting good or bad page experiences.

This is just a quick config to help speed up your store using I’ve a lot more ideas on how to speed up your BigCommerce store.