My understanding is that a document.write after onload will replace the body so why does setTimeout(DoSCWork, 5000) work when the following replaces the body?

function helloWorld() {
document.write(“hello world!”);
}

setTimeout(helloWorld, 5000);

@VaBeachKevin: where’s the “here’s how I currently do it” post?

and then in the s_code.js file have
if (window.sProp1) s.prop1=sProp1;

Modern web site performance best practices tell you to delay the loading of JavaScript to the end of the page. This is for code that is not required toward the top of the page. I am not sure if you know this or not, but JavaScript loading causes a blocking effect. By telling people to move something to the top, the browser will now need to process the download of the file and processing of the JavaScript blocks before it can continue to the next tag of HTML. Considering that the s_code is a terribly written piece of code, it’s a very costly change. Having it at the top will cause some sites to appear with a white background, while their are loading this support file, instead of continuing to load important files like CSS, other JS library files.

Here is what I have done when creating sites that use SiteCatalyst bloated code.

1. Add all of the code mentioned below to the very bottom of the page, right before the closing body tag. This will assure that you’re content loads first, the user is able to interact with your page before SiteCatalyst takes it over.

2. You can remove the noscript tag, but other than the 187 bytes the removal saves, it doesn’t hurt anything to leave it there. It ONLY processes when you have JavaScript is disabled. So this change doesn’t matter, it could actually break your support if you remove it since they told you not to.

3. Other than the properties, this is the meat of the code… the most costly one too: var s_code=s.t();if(s_code)document.write(s_code)

I have found a way to make sure that the processing of this code is not blocking anything else, like the onload event from triggering. So what I did is I wrapped that code in a function like this:

function DoSCWork()
{
var s_code=s.t();if(s_code)document.write(s_code)
}

I also added this line after the function:

setTimeout(DoSCWork, 50);

What this does is it delays the execution for 50 milliseconds. The delay doesn’t matter as much as what the side effect is. By calling it through set timeout, it will execute that code a-sync. This way the rest of the page can continue while the SC code executes in the background.

This also removes the dependency on omniture’s terrible code and unreliable DNS, since it doesn’t resolve quickly all the time.

———-

These suggestions should help anyone that has a high traffic site and should minimize the hit of dealing with omniture so you are not held hostage since they refuse to fix their problems.

I am having more advanced issues where I can’t do anything about it. The way that S_Code.js is setup, the browser has to take even longer to interpret their code strings to executable code. Their use of the “new Function” class slows down processing even more. Sometimes it hangs the browser if you have pages with large amount of content. I have a situation where I HAVE TO DISPLAY 1000+ table rows of results. The results render ultra fast, but the fact that SC is doing a document write of s.t() is really messing up performance for me. In my example it’s harder to deal with, because I can’t change their minified JS.

If anyone has any suggestions to encapsulating the execution of s_code.js, please let me know.

What are the repercussions of placing the SiteCatalyst code in the [head]. I left that as an HTML tag that the comment code on this site is cleaning up. Sorry for the confusion.

However, I can 100% absolutely tell you that they discourage this practice. I have spoken directly with principal members of their engineering team, and I have a quote for you from the SiteCatalyst knowledge base.

This question was answered on Sep 18, 2008, and the question was “What are the repercussions of placing the SiteCatalyst code in the tag?”

If the SiteCatalyst code is placed in the tag, several features will be impacted. Certain aspects of SiteCatalyst tracking rely on the existence of the body object, which is not created until the tag is reached. Specifically, Custom Link Tracking, file downloads, exit links, and ClickMap tracking require the document body and will not work correctly if SiteCatalyst code is placed outside of the tags. Additionally, SiteCatalyst code relies on having a valid document and body for many of the other things it tracks (home page, connection type, browser height, browser width, etc. ). For this reason, Omniture recommends that you place the SiteCatalyst code as high on the page as possible within the body tags. SiteCatalyst JavaScript code should never be placed in the of the document.

Now, you may say that this simply is referring to the .t() function call which triggers the page view. However, I can tell you that I have tested implementations myself with the .js file reference in the [head] and the .t() call in the body, and the impacts are real. You can refuse to believe this if you wish, but this has been vetted and tested over and over.

Specifically, IE 6.0, 7.0 & 8.0 will not populate the connection type and homepage flags if the .js reference is in the [head], no matter where you put the .t() call to trigger the page view.

There may be other impacts for which I have not specifically tested, but to say there is no impact created by placing the .js reference in the [head] is misleading your readers.

Outside of that, I totally agree with your other points in this article, and thank you for the opportunity to express my opinion on your site.