Cookies Can be Costly: How Separate Domains Can Save Big Bucks

At Eventbrite, we use separate domains for our static assets. Instead of having something like eventbrite.com/media, or media.eventbrite.com, we use completely different domains for hosting things like CSS, JavaScript, and Images. There are lots of reasons why we do this, but one of the big ones is saving our customers money and time. We’ll go into the details of what we do, but we need to go over some background first.

To start, remember that the full set of cookies that match the domain and path are sent with every web request, provided the cookie is valid (i.e., not expired, not secure on a non-secure connection, etc). For various reasons, most of the cookies Eventbrite sets are tied just to domain (*.eventbrite.com), and a survey of other top sites shows this is a pretty common practice. This means that, for most sites, having 50 requests to *.domain.com will result in a complete copy of the matching cookies being sent 50 times.

If you work on a site that gets a large amount of traffic (>1M pageviews/day), you might see why this can be a problem, but let’s break it down further.

Let’s pretend eventbrite.com gets 10 million pageviews per day. This is not our real pageview number, just an example for this post. Let’s further say that that the homepage has about 60 static assets, and those assets are hosted at media.eventbrite.com.

10 million x 60 requests = 600 million requests

For instance, say Eventbrite has about 1kB of cookies on it’s homepage, and all of those cookies get sent on every request to *.eventbrite.com

600 million requests x 1kB = 600,000,000 kB

600,000,000 / 1024≈ 585,937 MB

585,937 / 1024 ≈ 572 GB

So our customers in this hypothetical example are sending out over half a terabyte of cookies per day. This isn’t good, and it’s expensive. How expensive? Well, that’s a bit tricky to calculate, and depends a lot on locale. So let’s make some assumptions that will get us an order-of-magnitude calculation. Assumption 1: All these page views are in the US. Assumption 2: Half of our traffic is mobile. With these assumptions, we can use the findings in the Open Technology Institute’s Cost of Connectivity report to see how much we’re costing our mobile users.

572 GB / 2 = 286 GB ≈ Cookies sent over Mobile in US for our example

According to the report, 3GB of data costs about US$30, which makes a nice easy US$10/GB.

286 GB x US$10 = US$2860

So, if we were to have all our static assets hosted at a subdomain of our primary URL, we would be costing these hypothetical mobile users around US$2,860 per day. Another way of looking at this is we would be costing these example users US$1,043,900 per year.

Thankfully, this is not how eventbrite.com is set up. We don’t pay the “cookie cost” because we have our static assets hosted on a separate domain that is linked to from our pages. Since that static asset domain doesn’t set cookies, our users don’t have to send those cookies when they ask for an image or css file.

If your site is in a position where you’re making your users pay the cookie cost, I’d highly suggest creating a new domain for static content and switching the URLs in your codebase to that domain. As an added bonus, if you make that domain available over HTTPS, you can update all your URLs to only request assets over HTTPS, and provide a more secure experience for your users.

If you’re interested in helping make Eventbrite even more performant and better for our users, we are hiring. Thanks for reading!

One thought on “Cookies Can be Costly: How Separate Domains Can Save Big Bucks

Leave a Reply

Your email address will not be published. Required fields are marked *