[Resuelto] Severe backend performance issues with WPML String Translation (WooCommerce, PHP 8.1)

Hi WPML Support Team,

We are experiencing severe and intermittent backend performance issues on a WordPress + WooCommerce site using WPML.

Environment:

WordPress (latest)

WooCommerce (latest)

WPML CMS + WPML String Translation

PHP 8.1

No persistent object cache available (managed VPS limitation)

Database hosted remotely (not localhost)

Symptoms:

Intermittent long pending loads (very high TTFB) when generating HTML pages (products, categories).

Frontend assets load quickly once HTML is delivered, but the HTML generation itself is sometimes blocked for tens of seconds.

PHP warnings related to gzuncompress() in WPML String Translation (FieldCompression.php).

Actions taken:

We backed up and cleared WPML String Translation tables (icl_strings, icl_string_translations, etc.).

After clearing these tables, the gzuncompress warnings stopped and backend performance improved, but instability remains when WPML is active.

Questions:

Are there known performance or stability issues with WPML String Translation on PHP 8.1+ when persistent object cache (Redis/Memcached) is not available?

Is String Translation with compression enabled recommended for WooCommerce sites without object cache?

Are there recommended limits or best practices to prevent string tables from growing to a point where they cause blocking or locks?

Is there a safer alternative configuration for multilingual WooCommerce sites that minimizes backend load?

Could this be a known bug or edge case related to compression or serialized data in String Translation?

Our goal is to keep the site stable without requiring a major hosting architecture change if possible.

Thanks in advance for your guidance.