When you get below 50-100ms per action, things are generally fast enough that this is not a key problem any more. The user cares greatly if you can go from 800ms to 100ms, but not so much if you can go from 100ms to 70ms.
When you get below 50-100ms per action, things are generally fast enough that this is not a key problem any more. The user cares greatly if you can go from 800ms to 100ms, but not so much if you can go from 100ms to 70ms.
For example, if you are populating a bunch of divs inside a parent div with the data returned using json, you would describe this using something like jquery selectors. Now if someone else comes and moves around the div during a redesign, he must go through whole bunch of js to make sure his shuffling of the divs around won't break the jquery selectors populating the data from json.
Now think about having a parent div that is simply populated with returned HTML from server-side and it seems way easier than using json to populate the data.
My view is that you will get in significantly less trouble because manipulating an HTML template that is rendered on server side is much easier to manage and adapt to a new design than finding nitpick jquery selectors across the app that depend on a specific div structure.
Btw, my post doesn't imply anywhere that a designer should redesign an app without testing. Therefore, your argument about testing is garbage.
What browsers are you getting the 50-100ms numbers? Similar results on mobile (with a 3G connection)?
That's why it's great to be closer to 50ms so you'll stay under 100ms even with the network overhead.