Solid-State Drives (SSDs) are semiconductor-based storage devices that save persistent data by using NAND flash memory. See how Fastly manages caches with SSDs and how you can save.

At Fastly, we've made some key decisions about how to operate and structure our support team in a way that allows us to deliver quality at scale. Some of the lessons we learned are more specific to issues encountered as we grew, but most can be applied to any support or customer-facing team.

As many of you know, TLS best practices have changed a lot in the past two years. Recently, Fastly has changed how we configure TLS to make it even more secure. This includes migrating our TLS certificates from SHA-1 to SHA-2 and disabling RC4 for all our services.

If you want to increase the efficiency of your Varnish (or Fastly) cache, you need to figure out what traffic is not cached. By definition, any traffic that reaches your origin is not cached, and thus worthy of investigation.

What customers encounter when evaluating and onboarding with Fastly isn't arbitrary. It's an experience that we've intentionally crafted. This post will discuss what customers experience, and what we have in place to make sure it happens every time, for every customer.

TLS is especially applicable to news sites. News organizations bear a public responsibility to accurately report the news, and need to take the steps necessary to ensure credibility. The security of online news content is one of the first steps in verifying its veracity while protecting readers.

In the time I've been at Fastly, we've had enough customers and friends ask us about how we do support and what's going on under the hood that it seems appropriate to give a high level overview of how we build, what we've learned, and how other teams can borrow from our setup.

Today Logentries released a Fastly Community Pack, which automatically sets up tags, saved queries, and visualizations in the Logentries dashboard to help Fastly customers get the most out of their real-time logs.

In the second part of our series on accelerating Rails, I'll cover configuration of a few Fastly features, Varnish and Varnish Configuration Language (VCL), and strategies for caching dynamic content that are targeted towards the Rails developer.

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.

Security, compliance and transparency are very important to us at Fastly, and these updates will help protect our customers as well as our company.

In this post, I investigate several strategies for maintaining security while improving cacheability. I use Ruby on Rails for the examples, but the techniques apply to nearly any web application framework.

We’re beyond excited to introduce you to Fastly’s Community Forum. We’ve been working closely with our community to build an interactive, inclusive hub for our customers and fellow web performance nerds. The Forum is a place to share knowledge, give and receive help, and learn more about Fastly.

Americans are expected to spend $89 billion shopping online this holiday season, according to Forrester Research. Is your ecommerce site ready for the massive spike in traffic?

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.

A long time ago, I was helping out at a gaming conference where there was an intranet CMS using a Twitter search plugin. Unfortunately, the rather saturated Internet connection was slowing down all of the Twitter search requests. Each page needed 4 searches, at 500ms each, for a total of 2-3 seconds per page.

Today, we’re happy to announce a collaboration with Google Cloud Platform that will combine the power of Google’s infrastructure with the speed of our real-time content delivery network.