Closes #7894: Improve Rocket Insights time to get score - phase 2

[jeawhanlee]

Description

Fixes #7894
Improved the time to get score by reducing async wait time.

Type of change

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

Detailed scenario

What was tested

Cut down the time taken for RI score to be displayed after submission.

Total time taken for RI task on develop

Total time taken for RI task with current PR

How to test

• Use this filter to log the total time taken for a RI job to complete:

  add_action('rocket_rocket_insights_job_completed', function($row_details, $job_details, $current_plan){
      error_log('Total time taken for RI test to complete on ' . $row_details->url . ': ' . ( time() - $row_details->data['start_time']) . ' seconds');
  }, 10, 3);

• After RI test completes check debug.log

Technical description

Documentation

Bypass Async queue and schedule single task to process job in an estimated time in the future.

• Created a new method in WP_Rocket\Engine\Common\JobManager\Queue\Queue with the same hook name being shared with add_job_status_check_async method
• Called Queue instance in Rest Class and called this new method directly handle_sync_submission method
• Also update job to in-progress before calling new method.

Fallback
WIP

New dependencies

N/A

Risks

N/A

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Unticked items justification

Not applicable to the changes in this PR.

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.).
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for a2313ae1	✅ 66.67% (target: 50.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (a2313ae)	Report Missing	Report Missing	Report Missing
Head commit (53244e1)	41825	18808	44.97%

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 (#7915)	30	20	66.67%

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%

See your quality gate settings    Change summary preferences

Footnotes

1. 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. ↩

[wordpressfan]

Minor changes/questions.

I really like the PR description that it contains how time is enhanced here, good job Boss.

[hanna-meda]

Thank you, @jeawhanlee, for this PR.

Sharing the new timings using this PR compared against results from phase 1 PR results:

URL	Old Avg (Previous PR)	New Timings	New Avg
home	64.25s	64s, 38s, 45s, 32s → 44.75s	44.75s
post	44.67s	42s, 38s, 54s, 69s → 50.75s	50.75s
custom post	77.67s	35s, 56s, 32s, 67s → 47.50s	47.50s
product	57s	31s, 49s, 34s, 41s → 38.75s	38.75s
page	65s	34s, 47s, 41s, 40s → 40.50s	40.50s
Avg.	61.7s	—	44.85s

Overall improvement: 61.7s → 44.85s = 16.85s faster on average.

Notes:

• Same URLs were used. For each, the first try is ADD and the second is Re-Test, except for home, where the first is the auto-added home page.
• Open issue URL keeps loading in UI in some cases seems to be fixed. It did not occur in 20+ tries. There is still a delay between results being written in DB and shown in UI, but no more infinite spinner/loading states.

Shared results also on slack thread.

[hanna-meda]

QA Done. PR is looking good and all NRT in TP have passed.
testrail-report-791.pdf