Summary
PL plugin is using plugins_api() to retrieve the data of the standalone plugin from the WPOrg API.
|
$plugin = plugins_api( |
|
'plugin_information', |
|
array( |
|
'slug' => $plugin_slug, |
|
'fields' => array( |
|
'short_description' => true, |
|
'icons' => true, |
|
), |
|
) |
|
); |
Currently, when a user loads the admin page it gets fired to retrieve the data of each available plugin:
|
return array( |
|
'webp-uploads' => 'WEBP_UPLOADS_VERSION', |
|
'dominant-color-images' => 'DOMINANT_COLOR_IMAGES_VERSION', |
|
'performant-translations' => 'PERFORMANT_TRANSLATIONS_VERSION', |
|
'auto-sizes' => 'IMAGE_AUTO_SIZES_VERSION', |
|
'speculation-rules' => 'SPECULATION_RULES_VERSION', |
|
); |
Even when the data is retrieved for all plugins, it gets fired again when the user saves the settings or loads the page, and hence page loading time increases.
To avoid hitting the WPOrg API multiple times and reduce the page load time second time onwards, we should consider caching the plugin information for a day or so in the:
- Object cache if present.
- Else, save the response data as transients.
Summary
PL plugin is using
plugins_api()to retrieve the data of the standalone plugin from the WPOrg API.performance/admin/plugins.php
Lines 21 to 30 in 0f110ff
Currently, when a user loads the admin page it gets fired to retrieve the data of each available plugin:
performance/load.php
Lines 336 to 342 in 0f110ff
Even when the data is retrieved for all plugins, it gets fired again when the user saves the settings or loads the page, and hence page loading time increases.
To avoid hitting the WPOrg API multiple times and reduce the page load time second time onwards, we should consider caching the plugin information for a day or so in the: