Product Decisions This Supports
- Filament panel performance budget sign-off. 3.0.2 moves the per-request cost of theme splitting (~120 ms), rule indexing (~270 ms on Livewire HTML renders), and JS token scanning (~20 ms) into the cache store, landing at roughly 4.5 / 10 / 5 ms warm. That is the difference between "acceptable in staging" and "acceptable on a mid-tier production panel," and it is the kind of number that unblocks a launch or an upgrade decision rather than a new feature.
- Build vs. buy for CSS delivery. The alternative to adopting this is hand-rolling per-panel Tailwind purging or shipping a full stylesheet everywhere. Release 3.0.2 is effectively a "buy" argument: the vendor has now absorbed the hard part (indexing and invalidation) that an internal build would have to reimplement and maintain.
- Roadmap sequencing for admin/back-office surfaces. If admin panels are on the roadmap and currently ship bloated CSS, this becomes a low-effort enabler for adding more panels, custom themes, or tenant-specific branding without a linear CSS cost.
- Feature bets that depend on cheap HTML re-renders. Livewire-heavy admin UIs render HTML constantly; the ~270 ms → ~10 ms improvement on the index path makes interactive features (inline editing, filters, modals, dashboards) materially cheaper to justify.
- Cache architecture decisions. The change introduces production dependencies on the cache store — cache driver choice, key eviction, multi-server consistency, and deploy invalidation now matter to correctness. That is a decision the PM should surface to engineering before rollout, not after.
When to Consider This Package
Consider it when:
- You run one or more Filament panels with custom or per-panel themes and CSS payload has become a measurable page-weight or render-time issue.
- Your panels are Livewire-heavy — the index cost was previously paid on updates that rendered HTML, which is exactly the common path.
- You have a real cache store in production (Redis, Memcached, or a shared database cache) and can rely on it across all app servers. The new warm-path numbers assume cache hits; a cold or per-server-local cache will show a mix of warm and cold costs.
- You deploy frequently and can tolerate content-hash / mtime-based invalidation. Both are sound, but mtime invalidation on the JS scan is sensitive to how you deploy (e.g. preserving mtimes across releases, or symlink-based deploys that keep old timestamps) — worth verifying before you trust it.
- The ~120 ms theme split was the main objection to adding another panel or theme. That objection is now largely gone.
Look elsewhere or defer when:
- You are on a single-server setup with no shared cache and no appetite for adding one; the cold path remains, and you would be adopting cache infrastructure as a side effect of a CSS tool.
- Your CSS strategy is already solved (e.g. a single prebuilt stylesheet that is small enough, or a CDN-level solution), in which case this adds a moving part for little gain.
- You need deterministic, cache-independent rendering — for example, strict first-request latency SLAs, or environments where cache is flushed often (ephemeral CI previews, autoscaled cold-start-heavy fleets). Warm numbers are the headline; make sure your cold-path traffic share is acceptable.
- You are mid-freeze or mid-incident: this is a performance release, not a fix, and the cache dependency is a behavior change worth scheduling.
Before adopting, get answers on: which cache store, cache key namespacing and flush strategy, behavior under multi-tenant panels (one key each — confirm keys do not collide across tenants or themes), and whether the theme content hash covers partials/includes that affect the split.
How to Pitch It (Stakeholders)
To executives: A single upgrade removes a meaningful per-page tax from our admin panels. The worst case was ~270 ms of work on every interactive page update; it is now ~10 ms. That is a straightforward responsiveness and infrastructure-efficiency win — cheaper renders, fewer CPU cycles per request, no new product surface to support. It also lowers the cost of future admin-panel work, because adding panels or themes no longer means paying that tax each time. The trade-off is a dependency on our cache layer, which we already run; engineering should confirm the cache configuration rather than the package itself.
To engineering: 3.0.2 caches the three previously per-request artifacts — theme split (keyed on theme content hash), rule index (keyed on the same hash), and the Filament JS runtime-token scan (keyed on script mtimes) — in the configured cache store, one key each, replaced on source change. Warm costs are ~4.5 / 10 / 5 ms versus ~120 / 270 / 20 ms cold. There is also an early return when a render introduces no class the page lacks. What we need from you: (1) confirm the production cache store is shared across all app instances, otherwise every node pays the cold path; (2) review key namespacing for multi-tenant or multi-panel installs; (3) sanity-check mtime-based invalidation against our deploy mechanism — if we preserve mtimes or use symlinked releases, the scan may not invalidate when it should; (4) measure cold-path share in real traffic before we quote the warm numbers upward. No API changes or deprecations are indicated, so the integration risk is configuration, not code.