Sulu Image Optimizer Bundle Laravel Package

Product Decisions This Supports

• Media pipeline cost modeling: Quantifies how much storage and egress you can shave by normalizing and compressing uploads at the source rather than storing originals and re-deriving derivatives later. Useful input for CDN/object-storage budget conversations.
• Build vs. buy vs. ignore for image optimization: This bundle sits in the "pre-storage" layer of the stack. It clarifies a decision boundary — do you optimize at upload (this package), at render (Sulu's image format/thumbnails system), or at the edge (CDN transform services like Cloudflare Polish, imgix, Fastly IO)?
• Core Web Vitals / LCP roadmap item: Smaller source images mean smaller derivatives and faster delivery. This is a concrete, low-effort lever to attach to a performance initiative, especially for editorial-heavy sites with untrained contributors uploading 8MB camera JPEGs.
• Editorial UX decision: Whether to enforce optimization automatically in the upload flow (invisible to editors, zero training) or push the burden onto content teams with guidelines and manual pre-processing. This package argues for the former.
• Dependency risk / maintenance ownership: The archived status and near-zero adoption make this a fork-and-own decision, not an install-and-forget one. That's a resourcing call, not just a technical one.
• Scope check against Sulu's native capabilities: Before adopting, validate that Sulu's own image format and thumbnail configuration plus a modern Imagine/post-processor setup doesn't already cover 70–80% of the benefit — which would make this package redundant.

When to Consider This Package

Consider it when:

• You run Sulu 2.x (Symfony-based CMS) with a media library that receives large, unoptimized source files from non-technical editors.
• Storage and bandwidth costs are material and growing — media-heavy catalogs, marketing sites, multi-site deployments.
• You want optimization to be transparent to editors and applied consistently at ingestion, rather than relying on content guidelines.
• You have in-house PHP/Symfony capability to fork the repo, audit the image-processing path, pin dependencies, and own upgrades. Treat it as source code to adopt, not a vendor product.
• You're already paying for an image optimizer binary/library (jpegoptim, pngquant, cwebp) or can add one to the container — the bundle is a thin integration layer, not a standalone optimizer.

Look elsewhere when:

• You need vendor support or SLAs. Archived repo, 2 stars, 0 dependents, single maintainer history — there is no support channel and no community safety net.
• You can solve it at the edge. A CDN with on-the-fly transformation (imgix, Cloudinary, Fastly IO, Cloudflare) usually delivers more value per engineering hour, including modern formats (AVIF/WebP) and responsive variants, and requires no application code.
• You need modern format negotiation and responsive art direction. Pre-upload compression alone won't produce AVIF/WebP derivatives or srcset variants — that's Sulu image formats plus a CDN or a dedicated transformation service.
• Your Sulu version, dependency constraints, or PHP runtime don't match. With no release cadence to speak of, compatibility gaps are yours to close.
• Your upload volume is low. If you're storing a few hundred images a month, the engineering overhead of owning a fork outweighs the savings.

How to Pitch It (Stakeholders)

One-liner: A small Sulu add-on that compresses and normalizes images the moment they're uploaded, so the media library never stores bloated originals.

For executives: Editors routinely upload multi-megabyte camera images. Every one of those is stored, replicated, and served — often several times over as thumbnails and responsive variants. Optimizing at ingest is the cheapest point in the pipeline to fix that: it cuts storage and egress costs and improves page load times without adding a step to anyone's workflow. The trade-off is ownership: the project is archived and effectively unmaintained, so adopting it means our engineering team forks it and carries it. That's a small, well-bounded piece of code — but it is a commitment, not a purchase.

For engineering: Hooks Sulu's media upload path to run images through an optimizer before persistence. Thin integration surface, straightforward to audit and fork. Two things to settle before committing: (1) confirm it isn't duplicating what our Sulu image-format configuration and CDN already do; (2) decide whether the fork lives in our monorepo or as an internal Composer package with pinned dependencies and a container-level optimizer binary.

Recommendation: Evaluate as a fork-and-own candidate, not a dependency. First run a two-week spike measuring current library size distribution and egress, then compare the projected savings against a CDN transformation service — the edge option usually wins on both capability and maintenance burden unless storage/egress is unusually concentrated in origin-served assets.