who’s faster, json or jsonp?

You may have read Jonathan’s post about our TV Listings widget (powered by Atlas, obviously) going live. It was a great day to see months and months of work majestically strolling into the wild, but no sooner had the beast been released we realised it could be faster.

It’s worth noting at this point in the story, we’re loading* a single channel using JSONP in ~107ms. I won’t go in to details as to why we use JSONP, but in short the Listings Widget is a bit of JavaScript loaded onto a page that isn’t hosted at http://atlas.metabroadcast.com. Cross Domain Access anyone?

* “loading” is the time between the browser fully receiving a 12 hour block of channel data and the point at which the programmes for that block are ready to be added to the DOM.

early speed improvements

Before we even considered changing to JSON, we thought we’d work on the data Atlas returned. We’re aware that for small specific front-end applications Atlas 3.0 isn’t the most lean of API’s (don’t worry though, this will all be changing in Atlas 4.0). Changing Atlas for this experiment wasn’t an option so Liam flexed his PHP prototyping muscles and created what is essentially a proxy called Lilliput.

Lilliput sits between the listings widget and Atlas, whittling the Atlas response down to the bare minimum required. Liam did some fantastic work, and this alone, through various iterations, reduced a 12 hour block of programmes for one channel down to ~75ms (1.4x faster).

So we’d boosted the speed quite considerably, but in the last few Lilliput iterations we were putting in more effort to only get improvements of 1ms each time, suggesting we were getting to the end of the ‘data is too big’ line of enquiry.

MOAR FAST

While analysing the page load, I noticed the tell tale flashing of JSONP <script> tags in the header. Knowing that we’re loading up to 355 channels and that manipulating the DOM with JavaScript is fairly expensive, I thought the adding and removing of <script> tags could possibly be wasting precious milliseconds.

JSON enters, and stares you in the eyes.

JSON, unlike JSONP, doesn’t throw anything into the DOM, however due to security issues, it doesn’t work across different domains. A bit of CORS (Cross-origin resource sharing) fu later and the listings widget, without Lilliput, is loading a channel in ~40ms, that’s almost 2.7x faster than the original! Not only do the numbers look good on paper, the speed is immediately noticeable to users, blocks seem to load before you’ve even got to them.

summarise that for me

Vanilla: 107ms (Baseline)

Lilliput: 75ms (1.4x faster than Vanilla)

JSON: 40ms (2.7x faster than Vanilla)

JSON + CORS = Listings Widget Beast Mode

For our use case the benefit of switching from JSONP to JSON is very obvious. Other benchmarks have discovered JSONP to be better for certain use cases, so always benchmark both methods for you application.

If you’ve found JSONP to be more performant, or you want to know more please get in touch!

blog comments powered by Disqus