-transparent.png){kind=spacer}
I received a request regarding a solution with extremely bad performance. The solution was running DynamicWeb 10.10 with Swift frontend and integrated with Dynamics NAV 2018. First impression was that loading a product detail page took around 21 seconds. In the Live Integration log there was a request of 96 products, and the response had generated 96 prices plus 288 unit prices, so a total of 384 prices, which NAV had spent 20 seconds on processing.
In the Live Integration setup, the “Use unit prices” flag was on:
This setting is used to show prices for different units of measures (pieces, boxes, pallets, etc.), when we want to offer the customers to purchase goods in different UoMs. In this case we don’t, and after switching this setting off, the load time dropped from 21 seconds to 6 seconds.
6 seconds is still a long time to wait for a page to load in 2024, so there is still room for improvement. The live integration no longer retrieved unit prices, but it still retrieved prices for 96 products, i.e., the number of variants of that particular product. The reason for this is to be found in the configuration of the Products app on the PDP. In the “Variant info” selector box, all properties are included, because nothing has been selected. This also includes prices, so when loading the PDP, DW sends a price/stock request to NAV to retrieve all prices.
In this scenario, we display a list of variants on the PDP, but the variant info is not processed by this instance of the Products app but by the “Related products list” component. So, adding an entry to the “Variant info” (except price, of cause 😉) excludes the price processing on this instance, and so the price request with the 96 products is not sent from here.
It is a relatively new feature that the price request is not done if it is not included, so definitely worth checking if you have experience response rates.
So, now we were down to 0.35 seconds for loading the page around 1.5 seconds including the list of variants. But there’s still something gain to make.
The Related products list lazy loads products onto the page by e.g. 12 products at the time. The implementation in Swift is not ideal, however, since at the first load it loads 12 products, loading the next batch then also includes the first batch, so 24 products in total. So, loading the last batch on this page will process all 96 products including a price request of 96 prices.
The live integration has a setting to cache product information in page or session scope. By setting this to “Session” DynamicWeb will cache the received price information for 20 minutes after the last interaction from the user. So, by setting this, Swift will still eventually load 96 products from DynamicWeb, but the live integration will only retrieve the prices that are not in the cache from the ERP system:
The downside of this is that when there is interaction from the user, the prices and stock are not refreshed from the ERP system. Prices may not change much, but stock change all the time, and there is a risk of overselling your stock. So, you’ll have to assess, do I accept this risk, but keep in mind that online shoppers are impatient and may have faster access to goods at the competitor shop.
So, with three settings we went from 21 seconds load time on each the page load to 1.5 seconds on first load an around 0.7 for subsequent loads. Definitely not a bad result from clicking around in the UI 😊
