Storefront handlebars not consistently working on instances of BigCommerce

[fthobe]

Expected behavior

Featured products and other storefront elements show up as implemented in the source code of the custom template.

Actual behavior

We run a template in a sandbox store as well production for the purpose of developing a heavily modified template.

While the following code results on the sandbox in showing the product on the production system it doesn't.

<div id="featured" class="other-products">
    <div class="other-products_title">
        <div class="other-products_title_text">
            <div class="bold">Promozioni e sconti</div>
        </div>
    </div>
    {{> components/custom/carousels/shop-carousel products=products.featured 
        columns=5 
        listName="Featured Products"
        productType="featured"
        event="product-list"
    }}
</div>

UPDATE

@karen-white it just got slightly more complicated: The issue presents itself in production front-end but not in the Customize Theme preview screen:

@robertoboldi

[karen-white]

Hi @fthobe , could you share the URLs for your stores please so we can take a look? Thank you!

[fthobe]

Goodmorning @karen-white ,

here you go: Sandbox: ricomprostaging.it Prod: ricompro.it

[karen-white]

Thanks @fthobe ! It looks like the staging store is on our newer version of the storefront service and the production store was on the older version. We've switched the production store to the new storefront service, and it looks like the featured product carousel is now showing. Could you confirm whether the issue looks resolved on your end?

[fthobe]

@karen-white First let me say thank you because you solved the problem, but now products that our out of stock appear in category pages despite they shouldn't.

See https://www.ricompro.it/iphone-xs-argento-512-gb-usato-ricondizionato-rigenerato/

[karen-white]

Sorry to hear that didn't completely solve the problem. Could you link us to a category page where the out of stock product is appearing? And are you only seeing this behavior on the production store--not the staging store--when the themes applied to both stores are identical?

[fthobe]

@karen-white Hi Karen, well.... we fixed one problem but we opened up another can of worms :(

our production environment used to be ~10-15 points ahead on google page speed insights on mobile. Since the update we lost them. While we always scored very highly on desktop (~94-97 of 100 points) mobile dropped from 75 to low 60ies. We have the impression that TTFB dropped significantly (TBH BC was never the quickest horse in the stable). As we work in a very competitive landscape (mobile handset sales) any ranking factor counts for us because marginal differences in ranking factors can impact you dramatically. Please find below current scores.

[karen-white]

@fthobe That's odd, we would have expected you to see a performance improvement on the new service, but thanks for letting us know--we'll have the team check it out. In the meantime, please let us know if you'd like us to switch you back to the old service for the time being.

[karen-white]

@fthobe We're having a tough time replicating those numbers on your store. I'm seeing a Lighthouse score of 100, both on mobile and on desktop. Could you point us to the settings you're using to run the audit? thanks!

[fthobe]

Hi @karen-white , some notes:

• keep in mind that your internal chrome result can vary for various reasons
  • your local connection might be much stronger than the average
  • your local DNS (router) will eventually cache the DNS entry of the URL
  • your computer will cache the DNS entry of the URL
  • check if you use GCP Hybrid Connectivity which gives you direct access from your office network to cloud network, that might have another positive impact
  • check if you are on Google Fibre, that might give you another advantage as google traditionally doesn't route externally what can be routed internally

Best practice would be to use Google Page Speed Insights which shows consistently even lower results to us than before. BTW: I was able to replicate the results on:

• online page speed insights (see pictures below attached)
• chrome as I use personally on my mac
• Chrome on a vanilla installation of MacOS without any extensions (we sell refurbished hardware, so we have a lot of them here
• Chrome on in incognito mode

What you see is great on one side and bad on the other: Good:

• if you score 100% it means that we done heavy mistakes on front-end coding and cornerstone seems to work great (💖;)

Bad:

• it means that content serving from either GCP or Akamai is not working properly. I can't say though if this is up to your configuration / investment or up to Akamai / GCP not working properly and not serving content by the closest location.
• keep in mind that Google disproportionally favors fast servers on mobile given the increased latency of mobile devices on 3g/4g/5g/wimax compared to most cabled WAN connections such as Fibre
• Akamai and GCP have been and are consistently the fastest CDNs in Europe, we shouldn't experience drawbacks

I attached screenshots of the mobile and desktop review of Google Page Speed. You can try by yourself: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.ricompro.it%2F&tab=mobile

Fabian

[fthobe]

@karen-white Can we maybe try to update staging to a new version to see if everything works and afterwards production to see if something changes?

[karen-white]

@fthobe Thanks for following up with those notes! The staging store was on the latest version of the storefront service previously, so they are now both currently on the latest. We'll dig into this more today and let you know what we find.

[fthobe]

@karen-white Hey, I already ruled out the DNS, I thought first that was the issue. But if you get a 100, that can't be the issue.

[fthobe]

@karen-white Hi Karen, we are seeing outages, are you changing something?

[karen-white]

@fthobe We do currently have an incident in progress--apologies for the interruption on your store. We'll be posting updates on the status page: https://status.bigcommerce.com/

[fthobe]

Hi @karen-white , please find attached the page load statistics of google analytics+ As you can see page loads are continously deteriorating (keep in mind that yesterdays seconds can be caused by the network problems). As you can see we deployed thursday morning and the numbers remained stabled throughout the day. From friday on we keep seeing ups and downs from what was before ranging between 2.8 and 3.3 seconds (4 seconds is absolute die hard limit you should reach with your website, beyond that you can see dramatically increased bounce rates). We are now continously seeing >5s loading time.

[fthobe]

@karen-white do you see a possibility to increase the page speed sampling rate for google analytics to 100% on our instance?

[karen-white]

Hi @fthobe , we're still looking into this with our ops team. It would be good to see the numbers you're reporting for server response time, since page load includes other factors as well. Could you send me an email at karen.white@bigcommerce.com and we can dig into it more deeply?

[fthobe]

@karen-white pinged you via mail

[karen-white]

Hi @fthobe - Wanted to give you a quick update and let you know that the engineering team is still continuing to look into this. I'm going to go ahead and close out this issue, since the root cause is not based in the theme, but we can continue the conversation either through support or email if there are any questions while the ticket is being investigated.