A huge amount of the content on the web is static. Delivering that content should be simple, cost-effective, do everything you'd expect of a modern website, and not get in the way of the dynamic parts of your user experience.
Static hosting providers vary in the feature set they provide and a variety of Fastly features can be helpful. When defining a backend, you should almost always configure a host header override and this is usually necessary for static content hosting providers like AWS S3 and Google's Cloud Storage. Learn more
Most other actions you may find useful in dealing with static content hosting can be implemented in VCL or your preferred Compute@Edge language.
Ideas and typical uses
Here are some of the things that customers putting Fastly in front of a static hosting provider or storage bucket will typically do:
- Some bucket hosts may require a path prefix.
- You may need to add /index.html to bare directory URLs.
- To avoid serving ugly error pages, consider detecting and replacing error responses with custom error pages.
- It's better to have the cache TTL of an object defined at the origin, but if that's not possible you could override the cache lifetime.
- Consider removing extraneous HTTP headers like
x-goog-hash, and adding best practice security headers like
Content-Security-Policy. Learn more.
- You may want to ensure that traffic to the backend host comes only from Fastly.
- When you move objects around in your buckets, redirect the old paths at the edge.
The following demos, tutorials, starter kits, and code examples are relevant to this use case. Try them out!
Template Compute@Edge applications you can use to bootstrap your project.
|Static content||Apply performance, security and usability upgrades to static bucket services such as Google Cloud Storage or AWS S3.|
Snippets of code ready to copy and paste.
|AWS S3 bucket origin (private)||Use AWS authenticated requests (signature version 4) to protect communication between your Fastly service and AWS.|
|Alibaba Object Storage Service origin (private)||Use authenticated requests to protect communication between your Fastly service and Alibaba's Object Storage Service.|
|Azure blob storage bucket origin (private)||Use Microsoft Azure authenticated requests to protect communication between your Fastly service and Azure.|
|Google Cloud Storage origin (private)||Use AWS compat mode to make authenticated requests to your GCS bucket.|
|Google Cloud Storage origin (public)||Use a public GCS bucket as a backend for your Fastly service.|
Real world usage
Many Fastly customers incorporate static content delivery into their Fastly services.
The cURL project, beloved of developers everywhere for it's straightforward but powerful ability to wrangle HTTP requests on the command line, fronts its website using Fastly, as part of our Fast Forward program. cURL's main developer Daniel Stenberg is a fan:
The curl website is almost entirely a set of generated static HTML and CSS pages. They are built from source files that trigger a rebuild when anyone of them is updated. A static website is snappy to serve, cache-friendly and it is easy to run a local copy of it on your own dev machine to try out website changes before you deploy.