Asynchronous optimizations

WP Rocket has a few asynchronous optimizations. This means that while the optimizations are applied automatically, they are not instantaneous, and they require a series of steps (and time) before they're applied to a site.

The following features are applied asynchronously:

  • Optimize critical images - The critical images have to be detected before their related optimizations are inserted into the pages.
  • Automatic Lazy Rendering - The HTML elements which are below the fold have to be detected, and then, their optimized markup will be applied to the pages.
  • Remove Unused CSS - The pages have to be scanned, and the Used CSS has to be generated before it's applied to the pages.
  • Load CSS asynchronously - The different page types have to be scanned, and the Critical Path CSS has to be generated, so that it can finally be added to the pages.

Overview

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.

Basic requirements

WP Cron or a server-side cron (preferred) is very important for this WP Rocket approach, please check his article for more information.

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. With the Mobile Cache option, the plugin will also send info about whether the request is 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 generation fails the first time, WP Rocket will retry generating the CSS up to 5 more times.

    To avoid overloading the CPU, the waiting time between each retry will be gradually incremented.

    If the generation fails after the 5th retry, the Used CSS for the specific URL will be marked as 'failed' in the database and WP Rocket will retry to generate the Used CSS in these cases:

    • After 3 days passes.
    • The used CSS for a specific URL is cleared using the "Clear Used CSS of this URL" admin bar menu item while visiting the URL in the back end.
    • The whole used CSS is cleared using the "Clear Used CSS" admin bar menu item while visiting WP Rocket's settings page.
    • The Automatic clearing of Used CSS takes place.
  5. Applying the optimization

    If the API indicates the Used CSS for a page is available, upon the next visit, that page's cache will be cleared so new cache can be generated that includes the resulting Used CSS.

    Again, this visit can be triggered by a user or the Preload.

Technical notes for Remove Unused CSS asynchronous approach

  • Your site's database will store an entry for each optimization request in a table named wpr_rucss_used_css (one entry for each URL).
  • The optimization requests are sent to WP Rocket's external tool, which handles each of them as a job.
    • The external tool's API_URL is https://saas.wp-rocket.me/.
  • The API will respond and the value for the status column in the wpr_rucss_used_css table will be updated accordingly for each entry.
  • The wpr_rucss_used_css table status column will have one of these five possible values for each entry:
    • to-submit - Initial status for all pages that are triggered for Used CSS generation, meaning the page needs to have Used CSS generated, but processing is not scheduled yet.
    • pending - Status for pages that have been submitted to be processed in the generator, meaning processing is scheduled but has not started yet.
    • in-progress - Status for when Used CSS is currently being processed by the generator.
    • completed - Status confirming that the generator has successfully created the Used CSS for the URL.
    • failed - Status when a request was not successful, i.e, it doesn't send a 200 (OK) status code. In this case, the error_code, and error_message columns will show more details.
  • The rocket_rucss_on_submit_jobs cron event will process and control how many new URLs can be sent to the Used CSS generator (pending status) in each batch.
  • The maximum number of URLs that can be in pending status at any given time is set to 300 by default.
    • This value is calculated as 3 times the number of the rocket_saas_pending_jobs_cron_rows_count filter value (which is 100 by default).
    • This limit is in place because if the total number of pending jobs gets too high it can lead to Used CSS generation errors.
  • All of these optimization requests and status checks rely on WP Cron or a server-side cron (preferred).
  • If a response comes back as completed it means:
    • The Used CSS is generated and ready to be applied, so the cache for the URL will be flushed on the next page view.
    • Entries' hashes will be stored in the database in the wpr_rucss_used_css table.
    • The Used CSS is stored on your server's disk in the /cache/used-css/1/ folder. If you use WordPress multisite, the folder named /1/ will change to reflect the site number.
  • If the Used CSS generation fails the first time, it means that:
    • Additional attempts of Used CSS generation for the page will be made for a maximum of 5 total retries. The additional 5 retries will happen only for URLs whose Used CSS generation failed because of a temporary issue, but they won't happen if the URL doesn't meet the basic requirements.
    • If the request response is still not successful after the 5 retries, the status for that page will remain as failed, and other pages will be processed.
    • For pages with failed status, Used CSS generation will be retried again either after 3 days or 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 Remove Unused CSS feature:

  • rocket_saas_pending_jobs_cron_rows_count - Specify the number of new pages WP Rocket will schedule for processing (set to pending status) in each batch.
    • The default value is 100 URLs.
  • rocket_saas_pending_jobs_cron_interval - Set the time interval between each request to schedule more pages for processing.
    • The default value is 60 seconds.
  • rocket_rucss_max_pending_jobs - Set the maximum number of URLs that can be in pending status at any particular time.
    • The default value is 300, which is calculated as 3 times the value of the rocket_saas_pending_jobs_cron_rows_count filter.
Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.