In the continued quest to increase cache hit ratios, the chant is: "Normalize, normalize, normalize." Less variation in your requests means you have a higher chance of getting hits. This month's highlight is the Host header.

Caching is one strategy that helps ease scaling pains that I often see Rails developers overlooking. Starting out with caching can be confusing, because terms and documentation can be convoluted, especially if you’re not an expert.

In this post, I’m going to discuss how you can leverage ESI and VCL (Varnish Configuration Language, the domain-specific language that powers Fastly’s edge scripting capabilities) to use JSON responses, even when they’re loaded from another site. This is useful in many cases, including various analytics and social sharing instances.

Today, we’re excited to announce two related features that lower bandwidth costs and reduce origin load for Fastly customers, resulting in faster downloads for their users: Streaming Miss and Large File Support.

Fastly recently conducted an extensive analysis of which resources should be compressed. Today, the results of that analysis are reflected in the Fastly app, which allows our customers to adopt better gzip settings. This not only makes our customers' websites faster, but it will also reduce monthly bandwidth charges.

Hooman Beheshti, VP of Technology at Fastly, recently gave a talk at Velocity NYC 2014 about the challenges CDNs face with dynamic content and how businesses can use programmatic means to fully integrate their applications with their CDN.

Fastly is excited to announce that as of today, we support stale-while-revalidate and stale-if-error. As a company dedicated to building a better Internet, we work hard to identify and support new standards that move the Web forward. Read on for an explanation of how these Cache-Control extensions make the Web faster and more reliable for browsers and CDNs, and check out documentation of these features.

Fastly customers can use ESI to cache pages that contain both cacheable and uncacheable content (such as user-specific information).

Vary is one of the most powerful HTTP response headers. However, if used incorrectly, it can cause problems for developers. Understand vary header best practices to reduce mistakes and improve performance.

In a blog post about caching with tracking cookies, I explained how Fastly’s edge scripting language allows businesses to cache things that were previously uncacheable as well as send data back via our real-time logging system.

But what happens when you need to cache something more complicated, such as a product that handles user interaction?

In this, our final API Caching installment, we're going to explore how to use Surrogate Keys to reduce the overall complexity of caching an API.

At Fastly, we’re always working to make our systems faster and more reliable. One of the more difficult problems we’ve faced is efficient cache invalidation across our global network, or as we call it: Instant Purging. When content changes, our customers issue a purge request, which we then need to deliver to each of our cache servers. The system that handles these purge requests is codenamed Powderhorn.

Build a network that can scale indefinitely, be managed by a small crew of skilled ops and network engineers, and handle current web traffic and the next generation of protocols. Sounds impossible, right?

Not true.

When planning a major content delivery network, you’d think that it would make sense to put your equipment where the most people are, right?

Not always.

In Part 1, we covered the basics of using Fastly to accelerate a comments API. Using Instant Purge, we hooked into model callbacks to ensure that the appropriate content was purged from the cache whenever data changed. In this article, we’ll build upon the original approach and use one of Fastly’s more advanced features: cache control.

The web has come a long way since the 90s. In the past, sites were commonly driven by a single, monolithic application that acted as the only communication medium to a centralized database. The modern approach is to break this one large application into a set of interdependent and cooperative services.

At Fastly, we’re constantly working to upgrade our network and expand global capacity. Last week, we built up capacity in our Ashburn, New York City, and Los Angeles POPs and brought a new Miami POP online to improve user experience in South and Central America. We also brought a second London POP online and increased the capacity in our existing London and Frankfurt POPs. In addition to our existing POPs in Tokyo and New Zealand, we’ve added new POPs in Singapore and Hong Kong to bring our customers’ content even closer to users in Asia Pacific. These upgrades are already available to current customers.

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.

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.