Server-side image swap performance

[rhoerr]

Profiling a client site in New Relic, I found Yireo_NextGenImages frequently adds ~140 ms to the response times of category and product page views. This is purely for parsing, checking, and swapping to WebP images -- all images are already converted.

Is there anything that can be done to optimize this?

[jissereitsma]

Before diving deeper into this, could you mention which version of Yireo NextGenImages you are using? And also, I'm assuming that you are using the Yireo Webp2 module. Which version is that? Which PHP version?

In my own results - profiled months ago - I only saw additional loads of 20-30 ms. Still a lot perhaps, but a lot less than WebP. 140 ms sounds huge, but it would be nice to know the percentage of the total page load, to put things in perspective.

Theoretically, https://symfony.com/doc/current/components/dom_crawler.html could be used to make things a bit faster. in a similar way like the following: https://github.com/yireo/Yireo_LinkPreload/blob/master/Link/LinkParser.php

[rhoerr]

Versions:

PHP 8.1

            "name": "yireo/magento2-next-gen-images",
            "version": "0.5.14",
...
            "name": "yireo/magento2-webp2",
            "version": "0.14.3",

Yes, this is with the Yireo Webp2 module.

• PLP page size is 20 products.
• Total HTML size for a given page is 800-1000 KB (I'm working on cutting this down -- a lot of menu code).
• Average TTFB is 800-1100 ms. 95th percentile is 2300 ms. The profile was a notably slow load, so closer to that 2 second mark. It's possible the actual time is much lower on average pages, but if so, we still have these slow high-percentile loads like the screenshot.
• The environment is a Nexcess Cloud VPS. No network file storage involved. I haven't dug into code to see what exactly is causing the slow replace call (whether that's CPU-bound, or I/O bound, or something else).

[Yonn-Trimoreau]

@rhoerr @jissereitsma I can confirm this issue on Adobe Commerce Cloud platform with a category page containing 378 images (we have a significant number of swatch images).

As shown in the screenshot, the DOM parser is not the cause of the slowness.

After running a few benchmarks on my local environment (where I was experiencing ~460ms delays), I identified this line as the sole culprit: $html = str_replace($imageHtml, $pictureHtml, $html);

By replacing str_replace with strtr, I was able to reduce the execution time to under a millisecond.

You can find the corresponding pull request here: #93