Boost: Reduce unnecessary CSS regenerations

[dilirity]

Proposed changes:

• Reduce number of providers needed for CSS generation from 20 to 10 (affects both free and premium versions);
• Reduce number of successful providers needed from 10 to 5 (affects both free and premium versions);
• Check if currently updated post is part of the source providers list and don't regenerate (only premium);
• Update Cloud CSS requestId to be more predictable. This allows the Boost Cloud to easily identify if a job with the same payload is already queued or deferred.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

n/a

Does this pull request change what data or activity we track or use?

no

Testing instructions:

This is easier to test with the Boost companion plugin and a local boost cloud instance.

• Setup Boost (premium) running this patch;
• Open the Boost Cloud logs (whether it's local or production);
• Add either 11 posts or 11 pages (note the first post/page you added, you'll edit it later). There should be a regeneration after each is added;
• Now edit the first post/page you added. Since that post/page won't be in the group of URLs sent to the Boost Cloud for Cloud CSS generation, there should be no generation attempt in the logs;
• Edit one of the other 10 posts/pages and there should be a generation attempt in the logs.

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Choose a review path based on your changes:
   • A. Team Review: add the "[Status] Needs Team Review" label
     • For most changes, including minor cross-team impacts.
     • Example: Updating a team-specific component or a small change to a shared library.
   • B. Crew Review: add the "[Status] Needs Review" label
     • For significant changes to core functionality.
     • Example: Major updates to a shared library or complex features.
   • C. Both: Start with Team, then request Crew
     • For complex changes or when you need extra confidence.
     • Example: Refactor affecting multiple systems.
3. Get at least one approval before merging.

Still unsure? Reach out in #jetpack-developers for guidance!

---

Boost plugin:

• Next scheduled release: none scheduled.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[haqadn]

The changes look good to me. I'll wait until hearing back from Mark on p1736786526455429-slack-C016BBAFHHS

[haqadn]

Not an objection to this change: We combine all pending critical CSS requests from the same site on the cloud. What do you have in mind with the requestId?

[dilirity]

Having the time() in there generates a new requestId every time. Because the requestId was unique each time, hydra wasn't able to to figure out if the job is in the queue or not (for the deferred jobs primarily).

To make it easier to identify in the cloud, I removed the time().

I'm not sure what you mean by "combine all pending critical CSS requests". Maybe we can discuss this sync.

[dilirity]

I've reverted the change as it was unnecessary. I was confused. More info here - p1736848836046599-slack-C016BBAFHHS

[dilirity]

Looking at this again - why do we even need time() in the mix? If we're merging requests, does the requestId even matter? Or is it so we can easily identify them for some reason?

[donnchawp]

Works for me too.

[haqadn]

👍🏼