What is a
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.:
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 , 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
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.
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  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
These are the results , specifically, the number of roundtrip messages that we can send per second:
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.
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.
1. Mozilla Developer Network –
window.postMessage API Doc
postMessage test suite on jsperf.com
3. Browserscope result page