I believe that this plugin is not gracefully handling REST API calls to a Bitbucket Server that takes a long time to respond, on the order of 10 seconds to a minute per call. I don't expect you to solve my company's configuration problems, but I think that you might be able to test around some corner cases that I am running into and improve how your plugin handles them.

I had configured my team's Jenkins jobs to use the Atlassian Bitbucket Server Integration Jenkins plugin quite a while ago and was very happy with it.  My corporate Bitbucket Server was recently updated to version 7.6.0.  After the upgrade performance of some features has dropped:

• It (now) takes a browser 30 seconds to a minute to load the "landing" page for a Jenkins build job that is using the Bitbucket Server plugin. Build jobs that do not use the plugin do not have this problem.
• When you edit a functioning build job's configuration in Jenkins you need to wait for the plugin to finish communicating with the Bitbucket Server before you save the configuration, even if the build job had already connected successfully to the Bitbucket Server during an earlier session. It can take 30 seconds to a minute for the communication to complete. If you don't wait for the communication to complete, when you save the build job it will write empty values for the associated git repo to the configuration and the job will fail to build when triggered (because the build node has no git repo URL to pull).

I don't know which version of Bitbucket Server was in use before - probably 6.something.

It seems to me that the Bitbucket plugin should not be slowing down the loading of the "landing page" for a build job.  It must be making some number of REST API calls, even if it does not render anything related to the Bitbucket Server.  I would guess that if you are testing with a fast-responding server you won't see the issue, but if you simulate some latency you would.

It also seems like it would be good to ensure that when saving a job configuration, if a git repo's data has already been stored in the configuration file, you should avoid writing empty values in the case where a connection to the Bitbucket Server is still in progress when the user saves the configuration.  Instead you should avoid changing the previously saved configuration.

On a related note, I have tested that access to Bitbucket Server's REST API is slow from that Jenkins machine using its Script Console to run a curl command to post build status to the Bitbucket Server's API.  

TLS negotiation is fast and curl reports that the POST is sent in 200-300 ms.  The response to the POST takes anywhere from 3-60 seconds.  Longer response times seem to occur more frequently when I issue the curl commands in a loop. 

This makes me think that there is a problem either in our intranet or in the Bitbucket Server's configuration.

More info can be found at: https://issues.jenkins-ci.org/browse/JENKINS-64022