If you are using Joget DX, perhaps its a good idea to check out the APM to see the slow traces and try to solve the root of the performance issue.

Now about this issue, it does seem strange because usually in my experience, Joget will load the form entirely before allowing users to interact with the form. But if you need to do this, maybe you can disable the submit buttons via CSS first, then write a short JS script to enable them again once all your other JS functions has executed completely.

Hi Chris,

we have not upgraded to DX yet, but I was thinking about APM too. we will be doing upgrades soon.

what would be the JS Script that would "check" all other JS functions executed completely?

Thank you.

As I do not know your JS scripts and form design, I cannot pinpoint precisely what you can do.

But if you are familiar with jQuery, you can see the solution here: https://stackoverflow.com/questions/3030713/javascript-how-to-check-all-code-of-an-html-page-is-loaded

Basically, either place the code to re-enable the submit button at the end of all your JS scripts, or call the jquery function to ensure the document has loaded finish.

Dear Chris,

Being in the same organization as the OP, I am trying to follow up on this.

As suggested in your post, we have tried to disable the submit buttons via CSS first, then to re-enable the "submit" button in the callback of $(document).ready().

However, after pressing the "submit" button, our remote users are still experiencing the same following Joget error message as they have been. Does this mean this error is irrelevant to page loading? If so, could you please advise on how to fix this error issue? Thank you.

" Sorry, access is forbidden for security reasons.

Please refresh the previous form before submitting it.

Security Violation (Code 403)"

This seems like a separate issue.

This can be caused by many reasons. As I do not know your app design, custom code in use, etc., there's no way to know just from this error message.

First, check the server log for any errors thrown.

And is this issue consistently replicable?

Dear Chris,

Yes, this issue has been consistently experienced by our remote users when they press the same button. Though according to the users, it seems that sometimes this error wouldn't happen when they waited a bit (arbitrarily) longer. That's why it was suspected to be related to page loading.

Based on the time stamp, this error message corresponds to the following message in joget.log:

ERROR 21 Apr 2021 23:03:04 org.owasp.csrfguard.CsrfGuard - potential cross-site request forgery (CSRF) attack thwarted (user:<anonymous>, ip: , method:POST, uri:/jw/web/userview/quote_app/quote_app/_/update_cost_model, error:required token is missing from the request)

Could you please advise? Thank you.

By any chance, are you using the Multi Paged Form element? Just a blind guess because at times when using with other potentially slow wait / heavy processing elements such as heavy JS scripting, JDBC binders, etc., it can impact page loading performance.

Try using the Performance Analyzer feature to see where takes up the most loading time in your form, and you can start optimizing performance accordingly.

Without knowing your app and form design, unfortunately I can't help much either. This is where the APM in Joget DX would be really handy, as you are able to see slow traces and study the trace to pinpoint exactly what part of the app/userview/form is taking up the most waiting time or resources. 
Don't mean to be 'advertising' Joget DX so much but it is a really handy feature for pinpointing performance issues.