No risk at all. So long as the call to the s_code.js file happens before the actual ‘money line’ of code you are fine. Now that ‘money line’ needs to be within the actual body section of the document, either right before the opening body tag
or right before the closing body tag . Since that call actually calls an image it can’t be outside of the body section. You can’t display images in the head section. I’m all for organization, that’s why I like to keep all references to any .js file all together, in the head of the page. Now placing the call to Omniture at the top of the code or the bottom of the code I could debate all day. If you place it at the top of the code, then there is the (unlikely) opportunity, for there to be an error that holds up the loading of the page resulting in a bad user experience. Placing the call at the bottom of the page if the visitor navigates away from the page before it fully loads, or there is any other error that prevents the SiteCatalyst code from firing off, than that page does not get counted. It can go either way. I prefer to have the js file as high in the page as possible, and the call to fire off the code as low as possible.Omniture discourages placing the reference to the remote .js file in the [HEAD] of the document because of the impacts to tracking. Specifically, ClickMap, homepage reporting and connection types are impacted by this. It’s also possible that exit link reporting will be impacted with some browsers.
There is no advantage gained by placing this reference in the [HEAD] against the best practices of Omniture. If you’re worried about performance, you can load the file using dynodes so the .js file does not block your content.
The call to the .js file can be placed anywhere. That is not what matters. As long as the line of code that fires off the call to SiteCatalyst is within the body tags, you will be fine. Take a look at what Omniture does on their own site. They call the js file in the head. In fact they have it bundled with a bunch of other JavaScript in one file.
I don’t think they would advise against it if they do it themselves for their own tracking.
Your correct that there is no advantage to doing it, I just like to keep all the js calls together in one place mainly for housekeeping purposes.
Perhaps Omniture doesn’t care about any of the impacted features for their own website. How many people are going to have http://www.omniture.com set as their homepage?
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.
Sorry, looks like I forgot to edit the question and answer that I copied from the SiteCatalyst knowledgebase. Where my previous comment says “What are the repercussions of placing the SiteCatalyst code in the tag”, that should read:
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.
I have implemented SiteCatalyst on over 90 sites and have never seen any issues with having the s_code file in the head, but that doesn’t mean there is something I have missed. I will absolutely review some of my implementations and see if there has been something I have overlooked. The only reason I said to move it it just for housekeeping reasons (I’m anal about my code) and I like to keep everything nice and neat. You make some real good points and I appreciate it. Thanks for your input.
Yes if you have the s.t() call outside your body tags it could effect any onclick tracking that you are doing. But placing the call to the s_code file, and only this call, outside the body tags should not effect any suctom link tracking (s.tl calls) that you are doing. But we ahve seen that by placing the s_code call outside the body tags it will effect other things, such as the Connection Types report. My suggestion is to place the s_code call somewhere between the opening and closing body tags to prevent any errors that may occur. We’d rather be safe than sorry. 
This blog entry is pretty misleading. All of the “performance enhancements” are pretty negligible. One of the recommendation actually makes the page even slower. The part I am referring to is where you recommend to more the s_code.js file to the top.
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.
Is it possible to set variables such as s.events on your page prior to loading the global JS file? Note I have s.t() in the global file so I thought it shouldn’t be an issue. However, my custom code isnt being picked up.
I couldn’t agree with you more! I actually have changed the way I personally do things myself and what I do is pretty different than what I have listed here. When I originally wrote this I took my personal experiences along with what Omniture did themselves on their own site and put together a few suggestions. If you look at this very own site, you will see what I am doing is pretty different. I guess my coding has evolved a bit 
Stay tuned for a “Here’s how I currently do it” post coming very soon. Thanks for your input!
No, you need to call the s_code.js file before you set any of the variables. This is one instance where you would want the s_code file to be called high up in the page. If you set a lot of variables right in the page you may want to do something like
sProp1=”Whatever”;
and then in the s_code.js file have
if (window.sProp1) s.prop1=sProp1;
@ThirdWishER: like the strategy of using setTimeout to delay the s.t() invocation (I’ve tested it successfully, even with a delay as large as 5000 ms); however, I’m not sure why this works as t() will invoke a document.write which you can confirm by overriding document.write = function(s) { alert(s); } and watching it alert the tag.
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?
Is there any risk to placing the call to the .js file in the head section rather than in the body with the page code? All implementation guides show this with the page code, and instruct us to place the code as high as possible on the page but within the body. Is their recommendation just for organizational purposes to keep all of the Omniture code in one place?