Which loads faster for you? PHP or Javascript?

Permalink
Hi!

I recently created an alternate version of my WordPress for Concrete5 add-on. The original runs in PHP, and the alternate relies much more on Javascript. It is hard to tell which is better all around.

Would anyone mind giving it a try and letting me know which seemed to work better for them?

http://www.joshuagranick.com/blog...
http://www.joshuagranick.com/blog/ajax...

Thanks for your help!

elyon
 
triplei replied on at Permalink Best Answer Reply
triplei
Hi there,

I just ran an apache benchmark on both version with the following results. (I know this doesn't take dom rendering / the extra ajax requests into consideration, but should give you a feel for the amount of content being transferred)

standard version
$ ab -n 10 http://www.joshuagranick.com/blog
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.joshuagranick.com (be patient).....done
Server Software:        Apache
Server Hostname:        www.joshuagranick.com
Server Port:            80
Document Path:          /blog
Document Length:        29994 bytes
Concurrency Level:      1
Time taken for tests:   37.051 seconds
Complete requests:      10
Failed requests:        0
Write errors:           0


ajax version
$ ab -n 10 http://www.joshuagranick.com/blog/ajax
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.joshuagranick.com (be patient).....done
Server Software:        Apache
Server Hostname:        www.joshuagranick.com
Server Port:            80
Document Path:          /blog/ajax
Document Length:        10983 bytes
Concurrency Level:      1
Time taken for tests:   17.673 seconds
Complete requests:      10
Failed requests:        0
Write errors:           0


hitting it in chrome and watching the network timer gave the following

standard:
9 requests ❘ 115.24KB transferred ❘ 4.45s (onload: 4.45s, DOMContentLoaded: 4.18s)

ajax:
17 requests ❘ 113.54KB transferred ❘ 5.60s (onload: 5.61s, DOMContentLoaded: 4.99s)


from my objective watching, it seems that the ajax version starts rendering content earlier, however takes a bit longer to load overall. Given the option I'd probably lean towards the ajax version, however I would be a bit concerned about the SEO impacts since the content may not be crawled by search engines.


Hope that feedback helps :) Let me know if you want any other testing.
elyon replied on at Permalink Reply
elyon
Thanks! That is very helpful!

I haven't used ApacheBench before, but I think that helps illustrate both sides of the performance difference here.

It looks like ApacheBench is counting the time it took for the server to respond as well as the time it took for content to download. On the other hand, I would guess that Chrome's timer is designed for client side performance, so it might not be taking a server-side delay into account as much.

In the end, it seems that the AJAX version is a little bit heavier on the client side, but ultimately is not tremendously different because the client needs to download the page, either way. However, the AJAX version is much lighter on the server, since it does not have to process any network calls before serving up the page.

I went ahead and included the AJAX version as a custom template with the add-on, but now I wonder if it should be a block setting, or if AJAX should just be the default.

I also wonder about SEO ... it would be interesting to know if Google, Yahoo and Bing process simple AJAX calls ...
triplei replied on at Permalink Reply
triplei
Yeah, ab is a pretty slick system to generate stats on the server's performance. It'll at least give you part of the story about how quick the server is responding, but as Phallanx pointed out, having 404's in there could throw off a browser's response time.

Unfortunately, as far as I know, search engines typically don't do any javascript processing so ajax requests are ignored. If you wanted to get creative, you could do some user agent checking, but you'll want to be careful there as well. Search engines don't like it if they notice that you're serving different content to them compared to actual users.
elyon replied on at Permalink Reply
elyon
Yeah, I just came across this page:

http://code.google.com/web/ajaxcrawling/docs/getting-started.html...

It seems pretty convoluted. Basically Google recommends a scheme for serving up static HTML when the crawler wants results, instead of providing content through Javascript. I don't know why in the world anyone would want to create their site with AJAX, just to hand-create a static HTML alternative (with the same content) or to write the same page using a server-side language instead.

I suppose this scheme is primarily designed for sites which go to new pages without changing the main URL, but it still seems weird.

I guess the design of the page doesn't matter as much when it is only for search engines, but still ... Google at least will read Flash SWFs and pull out text.

I guess it is good that I let users choose between cURL and AJAX ... I wonder if it would make sense to try and detect crawlers through PHP, and always provide the cURL version so it can read content?
Phallanx replied on at Permalink Reply
Phallanx
Well.
You have a few error 404s (not found) due to the quotes around the file names in these import rules

@import url(http://www.joshuagranick.com/packages/theme_smashing_html_five/themes/smashing_html5/"reset.css");
@import url(http://www.joshuagranick.com/packages/theme_smashing_html_five/themes/smashing_html5/"global-forms.css");

And the file in the IE7 switch also results in an error 404 but only for the non-ajax version

<!--[if lte IE 7]>
<script src="js/IE8.js" type="text/javascript"></script><![endif]-->

Try your tests again once you've resolved these as it could be more to do with time-out values at the moment
elyon replied on at Permalink Reply
elyon
Yeah, those do look weird.

I'm using a free theme from the Marketplace ... I bet that cleaning up those paths would help a bit. I'll spend a couple minutes to clean it up. Thanks
elyon replied on at Permalink Reply
elyon
I removed the missing IE stylesheet, but the other two are generated by Concrete using this->getStyleSheet(). I'm getting a warning, but I guess they are loading fine, since the site does have styles :)