SOLVED

Safeguards for Marketo Outages

Go to solution
SanfordWhiteman
Level 10 - Community Moderator

Re: Safeguards for Marketo Outages

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.

Anonymous
Not applicable

Re: Safeguards for Marketo Outages

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.

SanfordWhiteman
Level 10 - Community Moderator

Re: Safeguards for Marketo Outages

The asynchronous code does not block on load. You are incorrect. Watch your Network tab.

Anonymous
Not applicable

Re: Safeguards for Marketo Outages

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.

SanfordWhiteman
Level 10 - Community Moderator

Re: Safeguards for Marketo Outages

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.

Anonymous
Not applicable

Re: Safeguards for Marketo Outages

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.

Anonymous
Not applicable

Re: Safeguards for Marketo Outages

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:

https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2016/september/how-loading-javascri...

Beware of "script async defer" blocking HTML "load" event · GitHub

"What might be surprising is that <script async defer> also blocks the raising of load 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 the load event.

Unfortunately we were doing just that: using window.onload = ... instead of listening to DOMContentLoaded 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 the async flag to each of them. However, no amount of asynccan save you if you're waiting for loadevent!"

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.

SanfordWhiteman
Level 10 - Community Moderator

Re: Safeguards for Marketo Outages

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.

SanfordWhiteman
Level 10 - Community Moderator

Re: Safeguards for Marketo Outages

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.

SanfordWhiteman
Level 10 - Community Moderator

Re: Safeguards for Marketo Outages

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).