At Fastly, we’re always looking for ways to help our customers optimize for speed. Today, we’re happy to announce that (by popular request), we’ve made the Fastly control panel even better with a new Historical Stats Tool. We’ve always provided real-time stats, but we wanted to take transparency one step further. Now you can quickly and easily view your entire usage history.

This week, the Fastly team will be in New York for Velocity 2013. If you’re attending the conference, we hope you'll stop by kiosk #27 in the Sponsor Pavilion to meet the team, talk to an engineer, and grab some Fastly gear.

This week, the Fastly team heads east for Surge 2013 in National Harbor, MD. We look forward to seeing partners like Dyn, Etsy, Twitter, and Wanelo and making new connections at the conference. Here’s where you’ll find the Fastly team on Thursday and Friday.

One of my favorite computer science jokes is that there are only two truly difficult problems in computer science: naming things, cache invalidation, and off-by-one errors. At Fastly, we deal with these sorts of difficult problems every day. In our previous post on surrogate keys, we discussed how this feature can help you solve the problem of invalidating dynamic content. In this post, we’ll take a look under the hood at how we efficiently represented this system.

A few weeks ago I had the pleasure of speaking at Velocity2013 about fine tuning application performance to increase end-user experience and satisfaction.

Here at Fastly HQ, we want websites to be fast. Caching is commonly used to speed up websites. However, caching rapidly changing and unpredictably updated content can be difficult. To make it easier, we built surrogate keys: a system that makes it possible to quickly purge related content.

I recently had the pleasure of speaking at ChefConf 2013 in San Francisco. My presentation showcased how both Chef and Golden Images can be used together for deploying applications faster. I also addressed some of the common pitfalls that can make deployments painful and how to avoid them. Because we need to be able to deploy often, our goal is to be able to create a process that is repeatable, scalable and readily modified. It's not always easy and small mistakes can turn into annoying problems fast. Hope you enjoy my presentation! - Jason

When I first joined Fastly two years ago, I had a vague idea of what Content Delivery Networks – CDNs – were and how they worked. Since then I’ve learned quite a bit more from some very bright folks and now have a pretty good grip on things. It recently occurred to me that there are probably a lot of people who think about CDNs the way I once did, so I decided to share what I’ve learned by writing this article and hopefully in the process showcase some of the ways Fastly is different from traditional CDNs.

When I started Fastly in 2011 I wanted to bring the CDN experience into the 21st century – CDNs were too slow, inflexible and opaque. Based on our experience building large websites, we re-thought how to deliver content, built a powerful caching engine and tied it together with advanced distributed systems.