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)
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.
Analytics or For Another Adobe Marketing Cloud products ?
If Analytics is it H code or AppMeasurement.js ?
>> Not sure about this.
Which version of the library are you using ?
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:
Your page has 2 blocking script resources. This causes a delay in rendering your page.