Optimizing Web Performance: Unpacking Fastly’s Intelligent Compression Defaults

In today's fast-paced digital landscape, a slow website is a losing website. It's not just about user frustration; it impacts search engine rankings and ultimately, your bottom line. 

What if there were a simple, yet powerful, way to dramatically speed up your site and cut costs at the same time?

The secret lies in content compression.  An often-overlooked optimization that can shrink payload sizes by up to 70%. By using algorithms like Brotli or gzip, you can deliver content faster, reduce bandwidth usage, and give your users a smoother, speedier experience.  All without changing a single line of your site’s design.

At Fastly, we're dedicated to making our customers' websites faster, and content compression is a cornerstone of this commitment.  In fact, we have been on the cutting edge for over a decade. 

This post will dive into Fastly's default compression settings, review their effectiveness based on recent data from the HTTP Archive, and how we use this data to provide better experiences for our customers.

How Fastly Powers Up Your Content with Compression

Fastly automatically optimizes requests to efficiently cache compressed responses, delivering a significant boost to performance. We support two primary compression algorithms for data at the edge: Gzip and Brotli.

Fastly handles content compression in a few key ways:

• Compression at Origin: If your origin server delivers content already compressed and correctly configured with Accept-Encoding and Vary headers, Fastly will ensure these compressed responses are delivered only to supporting clients and reused from cache as much as possible.

• Compression at the Edge: Fastly can also compress data directly at the edge of our platform:

• Static Compression: Static compression occurs when Fastly receives responses from your origin server before caching them. It’s highly efficient for cacheable content — Fastly takes the uncompressed response, compresses it at the edge, and stores the compressed object for future requests.

Static compression is available for VCL services using either Gzip or Brotli. Because the compressed object is cached and delivered in its smaller form, billing is based on the compressed size delivered to the client. This helps reduce bandwidth costs while improving overall performance.  Fastly can also optimize static resources even further by recompressing gzipped payloads with Brotli, achieving up to 25% smaller payloads compared to Gzip. While this process involves decompressing the origin’s response and recompressing it at the edge, the performance and cost savings make it well worth it.

• Dynamic Compression: This happens just before responses are delivered to the client, after caching. It's ideal when static compression isn't viable and is compatible with Edge Side Includes. Responses compressed dynamically are billed based on the uncompressed size before the compression takes place.

• Optimizing Accept-Encoding: Fastly normalizes the Accept-Encoding header values sent by clients. Many variations of this header are semantically equivalent (for example, gzip, br, and gzip, br, deflate).  By normalizing this header, Fastly reduces the number of cache key permutations, allowing a single cached compressed response to be reused across more users, even when their browsers send slightly different Accept-Encoding values. The result is higher cache efficiency and faster response times for end users.

Fastly's Default Compression Settings: An In-Depth Look

When you onboard with Fastly, certain compression settings are enabled by default. These defaults determine which content types and file extensions Fastly will automatically compress if they arrive uncompressed from your origin server.

Fastly's default compressible content types include:

text/html|application/x-javascript|text/css|application/javascript|text/javascript|application/json|application/vnd\.ms-fontobject|application/x-font-opentype|application/x-font-truetype|application/x-font-ttf|application/xml|font/eot|font/opentype|font/otf|image/svg\+xml|image/vnd\.microsoft\.icon|text/plain|text/xml

The default compressible extensions are:

"\.(?:css|js|html|eot|ico|otf|ttf|json|svg)(?:$|\?)"

How do these defaults perform in the real world? 

To answer this, we turn to the HTTP Archive, a monthly dataset that collects WebPageTest results for approximately 15 million URLs in Google’s CrUX dataset. 

For the July 2025 dataset, this analysis included an astounding 25 billion requests overall. This rich dataset enabled a detailed examination of request URLs, file extensions, and Content-Type / Content-Encoding response headers to evaluate compression effectiveness.

This work builds upon the foundational research by Steve Souders (2014), who also leveraged the HTTP Archive to refine and optimize Fastly’s Gzip settings—continuing a decade-long pursuit of better web performance through smarter compression.

An evaluation of HTTP Archive data for Fastly indicates that the majority of file extensions classified as compressible under Fastly’s default configuration are, in practice, delivered in a compressed format at a high rate. This alignment between configuration and observed behavior suggests that Fastly’s defaults are generally effective in optimizing transfer size for compressible content.

A notable outlier is the .ico extension, which exhibits a comparatively low compression rate. Further inspection reveals that a significant portion of resources with this extension are served with the image/png content type. As PNG is already a lossless compressed format, the incremental benefit of additional HTTP compression is negligible, which likely explains the low adoption. The table below details the most frequently observed content types associated with .ico responses.

For resources with extensions not included in Fastly’s default compressible list, a substantial proportion were still served compressed due to matches on the Content-Type header. For example, although the .php extension is absent from the default list, most .php responses in the dataset were associated with content types such as application/javascript, text/css, application/json, and text/html — all of which qualify under Fastly’s default compression rules. The only frequently observed compressible content types lacking a corresponding extension in the default list were text/vtt and text/markdown. The table below summarizes the most common content types delivered by Fastly customers and indicates whether they would be matched by the default compression rules.

Enhanced Compression Defaults: Faster Sites, Lower Costs

While Fastly’s default compression configuration was already highly effective, analysis of HTTP Archive data revealed opportunities for incremental improvement. Based on these findings, we’ve expanded the default compression rules to further increase coverage and efficiency:

Extensions added to the defaults

• jsonp

• txt

• vtt

Content types added to the defaults

• text/* (wildcard for all text-based formats)

• application/*json (wildcard for all JSON-based application types)

• application/*xml (wildcard for all XML-based application types)

These additions enable Fastly to automatically compress an even broader set of relevant content, further reducing payload sizes — a double win of faster site performance and lower delivery costs, all without changing a single line of code.

And we’re not stopping there. Our engineering teams are actively monitoring and evaluating emerging compression technologies such as Zstandard and Compression Dictionary Transport to identify where they can deliver further gains in speed and efficiency. As the web evolves, so will Fastly’s intelligent compression defaults — keeping our customers at the forefront of web performance.

Curious what Fastly’s intelligent compression could do for your performance metrics? Connect with your account team or reach out to us.  We’d love to show you!

Supporting Dataset

The BigQuery SQL used to extract the compression statistics is provided below. Executing this query processes approximately 2 TB of data (This query may exceed the free tier). 

To reduce the volume processed and lower associated query costs, the ‘is_root_page’ and ‘rank’ filter clauses can be uncommented to further limit the dataset.

WITH request_data AS (
 SELECT
   rank, page, url,
   JSON_VALUE(payload._contentEncoding) AS encoding,
   JSON_VALUE(summary._cdn_provider) AS cdn,
   header_name.value AS content_type,
   JSON_VALUE(summary.ext) AS ext,
   JSON_VALUE(summary.type) AS type,
   JSON_VALUE(summary.respBodySize) AS size,
 FROM `httparchive.crawl.requests` ,
   UNNEST (response_headers) AS header_name
 WHERE
   date = "2025-07-01"
   --AND is_root_page = true
   --AND rank <= 1000000
   AND client= "mobile"
   AND header_name.name = "content-type"
)
SELECT
 ext,
 content_type,
 COUNTIF(encoding IN ('gzip', 'br')) AS compressed,
 COUNTIF(ext IN ('css','js','html','eot','ico','otf', 'ttf', 'json', 'svg')) AS fastly_extension_defaults,
 COUNTIF(REGEXP_CONTAINS(content_type,
'(text/html|application/x-javascript|text/css|application/javascript|text/javascript|application/json|application/vnd.ms-fontobject|application/x-font-opentype|application/x-font-truetype|application/x-font-ttf|application/xml|font/eot|font/opentype|font/otf|image/svg\\+xml|image/vnd.microsoft.icon|text/plain|text/xml)')
) AS fastly_content_types_defaults,

 COUNTIF(ext IN ('css','js','html','eot','ico','otf', 'ttf', 'json', 'svg') OR REGEXP_CONTAINS(content_type,
'(text/html|application/x-javascript|text/css|application/javascript|text/javascript|application/json|application/vnd.ms-fontobject|application/x-font-opentype|application/x-font-truetype|application/x-font-ttf|application/xml|font/eot|font/opentype|font/otf|image/svg\\+xml|image/vnd.microsoft.icon|text/plain|text/xml)')) AS fastly_default_compressible,
 COUNT(*) AS requests,
 COUNTIF(encoding IN ('gzip', 'br')) / COUNT(*) AS pct_compressed
FROM request_data
--WHERE cdn = "Fastly"
GROUP BY 1,2
HAVING COUNT(*) > 1000
ORDER BY 3 DESC