Performance problem on listings and widgets with Price box

[ilnytskyi]

Preconditions (*)

1. 2.4-develop or any previous version

Usage of \Magento\Catalog\Block\Product\ListProduct::getProductPrice in app/code/Magento/Catalog/view/frontend/templates/product/list.phtml or product boxes in widgets affects listing performance. It calculates price for products again even if the values received from collection. On the screenshot you can see that product items have price values.

Then when a product is rendered, magento starts to resolve the price

It does these steps:

• Looks for price renderer
• loads linked products for composite products
• Resolve price type (it already available from collection)

Because the prices already available from the collection it's enough to render formatted price value (amount and currency) [e.g. 10.00 $]. But magento loads prices again does comparations and then renders it. Even when sort by price used.

Steps to reproduce (*)

1. Render price box from the product collection on listing or search pages
2. Use simple or composite products
3. See that price boxes consumes a lot of time for price rendering by calling \Magento\Catalog\Block\Product\ListProduct::getProductPrice in the loop

Expected result (*)

1. Prices are rendered faster
2. Redundant loads and price comparations in ListProduct::getProductPrice are eliminated
3. ListProduct::getProductPrice just formats given price float values. It does not resolve prices again
4. Moreover it does not load linked/child products

Actual result (*)

1. Prices are rendered slowly
2. ListProduct::getProductPrice loads extra price data and performs comparations
3. ListProduct::getProductPrice does not use data already available from collection, loads prices again
4. ListProduct::getProductPrice loads child/linked products and performs redundant price resolve.

[m2-assistant[bot]]

Hi @ilnytskyi. Thank you for your report. To help us process this issue please make sure that you provided the following information:

• [ ] Summary of the issue
• [ ] Information on your environment
• [ ] Steps to reproduce
• [ ] Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

@ilnytskyi do you confirm that you were able to reproduce the issue on vanilla Magento instance following steps to reproduce?

• [ ] yes
• [ ] no

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[m2-assistant[bot]]

Hi @engcom-Delta. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).

  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 4. Verify that the issue is reproducible on 2.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

• [ ] 5. Add label Issue: Confirmed once verification is complete.

• [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

[magento-engcom-team]

:white_check_mark: Confirmed by @engcom-Delta Thank you for verifying the issue. Based on the provided information internal tickets MC-31591 were created

Issue Available: @engcom-Delta, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

[verheesj]

Isn't this because the product in question is a configurable product?

[ilnytskyi]

@verheesj yes, but the problem is in its price renderer implementation

[m2-assistant[bot]]

Hi @vishvesshah. Thank you for working on this issue. Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• [ ] 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 2. Verify that the issue is reproducible on 2.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

• [ ] 3. If the issue is not relevant or is not reproducible any more, feel free to close it.

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[VladimirZaets]

Action items to fix:

• Verify that recalculated data is the same as the data from the index table ( collection )
• If data the same, refactor implementation to use data from the index (collection)
• If not, investigate the reason why data is different

Action items to testing:

• Test fix with all types of the price (Tire, special, catalog rule, layered navigation prices)

[m2-assistant[bot]]

Hi @engcom-Kilo. Thank you for working on this issue. Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.
• 2. Verify that the issue is reproducible on 2.4-develop branch
     Details

     - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
     - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
     - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
• 3. If the issue is not relevant or is not reproducible any more, feel free to close it.

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[mrtuvn]

This one still valid today. Hope someone can take a look at it

[Nuranto]

Hope we'll have a fix for this in 2.4.5 !

Note : I see that @engcom-Kilo's commit deals only with configurable products. We have the same issue with grouped products. If this can help with grouped products, here is some trace from newrelic : Rest of the trace :

[Nuranto]

still valid on 2.4.5. I think this issue should be upgraded to P1 priority.

[MTheProgrammer]

Same here, prices are loaded separately for every product of the configuration.

EDIT: One trace says that MSI is a bottleneck: The plugin: Magento\InventoryConfigurableProduct\Plugin\Model\Product\Type\Configurable\IsSalableOptionPlugin::afterGetUsedProduct is called in: Magento\Catalog\Pricing\Render\FinalPriceBox::_toHtml

        if (!$this->salableResolver->isSalable($this->getSaleableItem())) {

Also this line might be slow as it check sku manually for every product: Magento\InventorySales\Model\AreProductsSalable::execute

        foreach ($skus as $sku) {
            $isSalable = $this->isProductSalable->execute($sku, $stockId);
            $results[] = $this->isProductSalableResultFactory->create(
                [
                    'sku' => $sku,
                    'stockId' => $stockId,
                    'isSalable' => $isSalable,
                ]
            );
        }

isProductSalable calls composite stock resolvers in a loop which has major impact on the performance.

[lukutpg]

I had also performance issue for configurable product which have almost 2000 simple products (Magento CE 2.4.4). For me the most slow was function \Magento\InventoryConfigurableProduct\Plugin\Model\Product\Type\Configurable\IsSalableOptionPlugin::filterProducts, so I just overridden it with follow code:

--- vendor/magento/module-inventory-configurable-product/Plugin/Model/Product/Type/Configurable/IsSalableOptionPlugin.php   
+++ vendor/magento/module-inventory-configurable-product/Plugin/Model/Product/Type/Configurable/IsSalableOptionPlugin.php
@@ -106,15 +106,24 @@
      * @param array $isSalableResults
      * @return void
      */
-    private function filterProducts(array $products, array $isSalableResults) : void
+    private function filterProducts(array &$products, array $isSalableResults) : void
     {
+        $isSalableResultsTest = [];
+        foreach ($isSalableResults as $result) {
+            if (!$result->isSalable()) {
+                $isSalableResultsTest[$result->getSku()] = $result->isSalable();
+            }
+        }
+
+        if (empty($isSalableResultsTest)) {
+            return;
+        }
+
         foreach ($products as $key => $product) {
-            foreach ($isSalableResults as $result) {
-                if ($result->getSku() === $product->getSku() && !$result->isSalable()) {
-                    $product->setIsSalable(0);
-                    if (!$this->stockConfiguration->isShowOutOfStock()) {
-                        unset($products[$key]);
-                    }
+            if (array_key_exists($product->getSku(), $isSalableResultsTest)) {
+                $product->setIsSalable(0);
+                if (!$this->stockConfiguration->isShowOutOfStock()) {
+                    unset($products[$key]);
                 }
             }
         }

[MTheProgrammer]

Exactly, MSI is querying every stock for every product. Another pain point is swatches renderer which loads all options for every configurable product on the listing.

[jakwinkler]

Latest version of M2 has the same issue.

[hubertus2017]

For google shopping we there upload each simple products of configured products with their prices and individual links to preselect the option, e.g.

https........html?ps=MTU4PTIxOCYxNTk9MjIy#158=218&159=222

When loading the page, for the first second it displays the "as From" price from the lowest price of another simple product of the configurable product. Later (3 second?) it renders the correct price of the simple product together with its swatches. But that's too late for the google shopping crawler. He takes the first displayed "from price", which is incorrect. this leads to penalties at google and wrong ads.

I looked into final_price.phtml files but it did not help. i believe the Magento_Catalog/js/price-box.js must be changed?

Either to get rid of the display of the "from price" and/or how to speed up the display of the correct price?

Magento ver. 2.4.4

[jlenzstaysafe]

Latest version of Magento Commerce. Performance cannot be this bad, this isn't acceptable. We're sadly looking at other platforms as a result. I really want to stick with Magento, but I honestly cannot make a good case for it when things like this always make it to production.

[ilnytskyi]

@jlenzstaysafe try this module https://github.com/EcomDev/magento2-product-preloader As claimed it fixes Price of configurable product on product list can be some sort of workaround

[jakwinkler]

@ilnytskyi @jlenzstaysafe this module is just a one part, it still requires to create a custom module and optimization of SQL queries. But yes, using it you drop PLP page to under 700ms load time