Internal Contents
Summary
- CDN hosts images on multiple server nodes for faster image load time.
- Page speed is one of the metrics that search engines such as Google use for ranking search results.
- Cloudflare is our provider for CDN services.
- Merchants can use tools such as Pingdom to check their site speed and review recommendations for improvements.
- Customized themes should take advantage of our CDN to improve page speed, and thus SEO.
Support Notes
- Editor's Note: All of this content came from an Confluence page developed from a post by Chris Boulton in the forum that was created at the time the CDN was introduced to the platform, and was last updated August 15, 2013.
- You'll see language referring to the CDN like it is new. When it was introduced, some clients had concerns about their image file names and their impact on their search engine rankings. Long story short, the speed gains from the CDN outweigh whatever small SEO benefit you might have had from file names.
How our CDN works
We utilize what's called an "origin pull" based CDN platform. That is, content is not uploaded to the CDN, it is instead fetched from our origin (your store) first visit, and then cached on the edge node that the request went through.
The CDN URL for a BigCommerce store (and I will cover structure of the URLs below) actually maps back to the http://store-xxx.mybigcommerce.com/ URL that every BigCommerce store has, over our internal/private network.
It's easy to verify that we're using an origin pull based CDN. You can take any store-specific URL that goes through the BigCommerce CDN (product image, etc) and map it back to the existing URL:
- CDN: http://cdn2.bigcommerce.com/server3800/fb2b6/products/300/images/387/partypets_blowout_l__96761.1323375219.600.600.jpg
- Store: http://www.kidspartymall.com/products/300/images/387/partypets_blowout_l__96761.1323375219.600.600.jpg
The first request for an asset follows a path like this, and if there's a "hit" anywhere along the way, the image is returned immediately which offloads the traffic from your store, and the internals of our infrastructure.
Browser/Visitor ‹ › CDN ‹ › BigCommerce Cache Server ‹ › BigCommerce Store
We operate another layer in between the CDN and your BigCommerce store in order to prevent what's known as "thundering herd". Because each first hit from a CDN edge results in a "miss" on that edge and a hit back to us, in order to prevent multiple hits back to our internal infrastructure from each of these edges, we cache the images on an internal cache server.
What's with the URL structure?
There's a lot of discussion about why CDN URLs don't include a store's domain name, or why they're not hosted on a subdomain of a store.
A lot of thought went in to the URL structure before the CDN was launched, and the URL structure we've implemented is the only implementation that's feasible.
First, I need to explain why it's not possible to use a store's domain or a subdomain to serve content over the CDN.
-
SSL: Content from the CDN may need to be delivered over SSL (HTTPS) on certain pages. Each BigCommerce store that has its own SSL certificate requires a dedicated IP address (stores with shared SSL share a handful of addresses from a pool). Each IP address (a second IP address, one for each store utilizing the CDN) would require provisioning, and configuration. This comes at a significant setup, and then significant monthly cost. Not only is there the cost, the provisioning process is not instantaneous (it takes a day or two), and cannot be automated.
There are workarounds to this, such as SNI (server name indication), which allows you to get around having a dedicated IP address for each SSL certificate, but all of the provisioning and management problems still exist.
(Side note: with Amazon Cloudfront, secure content is not loaded over your vanity URL, which means images/content loading over the CDN on secured pages would load off a Cloudfront URL and not that of your store.)
-
Configuration: Each origin domain/vanity domain needs to be configured on the CDN. We have nearly 30,000 stores on the BigCommerce platform at the moment, and each time a store needs to be provisioned or deprovisioned, the CDN needs to be reconfigured, which can take up to 1-2 hours before the changes are live. They would also make management a nightmare, as any change as to which origins to point back to would require 30,000 CDN edge CNAMEs to also be reconfigured. DNS changes, etc, also play into this a little as well.
One of the other suggestions that I've seen mentioned was the addition of a store's domain name to a CDN URL, so it looks similar to cdn1.bigcommerce.com/mitchs-shoe-store.com/xxx.jpg.
This was something we considered, however this is problematic for two reasons:
-
When a store's domain changes, as would the CDN URL. All content that was then linked via the CDN and not controlled by BigCommerce (copy/pasted image URLs embedded on other pages, etc) would then 404.
-
There's another technical/architecture limitation that I can't discuss right now, which was factored into the decision ever so slightly - the primary reason is the first above.
Unfortunately some of the solutions and ideas that have been discussed here and on UserVoice will work fine for a single store, but don't work at scale when you're working with 30,000. As others have noted - our competitors actually work in a very similar way to us when working with CDNs, because it is the only way that will work at scale.
Other FAQs
What is CDN?
CDN stands for Content Delivery Network. The CDN serves your store from servers distributed around the world instead of from just one or two locations.
Can the CDN be turned off for my store?
There is no opt-in/opt-out for the CDN. With no changes in the way your store appears and functions, we don’t want to hold back the gains in speed that positively impact your site experience and sales.
How does this affect my SEO?
Google uses site speed as a ranking factor, and rank faster loading sites higher. BigCommerce uses a CDN to make your site load faster. It makes it faster because your shoppers are now served from a place that’s closer to them. The biggest speed gains will be experienced by shoppers who are closer to one of our CDN nodes, some of which are located in London, Los Angeles, New York, Sydney, Tokyo, Sao Paulo, Hong Kong and Singapore.
I’ve noticed that my images, CSS and Javascript files are sometimes delivered by cdn1.bigcommerce.com , and sometimes by cdn2.bigcommerce.com. What's up with that?
Delivering content over multiple hostnames allows us to parallelize downloads in web browsers, which limit open connections per domain. By having more simultaneous connections, we can achieve even faster page loads. This is best practice, and is acknowledged by Google and Yahoo.
Why can't you utilize an application delivery platform (ADN)?
An ADN is basically whole site acceleration. Your entire BigCommerce store would be pushed through the ADN, and then for certain paths the ADN would cache the content on their edges. The big benefit is all traffic loads over optimized traffic paths that are owned/managed by the service provider delivering the ADN instead of the general Internet.
An ADN is problematic for a service such as BigCommerce, for reasons I've discussed above - SSL certificates, and configuration/management for the large number of stores we manage.
Timeline
- 4/29/2021 — Migrated from Akamai to Cloudflare for CDN services. (KB-13406)
- 5/22/2017 — Migrated from Fastly to Akamai for CDN services. (KB-4220)
Changelog
- 8/10/2021 — Reworded information on theme assets. (KB-14167)
- 5/24/2021 — Removed mention of Akamai. (KB-13557)
- 4/12/2021 — Maintenance. Updated links, wording. (KB-12905)
- 5/1/2020 — Maintenance. Updated Internal notes anchors. Fixed links. Updated wording. (KB-11062)
- 7/23/2019 — Maintenance. (KB-8858)
- 8/14/2018 — Maintenance review. (KB-7391)
- 2/5/2018 — Internal article summary and changelog sections added. Added more links to additional resources (KB-6309)
