I see that the tag killing is working for missing scripts directly linked to in Tealium. But we have found some hanging embedded scripts within those tags that hang. One yesterday... ib.adnxs.com, hung on our site for over 10 seconds, sometimes more. Is there anything that can be done about these?
Piggy backed tags like the ib.adnxs.com tag you mentioned are out of our control. We only control those that Tealium directly fires.
The best option to prevent this in the future is to use Tealium to manage all tags including those that are piggy backed. I understand it may involve more work to migrate tags but in the end it will provide greater site control, security, and up-time.
We recommend only running "Asynchronous" scripts on your website. By default all tags are set to "Wait" when added in Tealium. That means we are prioritizing your page render before loading in additional tags.
From what I can tell, the AppNexus is not a "blocking" tag but a simple image pixel. Are you running a custom version of their pixel? Can you provide more details on how your site was "hung"?
Hi Danielle, you are correct that the file is not linked from the Tealium template. These piggyback tags reside within the tags we call - e.g. we can a tag and that tag returns a script that calls several other tags including Adroll. There are two ways to find these calls:
1)A vendor should have a UI available where you can see these types of configurations. There may even be a script section where you can see the extra JS calls. I'm not too familiar with the UI of these vendors so I can only speak theoretically but somewhere in their UI the scripts will reside. This is probably the easier method.
2) You can use Chrome's Developer Tools to view the Network log and use the Initiator column to see who is making the call. You'll have to reverse engineer the log because there could be several redirects. For example, if the page URL calls utag.js which calls utag.#.js which calls DoubleClick which calls AdRoll, you would start with DoubleClick and work backwards finding the Initiator and documenting the findings.
Neither are exactly great as it's a pretty manual process, but there isn't much more to help determine from where all the extra calls are coming.
Hopefully this helps point you in the right direction.