Laravel Last Modified Laravel Package

Product Decisions This Supports

• Cheap wins on perceived performance and infrastructure cost. The package sets Last-Modified headers (and evaluates conditional requests) from Eloquent model timestamps, letting clients get 304 Not Modified responses instead of full payloads. That translates into bandwidth savings and faster perceived loads — a lever a PM can pull without a redesign.
• Roadmap sequencing for performance work. Because adoption is a small middleware/config change rather than an architectural one, it is a good "fill-in" item to slot between larger initiatives, or a low-risk first step before investing in a full HTTP caching layer (CDN, ETag strategy, response caching).
• Build vs. buy. This is squarely a "buy" (composer require) decision: the behaviour is generic, unopinionated, and well within the scope of a small maintained package. Building it in-house would mean owning conditional-request parsing and freshness logic for no differentiation.
• Scope decisions on caching strategy. The package covers freshness validation only (304s), not cache lifetime or invalidation policy. Deciding to adopt it clarifies that the team is standardising on Last-Modified semantics for API/HTML responses, and separates that concern from Cache-Control/CDN work.
• Framework upgrade planning. This release adds Laravel 13 support and stops testing Laravel 11. A PM can treat continued Laravel-major support as a signal the dependency will not block an upgrade cycle, and can schedule the Laravel 11 → newer upgrade without listing this package as a blocker.
• Use cases where it is a clear fit: public read-heavy content pages, JSON APIs serving entity detail endpoints, documentation or marketing surfaces backed by Eloquent, and any endpoint where the same resource is fetched repeatedly by the same client.

When to Consider This Package

Adopt when all of the following hold:

• Responses are backed by Eloquent models with reliable updated_at (or an equivalent timestamp column) that genuinely changes when the represented content changes.
• The workload is read-heavy and clients are well-behaved enough to send If-Modified-Since — browsers, mobile clients, and most HTTP libraries do.
• You want correctness-preserving bandwidth reduction without standing up a full caching layer or adding ETag generation.
• You are on a supported Laravel version. Note the 1.1.0 change: Laravel 13 is now supported; Laravel 11 is no longer in the test matrix. Teams still on Laravel 11 should either stay on the 1.0.x line or treat this as a signal to plan their upgrade — do not assume future patches are validated against 11.

Look elsewhere or defer when:

• Content is assembled from multiple sources or side-loaded relationships, so a single model timestamp would produce a stale-but-304 response — a correctness bug, not an optimisation.
• You need time-based expiry, Cache-Control policy, or CDN/stale-while-revalidate behaviour; this package does not do that.
• Responses are personalised or auth-dependent in ways where a shared validator could leak freshness signals across users.
• You already have ETag/Vary-aware caching middleware in place; running both invites conflicting validators and hard-to-reason-about behaviour.
• You require a formal vendor SLA or long-term commercial support — this is a single-maintainer community package.

How to Pitch It (Stakeholders)

For executives (one line): A small, low-risk package that lets repeat visitors' browsers skip re-downloading pages that have not changed, reducing bandwidth and improving load times for the cost of a config change rather than a project.

For engineering:

• Adds HTTP conditional-request handling (Last-Modified + 304) driven by Eloquent timestamps, via middleware and per-route configuration.
• Trivial to trial: install, enable on a small set of read-only routes, and measure 304 rate and bytes saved before broader rollout.
• Version 1.1.0 is a compatibility-only release: CI/dependency bumps plus Laravel 13 support, with Laravel 11 removed from testing. There are no new features, no deprecations, and no API changes — so there is no migration work, but the Laravel 11 drop is the one thing to confirm against our support matrix before bumping.
• Known limits to design around: freshness is only as good as the underlying updated_at; relationship or aggregated content needs an explicit freshness source; it composes poorly with a second ETag/caching layer, so pick one owner for conditional requests.
• Maintenance signal: active dependency hygiene and prompt Laravel-major support are positive, but it remains a single-maintainer dependency — worth pinning and monitoring rather than making load-bearing for critical caching.