Statamic Image Optimizer Laravel Package

Product Decisions This Supports

• Core Web Vitals / page-speed investment: Image payload is typically the largest contributor to LCP on content sites. This addon lets you ship optimized derivatives (resized, recompressed, modern formats) without building a pipeline, so it directly supports decisions like "do we invest in performance work this quarter?"
• Build vs. buy on the image pipeline: The realistic alternatives are (a) hand-rolling resizing/compression in Laravel jobs, (b) adopting an image CDN/transformation service (Cloudinary, imgix, Cloudflare Images), or (c) taking a maintained Statamic addon. This package is the cheap end of that spectrum — a useful baseline to price the other two against.
• CMS/platform choice: If you're evaluating Statamic against WordPress or a custom Laravel build, "is there a credible image-optimization story out of the box?" is a real criterion. A maintained addon with an active release cadence is evidence in Statamic's favor.
• Editorial workflow and content operations: Auto-generating optimized variants on upload removes a manual step from the content team's process — a workflow/headcount decision as much as a technical one.
• Roadmap sequencing for a media/asset backlog: If a richer media roadmap (DAM features, responsive srcset policies, per-format quality tiers, CDN delivery) is coming, this package sets a floor you can build on or later replace. It's a "de-risk now, revisit at scale" decision.
• Cost and infrastructure tradeoffs: CPU-on-origin (this package) vs. per-transformation CDN pricing is a real budget line. The decision flips at different traffic and catalog sizes, and this is the low-end anchor for that model.

Release context for this decision: v2.1.3 is a patch release. Per semver, treat it as a low-risk, no-breaking-changes, no-new-capability bump — it should not change any of the above decisions on its own. Note the published notes are a link to the compare diff only, so confirm the actual contents against the changelog before citing specific fixes in a stakeholder doc.

When to Consider This Package

Consider it when:

• You are already on Statamic (or a Laravel app with Statamic in the stack) — this is an addon, not a standalone library, so the value is concentrated in that context.
• Your site is asset-heavy and content-led (marketing pages, editorial, catalogs) and images are a measurable share of page weight.
• You do not already have an image CDN or a transformation service in front of your assets — otherwise you'd be duplicating work, and the addon's job is largely done upstream.
• You want modern formats (WebP/AVIF) and size-capped derivatives without writing and maintaining the queue jobs, cache invalidation, and regeneration logic yourself.
• Your hosting can run the required image binaries (e.g. compression/conversion tooling on the box or in the container image). This is the most common practical blocker — verify it on your actual runtime, especially on serverless or restricted PaaS environments.
• You value a maintained dependency over bespoke code and can tolerate a smaller-community addon whose support model is essentially "the maintainer plus the source."

Look elsewhere when:

• You're on WordPress, Craft, or a non-Laravel stack — the addon has no applicability.
• You already run Cloudflare Images / imgix / Cloudinary, or your CDN does on-the-fly transformation. At that point on-origin processing adds CPU cost and cache complexity for marginal gain.
• You need video transcoding, a full DAM, or sophisticated art-direction/responsive-image policy management — scope mismatch; plan for a dedicated service.
• You operate at a scale where per-image transformation cost at the CDN is cheaper than origin CPU and storage, or where you need guaranteed SLAs and vendor support.
• Your team can't own the operational surface — binary availability, cache invalidation on template changes, storage growth from generated variants, and regeneration after design changes.

How to Pitch It (Stakeholders)

For executives (one paragraph): Page speed is a revenue and SEO input, and images are usually the biggest lever on it. This is a small, low-cost addon that automatically produces optimized image variants when content is published, so editors don't have to think about it and we don't pay a per-image transformation vendor. It's a patch release with no breaking changes — low risk, no migration work, no new spend. The strategic read is that it buys us credible image performance now and defers a CDN/transformation contract until traffic justifies it; we should revisit that decision if image volume grows substantially.

For engineering (the ask): Adopt and pin it; validate that the required image binaries are present in our container/runtime before rollout, since that's the failure mode that bites in CI and on serverless. Add a smoke test that a published asset produces expected variants, and confirm cache invalidation behavior when templates or quality settings change. Treat v2.1.3 as a routine patch — read the compare diff rather than the release notes, which are link-only, and confirm no binary-version or config assumptions shifted.

The one-line framing: a cheap, reversible bet on image performance inside the stack we already run — worth taking, with a documented trigger (image volume or CDN adoption) for revisiting it.