Performance-wise: request JSON and render in JS, or request the entire HTML?

Question

IF I send an AJAX request to a PHP file, what would result in faster rendering of HTML:

1. Sending the completely formatted HTML straight from PHP, or:
2. Just send JSON data and let Javascript do the HTML rendering?

I have a rather complex HTML structure, and this puts download time of a large HTML chunk vs. the times Javascript (jQuery) needs to render the same structure.

Is there even a conclusive answer?

Answer 1

I would say #2 - this way it puts less strain on your server and allows the client browser to do the work. This is much faster as well, because it's transferring less data.

Answer 2

You need to measure, on fast and slow computers. The JavaScript could take longer to render than PHP + transfer time, but it depends on the speed of the client (and the speed of the connection, and the speed PHP takes to produce the HTML).

Answer 3

Probably no conclusive answer. But consider that although from a request perspective AJAX returning JSON is lighter than requesting the whole page with PHP. Processing the JSON request and updating the page components has a higher management burden.

Have you considered a hybrid? AJAX requests where PHP returns small chunks of HTML.

Answer 4

You're going to need to measure the times for your situation, because the answer will depend upon:

Server-rendered HTML:

1. The amount of time necessary on the server to format the data as HTML, under low and high loads.
2. The amount of time necessary to move formatted HTML to the client, under low and high loads.
3. The amount of time necessary to redraw your page with the formatted HTML on the client, for slow and fast clients and browsers.

Client-rendered HTML:

1. The amount of time necessary on the server to format the data as JSON, under low and high loads.
2. The amount of time necessary to move the JSON data to the client, under low and high loads.
3. The amount of time necessary on the client to render HTML from the JSON data, for slow and fast clients and browsers.

This is a case where an hour in the lab running tests before coding could save you from having to redo everything later.

[Added]

Each set of measurements (1, 2, 3) is going to require a different set of tools to capture the data. I would pick 3 sets of representative data (smallest, average, largest) and then for each dataset, make each of the measurements listed above. Note that you don't need to (and in fact shouldn't) use your full application -- you really just want the smallest chunk of code that will do what you want. Then I'd look for the variations between server-rendered and client-rendered, and decide which (if any) was more important in my application.

You're NOT going to be able to measure every possible combination, but if you choose the slowest browser on the slowest PC you can lay your hands on (eg: a cheap netbook), and use the slowest possible internet connection (you've still got an AOL dialup account for testing, right?) that will tend to show you the worst case, which is what you really care about.

Answer 5

JSON is the way to go. Network can be huge bottleneck while javascript is fast at handling things. The greatest difference will be on slow connections. And it definitely worth the parsing. New browsers offer native JSON, so it should be crazy fast.

One more thing to consider: innerHTML has a lot of bugs (tables, forms, etc.). In those cases you have do a lot of overhead in order to get it work cross-browser. Problems may arise unexpectedly, which makes your application less stable.

JSON, however, let you decide if you want to use innerHTML or DOM methods according to the content. This is another huge win.

Answer 6

First you need to compare the size in bytes of the JSON vs the HTML.

If the JSON is not a lot smaller, then just send the HTML. Using JavaScript's innerHTML to put the HTML chunk into the page is very fast. Building a DOM tree from some JSON will be slower.

Ultimately the difference in time for the user is likely to be negligible, unless the amount of JSON/HTML is truly enormous.

Answer 7

Depends on the type of site more than anything else imo.

• Do you need it to degrade gracefully?
• What browsers are your target audience likely to be using?
• What kind of connections might they have?
• How many hits will the site have?

It might, for example, be fair to assume that 'tech' site will be visited by people with faster computers using decent browsers with fast connections.

If you've got to support IE6 then i'd be wary of too much javascript, but its something that needs to be tested really.

I tend to render on the server generally, its just easier, but then again i make low load intranet sites generally!

Answer 8

This would really depend on what kind of data you are transmitting.. If you have some static HTML elements on the front end that you only need to fill in with values, JSON is the fastest and easiest solution. For this, there are many, many, many client-side JS libraries out there. If this is your requirement, know that with this approach, your HTML already exists, either in the page, or in the client's memory as a template (depending on how you script it)

As to the other option, I would suggest you only do that if you have some very.. "sophisticated" or really server-dependent HTML that only the server can generate... or if you are embedding HTML from someplace else that delivers HTML.

Speed of generating a response is totally dependent on your server, and the way it is programmed.. Since JSON is smaller, it is usually faster, and there are numerous JSON libraries for all flavors of back-end programming..

I think you should look into some of the more UI-centric JS frameworks out there

Answer 9

This was mentioned by Nicholas Zakas of Yahoo in his artical/talk at Velocity 2010,

it sounds like you're into javascript performance so it's well worth checking out the slides/pdfs.

includes stuff by Steve Sounders and a load of people i've never heard of:

http://en.oreilly.com/velocity2010

edit: if i rememer correctly the conclusion was html is usually better due to IEs slow json parsing (i think!)

Answer 10

Bear in mind that to the user, what actually matters is not the total time but what it looks like to them.

• Situation A) User presses a button, nothing happens for 2 secs, then data loads.
• Situation B) User presses a button, it says "please wait" or something, then data loads 3 seconds later.

To most users situation A will actually seem slower.

So whatever you do, really try to get progressive rendering working for you so the user sees something happening ASAP.