Slow website and large wp_option autoload

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Our wait time is higher than usual, please make sure you are meeting the minimum requirement - https://wpml.org/home/minimum-requirements before you report issues, and if you can take a look at current Known Issues - https://wpml.org/known-issues/. Thank you.

Sun	Mon	Tue	Wed	Thu	Fri	Sat
-	8:00 – 13:00	9:00 – 13:00	9:00 – 13:00	8:00 – 12:00	8:00 – 12:00	-
-	14:00 – 17:00	14:00 – 18:00	14:00 – 18:00	13:00 – 17:00	13:00 – 17:00	-

Supporter timezone: Europe/Zagreb (GMT+02:00)

Tagged: Performance

This topic contains 0 replies, has 0 voices.

Last updated by Bruno Kos 1 day, 13 hours ago.

Assisted by: Bruno Kos.

Author	Posts
April 4, 2025 at 11:11 am
Gerardo Bramati	Background of the issue: I am trying to address a slow website issue, particularly on the Dashboard side, where loading times can reach 15 seconds. Site Health indicates a large number of records in wp_option autoload. We've changed web hosting several times and even tried a local environment, but the website still times out with error 504. Using Query Monitor, I noticed a slow HTTP call linked to WPML: GET hidden link cURL error 28: Operation timed out after 5000 milliseconds with 1702220 out of -1 bytes received. The issue can be seen at hidden link. Symptoms: The website is experiencing very long loading times, especially on the Dashboard. There is a cURL error 28 indicating a timeout after 5000 milliseconds. The site also goes into timeout with error 504. Questions: How can I reduce the loading time on the Dashboard? What can be done about the large wp_option autoload records? How do I resolve the cURL error 28 linked to WPML? What steps should I take to prevent the website from timing out with error 504?
April 4, 2025 at 12:30 pm
April 7, 2025 at 8:25 am #16902822
Bruno Kos Supporter Languages: English (English ) German (Deutsch ) French (Français ) Timezone: Europe/Zagreb (GMT+02:00)	It looks like the REST API might be disabled on your site. To check this, we ping the REST endpoint and store the result as a transient. If that transient isn’t being set, the system keeps trying to ping repeatedly. This could be a sign there's an issue with the wp_options table in your database that's preventing transients from being saved correctly. Can you please try the following: 1. Manually set a transient named `_transient_wp-rest-enabled-ping` with the value `enabled`. You can do this by temporarily adding the following code to your theme’s `functions.php` file or via a plugin like Code Snippets: add_action('init', function() { set_transient('wp-rest-enabled-ping', 'enabled', 12 * HOUR_IN_SECONDS); }); After adding it, visit your site in a browser to trigger the code, then you can safely remove it. Alternatively, if you're using WP-CLI, run: wp transient set wp-rest-enabled-ping enabled 43200 2. Confirm that the transient was successfully set: - Via database: Check your `wp_options` table and run the following SQL query: SELECT * FROM wp_options WHERE option_name = '_transient_wp-rest-enabled-ping'; If you see a row with the value `enabled`, it’s confirmed. - Via plugin: Install a plugin like https://wordpress.org/plugins/transients-manager, search for `wp-rest-enabled-ping`, and check if the value is set to `enabled`. Let me know about the results!