Asynchronous optimizations

Feature overview

WP Rocket uses an asynchronous approach. Currently, Remove Unused CSS and Load CSS Asynchronously are applied asynchronously.

In general, an asynchronous optimization follows these steps:

1. Starting the process with a trigger
2. Sending information to the API
3. Checking the status
4. Retrying, if needed
5. Applying the optimization

Heads up! This is an advanced-level article dedicated to documenting the asynchronous approach in-depth.

Feature requirements

Asynchronous approach for Remove Unused CSS

The asynchronous approach for the Remove Unused CSS uses the following specific steps for Used CSS generation and application:

1. Starting the process with a trigger
   
   A visit to an uncached page will generate the cache of the page. If Remove Unused CSS is enabled, this will trigger the generation of the used CSS for that page.
   
   The visit can be done by the Preload or a visitor.
2. Sending information to the API
   
   The plugin sends the page's URL to the API. If the "Separate cache files for mobile devices" feature is enabled, the plugin will also send info about whether the request if for desktop or for mobile.
   
   
3. Checking the status
   
   After 60 seconds, WP Rocket's cron will call the external API to ask about the status of the requests.
   
   In the database, each entry will have a status that is set according to the API response.
   
   
4. Retrying, if needed
   
   If the Used CSS isn't ready, it'll be processed during the next batch. WP Rocket will retry up to 3 times to see if the used CSS of a specific URL has been created.
   
   If the retries limit is reached, the Used CSS for the specific URL will be processed the next time Used CSS is cleared, and the process starts again.
   
5. Applying the optimization
   
   If the API indicates the Used CSS for a page is available, that page's cache will be cleared.
   
   Upon the next visit, the cache will be generated this time including the resulting Used CSS.
   
   Again, this visit can be triggered by a user or the Preload.
   

Technical notes for Remove Unused CSS asynchronous approach

• The database will store an entry for each optimization request, one for each URL.
• Entries' hashes will be stored in the database in the wpr_rucss_used_css table.
• Used CSS entries will be stored in the server disk, at the /cache/used-css/1/ folder.  If you use WordPress multisite, the folder named /1/ will change to reflect the site number.
• The database will have a status column, with four possible values, as follows:
  • pending - when Used CSS is waiting to be processed
  • in-progress - when Used CSS is being processed
  • completed - when the used CSS for a URL has been created
  • failed - when a request was not successful, i.e, it doesn't send a 200 (OK) status code.
• For each entry, a request will be sent to WP Rocket's external tool and will be handled as a job.
• External tool's API_URL is https://saas.wp-rocket.me/.
• The API will respond and the value for the status column will be set accordingly for each entry.
• The status checks rely on WP Cron or a server side cron.
• If the request response is completed , the Used CSS is ready to be applied and the cache for the URL will be flushed.
• If the request response is failed , other two attempts will be done. There is a maximum of 3 retries.
• If the request response is not successful after the 3 attempts, the item status will be kept in failed  and will be processed after clearing the Used CSS of this entry (or all Used CSS entries).

Available filters for Remove Unused CSS

The following filters are available to customize the batch size and the frequency of the cron runs.

• With rocket_rucss_pending_jobs_cron_rows_count you can handle the number of pending jobs WP Rocket will process in each go.
  
  The default value is 100 URLs.
• With rocket_rucss_pending_jobs_cron_interval you can set the interval between two requests to process pending entries.
  
  The default value is 60 seconds.