comotive

An update to 5.4 didn’t help. Claude analyzed as follows:

—-

Performance culprit: matomo/device-detector

The main suspect is the new DeviceDetector library (Server.php:58-60). In v5.3, Weglot
replaced their bot detection with matomo/device-detector — a heavy library that:

1. Parses the full User-Agent string against thousands of regex patterns from large
   YAML files (browsers, bots, devices, OS — ~70k lines of regexes added in this commit)
2. Runs on every single page request — Server::detectBot() is called during the
   translation flow to determine if the visitor is a bot
3. Has no caching — each request re-instantiates new DeviceDetector($userAgent) and
   calls $dd->parse(), which runs through all those regexes fresh every time Previously Weglot likely had a simple string-match bot check. Now it loads and
   evaluates a full device detection library.

Other changes (less likely culprits)

• New preserve_words feature with regex processing (but only runs if
  weglot_preserve_words_enabled filter returns true — off by default)
• New Iubenda third-party integration (only loads if Iubenda plugin is active)
• New get_default_regex_checkers() for data-et-multi-view attributes (Divi builder)

—

I’ve mitigated by injecting a class loader like this

spl_autoload_register(function ($class) {
if ($class === ‘DeviceDetector\\DeviceDetector’) {
require_once __DIR__ . ‘/src/customer_name/Weglot/CachedDeviceDetector.php’;
return true;
}
return false;
}, false, true);

The CachedDeviceDetector then roughly does the same as the original class. Doing this actually results in -400ms, so claude is most likely correct 🙂 I’il keep that in place until this might be solved (by object caching?) within the plugin.

• This reply was modified 1 month, 2 weeks ago by comotive. Reason: made it more clear that our own CachedDeviceDetector does kinda the same, so code depending on it still works