Isn't it exactly the same speed?

Is it? I'd assume a dialog at least isn't building an entire new page?

(do we fake it?)

The cost of the page frame should be so small that it never motivates a page -> dialog change. If it isn't, this task should be "remedy performance problems of page frame", or if we can't we should merge it into T2086.

If pages feel slow to you, let's talk about prioritizing some performance work. We're basically doing zero optimization right now, except in the rare cases where something is so explosively bad that it stops workflows completely (e.g., the task queue thing).

Basically, the proposed solution increases the complexity of the codebase (all the create pages need to have dialog rendering paths) and only improves the situation if the page frame has a significant performance issue. If it does, it sweeps it under the rug in a non-general way that applies to only one relatively rare workflow.

Should I say it feels quicker to be a dialog? I have no actual data on the speed, just that I was very happy with the UEX of the Conpherence Dialog.

I guess Conpherence only exists as a dialog.

When loaded as raw pages, the "New Conpherence" page is >2x faster for me than the "New Task" page:

https://secure.phabricator.com/conpherence/new/
https://secure.phabricator.com/maniphest/task/create/

That is, if they were both dialogs, the Maniphest one would still be about twice as slow.

I mean more from a psychological point of view it feels faster. The UX now is page load (new task) page load (submitted task), so 2 page loads to submit a new task. Where with a dialog (even is same end to end time) the user only experiences one page load change (submitted task).