The code is in wp-e-commerce.js
Comment this out as an experiment. As you can see the code isn’t doing anything intensive, so if it is taking a long time to execute it is symptomatic of a larger issue.
///////////////////////////////////////////////////////////////////////////////////////////////
// Setting up the WPEC customer identifier
//
// When WPEC generates a page it sets a 'customer cookie' into the browser. This cookie is a
// persistent identifier that connects a user's session to their cart or other profile data a
// store may need to work correctly.
//
// When page caching or a CDN is in place WPEC does not get to set the cookie because
// the page is served without the overhead of computing the page contents.
// This means that the first GET/POST request, including requests using AJAX are required to
// initialize the customer identifier
//
// Because browsers may execute these requests in parallel the probability of multiple unique
// cookies being set is very high. This means that in the absence of the logic below WPEC would
// have to create multiple unique profiles as each of the parallel requests are executed. This
// can cause data when one request uses one profile and the other request uses a different profile.
// It could also cause performance issues on the back-end, and create a potentially resource
// intensive and wasteful situation.
//
// The mitigation for this issue is to look for the customer identifier when this script first
// runs. If the identifier is not found, initiate a very quick synchronous AJAX request. This
// happens before any other processing takes place. This request should create the unique
// customer identifier before it is required by other processing.
//
// a global variable used to hold the current users visitor id,
// if you are going to user it always check to be sure it is not false
var wpsc_visitor_id = false;
if ( ! ( document.cookie.indexOf("wpsc_customer_cookie") >= 0 ) ) {
if ( ! ( document.cookie.indexOf("wpsc_attempted_validate") >= 0 ) ) {
// create a cookie to signal that we have attempted validation. If we find the cookie is set
// we don't re-attempt validation. This means will only try to validate once and not slow down
// subsequent page views.
// The lack of expiration date means the cookie will be deleted when the browser
// is closed, so the next time the visitor attempts to access the site after closing the browser
// they will revalidate.
var now = new Date();
document.cookie = "wpsc_attempted_validate="+now;
var wpsc_http = new XMLHttpRequest();
// open setup and send the request in synchronous mode
wpsc_http.open( "POST", wpsc_ajax.ajaxurl + "?action=wpsc_validate_customer", false );
wpsc_http.setRequestHeader( "Content-type", "application/json; charset=utf-8" );
// Note that we cannot set a timeout on synchronous requests due to XMLHttpRequest limitations
wpsc_http.send();
// we did the request in synchronous mode so we don't need the on load or ready state change events to check the result
if (wpsc_http.status == 200) {
var result = JSON.parse( wpsc_http.responseText );
if ( result.valid && result.id ) {
wpsc_visitor_id = result.id;
}
}
}
}
// end of setting up the WPEC customer identifier
///////////////////////////////////////////////////////////////////////////////////////////////
Note, the logic above only causes a cookie to be set. If the shopper is going to do anything in the store the cookie will have to eventually get set, so you might as well investigate the cause of the initialization problem. It would be much worse for a shopper to click the add to cart button and then have to wait a couple of seconds for the action to complete.
