Fastly Sets Compression, HTTP/3 and HSTS as New-Service Defaults

Fastly is changing the starting point for new services: compression, HTTP/3 and HSTS will be enabled by default through its Recommended Defaults feature. The practical idea is straightforward. Teams creating a service begin with several common performance and transport settings in place, then review or change them before the service goes live.

That matters because these settings often sit in the gap between knowing what a service could support and configuring it to do so. A platform specialist may regard compression or protocol selection as routine. For teams focused on application development, those choices can be easy to miss during setup, even though they affect how content reaches users.

What new services get

Fastly says Recommended Defaults applies a set of high-impact, low-risk settings to each new service. Compression uses Brotli with Gzip as a fallback, allowing supported clients to receive smaller payloads while retaining an option for clients that need Gzip. HTTP/3 is enabled from the start. TLS is enforced with HSTS, which tells browsers to use secure connections for the service.

The settings reflect recommendations that Fastly says its Solutions Engineers and Customer Engineers already make during many onboarding conversations. The change puts that operational guidance into the service creation experience, so customers don’t have to remember each setting or find a separate setup guide before they can begin.

That is a useful product choice, though its effect depends on what teams serve and how their existing configuration works. Compression can reduce transferred data; HTTP/3 gives compatible clients another way to connect; and HSTS helps keep repeat visits on secure connections. These settings address different parts of delivery, so enabling them together creates a stronger starting configuration rather than a single switch that makes every service fast.

Defaults that teams can inspect

Automatic setup can be a problem when it hides behavior or makes a change difficult to undo. Fastly says the recommended settings are visible when a service is created, explained inline and editable before the service goes live. Teams can therefore see what the platform has selected and adjust the configuration to suit their service.

Starting from a populated configuration may also make review more concrete. Instead of facing an empty screen and deciding which settings to investigate, a team can examine a proposed baseline and focus attention on exceptions. That can reduce setup work for routine services, while leaving room for specialists to account for unusual client support, content types or connection requirements.

The approach shifts some responsibility from individual memory into the product interface. It doesn’t remove the need to understand a service’s needs: teams still have to check the choices and decide whether they fit. But it makes commonly recommended settings easier to consider at the point when they can be reviewed before launch.

Why the defaults matter

The case for making performance settings easier to adopt is supported by the figures cited in the source article. Digital Applied’s 2026 Page Speed Statistics report says each additional second of load time is associated with a 7% drop in conversions and an 11% drop in page views. It reports conversion rates of 39% for pages loading in one second and 22% for those taking five seconds. The report also says more than half of mobile visitors leave a site that takes over three seconds to load.

Those figures describe the stakes of slow pages, but they don’t show what improvement any particular Fastly customer will see from these settings. Results depend on the service, its content, its users and other parts of the delivery path. The more direct point is that a configuration step can determine whether established performance options are used at all.

Adoption data suggests that gap remains. Google’s Chrome User Experience Report for May 2026 found that 55.9% of tracked origins passed all three Core Web Vitals. Digital Applied’s benchmark report says Google tightened the Largest Contentful Paint threshold from 2.5 seconds to 2.0 seconds in its March 2026 core update. Separately, TechnologyChecker’s protocol adoption analysis put global HTTP/3 traffic at around 21% to 28% in early 2026, despite support in every major browser.

A practical change with a clear test

Fastly’s move is incremental in technical scope: the settings themselves already exist, and the company describes them as familiar recommendations. The product change is where those options appear in the workflow. By enabling them at service creation, Fastly makes the recommended configuration the starting point rather than a follow-up task.

For teams, the immediate value is less repetitive setup and a baseline they can inspect before launch. The next thing to watch is how well that baseline fits varied services, and whether teams can understand when an adjustment is needed. Speed becomes easier to pursue when routine configuration is handled early; the useful measure will be whether customers can validate the defaults against their own services and keep the settings that serve them well.