No doubt it depends on how you use it, but I find it very slow.

For example, I just tested following a permalink to a comment on a ticket. After 1.3 seconds I see the ticket - but it takes more than 7 seconds until I'm scrolled to the right comment, all the ticket details are loaded, and so on.

And the slow-ass lazy loading means you daren't click something between 1.3 seconds and 7 seconds, because at any moment a new button or linked issue box or the addition of status icons next to links or something will reflow the page.

In my experience this shitty performance is baked into every single interaction with Jira. You want to create an issue? Two seconds to show up the form. You click the 'epic link' dropdown on that form? A full second just to display a dropdown menu. Oh, and you also want to open the 'label' dropdown? That'll be 1.8 seconds.

And all those are on Cloud Jira, at a weekend, on a <300 ticket project, on a powerful developer workstation.

I used to complain about Jira for similar reasons. Then we switched to Azure DevOps, and now I have tears in my eyes and cry "I want my simple and fast Jira back!"

> I agree that Jira isn’t the snappiest tool

It is forbidden in the ToS 3.3 to “(i) publicly disseminate information regarding the performance of the Cloud Products“.

https://www.atlassian.com/legal/cloud-terms-of-service

Even if that clause is enforceable, you can just tell people about it instead. No company would try to prevent talk about their products' good performance.

Actually, I’m obviously not talking about Jira but imagine some made an issue tracker in cloud mode and programmed it using microservices, the speed of each microservice would vary a lot depending on workload, time of the day, location, time since last access of the document/attachment/screen/userdata, configuration of the instance, importance of this customer (maybe I would give privileged speed to a good customer, or to one whom I’ve had problems with on other features) and it would vary so much that performance for one person would be hardly representative of another person’s experience.

That would be one legit reason for thinking about writing this clause. Because it’s really curious to think about writing that.

Not that I disagree, although I feel the problem here is that this clause then can apply to all types of softwares. And even hardwares too. Just think if tomorrow Apple says that you cannot talk about degradation in performance in iPhones (because battery capacity reduces over time or something). We both know this, like we know that a user's experience will differ from the other. A company shouldn’t be adding a clause to prevent talking about this, it sounds like a malpractice to me. (I know it’s not that serious but still…)

Anytime I see similar language, I know I do not have to look very hard to understand why someone felt it worth producing.

They might as well say it:

Will be slow, we feel that does not impact the value proposition.

Our license revenue is super necessary and this is not a race.

Ya, slow now because we need users and features now, go faster later.

If you need it to be more performant, pay us more and make the hardware investments we tell you to...

I personally would respect those more than a blanket gag attempt.

I also confirm that in my experience the performance of the JIRA Cloud installation has been mostly fine. It's not amazingly fast but only having used JIRA cloud, even with loads of projects and so on, I always thought it was weird to read all the stories of poor performance.

Compared to something like pivotal tracker, Jira feels like trying to swim in glue.

It just gets in the way. Individual actions are tolerable-ish. But it’s never setup right. Constantly hunting for the field that is blocking story creation. Permission issues all over the place.

Finding things is often nightmarish.

Management basically doesn’t care, and doesn’t want to put effort into making it work in sane fashion. Yet freak out if team wants to use something else. So we do all our planning and story tracking in google sheets instead.

It's like medieval doctors and hand washing.

Fast solutions clearly exist. But somehow everybody ends up using slow Jira.

> but I don't sit there consciously waiting for it to do stuff.

100% of the time I want Jira to do stuff is when I'm interacting with it, and thus absolutely waiting for it.

I use Jira a lot. Waiting three seconds per action makes me think that interfaces based on old-timey mainframes were probably faster.