perf: defer the shared plugin list out of the initial document (metric: byte weight / FCP)

[phyceClaw]

Metric targeted: Total byte weight → FCP

plugins is a shared Inertia prop, so all 2048 records are embedded in the HTML of every page even though only the header search box reads them. Measured against production:

Page	Inertia JSON	of which plugins	Share
/naturalspeech	925 KB	907 KB	98%
/developers/growing	938 KB	907 KB	97%
/top	969 KB	907 KB	94%
/developers	1,095 KB	907 KB	83%

Change

Inertia::defer(...)->once(until: 10 minutes):

• Deferred — the list is excluded from the initial document and fetched by the client after paint, taking ~907 KB uncompressed (~250 KB on the wire) off the critical path of every non-homepage response.
• Once — the client records it and sends X-Inertia-Except-Once-Props on later visits, so navigating between pages does not re-send it. This matters: deferring alone would only move the same bytes off the critical path, not stop repeating them on every navigation.

The homepage is deliberately unaffected

PluginController@index passes its own eager plugins prop, and PropsResolver::resolve() does array_merge($shared, $props) before resolution — so on / the page prop replaces the DeferProp object outright. The homepage still server-renders the full table (SSR and crawlers see it as today) and advertises no deferred prop, so it issues no follow-up request.

That behaviour is load-bearing and would break silently, so there is a test asserting the homepage still has an eager plugins prop and no deferredProps metadata.

A cache bug this would otherwise have exposed

CacheResponse keyed on md5(fullUrl + X-Inertia). A deferred fetch hits the same URL with the same X-Inertia: true as a full visit — the only difference is X-Inertia-Partial-Data / X-Inertia-Partial-Component. So the two would have shared a cache entry for 60 seconds, and a partial response containing only plugins could be served in place of a whole page (or vice versa).

The key now also covers the partial and once-prop headers. test_partial_and_full_responses_do_not_share_a_cache_entry fails if that hunk is reverted — I verified this rather than assuming it.

Without deferred props this bug was latent, since nothing issued partial requests. It has to be fixed in this PR, not after.

Tradeoffs worth a maintainer's opinion

• Staleness. With once() the search index can be up to 10 minutes old within a single session, while the homepage table stays fresh. Install counts move slowly so this seemed a fair trade, but the TTL is one argument — or drop ->once(...) entirely and accept the re-fetch per navigation.
• Search latency. On a non-homepage cold load, typing immediately after paint hits a brief window where the list has not arrived. The dropdown now shows "Loading plugins…" rather than appearing to find nothing.

Verification

vendor/bin/pint --dirty, npm run build, vue-tsc --noEmit all pass; suite green (7 passed). ESLint on AppHeader.vue reports 3 import/order errors — identical to main, since this branch adds no imports there.

⚠️ The FCP effect is projected, not measured — this VPS is build-only, so I could not re-run Lighthouse end to end. The byte figures are measured off the live payload.

Interaction with the other open PRs

• perf: strip unread fields from the shared plugin payload (metric: total byte weight / FCP) #6 trims 3 unread fields from the same list. The two compose (defer the trimmed list) but touch the same line in share(); whichever merges second should keep getClientPlugins() inside the Inertia::defer() closure.
• perf(home): grid rows + content-visibility, search filters in place (metric: TBT / Style & Layout) #7 touches AppHeader.vue too. Conflicts there are in different hunks (imports/search wiring vs. the pending state).

🤖 Generated with Claude Code