You're right, that's the mystery of averages (sum of averages differs from the average of sum).
I was aware of an inevitable difference, I never checked how much it could be, and it occurs to be very significant ... Better take it as orders of magnitude.

UPDATE: there is some discussion on this subject: http://math.stackexchange.com/questions/105463/sum-of-averages-vs-average-of-sums
There may be a glitch in our time measurement (calculation shared by browser and server, somewhat tricky)

An other possible observation is that the web app saves time for GUI rendering as forms run hidden on the server (FiC uses the forms are logical containers, graphic displays occurs on the browser only). Though it's almost impossible to measure that on a desktop GUI, based on sight impression and for this particular app, GUI rendering takes almost as long as method code (seeing the controls flickering: combo boxes, grid, etc. until user can interact again).

FiC app always skips the 'restore' step when the same user fires another event on the same form (and parent form if running in default datasession) and on the same server (up to 32 servers can run simultaneously).
The 'save' step is almost mandatory (except for a very limited set of events) because FAS identifies changes by comparing the 'ante event' and the 'post event' states. Some expert argue that we could pick the changes on the fly, using techniques like this_access(), I prefer keeping this state comparison mechanism which is, IMO, easier to debug.
The downside is that the developer must list, for each object and classes, the native 'display' properties (.Visible, .Enabled and so on) that can change during a user event -- of course FAA does the job initially; later, when creating new functionalities, dev must either do it her/himself (it soon becomes automatic), or re-run FAA against the modified application.

Another (very strong) lever to improve Web response time is to upgrade the server box frequently (say every year) -- Moore's law is still here.

>Interesting. The 2 possible scenarios (either something like Electron RPCing the local app enhanced with HTML/XML generation or deploying FIC locally) of providing the web GUI as a locally installed and performed application probably would be close in speed, provided a local FIC could skip form save/restore in most cases by caching, as the user most of the times works on the same form.
>
>many thx for the data - even if 13% are missing ;-))
>
>thomas
>
>>>>Desktop app is about 4 times faster than the Web app (server overhead), GUI is much rougher (see attached)
>>>
>>>As you often take the time to measure exactly, did you measure which parts slowed down to what percentage or try out running the browser on the machine working as server ?
>>
>>FAS does that automatically per request, min, avg and max:
>>
>>avg based on 2,481 user actions from 31 unique users
>>
>>initializing request 1%
>>restoring application state for user 0%
>>restoring form state for user 12%
>>application 23%
>>updating menus 0%
>>saving application state for user 0%
>>saving form state for user 12%
>>identifying visual changes 0%
>>mapping visual changes into HTML 14%
>>mapping visual changes into XML 4%
>>cleaning up environment 0%
>>Internet 16%
>>Browser 5%
>>FoxInCloud Application Response Total 100%