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:
- Starting the process with a trigger
- Sending information to the API
- Checking the status
- Retrying, if needed
- Applying the optimization
Heads up! This is an advanced-level article dedicated to documenting the asynchronous approach in-depth.
Feature requirements
WP Cron or a server side cron 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:
- 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. - 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.
- 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.
- 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.
- 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 processedin-progress
- when Used CSS is being processedcompleted
- when the used CSS for a URL has been createdfailed
- when a request was not successful, i.e, it doesn't send a200 (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
ishttps://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.