Assetic Static Gzip Bundle Laravel Package

Getting Started

Prerequisites (read this before composer require): the bundle compresses the output of assetic:dump, so it only makes sense on a project that already uses AsseticBundle (Symfony 2.x/3.x, pre-Flex). On Symfony 4+ Assetic is no longer integrated and this bundle has nothing to hook into. Also confirm you control the web server, because the whole point is serving the .gz siblings it writes.

Minimal setup:

1. composer require konstantin-kuklin/assetic-static-gzip-bundle — watch what Composer does to your symfony/* and assetic/* constraints. Version pinning is the most likely failure point.
2. Register the bundle in app/AppKernel.php (prod at minimum):

   new KonstantinKuklin\AsseticStaticGzipBundle\AsseticStaticGzipBundle(),
   

3. Inspect the available configuration rather than guessing:

   bin/console config:dump-reference assetic_static_gzip
   

4. Dump and look at the result:

   bin/console assetic:dump --env=prod
   ls -l web/js web/css   # expect app.js.gz next to app.js
   

5. Verify end-to-end, not just on disk:

   curl -sI -H 'Accept-Encoding: gzip' https://example.test/js/app.js \
     | grep -iE 'content-encoding|vary|content-length'
   

Where to look first: the README (usually thin at this star count), then DependencyInjection/Configuration.php and Resources/config/services.yml to see exactly what service/event it hooks, and finally the listener or writer decorator itself. Ten minutes in those three files tells you more than the docs will.

First real use case: you have an assetic:dump step in deploy, nginx with gzip_static on;, and you want to stop paying CPU for on-the-fly gzip on every request to app.js/app.css.

Implementation Patterns

• Treat the .gz files as build artifacts. They only exist after a dump. In dev, either run assetic:dump --watch or accept that you're testing the uncompressed path; don't be surprised when a fresh checkout serves no .gz.
• Deploy pipeline pattern. Order matters: dump → verify .gz exists and is newer than the source → deploy. A cheap guard in CI:

  test -f web/js/app.js.gz || { echo "missing gzip"; exit 1; }
  for f in web/js/*.js web/css/*.css; do gzip -t "$f.gz"; done
  

  The most common production incident with this bundle is "we deployed but the old .gz is still being served."
• Server pairing is the real config work. nginx:

  gzip_static on;
  

  Apache needs a rewrite that serves .gz with Content-Encoding: gzip and Vary: Accept-Encoding — the bundle does not do this for you.
• Versioning/immutability. If your Assetic output includes a content hash (app-4f3a1c.js), the .gz inherits it and long Cache-Control headers are safe. If output names are stable, add a hash in the Assetic config or you will eventually serve a stale compressed file against a fresh HTML reference.
• Filter chain interaction. Gzip happens after the Assetic filter chain and the write, so uglify, cssrewrite, etc. all run first — good. It compresses whatever ends up dumped; it does nothing for files produced elsewhere (Webpack, hand-written vendor files).
• Environment gating. Only enable in prod/staging where gzip_static is actually on. In dev you generate noise that hides real problems.
• CDN/object storage. Local files only. If assets are pushed to S3/CloudFront, your upload step must also ship the .gz and set Content-Encoding: gzip per object; otherwise the bundle's work is wasted.
• Smoke test in CI (same as the curl above) is worth more than any unit test here — it catches server config drift, which is the failure mode you actually hit.

Gotchas and Tips

• The ecosystem is the gotcha. Assetic has been effectively unmaintained for years and Symfony dropped the bundle integration in 4.0. If Composer resolution fights you, stop — you're burning time on something the modern toolchain solves for free (Webpack Encore/Vite + compression-webpack-plugin, or plain nginx gzip on;). Reserve this for genuinely legacy apps already on Assetic.
• Double-serving confusion. With both gzip on; and gzip_static on;, nginx prefers the pre-compressed file when present and falls back to dynamic compression otherwise. That's fine, but it means "is my .gz being used?" can't be answered by a browser alone — verify with curl -I and check Content-Length against ls -l of the .gz.
• Content-Length mismatch is the classic breakage. Some Apache rewrite recipes send the uncompressed length with a compressed body, producing truncated or hanging responses. If JS "randomly fails to parse" in one environment, check headers first.
• MIME type. Serving .gz as application/gzip for a .js URL breaks module loading in strict clients. Always set the type from the original extension and add Vary: Accept-Encoding.
• Ownership/permissions on deploy. The .gz files are written by whatever user runs assetic:dump; on CI-driven deploys that's often a different user than the web server. Compare ls -l of the .js and .js.gz — mismatches here cause silent 403s that only affect clients sending Accept-Encoding: gzip.
• Debugging workflow: assetic:dump -vvv, then compare stat of source and .gz, then check your app/var logs for errors from the bundle's listener or writer decorator. If the listener throws, the whole dump can fail — a good reason to keep it out of dev where you dump often.
• Extension points are limited. Compression level and which extensions get gzipped are the two things you'll want to tune; check Configuration.php before assuming they're configurable. If not, decorating the bundle's service or listener from your app is the clean patch — but you've now forked behavior on an unmaintained dependency.
• Scope: CSS/JS only. Do not expect it to help images, fonts, or JSON responses.
• Support expectations: 14 stars, 0 dependents, no meaningful issue traffic. Assume you are the maintainer if it breaks on a PHP or Symfony minor. Budget for reading source and, if needed, pinning a working commit in composer.json rather than fighting for a release.