I see that Marketo recommends adding the asynchronous Munchkin tracking code in the <head>, but will it still work if added to the footer? If so, what are the advantages and/or disadvantages of doing it that way?
Solved! Go to Solution.
What we think of as "loading Munchkin" is actually three different network requests: [1] the Munchkin bootstrapper, which chooses the current version and creates a little event queue for stuff that happens before [2] is done; [2] the actual Munchkin library; and [3] the request to the tracking server to log the initial pageview.
The async tracking code loads [1], [2], and [3] asynchronously, meaning those network requests do not inherently block other page assets from loading until they are done.
(Note the "sync" tracking code is a bit of a misnomer because it loads only [1] synchronously, [2] and [3] are still async.)
In the absence of any other assets, then, relocating the async tracking code to the end of the <body> would make no difference.
However, that's not the whole story. If you have other blocking assets at the top of your page, then all of those will stop the bootstrapper from even starting to load. So it's not that Munchkin is itself blocking, it's that it's being blocked by other assets. And even if you have a mixture of blocking and non-blocking assets above Munchkin, if you have enough assets in motion the browser will not open a new connection until has connections to give. I've seen plenty of sites that have 20-30 remote scripts loading, and the people who build the sites imagine that everything is loading at the same time, but when you check the waterfall you see the browser is making some of them wait. And like Josh says, the longer you wait, the greater the chance the person navs away before Munchkin's 3 parts are complete.
So, long story short, if Munchkin is important to you, put it in the <head>. Of course every other library is going to say, "If this is important, put it in the <head>" so you still have to make a judgment call about the priority given to internal styles, internal scripts, syndication widgets, analytics scripts, conversion scripts, etc. This kind of optimization is not an overnight thing. There are assets that may be mission-critical and worth waiting for, or assets that need to be downgraded from mission-critical to best-effort.
There are tons of info on the internet about this issue. it's not Marketo specific.
Head tag will load early and let you record the visit. On a basic level, this slows the page load, but gets the code loaded.
Footer lets the page load faster, but risks losing the tracking if someone presses Stop or bounces.
Unless Sanford Whiteman disagrees, most people do Head.
What we think of as "loading Munchkin" is actually three different network requests: [1] the Munchkin bootstrapper, which chooses the current version and creates a little event queue for stuff that happens before [2] is done; [2] the actual Munchkin library; and [3] the request to the tracking server to log the initial pageview.
The async tracking code loads [1], [2], and [3] asynchronously, meaning those network requests do not inherently block other page assets from loading until they are done.
(Note the "sync" tracking code is a bit of a misnomer because it loads only [1] synchronously, [2] and [3] are still async.)
In the absence of any other assets, then, relocating the async tracking code to the end of the <body> would make no difference.
However, that's not the whole story. If you have other blocking assets at the top of your page, then all of those will stop the bootstrapper from even starting to load. So it's not that Munchkin is itself blocking, it's that it's being blocked by other assets. And even if you have a mixture of blocking and non-blocking assets above Munchkin, if you have enough assets in motion the browser will not open a new connection until has connections to give. I've seen plenty of sites that have 20-30 remote scripts loading, and the people who build the sites imagine that everything is loading at the same time, but when you check the waterfall you see the browser is making some of them wait. And like Josh says, the longer you wait, the greater the chance the person navs away before Munchkin's 3 parts are complete.
So, long story short, if Munchkin is important to you, put it in the <head>. Of course every other library is going to say, "If this is important, put it in the <head>" so you still have to make a judgment call about the priority given to internal styles, internal scripts, syndication widgets, analytics scripts, conversion scripts, etc. This kind of optimization is not an overnight thing. There are assets that may be mission-critical and worth waiting for, or assets that need to be downgraded from mission-critical to best-effort.
Great information, thank you!