It is not possible as described, because such "waiting" is in the background.
When Munchkin completely fails, your page is unaffected, unless you're using the synchronous (more properly called the "part-synchronous") form of the embed code.
A partial Munchkin failure, for example loading the Munchkin library successfully but having the Munchkin logging endpoint be slow to respond, will affect the end-user experience.
If your Munchkin code script is at the top of your page, it will slow your site if it goes down. This is because the browser is attempting to load the script at no response, and it will continue to do that until it gives up before it fully loads the rest of your script. A good practice is to put your external tracking codes at the bottom of the page in the event that their service goes down.
When Marketo went down, it heavily slowed down our site performance, so we just removed the munchkin code. Yes, we use asynchronous.
The asynchronous code does not block on load. You are incorrect. Watch your Network tab.
I really don't care if "technically" I am. Yes, in asynchronous script is executed as soon as it's downloaded, without blocking the browser. But the fact is, our site performance was slowed down on all pages, so we removed it.
Why put "technically" in quotes when you're talking about a purely technical matter?
You should care about giving completely incorrect information, because again, people will repeat this later as if it's true ("I've heard...").
Loading a script asynchronously -- any script, not just Munchkin -- is non-blocking. That's the definition of asynchronous.
I did that just for you.
To my experience, it wasn't completely incorrect because the fact of the matter is, it slowed down our site. Things don't always work as expected. I don't see any harm in people removing and later reinstating their Munchkin code if it is slowing down their site for ANY reason during a Marketo outage.
I'm not arguing if asynchronous is suppose to affect your load time or not, because like i also repeated, yes it shouldn't.
I looked around a little more, and people say that async can still slow down your site if it doesn't load, especially if your page is script heavy:
Beware of "script async defer" blocking HTML "load" event · GitHub
"What might be surprising is that
<script async defer>
also blocks the raising ofload
event!In a web dev slang, you may hear a script with
async
flag to be called non-blocking, but they're not blocking only the construction of the DOM tree (i.e.DOMContentLoaded
event). But they're still blocking theload
event.Unfortunately we were doing just that: using
window.onload = ...
instead of listening toDOMContentLoaded
to boot our app. In normal circumstances, the difference was negligible, but today it his us hard.Actually, in our case, we were loading an external script via JS, using
script.async = true
, and that external script was in turn loading several others, also setting theasync
flag to each of them. However, no amount ofasync
can save you if you're waiting forload
event!"
I'm not a JS expert of any sorts, so I can't attest to whether these statements are completely true, but based on my experience I'm going to go with it. They do have some useful steps to add on that will further prevent blocking.
The operation of window.onload doesn't change the asynchronous contract. By choosing to use onload you're artificially creating a load order, just as you would be if you waited for a certain script.onload to fire before making the site ready to use.
Also note that the Window's load event is misnamed/misleading when you compare it to the load events fired by DOM elements like <img> and <script>. While those elements have both load and error events (and without both you aren't covering all the possible conditions), load on Window fires when the load or error state is reached for all assets. Ergo, if the remote <script> that loads Munchkin immediately fails due to a network outage, window.onload will fire without interruption.
They do have some useful steps to add on that will prevent blocking for good.
You can't prevent blocking Munchkin events (not library load, but the page event Click Link) via generic methods. You must turn off exit link tracking to do this.
Things don't always work as expected.
Async loading of the Munchkin library always works the same way, per the contract between all modern browsers and JavaScript authors. Complete failure of the lib to load asynchronously (due to complete outage at Marketo) will not, on its own, affect page rendering.
However, a network slowdown -- not complete outage -- at Marketo is a different story. In that case, if the library is ever able to complete loading, inter-page navigation will be heavily affected (if you haven't already disabled exit link tracking for performance reasons, a very good idea in its own right). It's far more likely that this was what you were experiencing.
I agree that there's no harm in disabling all impacted services during a Marketo outage. If you're not sure whether Munchkin is affected then you can disable it to be safe. But you should know why you're doing everything, including that you may be disabling a service that wasn't impacted and or amounted to a no-op (i.e disabling something that was implicitly disabled).