13

Possible Duplicate:
Why is it a bad practice to return generated HTML instead of JSON? Or is it?

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?

Community
  • 1
  • 1
yanayz
  • 163
  • 2
  • 8
  • See http://stackoverflow.com/questions/1775797/html-template-json-vs-server-html – Crescent Fresh Jul 04 '10 at 16:14
  • thanks, but not very conclusive answers there either. – yanayz Jul 04 '10 at 16:19
  • Recent experience has shown that new HTML elements are'nt fully supported with dropping html straight in. We had to go for a JSON rebuild solution instead – Duncan Jul 04 '10 at 16:24
  • that's an interesting point. I have a feeling JSON is the answer here, but will run some more tests first. – yanayz Jul 04 '10 at 16:33
  • @Duncan as duncan said, innerHTML has a lot of problems. See my updated answer. – gblazex Jul 04 '10 at 17:48
  • You need to define what you mean by performance. If your talking about the time spent waiting for the entire page to load then HTML will most likely be faster assuming your web server is compressing the data (assuming the server generates the required output at the same speed.) If you're talking about user experience then JSON will most likely be faster since you can load relevant data asynchronously. There are many other technical reasons to do one or the other. e.x. Not reloading the page will allow you to do state-full programming. – gradbot Jul 04 '10 at 21:49
  • My main concern is the user experience, and so after playing with it some more - JSON wins: users get instant feedback, and you can also progressively construct the final HTML, if heavy lifting involved. – yanayz Jul 06 '10 at 08:45

10 Answers10

2

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.

Craig Trader
  • 15,507
  • 6
  • 37
  • 55
  • Craig, I would be happy to run tests, but there are no absolutes here: browsers rendering speed differs, as well as network connection speed at different locations/times. Do you have an idea how to research this? – yanayz Jul 04 '10 at 16:03
  • Sounds like a plan. I'll give it a run and let you know. – yanayz Jul 04 '10 at 16:35
1

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.

gblazex
  • 49,155
  • 12
  • 98
  • 91
0

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.

xil3
  • 16,305
  • 8
  • 63
  • 97
0

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).

Skilldrick
  • 69,215
  • 34
  • 177
  • 229
0

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.

Jason McCreary
  • 71,546
  • 23
  • 135
  • 174
0

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.

Rafael
  • 559
  • 4
  • 12
0

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!

Paul Creasey
  • 28,321
  • 10
  • 54
  • 90
  • IE6 is dead (thank god), but other than that - potential visitors are all over the place. thanks. – yanayz Jul 04 '10 at 16:28
0

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

arunjitsingh
  • 2,644
  • 2
  • 22
  • 16
0

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!)

Haroldo
  • 36,607
  • 46
  • 127
  • 169
0

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.

James
  • 3,265
  • 4
  • 22
  • 28
  • ps. and no, there is no conclusive answer. It depends on so many factors. – James Jul 04 '10 at 22:39
  • of course, but the any AJAX solution allows us to show a "loading/wait" message and the question is what's the fastest way to replace the "Wait", with real content. – yanayz Jul 06 '10 at 08:35
  • Yes. AJAX definitely allows for a loading message but you have to weight that against heavier client side load and problems for readers with old computers/mobile users. But remember HTML has progressive rendering to - where you place certain elements can be very important for the speed a page actually starts to appear to the user. But mainly, It's just that ppl were answering lots of "well you count the bytes" type answers and I just wanted to point out that while a straight comparison is useful it's not the complete picture. – James Jul 08 '10 at 11:43
  • But can I just add, I strongly lean towards HTML because I tend to use older computers and the number of times I have problems with websites because the developer has done some fancy AJAX thing when HTML would have worked just as well is amazingly annoying. – James Jul 08 '10 at 12:11