How to Add Virtual Try-On to BigCommerce

BigCommerce merchants can't just drop a Shopify-style app-block into a theme and call it done — Stencil's template structure means script placement and product-page hooks matter. Get the wiring wrong and the try-on button either never renders or breaks on your fastest-selling product template. This guide walks through the actual Stencil edits, in order, so launch day doesn't turn into a debugging session.

BigCommerce's Stencil framework separates concerns in a way that trips up teams used to more monolithic theme editors: Handlebars templates render the markup, theme.js (or your custom bundle) handles behavior, and the Page Builder widget layer sits on top of both. Virtual try-on needs a foothold in all three if you want it to survive a theme update. Below is the sequence we recommend to merchants integrating YourSizer or comparable try-on tools on BigCommerce.

Why BigCommerce Integration Isn't Just "Paste a Script Tag"

A generic embed script dropped into header.html will technically load, but it won't know which product the shopper is viewing, what images are available, or where to render the try-on trigger relative to the "Add to Cart" button. BigCommerce product pages pass structured data through the product Handlebars context and the window.BCData global, and a properly wired try-on widget should read from both rather than scraping the DOM.

This matters because Stencil themes (Cornerstone and its forks) get updated periodically, and DOM-scraping scripts break silently when a theme author reorders elements. Reading from BCData.product_attributes or the product JSON embedded in the page is more resilient. It's a small extra step during setup that saves a support ticket three months later when your theme vendor ships an update.

Preparing Your Stencil Theme Before You Touch Code

Before editing anything, pull a local copy of your theme with the Stencil CLI (stencil pull) rather than editing directly in the BigCommerce theme editor. This gives you version control and a rollback path if a template edit breaks the product page.

Two files matter most for a try-on integration:

You'll also want to confirm which product template variant your store uses — Cornerstone ships more than one product-view layout, and custom themes often fork this file. Check config.json for the active theme name before assuming Cornerstone's default paths apply.

Script Placement: Where the Try-On Bundle Actually Loads

Add the try-on loader script in templates/layout/base.html, just before the closing </body> tag, gated so it only loads on product pages:

{{#if type "product"}}
  <script src="https://cdn.yoursizer.com/widget/loader.js" defer></script>
{{/if}}

Loading it store-wide with a defer attribute is usually fine too — the script footprint is small and a global load means the widget also has a foothold on collection pages if you later add a "quick try-on" preview from category grids. But if you're optimizing Core Web Vitals aggressively, the conditional {{#if type "product"}} gate keeps things scoped to where it's actually used.

Do not place the script in the <head> unless it's explicitly built for async, non-render-blocking load — a synchronous script tag in <head> on a product page is a common cause of a delayed Largest Contentful Paint, which BigCommerce's own Page Builder performance reports will flag.

Wiring the Widget Into the Product Page Template

This is the step most integrations get wrong: the trigger button needs to sit near the size/variant selectors, not floating disconnected at the top or bottom of the page. In product-view.html, locate the block rendering product.options or the "Add to Cart" form, and insert a container div immediately after it:

<div id="yoursizer-tryon-root"
     data-product-id="{{product.id}}"
     data-product-images="{{product.images}}">
</div>

Then in product-details.js, hook the widget's mount call into the same lifecycle that BigCommerce uses to update the page when a shopper changes variant/color options — typically the ProductDetails view's updateProductAttributes or equivalent event. This is critical: if a shopper switches from "Red" to "Blue," the try-on preview needs to re-render with the new product images, not keep showing the old color. Skipping this step is the single most common bug we see in early integration attempts — the widget works on page load, then silently shows the wrong garment after a variant change.

QA on Staging Before You Touch Production

BigCommerce lets you preview theme changes on a staging URL before publishing, and this step isn't optional for a try-on integration — it's where you catch the variant-sync bug above, along with mobile layout issues. Run through this checklist on staging:

• Load a product with multiple color/size variants and confirm the try-on preview updates on variant change.
• Test on an actual mobile device, not just a resized desktop browser — Stencil's mobile product template can differ structurally from desktop.
• Confirm the widget doesn't shift the "Add to Cart" button below the fold on smaller screens.
• Check a product with a single variant and no images, to make sure the widget fails gracefully instead of throwing a console error.
• Verify script load doesn't regress your Page Builder performance score.

Only after these pass should you publish the theme edit to your live store. Because Stencil-based edits are file-level rather than a toggleable app install, rolling back a bad deploy means re-publishing the previous theme version — so staging QA is your real safety net, not a quick production hotfix.

Where YourSizer Fits

YourSizer's BigCommerce integration is built to read product and variant data directly from the Stencil product context rather than scraping rendered HTML, which is the resilience gap described above. The loader script mounts into the container div you place in product-view.html, and the widget listens for the same variant-change events BigCommerce fires natively, so color and size swaps stay in sync without custom event-wiring on your side. For teams that want the size-recommendation layer alongside try-on rather than instead of it, the two run from the same script and container — useful context if you're also evaluating how to choose a size recommendation solution for the same product catalog. The setup itself doesn't require a full theme rebuild; most merchants complete the template edit and staging QA pass described above in an afternoon.

Frequently Asked Questions

Does adding virtual try-on to BigCommerce require a custom app, or can it be done with a theme edit alone?

Both approaches exist. A theme-level integration — editing product-view.html and base.html directly, as described above — gives you the most control over placement and is what most Stencil-savvy teams use for launch. Some try-on providers also offer a BigCommerce App Marketplace listing that installs via OAuth and injects the script automatically, which trades some placement control for a faster setup with no code edits. If your team already maintains a custom Stencil theme, the manual route is usually easier to keep aligned with your design system.

Will virtual try-on slow down my BigCommerce product pages?

It can, if the script loads synchronously in the <head> or the bundle isn't optimized for lazy loading. Loading the script with defer and gating it to product-page templates, as shown above, keeps the impact minimal — typically similar to adding a chat widget or a reviews plugin. It's worth checking your Page Builder or Core Web Vitals report before and after the integration goes live, since BigCommerce surfaces this data natively and it's the most reliable way to confirm nothing regressed.

How is virtual try-on different from a standard size chart on a BigCommerce product page?

A size chart is a static reference table a shopper has to interpret against their own measurements, while virtual try-on generates a visual preview of how a specific garment looks on a body or avatar. They solve overlapping but distinct problems — one addresses "will this fit," the other addresses "will this look right on me" — and many merchants run both side by side rather than replacing one with the other. If you're weighing which to prioritize first on a limited dev budget, virtual try-on vs size recommendation breaks down the tradeoff in more depth.

Conclusion

Getting virtual try-on right on BigCommerce comes down to respecting how Stencil actually renders and updates a product page — script placement, variant-change hooks, and a real staging pass matter more than which try-on vendor you pick. Do the template wiring properly once, and it holds up through theme updates and catalog changes without turning into recurring maintenance work; skip the staging QA step, and you'll likely find out about the variant-sync bug from a customer instead of a test run.