Feature: Add support for native brotli

[nickchomey]

Issue Details

I just came across this Golang native brotli package that claims to perform much better than the other ones. Perhaps it's worth evaluating for inclusion in Caddy?

https://github.com/molecule-man/go-brrr

Here's a blog post where the author showed the great lengths they went to to optimize it. https://blog.andr2i.com/posts/2026-05-03-notes-from-optimizing-cpu-bound-go-hot-paths

Assistance Disclosure

AI not used

If AI was used, describe the extent to which it was used.

No response

[steadytao]

Thanks for raising this but I think this is too early for core inclusion.

Caddy already supports Brotli for precompressed .br assets which is usually Brotli’s strongest fit by compressing once at build/deploy time then serve the result cheaply. What this would add is on-the-fly Brotli encoding which is a different trade-off. It puts Brotli in the hot request path with runtime CPU cost, memory/allocation behaviour, streaming/reset semantics, tuning choices and another dependency in the standard build.

go-brrr looks interesting and seems useful but it is still very young and pre-v1. Before considering it for core, I would want to see it prove itself more as a library and ideally as a third-party Caddy encoder module first with Caddy-specific benchmarks against the existing gzip/zstd encode path and some real-world usage.

I would not be opposed to experimentation with this but I do not think this is ready for Caddy core yet.

[nickchomey]

Fair enough. I opened this issue on the suggestion of the maintainers of frankenphp, who are content with the cgo brotli package there since they already use cgo.

php/frankenphp#2401

[steadytao]

Completely understandable. I do find the library interesting just don't think its proven itself enough just yet for inclusion in Caddy core, nor do I think that is particularly the way Brotli is used. Will leave this open for now awaiting opinions from other Maintainers.