Webp Convert Laravel Package

Product Decisions This Supports

• Build vs. buy for image optimization. This package lets you ship server-side WebP generation without building (and perpetually maintaining) a converter-detection layer. It replaces a "we'll write our own fallback logic" ticket with a single Composer dependency.
• Feature: automatic next-gen image delivery. Supports shipping "upload a JPEG/PNG, we serve WebP" in a media library, avatar pipeline, CMS, or product catalog. Directly tied to Core Web Vitals (LCP), page weight, and mobile conversion metrics.
• De-risking infrastructure decisions. Because it abstracts cwebp, vips, Imagick, GD, ffmpeg, GraphicsMagick, and remote converters behind one API, you can ship the feature before knowing what binaries your hosting fleet exposes — and defer "which binary do we standardize on?" to a later, cheaper decision.
• Hosting/portability strategy. Answers the question "will this work on shared hosting where exec() is disabled?" It falls back to GD/Imagick-based conversion or leaves originals untouched, which changes your deployment requirements doc.
• Roadmap sequencing for modern formats. Establishes the WebP generation step now, leaving AVIF (or a CDN) as an additive follow-on rather than a rewrite.
• Quality/bandwidth tradeoff policy. Its quality and metadata options are where product decides how much fidelity to trade for bytes — a measurable decision (quality 75–82 vs. 90) rather than an engineering default.
• Risk acceptance. A 603-star, single-maintainer MIT package is cheap and reversible (no lock-in, permissive license), so it lowers the bar for "try it on one surface first."

When to Consider This Package

Adopt it when:

• You are on PHP/Laravel and need server-side JPEG/PNG → WebP conversion of existing or user-uploaded assets at request or queue time.
• Your hosting is heterogeneous or constrained — shared hosting, cPanel, containers without cwebp, or exec() disabled — and you need graceful degradation rather than a hard dependency on one binary.
• You want one API that transparently tries the best available backend, including remote/cloud converters as a last resort.
• You already have an established upload/storage flow and want to insert a conversion step without re-architecting.
• You want a small, permissively licensed dependency you can remove later with minimal blast radius.

Look elsewhere when:

• Throughput matters. Per-image PHP execution and binary spawning do not scale like an image CDN (imgix, Cloudinary, Cloudflare Images) or a dedicated worker service. Use this for low/medium volume or as a bridge.
• You need rich transformations — on-the-fly crop, resize, focal point, format negotiation. Pair with intervention/image or move to a service; this package converts, it doesn't do a full transform API.
• You need AVIF/HEIC or format negotiation at the edge — a CDN handles Accept headers and format selection better than PHP.
• You're building a static site or build-time pipeline — sharp, squoosh, or spatie/image-optimizer in CI is a better fit.
• You need contractual support or an SLA. Confirm the release cadence yourself first — the metadata here lists a 2026 release date, and with a single primary maintainer, a bus-factor and security-review conversation is warranted before making it critical-path.
• Your platform already guarantees cwebp or Imagick everywhere — a thin wrapper may suffice, though this package still saves you the fallback maintenance.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed library that lets us serve WebP images without paying per-image fees or signing a CDN contract. Smaller images mean faster pages, better Core Web Vitals, improved SEO and mobile conversion, and lower bandwidth bills — the usual levers for e-commerce and content sites. Integration is small and reversible: no vendor lock-in, no procurement, and we can pilot it on one surface before committing.

For engineering: One composer require, PSR-friendly, actively maintained, MIT. It solves the genuinely annoying problem — you don't know which converter exists on each host, and exec() may be off — by trying cwebp, vips, Imagick, GD, ffmpeg, and remote fallbacks in order, and failing safe to the original image. We stop owning that detection matrix. Concerns to plan for: do conversions off the request path in a queue/job, monitor conversion-failure rates and output sizes, pin the version, and note it's effectively single-maintainer — so treat it as a swappable dependency behind our own small service class rather than calling it throughout the codebase.

For product/design: It enables "upload once, we serve optimized images" without asking users to change anything. Default quality (~80) is the knob that governs the fidelity/bandwidth tradeoff, and we should measure it against our own imagery rather than guessing.