Please fill out as many of the following questions as possible so we can help you promptly! If you don’t know how to answer or it does not apply, feel free to remove it or leave it blank.
Builder content link
Builder public api key
dc5c96804c6c4a068e9558f30660aaee
Code stack you are integrating Builder with
NextJS
This problematic symbol uses an API to fetch its content. It seems that the qwik API returns the default values for the three elements in the symbol. In the html inside the qwik api response, you can see 21 times the text “This is my title”, which is the fallback value for the title underneath every image.
Please let me know if you need more details about the issue.
Thanks,
Vincent
Sorry about the regression. Let me look into it and get back to you. I will be sure to add an automated test for this so that it will not happen again!
Thanks for getting back to me.
I’m a bit confused by how the QA environment is different from prod as on QA the /qwik endpoint returns html, while on prod it returns a JSON object with the html in the html field.
That difference aside, looking at the html returned by the qwik endpoint, all looks good now on QA!
Just pushed the fix to production. Usually, it takes about 20 mins for the deploy to go through and for the caches to clear.
Glad to hear that you are using it in production! Could I ask for a set of URLs (Both external as well as builder.io URLs) that you are using in production? I will add those to our automated tests so that we don’t break you accidentally again.
The menu system is owned by Next.js. This downloadss and executes a lot of code on the startup. About 1.1 seconds on my top-end mac or 7 seconds on a mobile phone. Getting rid of that would greatly improve the performance. The easiest thing would be to turn the menu into Builder.io symbol and serve it as a Qwik. Then assemble everything on the client without next.js. But I don’t know your setup so I am not sure what the best way to do this is.
I also notice that you have GoogleTag Manager. This also negatively impacts startup performance. I would suggest moving that into partytown.builder.io for a faster startup. Similarly, I see that you have some Shopify scripts as well. I am not sure if those are partytown compatible (they should) but moving those over would help as well.
Hi @Misko ,
Thanks for getting back to me, your comment about putting the code in production made me realise I accidentally deployed in production my code using the Builder QA endpoint. That has now been fixed.
Thanks as well for both suggestions, I appreciate your feedback.
Regarding the use of Next.js, the framework I’m using is react-storefront which is used to power mainly the shop part of the website (see for example https://www.sachini.co.uk/s/bags). Definitely a good suggestion to try to optimise the bundle size.
Partytown is next on my list.
Which scripts do you think are used by Shopify, because I don’t use that platform at all.
Links to use for your integration tests
https://staging.sachini.co.uk (staging is probably better as production has a CDN long cache period so you wouldn’t notice a breaking change and later trace it back to a roll out.
