I've not had the opportunity to do a before/after test, but I know there is an admin setting to move the viewstate. Have you tried A/B tests on any BV5 sites?

Did the sites that were slowest to load have flash, java, animated GIFs, SKU and image swapping, etc?

I've been to plenty of BV5 sites offered as examples by the third parties and BVC and haven't noticed any unusual lag times, but I do have Fios.

in review my prior post, I can understand how there could be confusion, as I am addressing two topics at once, so let me clarify.


[quote="myself"]
This has me asking, why do we need all this viewstate? How do other carts handle this? I have looked at the page source as rendered by some other carts that are asp.net, and I see very small or short viewstates, or even no viewstate. What is going on with BVC5 that is different here?
I go to http://www.coach.com/content/CollectionListAll.aspx?categoryId=74 and I have almost no viewstate [192 bytes]. I go to a product page on the same site with multiple product options and image swapping by choice and I have < 5k of viewstate [4192 bytes]. I go to other ecommerce sites running asp.net applications and notice considerably smaller viewstates. None of these come close to 20k-50k+ I am seeing on the BVC pages. My questions are related to determining what the difference is between BVC and the rest of the asp.net cart packages.
The remainder following these questions brings to attention that the product price in the cart was higher than the product price on the product page. I am curious how often things like this are occuring and the impact they are having. I randomly selected a site whose owner posts on these fourms and went to one product on the site and noticed what I reported. I would expect that things like this would drive up the phone/email workload. I would like to hear from merchants regarding any customer feedback about issues like this.
Andy, maybe you are right that reducing the size of the pages viewstate may not be worth it for BVC in terms of work and testing. I am mostly curious why other sites running other asp.net carts do not seem to have such large viewstates.
Scott Mech

One thing you may find beneficial is running HTTP compression.

Example: http://www.80stees.com/products...More-Cowbell-T-shirt.asp
Viewing page info shows 19.11 KB (19,566 bytes)
When it is actually 125.239 KB

Check your pages here http://www.port80software.com/products/zipenable/

Trimming viewstate is important but this is another value tool.

Know of any guidelines of how this could be done within a theme (master pages), or is this more specific to the BVModules?

My .Net skills are limited, but if I know what to look for, I'd love to help limit the VS because I'm seeing the same issues.

Andy is right. Follow his guidelines. It will take time and pain but it will work.
The most relevant test is NOT to load the page but to postback to the page. So always have a button on the page that will do a post back.
The viewstate has no meaning when you first load the page but it's used when you postback to avoid executing some of the code. Handling of events only relies on VS for very few controls like grids and repeaters but it is not required for simple controls like buttons or checkboxes.
If you have controls that make sense to be readonly once the page was loaded check the .vb code and see what is in the Page_Load .. If Not Page.IsPostBack Then ...
Most of that code can be taken out of the If so it will be run on every page load. A good example you can start with is the Sticky Note Content Block. Remove the If Not Page.IsPostBack .. and set it to EnableViewState=false. You just saved your strings from the note beeing loaded from the VS but from the DB. Considering the code checks the DB anyway there is no negative performance hit.
Start with small changes to get the hang of it and remember. Tests if you broke anything are ONLY VALID in postbacks and not on first loads.
Regards,
Corneliu.