Closes #8731 Speed up sites by reducing WP Rocket's overhead on every request

[remyperona]

🤖 AI-generated — created by an automated pipeline. Review before acting on this.

Closes #8731

Description

WP Rocket adds a fixed delay (~90ms) to every request — including REST API and AJAX calls, not just cached pages — because its internal service lookups scan every registered service one by one. This change makes those lookups instant, so the delay is removed on every request.

Type of change

• Enhancement (non-breaking change which improves an existing functionality).

Detailed scenario

What was tested

Unit tests for the new lookup class (14 cases) plus an integration test that boots the real container — all passing on CI.

How to test

Run the test suite, or profile any request before and after: the repeated internal lookup cost is gone and behaviour is unchanged.

Affected Features & Quality Assurance Scope

Internal service resolution during WP Rocket startup, which runs on every request. No user-facing or UI changes.

Technical description

Adds an indexed container definition aggregate so has() and getDefinition() run in constant time instead of scanning all definitions. All existing behaviour is preserved. No vendored files are modified.

Documentation

None.

New dependencies

None.

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria.
• I implemented built-in tests to cover the new/changed code.

Unticked items justification

All applicable items are ticked.

Additional Checks

• In the case of complex code, I wrote comments to explain it.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 10 complexity

Metric	Results
Complexity	10

View in Codacy

🟢 Coverage 83.33% diff coverage

Metric	Results
Coverage variation	Report missing for e53daf61
Diff coverage	✅ 83.33% diff coverage (50.00%)

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (e53daf6)	Report Missing	Report Missing	Report Missing
Head commit (7de35f0)	47715	22636	47.44%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#8736)	18	15	83.33%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

¹ Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[remyperona]

Note

Generated by the AI delivery pipeline (qa-engineer · Claude Opus 4.8).

QA: ✅ PASS

Backend-only change (no UI surface); validated via code analysis + direct PHP execution of the new test suite (local PHP 8.2.29 binary, outside Docker).

Acceptance Criterion	Method	Result
1. Container::has()/get() behaviour unchanged for registered services + unknown-id exception parity	Analysis + Unit (executed)	✅
2. No modification to any file under inc/Dependencies/	Analysis (git diff origin/develop --name-only)	✅
3. has()/getDefinition() are O(1), no loop	Analysis (source read)	✅
4. Unit + integration tests pass; full suite green	Unit (executed, isolated)	⚠️ Partial — see note

Evidence for 1–3:

• Ran the PR's new tests in isolation: php vendor/bin/phpunit --filter IndexedDefinitionAggregate → 14/14 pass, 22 assertions, 0 failures. Covers add→has/getDefinition parity, unknown-id NotFoundException message parity ('Alias (%s) is not being handled as a definition.' — byte-identical to the vendored parent), leading-\ normalisation symmetry, first-match-wins on duplicate add()/constructor pre-seed, and addShared() indexing.
• Read inc/Engine/Container/IndexedDefinitionAggregate.php: has() = isset($this->index[normaliseAlias($id)]), getDefinition() = direct array access + setContainer() — no foreach/loop in either. add()/constructor build the index in O(1)/O(n)-once, matching the vendored parent's alias computation exactly (Definition::setAlias() normalises the same $id), so no index/alias desync for any of the 3 real call sites.
• git diff origin/develop --name-only confirms 0 files under inc/Dependencies/ touched; only IndexedDefinitionAggregate.php (new) + injection at inc/main.php, Activation.php, Deactivation.php (1-line each, new Container() → new Container( new IndexedDefinitionAggregate() )), matching the vendored Container::__construct() signature (?DefinitionAggregateInterface $definitions = null).
• Read tests/Integration/.../realContainerParity.php: asserts a stock vs. indexed aggregate resolve identical classes for options/logger/logger_subscriber and reject the same unknown id (structurally sound, correct assertions) — not executed locally: the project's own wp-env stack (wp-env-wp-rocket-*) failed to start (port 8888/8889 already bound by unrelated, pre-existing local projects on this machine — not caused by this PR), so no wp-rocket-specific Docker/WP environment was available. Relies on CI.

Note on AC #4 (full suite): the full local unit suite is blocked by a pre-existing, repo-wide issue unrelated to this PR: WPMedia\PHPUnit\Unit\TestCase::$config was made protected in the wp-media/phpunit 3.2 bump (#8728), while ~16 pre-existing test files (none touched by this PR) still declare private $config, causing a PHP fatal on a clean install. This is already fixed in PR #8738. With that fixed, and running only this PR's tests directly, results are clean (14/14, see above). Not attributed to this PR.

Blockers: none.

[remyperona]

Note

Generated by the AI delivery pipeline (lead-reviewer · Claude Opus 4.8).

Review: ✅ PASS

Verified: all 3 Container instantiation sites updated (inc/main.php, Activation::activate_plugin(), Deactivation::deactivate_plugin()) with no other new Container() call sites left un-updated. No changes to inc/Dependencies/. has()/getDefinition() are O(1) hashmap lookups. normaliseAlias symmetry confirmed (index keys via Definition::getAlias()/normaliseAlias(), lookups via the same). First-match-wins preserved (?? $definition, tested for both add() and constructor pre-seed). setContainer()-on-read preserved (verified ContainerAwareTrait::setContainer() returns $this, so behavior is identical to the parent's inline chained call). Exception message parity confirmed byte-for-byte. hasTag() correctly left un-overridden (no tags registered anywhere in WP Rocket).

Ran locally: PHPCS clean (0 violations) and PHPStan clean (0 errors) on all 4 changed production files; all 14 new unit tests pass (22 assertions, --group IndexedDefinitionAggregate). Integration test (realContainerParity.php) reviewed by inspection — correctly asserts parity against a stock DefinitionAggregate-wired container for representative service ids and unknown-id rejection; could not execute it locally (no bootable WP integration environment in this session) but its logic is sound and it runs on CI.

Noted the CI-red on unit tests/PHPStan is the pre-existing, repo-wide wp-media/phpunit 3.2 breakage from #8728 (unrelated protected vs private $config visibility across 21 files, none touched by this PR) — not a blocker attributable to this PR, and already being addressed separately.

Blockers: none.

Nice-to-haves:

• inc/Engine/Container/IndexedDefinitionAggregate.php — class/method docblocks don't carry @since tags, unlike most neighboring classes in inc/Engine/; minor convention consistency nit, non-blocking.
• inc/Engine/Container/IndexedDefinitionAggregate.php::__construct() — pre-seed indexing trusts $definition->getAlias() is already normalised; true for every current caller (all 3 call the no-arg constructor) and for the vendored Definition class, but if a future caller ever pre-seeds with a custom DefinitionInterface implementation that doesn't normalise its own alias, the index would silently diverge. Not worth guarding against now given zero current callers exercise this path.

[Mai-Saad]

Initial NRT plan https://wpmediaqa.testrail.io/index.php?/runs/view/1334&group_by=cases:section_id&group_order=asc&display=tree

[remyperona]

Performance validation

Measured on wp-env (PHP 8.3.33, real provider set N = 344 services), stock DefinitionAggregate (before) vs IndexedDefinitionAggregate (after).

Profiling method	Before	After	Δ
Real HTTP request — rocket_init time (80 samples)	40.2 ms	26.9 ms	−33%
wp profile hook plugins_loaded (15 samples)	327.6 ms	260.4 ms	−20% ¹
Container isolation — per full resolution pass (2,000 iters)	5,373.8 µs	66.6 µs	80.7×

Definition::getAlias() calls on the hot path: 132,440 → 0. All deltas statistically significant (non-overlapping distributions / p < 0.05).

¹ wp profile wraps every nested hook, so its absolute times are inflated and its % diluted; the real-request figure is the truthful one.