There’s a warning in the forms docs that made an admin skittish the other day:
Was looking for a euphemism but came up short, so: this is just wrong. The number of choices you add in this dialog has no effect on form loading speed at all:
While I’m not privy to the edit history, the error is likely due to a misunderstanding. The Thank You choices can — if you have hundreds of them — slow down that particular page in Form Editor. An engineer might’ve mentioned that to a tech writer in passing.
But the choices are simply not loaded alongside the form. They’re not part of the public form descriptor (i.e. response to a /getForm call) and therefore have no effect on how long the form takes to load and render.
You can see that easily in your browser. Here, for example, are two forms that have one Thank You choice and 200 Thank You choices, respectively:
They have the same size and transfer time.
Thank You choices are only consulted upon form submission — on the server side —where finding the first match is instantaneous.
Thank You choices are private
The fact choices are only used on the server is a powerful differentiator vs. custom Thank You JS in an onSuccess listener.
I love the extended power of onSuccess, but it’s true that since Forms 2.0 JS runs in the browser, a curious end user can see all your possible criteria[1] and destination pages. In contrast, Thank You choices in Form Editor are private, and an end user can only see the one they matched.
Notes
[1] Technically you can hide some criteria by matching hashes instead of plain strings, but you can’t hide the destination URLs.
.png)