Assetic Static Gzip Bundle Laravel Package

Product Decisions This Supports

• Asset-delivery performance targets (Core Web Vitals / TTFB). The bundle pre-generates .gz twins of compiled CSS/JS at build time so nginx (gzip_static on) or Apache can serve them off disk with zero per-request CPU. This is a direct lever on payload size and server-side latency when you are the one serving static assets.
• Where compression happens on the roadmap. Gives you a concrete option in the "compress at build, at the edge, or at runtime?" decision — and a cheap way to remove runtime gzip from the request path before you have a CDN in place.
• Build vs. buy for a narrow capability. This is ~one gzip step wired into an existing Assetic pipeline. The decision is whether a third-party bundle earns its slot versus a two-line CI/pre-deploy shell step (gzip -9 -k over the build output) or an Encore/Vite plugin.
• Infrastructure cost conversations. Serving precompressed files reduces CPU on origin web servers — a useful data point when arguing for (or against) a CDN contract or a larger instance class during traffic spikes.
• Legacy-stack maintenance planning. With 14 stars, 0 dependents, and a single maintainer, adopting it is implicitly a decision to own a fork or accept bus-factor risk. That is a roadmap item, not a footnote.

When to Consider This Package

Important scoping note: despite the framing, this is a Symfony bundle built on AsseticBundle, not a Laravel package. There is no Laravel integration path here — do not evaluate it for a Laravel codebase.

Consider it only when all of the following hold:

• You are on a Symfony app that still uses AsseticBundle for asset compilation (roughly Symfony 2.x–3.x era; Assetic has been superseded by Webpack Encore since Symfony 3.4/4.0).
• Static assets are served directly by nginx/Apache with gzip_static, not by a CDN that compresses on the fly.
• You need gzip specifically (not Brotli) and want it produced at build time rather than per request.
• You can pin the version and are comfortable vendoring/forking a small, low-traffic dependency.

Look elsewhere when:

• The project is Laravel, or any modern Symfony app on Encore/Vite — use the bundler's own compression plugin or a CI step.
• Your CDN or edge already negotiates gzip/Brotli (Cloudflare, Fastly, CloudFront) — this bundle adds nothing.
• You need Brotli, which is the better default for text assets today.
• You are planning a migration off Assetic; adding a dependency to a stack you intend to leave is negative-value work.

How to Pitch It (Stakeholders)

To executives: A small, low-cost optimization that shrinks CSS/JS payloads and takes compression work off our web servers, improving page load times without new infrastructure. It is not a strategic bet — treat it as a tactical win with a known maintenance tail, and only if we are still on the legacy Symfony/Assetic stack.

To engineering: A Symfony bundle that hooks into Assetic's build to emit .gz siblings of compiled assets, enabling gzip_static at the web server. Adoption cost is low; the real costs are (a) Assetic is effectively end-of-life, (b) one maintainer and zero dependents means we own any bugs, and (c) a pre-deploy gzip -9 step gets ~the same result with no dependency. Recommendation: adopt only if we are staying on Assetic for the next two quarters — otherwise implement compression as a build-script step and skip the bundle entirely.