Making JSONP Calls from HTML5 Web Workers

HTML5 LogoThe importScripts() function can be used to load any JavaScript file asynchronously from within a Web Worker, making JSONP a snap.

I just put the finishing touches on a photo gallery for a fairly large commercial web site. This template involved two dependencies: mustache.js and a jQuery carousel plugin, as well as three JSONP calls. All of this has to happen before anything can be displayed in the browser. Fun stuff.

I’ve spent plenty of time pressing F5 over and over to see how many milliseconds I could shave off the page load time. Since there is a bit of data crunching that also has to happen once all dependencies and JSONP calls have loaded, I started to think that this project would be a perfect candidate for some Web Worker love (of course with a safety net for older browsers). After some A/B testing, I could see that there was no real savings when implementing Web Workers. This is because the average 3-second load time was mostly due to the multiple asynchronous calls, not the data crunching. Since asynchronous calls are asynchronous, they don’t lock-up the browser, and it is only their latency that “keeps us waiting.”

That said, in the process of setting up my A/B testing, I had fun messing with Web Workers, and picked up a few new tricks, so I thought I’d post an article about making JSONP calls from a Web Worker.

If you’re not too familiar with HTML5 Web Workers, you might want to read these three posts; they offer an overview and a quick dive in to the topic:

Getting Started with HTML5 Web Workers – Part I
Getting Started with HTML5 Web Workers – Part II
Getting Started with HTML5 Web Workers – Part III

Before diving into the Web Worker code, I’ll just mention that the JSONP call we make responds pretty quickly, almost too quickly. As a result, it’s tough to demo our Web Worker, because there is no sense of “wait” (I spent over an hour making a pretty “loading” experience that merely flickers for a nanosecond because the JSONP call returns so quickly : – ). So I’ve implemented a “sleep” feature: we add &sleep=NUMBER to the query string. This way, we can make the JSONP call perform a little slowly, which helps to demonstrate our topic. Here is the PHP code that is added to the top of the JSONP file:

Ok, a little JSONP / Web Worker Action Please!

Example # 1

In Example # 1, we have the code for our Web Worker. First, there is the JSONP callback. In this callback, we fire off a message to the script that started the worker, and pass it the JSON data. Note that we need to use JSON.stringify() to convert that JSON data to a string. This is because we can only pass strings as messages to and from a Web Worker. But if we “stringify” a JSON object, that will do just fine.

Next we have set up an event listener. When the calling script sends a message to this Worker, the code inside of the event listener is executed. We create a random integer which is used to tell the JSON page to “sleep” for a few seconds, imitating a slow response. The other random # is used as a cache buster.

After that, we simply make the JSONP call. The importScripts() is oh-so-lovely and makes it super easy to import any JavaScript file.

Example # 2

In Example # 2, we have a simplified version of the click handler for the “Make JSONP Call” button. It simply sends a message to the Worker, which “starts” it.

Example # 3

In Example # 3, we instantiate the Worker() constructor, and then set up the event listener for that Worker. The code inside of this event listener will be executed when the Worker sends this script a message. I won’t drive you nuts by going through it line-by-line, but on a high level, we take the JSON data that the Worker sends us, and use JSON.parse() to turn it back into an object. Then, leveraging Mustache.js, we create an unordered list, using the JSON data that the Worker fetched for us.

Here is a link to the full working example for this article. Make sure you click the “Make JSONP Call” button:


Again, the very act of making an asynchronous script call is not so strenuous for the browser. But I can imagine a case in which you need to fetch some JSON and then crunch the return data before passing it to the calling script. In such a case, the “crunching” is what could bog down the browser. And since data you pass to a Web Worker is essentially “copied,” your script could wind up using more memory than necessary, by getting the JSON data, passing a copy of it to the Web Worker, and then getting a copy back from the Worker once it has finished doing some work on the data. That is three copies of the same chunk of data!

By initiating your JSONP call from the Web Worker, you get the data, crunch the data, and then pass the data to the calling script. This removes one “copy” from the whole scenario. And, I’m thinking that after sending the data from the Worker to the calling script, you could probably delete the data inside of the Worker, freeing-memory. Although it will probably get cleaned up by garbage collection. More fun stuff to investigate.

Happy Web Worker-ing!


Helpful Links for Web Workers