Blazing Speed Without the Pain Points: Try the New BigCommerce, Gatsby, and Netlify CMS Starter

Grant Glidewell
BigCommerce Developer Blog
4 min readNov 20, 2019

At Third and Grove, we can’t help but blend the best technologies in an effort to create modern web front ends. Luckily for us, BigCommerce also likes to push the envelope. So far we have partnered with BigCommerce on projects like Drupal’s ACF reference architecture and the Gatsby source plugin which supports the game-changing Gatsby preview.

Our latest challenge arose from conversations leading up to JAMStack Conference SF. We kicked ideas around what it would take to eliminate pain points when building an ecomm site. Especially pain points keeping people from using JAMStack. Server rendering makes for a very fast site and we know that’s important because, for every second delay in load time, you’re losing 7% in conversions But getting that performance can often be an uphill battle when trying to build a brand-driven experience.

I’m proud to announce that here’s the answer we landed on: The Gatsby + BigCommerce + Netlify CMS Starter which I’ve been working on for the last few months is ready for production!

Right out of the box, we have a really great user experience and blazing-fast performance that only a Gatsby site can deliver! You’ll find data is fresh and accurate, and a persistent cart with access to the data in any component throughout the app. Let’s dive into how this starter solves major headaches by being built on solid best practices.

Prices you can trust

As a customer, the worst experience is to see prices, availability, and other product data change in front of my eyes. Nothing makes me lose faith faster in a store than to see a product with one price listed on the product details page, and then another price appears when I add it to my cart.

There is a somewhat well-known term in front end development called ‘flash of unstyled content’ (FOUC). This happens when a static page loads its styles/fonts/scripts impacting the overall style of the page after the first render. The result of this is that the user sees unstyled text in a flash, and then it all changes when those other things load. This is generally seen as undesirable, and there are things developers do to avoid this behavior.

In ecommerce, there are potentially more damaging flashes of content. I call it ‘flash of inaccurate values’ (FOIV). This is the experience I described before. It can take on many forms but in SSR applications there are specific steps to take to avoid this. One approach that worked well in the BigCommerce Starter is to not render any prices at build time. All of that data is fetched on the client. This could be heavy though. Depending on how its implemented, this could fire off a bunch of requests for each item as the user navigates around a store.

Using a global state implementation became critical. Each product’s price is rendered by a React component called Product Prices that looks the price up in the global store. The global store is implemented with React’s Context API, but it could easily happen in Redux or any other global state solution. Our Price Provider component makes one call through the BigCommerce cloud function to get pricing and availability for the whole store. This avoids some possible issues with deciding which prices to fetch based on what the user is viewing.

By not statically rendering price and other data, this allows for some other concerns to be handled by the client. Localizing and personalizing the product data that is skipped in the static rendering process opens up a world of possibilities. BigCommerce is going to support exactly this process via the V3 Pricing and GraphQL Storefront APIs. So your store will be capable of meeting a lot broader range of customer’s needs without changing anything on the front end or having to build multiple versions of the site.

A secure cart by default

Another concern we needed to address was cart behavior. BigCommerce’s cart API handles a lot right out of the box. But we needed a secure way to connect to this API. Netlify makes it simple to create lambdas that hide API keys. That’s exactly what the BigCommerce Netlify Lambda accomplishes.

With the details of security abstracted away, we were able to adapt the BigCommerce cart component logic into a Cart Context Provider. This way all of the cart data stays in sync across the application. The cart addresses session persistence as well through the Cart API’s cookies. These can be omitted if you want to use another method of cart persistence.

How to get started

Check out the repository and it would probably be useful to learn more about Gatsby. You should be able to get up and going in no time! You can even one-click deploy a clone to Netlify! I hope you enjoy and if you have any questions or issues, keep us in the loop!

--

--