Responsive Image Craft Laravel Package

Product Decisions This Supports

• Feature scope for media-heavy pages: v0.0.10 adds sizes attribute support alongside existing responsive image generation. This closes the most common gap teams hit when shipping srcset — without sizes, browsers assume full-viewport width and download oversized assets. That makes "responsive images done properly" a shippable feature rather than a partial one.
• Performance / Core Web Vitals roadmap: correct sizes hints reduce bytes downloaded on mobile and directly support LCP and page-weight targets. This is a concrete, low-effort lever to cite in a performance OKR rather than a speculative optimization.
• Build vs. buy: the package occupies the "generate derivatives + emit correct markup" layer. Building this in-house is a few days of work plus ongoing edge cases (DPR variants, format negotiation, cache invalidation). Adoption is defensible if you're already on Laravel and don't need a CDN-side image pipeline.
• Use cases that fit: marketing/CMS-driven pages, product listing grids, editorial content with variable image widths, and any layout where the same asset renders at multiple breakpoints.
• Use cases that don't: design systems already fully served by a DAM/CDN with URL-based transforms, or SPAs where image markup is produced client-side.

When to Consider This Package

Consider it when:

• You're on a supported Laravel version and want responsive image handling without a third-party image CDN.
• Your templates render images server-side (Blade) and you want srcset/sizes emitted consistently rather than hand-written per view.
• You need per-breakpoint derivative generation but your asset volume is modest enough for local/queue-based processing.
• Your front-end layout is width-constrained (grids, cards, sidebars) — this is precisely where the new sizes support pays off.

Look elsewhere when:

• Version stability matters. At v0.0.x the public API is pre-1.0; minor bumps may include breaking changes. Don't adopt for a long-lived platform without pinning and a migration budget.
• A CDN or DAM (Cloudinary, imgix, ImageKit, etc.) already handles resizing and format negotiation — you'd be duplicating the derivative pipeline.
• You need guaranteed long-term maintenance, a security disclosure process, or a support contract. Single-maintainer packages with a first-time contributor in this release need a bus-factor conversation.
• Your pipeline requires AVIF/WebP negotiation, art direction with <picture>, or per-image focal-point cropping — verify these exist before committing; the release notes only confirm sizes.

Adoption gate: pin the exact version, wrap the package behind your own image-rendering abstraction so a swap is cheap, and confirm the maintainer's release cadence before it lands in a customer-facing surface.

How to Pitch It (Stakeholders)

To executives: This is a small, focused library that makes our images load correctly on phones and desktops — serving smaller files where the layout is narrow instead of forcing one large download. The latest release adds the piece that makes that sizing actually accurate. Expected impact is lower page weight and better mobile load times, which is what our performance metrics track. Cost is low; the main caveat is that it's an early-stage (0.0.x) open-source dependency, so we'd pin the version and keep it behind our own interface so we're never locked in.

To engineering: The package generates responsive image derivatives in Laravel and emits srcset/sizes markup from Blade. v0.0.10 adds sizes support, which fixes the default full-width assumption and lets us express real layout constraints per component. It's pre-1.0 with a single primary maintainer — adopt with a pinned version, an internal wrapper around the rendering API, and a documented fallback (CDN transforms) if maintenance stalls. Confirm coverage for format negotiation and <picture> art direction before we scope it into a milestone.