Is there a limitation for installing no of Extensions...

[coolclassic]

I am new to Adobe Launch, there are many requests coming from marketing team for which i have to add multiple tags in, my question is, whether I have to be conservative adding these tags in our application? Ultimately adding more and more tags will definitely impact the homepage performance.

Are there any best practices or strategy i have to consider before i start adding all these pixels/tags in my application? 

[yuhuisg]

Probably not. But @thebenrobb would know better.

[coolclassic]

thank you @yuhuisg for your response. @thebenrobb appreciate if you can provide your inputs..

[thebenrobb]

We haven't provided any best practices because it's different for each customer. You are correct that anything you add to your property can potentially increase library size and thus have a negative impact on performance and user experience. This is generally true for anything you add to your page, but a Tag Manager certainly makes it easier to add a lot of stuff quickly. Ultimately, the best advice I have is to be methodical about it. Establish your performance criteria around load times and library size. Then when you add new tags, be sure to evaluate the new library against your criteria.

[Alexis_Cazes_]

1. All marketing tags either it be gtag, Pinterest, Twitter etc... has a core code and custom part of code where you would set your custom values. You should analyze each tag and see what is core and what is custom. In most cases the customer part only requires few details to be provided so I would replace the code there to get value from data elements using _satellite.getVar('Data Element'). You can use extension like Mapping table or use custom code inside your data element to set correct values based on lets say brand. One rule should be used per marketing pixel or product. If you are using more than one, compare the code and see what changes, most likely that can be refactored to use solution explained previously.
2. Never trust public extensions. Install them in a test web property, build it and review the code. Some use eval which are a performance and security risks. In most cases you can simply use custom javascript code in a rule to do the same and more efficiently, see #1
3. Last for the road and that is the must, create your own private extension to deploy the marketing pixels that you need.

[salimj · Accepted solution]

Great advice from @Alexis_Cazes_ and @thebenrobb ! To add to that:

1.) Create your own set of best practices, taking inputs from your site developers and QA folks to determine how reliable and performant a particular piece of code can be. Typically sites which have had marketing capabilities before the implementation of a tag manager, would need those implemented by a developer directly on the site code (then typically tested before releasing) - so your colleagues can be a great allies here.

2.) Pixel code has tons of potentially needless fallbacks. HTML injections, 1x1 image requests, <noscript> tags,etc - and often they're all provided to the marketing team verbatim with some comments in the code stating "Do not edit anything below this line". Evaluate these with your developers and determine what is required. Pixels typically just send a few parameters over to the individual vendor, so they don't need to be over-engineered. 

3.) Build an inventory of all your tags/rules. The requests for new tags/pixels are usually plentiful and have urgent deadlines - removal of these items may not have the same level of attention. Regular inventory and audit can help you keep your tag manager clean and tidy. Note: if there's a rule for a specific tag/pixel which expires 30 days from now, you could even put those into the rule name - might be easier to find later.

4.) Leverage custom code only if required. Many times the Launch UI will have some functions you can use which compile into performant, optimized code. Most of the time this is better than using a 5X nested IF statement. It also becomes an easier task to maintain for other members of your team that may not be too code-savvy. If you do have some custom code to implement, you could have a developer on your team review your proposed code (Internally, I like to refer to this as the Developer thrashing session) - but it typically also results in better code in the end which will jive better with your site.

5.) Document things. I'll be honest - I kind of miss the notes field from DTM to summarize changes, but that doesn't prevent you from adding notes in custom code, keeping notes in some ticket tracking tool just so when you revisit things 6 months later you know why you put in a particular change.