PostMessage performance analysis
What is a postMessage?
window.postMessage is the de facto mechanism for enabling cross-origin communication at the browser level. In other words, it allows you to send a message (in the form of a string) from one document instance to another in a secure way. It exposes an API to send bi-directional messages between two windows, making this feature ideal for mash-up implementations where you can have two completely isolated documents (running on different domains) and still have a way to keep them in sync. All you need is a reference to the receiver window to post a message to it, e.g.:
receiverWindow.postMessage(message, targetOrigin);
Since the purpose of this post is to do a performance analysis, I will leave the basic introduction at that. Mozilla has an extensive description of postMessage [1], and since all major browsers already implement this feature using the same API, this should be enough to move on to the main topic.
What is a round trip postMessage and how does it work?
We can have a regular page that includes an iframe from a different domain, and we want to notify the iframe whenever a user interacts with the page so the iframe can execute some code and callback with the result of the operation. We are assuming the iframe doesn’t have any UI, but that’s not a requirement, we can do it backwards as well, where the user interacts with the iframe UI, and it has to notify the parent window about the interaction, and wait for some command. Both scenarios are valid, and perfectly doable with postMessage.
In the context of this analysis, we define a roundtrip message as a message that is sent from a parent document to a child document, and a response to that message sent from the child document to the parent document. Both documents belong to different domains and all messages are delivered via postMessage. The whole workflow works in an asynchronous way.
Why Y.CL?
Y.CL is a sugar layer on top of postMessage to facilitate the use of YUI Custom Events to wrap the low level implementation. On top of that, it facilitates the hand-shaking process between two windows to avoid any race conditions and queues messages until both sides are ready to receive them. We will be talking more about Y.CL very soon.
What are we testing here?
The purpose of the test [2] is to understand how fast browsers can deliver a message via postMessage, in a roundtrip fashion, and see how this technique is suitable for a NRT (near-realtime) implementation. The test is an echo-like roundtrip implementation where the parent document messages the child document with the string “marco” and the child document responds with the string “polo”.
Results
These are the results [3], specifically, the number of roundtrip messages that we can send per second:
Note: Although postMessage is faster than Y.CL, the difference is not significant. Considering the overhead of using YUI Custom Events and JSON.stringify(), it delivers a consistent and adequate abstraction for this functionality. Again, we will be talking more in details about Y.CL in the upcoming days.
Conclusions
window.postMessage is a mature feature, supported on all major browsers, including mobile browsers. It works pretty fast, and it is getting faster with every release. You should be able to send hundred of messages per second, and that should be good enough for the majority of the cases, including near-realtime applications.
In my opinion, it is better to isolate and maintain a consistent API through postMessage between two independent logical pieces in a complex application than trying to couple the two pieces into the same context. And postMessage could be really useful for creating mash-ups and decoupled web applications.
References
1. Mozilla Developer Network – window.postMessage API Doc