The Channel Messaging API gives you a way to pass information asynchronously between different origins on the web, such as cross-origin iframes. Traditionally you would use window.postMessage(), but the a MessageChannel has the advantage of being clearer, only requiring validating origins on setup, and handling delegation better. Reading this 2016 post, however, I was worried that it might have enough overhead that postMessage made more sense in performance-sensitive contexts. Benchmark time!

I made a test page which alternates between loading trycontra.com/test/messageChannelResponse.html and trycontra.com/test/postMessageResponse.html. I'm using two different domains so that I can test cross-origin performance. First it loads messageChannelResponse in an iframe, waits for it to load, and then times how long it takes to pass in a MessagePort and receive a response on it. Then it does the same basic operation postMessageResponse with plain postMessage. This is a worst-case for MessageChannel, since I stand up the while channel only to use it a single time.

I ran 1,000 iterations, interleaved, on Chrome (80.0), Firefox (74.0), and Safari (13.1). All of these were on my 2017 MacBook Pro. Here are all the runs, sorted from fastest to slowest [1]:

In Chrome, MessageChannel is a bit faster, while in Firefox and especially Safari it's slower. Additionally, Firefox runs it faster than Safari, which runs it faster than Chrome. Safari also has more consistent performance than Chrome, with a flatter distribution. Firefox is in between, with a flat distribution for postMessage but a few slow calls in the tail for MessageChannel. If you're writing something where ~7ms/call in Safari is an issue then it might be worth sticking to postMessage, otherwise MessageChannel seems fine.

[1] I find this kind of "sideways CDF" a really useful visualization tool, and possibly the chart I make most often.