Expand my Community achievements bar.

SOLVED

Render blocking issue for Adobe scripts

Avatar

Level 2

We are facing some performance issues after implementing adobe analytics code in our site.

Google page insight is showing render blocking for the adobe script and leverage browser caching suggestion too.

Any suggestions to solve this?

--

Haripriya S

Mathrubhumi Printing & Publishing Pvt Limited.

1 Accepted Solution

Avatar

Correct answer by
Level 9

The notices are coming from the DTM library, not from Adobe Analytics.

To function properly, the DTM Header script must be placed directly on the page as a script tag, and must not have deferred or async attributes added to it.  If you follow their recommendation to add those attributes, or otherwise dynamically append the Header script to the DOM, you will break DTM and Adobe will not support your implementation. DTM does not have an async implementation of its library, and that's all there is to it. Live with it or move to a tag manager that can be deployed asyncronously (e.g. Adobe's new tag manager Launch)

Further, some of those notices are likely coming from how you have deployed certain tools or tags within DTM.  In a page load rule, if you select for it to trigger at Top of Page or Bottom of Page, then DTM will output code related to tools (e.g. Adobe Analytics) syncronously, and also any 3rd party tags specified as Sequential Javascript or Sequential HTML will also be output syncronously.  Depending on your implementation needs vs. limitations of whatever tags/code you have in a given rule, you can change this aspect of your implementation, by switching to Trigger at DOM Read or Window Load, and changing 3rd party tags to Non-sequential.

Overall, one thing I will note is that tools like this Google page insight or similar, that try and evaluate your site and make suggestions to improve performance, should not be 100% relied upon for making decisions.  In a perfect world, everything would be loaded asyncronously at the bottom of the page.  In practice, this simply isn't feasible to do many times.  You have a website that may contain hundreds, thousands of moving parts. Many of those parts depend on each other in many different ways. Load / execution order is a very important issue for those parts and you don't have a lot of options for controlling that order, especially when you are working with different tools/scripts from different vendors hosted in different places.

This becomes even more critical when you start dealing with UX stuff, like AB/MV testing.  Showing a visitor a designated experience is critical to protect the integrity of AB/MV tests, but this technology is fundamentally at odds with async philosophy.  BEST case scenario is UX takes a blow with "flickering" while alternate AB/MV content is loaded async, and that's not good at all.  That is not to say that these challenges cannot be overcome.  I have clients who opt to do things like show a loading splash screen with clever sprites. It's not ideal but it's better than having the user stare at a page that looks like it's having trouble loading.  But even then, there is only so much you can do with all this. Especially when it comes to integrating 3rd party tools with each other. Many tools out there simply don't have stuff baked in like load callback functions to chain things together, etc.

Site performance / optimization tools are useful as a benchmark / guide, but don't let them become the full/final authority for how your site is structured or how things are deployed on it.  It is "an" ideal to strive for, but in practice, a vast number of tags, scripts, libraries, etc. (not just analytics/marketing related) simply aren't there yet, and some of them are useful tools for your organization but fundamentally go against that ideal (which isn't a bad thing - it's just a different train of thought/approach).

But I guess the TL;DR here is if you really are striving to get rid of all those notices and get a 100% mark from your performance tool, then you are going to have to move away from DTM and use something else like Launch, GTM, or Tealium, which can be deployed asyncronously. In general, you will limit yourself to what you can actually deploy through them, though. But I don't know how this actually affects you in practice, as I don't know what all you currently have deployed in DTM.

View solution in original post

8 Replies

Avatar

Community Advisor

Hi,

Please provide more details.

  • Library version that you are using:
    • Analytics or For Another Adobe Marketing Cloud products ?
    • If Analytics is it H code or AppMeasurement.js ?
    • Which version of the library are you using ?
  • Can you provide the exact error that you are seeing.
  • Can you provide steps where we can see the issue or reproduce it ?

Best regards.

Alexis Cazes

Avatar

Level 2

Is your Adobe Analytics implementation deployed through through Adobe Dynamic Tag Manager (DTM) ?

Avatar

Level 2

Hi,

Here are the details as in-line comments  :

  • Library version that you are using:
    • Analytics or For Another Adobe Marketing Cloud products ?

               >>  Analytics

    • If Analytics is it H code or AppMeasurement.js ?

               >>  Not sure about this.

    • Which version of the library are you using ?

                >>  Adobe Visitor API for JavaScript version: 2.5.0

  • Can you provide the exact error that you are seeing.

      >> Please see below:

When checking our site performance via google page insight, we are getting the following suggestion:

Eliminate render-blocking JavaScript and CSS in above-the-fold content

Your page has 2 blocking script resources. This causes a delay in rendering your page.

Approximately 38% of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.

Remove render-blocking JavaScript:
  • Can you provide steps where we can see the issue or reproduce it ?

Best regards,

Haripriya S

Avatar

Correct answer by
Level 9

The notices are coming from the DTM library, not from Adobe Analytics.

To function properly, the DTM Header script must be placed directly on the page as a script tag, and must not have deferred or async attributes added to it.  If you follow their recommendation to add those attributes, or otherwise dynamically append the Header script to the DOM, you will break DTM and Adobe will not support your implementation. DTM does not have an async implementation of its library, and that's all there is to it. Live with it or move to a tag manager that can be deployed asyncronously (e.g. Adobe's new tag manager Launch)

Further, some of those notices are likely coming from how you have deployed certain tools or tags within DTM.  In a page load rule, if you select for it to trigger at Top of Page or Bottom of Page, then DTM will output code related to tools (e.g. Adobe Analytics) syncronously, and also any 3rd party tags specified as Sequential Javascript or Sequential HTML will also be output syncronously.  Depending on your implementation needs vs. limitations of whatever tags/code you have in a given rule, you can change this aspect of your implementation, by switching to Trigger at DOM Read or Window Load, and changing 3rd party tags to Non-sequential.

Overall, one thing I will note is that tools like this Google page insight or similar, that try and evaluate your site and make suggestions to improve performance, should not be 100% relied upon for making decisions.  In a perfect world, everything would be loaded asyncronously at the bottom of the page.  In practice, this simply isn't feasible to do many times.  You have a website that may contain hundreds, thousands of moving parts. Many of those parts depend on each other in many different ways. Load / execution order is a very important issue for those parts and you don't have a lot of options for controlling that order, especially when you are working with different tools/scripts from different vendors hosted in different places.

This becomes even more critical when you start dealing with UX stuff, like AB/MV testing.  Showing a visitor a designated experience is critical to protect the integrity of AB/MV tests, but this technology is fundamentally at odds with async philosophy.  BEST case scenario is UX takes a blow with "flickering" while alternate AB/MV content is loaded async, and that's not good at all.  That is not to say that these challenges cannot be overcome.  I have clients who opt to do things like show a loading splash screen with clever sprites. It's not ideal but it's better than having the user stare at a page that looks like it's having trouble loading.  But even then, there is only so much you can do with all this. Especially when it comes to integrating 3rd party tools with each other. Many tools out there simply don't have stuff baked in like load callback functions to chain things together, etc.

Site performance / optimization tools are useful as a benchmark / guide, but don't let them become the full/final authority for how your site is structured or how things are deployed on it.  It is "an" ideal to strive for, but in practice, a vast number of tags, scripts, libraries, etc. (not just analytics/marketing related) simply aren't there yet, and some of them are useful tools for your organization but fundamentally go against that ideal (which isn't a bad thing - it's just a different train of thought/approach).

But I guess the TL;DR here is if you really are striving to get rid of all those notices and get a 100% mark from your performance tool, then you are going to have to move away from DTM and use something else like Launch, GTM, or Tealium, which can be deployed asyncronously. In general, you will limit yourself to what you can actually deploy through them, though. But I don't know how this actually affects you in practice, as I don't know what all you currently have deployed in DTM.

Avatar

Level 2

Ok, then is it possible to place the analytics script somewhere in footer area ?

Avatar

Level 9

The official answer to that is Adobe states in the documentation the Header Code must be placed within the <head> tag, and doing it any other way is not supported.

Embed Code and Hosting Options

Header and Footer Code