Again a non-scientific look at an Ajax application and whether it delivers on the "many smaller requests" advantage of Ajax. Last time we looked at the old and new Yahoo Mail. There the traffic looked pretty bulky for Ajax, i.e. the new Yahoo Ajax Mail was sending large amounts of data with XHR and making more requests than the old non-Ajax app.
This time we don’t have an old app to compare it to, and yes it’s apples and oranges, i.e. we’re talking about calendaring, not email, so the information sent back and forth is likely to be smaller. Again, the disclaimer: not scientific. Just accessing the app and trying to excercise as many of the features as possible. Here are the numbers:
(The count is the number of hits. All the other figures are in bytes. The figures are for response data sent from the server and doesn’t include the size of the request data sent from the browser.)
| Count | 93 |
| Average | 4393.108 |
| Median | 110 |
| 10th | 44.2 |
| 25th | 66 |
| 75th | 581.5 |
| 90th | 2385.6 |
| Max | 331424 |
At first glance, the communication seems pretty bulky, but if you subtract out the honking Javascript file at 331424 bytes, your average comes down to 838. So, overall, this Ajax app seems pretty efficient. In particular, I performed many more actions on the browser than are reflected in the measely 93 hits in my proxy log. That suggests that plenty of the business logic is in the browser.
One more thought: as Ajax apps become more sophisticated, we may want to have web servers and proxies and such start logging both the response and request sizes.
Note: I’m not sure there’s any help for the ugly logo, no matter how well the app performs.
