I'm curious, I'm a Cloud customer and I can tell you that the service is incredibly slow even for a small scale setup (2 Jira Projects and 3 Confluence Workspaces). There's an insane amount of network requests seemingly for mouse tracking. By telling everyone here, that Atlassian Cloud products are insufferably slow, am I violating the ToS?
I was actually thinking about doing a write up on the issues I've had but this seems to make me think I should do so AFTER I find someplace else to go. Right now GitHub is the likely destination but would love to hear other suggestions.
I'm a heavy JetBrains user but I've found their server side offerings to be lacking. I haven't been a fan of YouTrack in the past but maybe it's time to give them another try.
Sorry to hear it's been a frustrating experience. I'm a PM for Confluence Cloud and we're always trying to make it better. Would you be willing to share more specifics, such as: - Pages with content X are the slowest - Trying to do A/B/C is annoyingly slow - etc ?
(edit: looks like HN is severely limiting my reply rate so apologies for delays)
We're trying to focus on frustrating pages/experiences rather than number of network calls and such, because while the latter is correlated, the former (frustrating slow experiences) is really the bar and the higher priority.
In terms of the ToS I'm not from legal so can't say (still looking into it), but have definitely had conversations with users on public forums about performance issues, and afaik no one has been accused of violating their ToS.
(edit: since I can't reply due to HN limits I'll try to add some stuff in this edit)
------- @plorkyeran
"target things that are easier to fix than those with highest impact" -> this is a good point and something we're trying to do. Engineers know the former (easier to fix) pretty readily, but identifying "highest impact" requires some work, so I'm (as a PM) always trying to find out. It's of course some combination of these two (low hanging fruit, high impact items) that forms the priority list.
------ @igetspam (moved followup into a reply to trigger notification)
------@core-questions
"perf to take over company for 6mo-1yr" I'm not in the position to make that level of decisions, but can certainly pass the feedback up the chain. The perf team is trying their best though, so any info anyone can provide us can help us apply our resources in the right place
I did a test for you just now. I have 100Mbps internet, 32GB RAM, 4ghz i7 processor and suchlike. To make it easy for Jira, I'm doing this at a weekend, late at night, during the new years holiday so the servers shouldn't be busy.
On a cloud-based classic software project (which has less than 200 issues) opening a link to an issue it takes 4.8 seconds for the page to complete rendering and the progress bar at the top of the screen to disappear.
Opening a Kanban board with 11 issues displayed? 4.2 seconds for the page to load.
Click an issue on the board? 2.5 seconds for the details to pop up.
Close that task details modal - literally just closing a window? 200 milliseconds. Not to load a page - just to close a modal!
In case I'm being hard on cloud Jira by insisting on using a classic project, I also checked with a 'Next-gen software project' with less than 2000 issues.
I click a link to view a particular comment on an issue. 4.8 seconds until the issue, comment and buttons have all loaded.
I choose to view a board? 9.9 seconds from entering the URL to the page load completing.
I'm viewing the board and I want to view a single issue's page. I click the issue and the details modal pops up - and just as I click on the link to the details, the link moves because the epic details have loaded, and been put to the left of the link I was going for, causing me to click the wrong thing. So this slow loading is a nontrivial usability problem.
View a single issue, then click the projects dropdown menu. The time, to display a drop-down menu with three items? 200 milliseconds.
This is what people mean when they say the performance problems are everywhere - viewing issues, viewing boards, viewing comments, opening dropdowns, closing modals? It's all slow.
And if you imagine a backlog grooming meeting that involves a lot of switching back and forth between pages and updating tickets? You get to wait through a great many of these several-second pageloads.
Literally everything? I don't think I could give an example of something which isn't frustratingly slow in Jira. It doesn't need targeted fixes to specific things; if I successfully made a list of the ten biggest offenders and they were all magically fixed tomorrow I don't think it'd appreciably change the experience of using Jira because the next 90 would still be awful.
When faced with long-tail performance problems, it's often better to target the things which are easier to fix rather than the highest impact fixes. Making 20 relatively low-impact things faster can easily be better than improving 10 individually high impact things.
> Trying to do A/B/C is annoyingly slow - etc ? [...] We're trying to focus on frustrating pages/experiences rather than number of network calls
It's not really a problem with a certain page or a certain action: it's a systemic issue, that can only be solved with a systemic change.
This has come up before here in HN [1]. From my point of view, ignoring the issue around number of calls/performance and all feedback regarding it is the root cause for the slowness.
Know what would be great? Markdown support. The WYSIYG is full of bad assumptions and has been forever. In the beginning, we could at least opt out but that's long gone. I actively encourage companies I consult for to use anything but confluence because it seems to be designed specifically for the lowest common denominator with no allowance for people who work faster with a keyboard.
You've got to be kidding me. Have you used your own product? Going from my carefully tuned Server install to cloud Jira or Confluence is a night-and-day difference. The Cloud product is virtually unusable in comparison for any heavy Jira user.
You don't need "specifics", you need your performance engineering team to literally take over the entire company for 6 months to a year. No new features - nobody fucking needs them, the features 99% of your users use have been in the product for 5+ years already. Whatever you're PM'ing, cancel it, it's a waste of time in comparison to making the product not suck. The biggest source of losing users to some other product is going to be the sheer pain of continuing to use Atlassian....
Just make it usable. Halve the number of requests. Cache more things client-side. Do more server-side pre-processing so that a round-trip is not needed when I click on a menu.
I'm not looking forward to when I am forced to migrate my users to a more expensive and less performant experience. I and hundreds of thousands of other administrators will be experiencing months of user complaints because of the forced migration as it is; this is Atlassian's real chance to make it suck less in time.
Other commenters have hit on this already, but the worst one that bites me all of the time is this one:
1. I click a link to an issue
2. I need to do something on that issue, so I attempt to click on a particular section to go make a modification
3. Bam, some background script has loaded, some new piece of content was shoved in, and what I clicked wasn't the thing I was expecting to click
Also, certain interactions within JIRA take far too many steps, and each one takes far too long to load, so it makes me dislike JIRA even more.
Project managers love JIRA, but engineers don't, because each time you make us wait we are less inclined to deal with the software that PM's need us to use so they know how things are going, so instead we get more meetings. If JIRA were fast, we could cut down on meetings.
this "trying to show concern" is just fake. Atlassian have a ticket tracking system for their problems. They just ignore so much of the big hard problems, they close tickets with hundreds and hundreds of people on it explaining a multitude of core problems. Coming on HN is just trying to spin it for PR purposes is just not going to work, thread after thread on HN just shows that many many people have been BURNT by Atlassian products. However, I will say, Confluence has improved, but so many things still suck about it, including it being sluggish, and a search that seems really brain dead.
The topic of poor Jira performance came up yesterday, and I did some quick benchmarking of Jira cloud using the best-case scenario for performance: A tiny amount of data, no complex permissions, a commonly used form, no web proxy, no plugins, same geo region as the servers (Sydney), gigabit fibre internet(!), etc...
I spun up a free-tier account and created an empty issue. No data. No history. Nothing in any form fields. As blank as possible.
The only positive aspect is that most of the traffic is coming from a CDN that enables: Gzip, IPv6, HTTP/2, AES-GCM, and TLS 1.3. That's the basics taken care of.
Despite this, reloading the page with a warm cache took a whopping 5.5 seconds. There's an animated progress bar for the empty form!
This required 1.2 MB of uncacheable content to be transferred.
With the cache disabled (or cold), a total of 27.5 MB across 151 files taking 33 seconds is required to display the page. This takes over 5 MB of network traffic after compression. (Note that some corporate web proxies strip compression, so you can't rely on it working!)
For reference, it takes 1.6 seconds on the same computer to start Excel, and 8 seconds to load Visual Studio 2019 (including opening a project). That's four times faster than opening an issue ticket with a cold cache!
Meanwhile, the total text displayed on the screen is less than 1 KB, which means that the page has transfer-to-content efficiency ratio exceeding 1000-to-1. This isn't the animated menu of a computer game, it's a web form!
To render the page, a total of 4.35 seconds of CPU time was required on a gaming desktop PC to with a 3.80 GHz CPU. Having 6-cores doesn't seem to help performance, so don't assume upcoming higher-core CPUs will help in any way.
A developer on an ultraportable laptop running on battery over a WiFi link with a bad corporate proxy server in a different geo-region would likely get a much worse experience. Typically they might get as little as 1.5 GHz and 20 Mbps effective bandwidth, so I can see why people are complaining that Jira page loads are taking 10+ seconds!
In perfectly normal circumstances your customers are likely seeing load times approaching a solid minute.
PS: I do development, and I've avoided Atlassian products primarily because there's been a consistent theme to all discussions related to Atlassian, especially Jira: It's slow.
Stop asking your customers if they're running plugins, or what configuration they're using. Start asking yourself what you've done wrong, terribly, terribly wrong.
It's hard to name a single action I can take in JIRA which does not feel unacceptably slow. However, these are the actions that cause the most issues for me due to being used most often (JIRA datacenter, MBP 2019 with i7 + 32gb ram):
1. Viewing a board. This can take 10+ seconds to load.
2. Dragging an issue from one column to another. This greys out the board, rendering it unreadable and unusable for 5-ish seconds.
3. Editing a field. I get a little spinner before it applies for 2-3s for even the simplest edits like adding a label.
4. Interacting with any board that crosses multiple projects. A single project board is bad enough, as in point 1, but we have a 5 project board that takes 20+ seconds.
Actually, I found an action that's pretty ok: Search results are fast, even if clicking into any of them is not. I'm not sure why rendering a board is so different performance wise.
If you honestly need details and specifics when Confluence has always been a slow mess to the point of being unusable, then maybe Atlassian needs a PM in charge of performance metrics first and foremost?
@confluence_perf The Cloud applications provide multiple avenues for providing feedback directly in the user interface. Some/many of them are quite invasive (as in part of the screen is taken over with a "rate your experience editing this document"). I have used these avenues to provide feedback many many times over the years with my #1 response always being "focus on the performance". None of those ever get a response and I don't see what reiterating them in a HN post is going to solve. You have the data, please do something with it.
>I'm a PM for Confluence Cloud and we're always trying to make it better.
That's the problem. It's beyond repair since many, many years. You can only make it worse.
Ditch it! Throw it away, and rewrite from scratch. If you don't bungle it again (here lies the risk, as we're still talking about Atlassian) you'll have a better product then ever in one year.
And the first answer to your comment in this thread profiling performance for an empty page with almost no data on a small project should give you even more data than you ever would want.
However, having personally experienced "upgrades to Jira and Confluence experiences" over the past few years, I can safely say: no one at Atlassian gives two craps about this. All the talk about "We are definitely working on generalized efforts to make 'most/all/everything' faster" is just that: talk. There's exactly zero priority given to performance issues in lieu of flashy visual upgrades which only make the actual experience worse.
> We're trying to focus on frustrating pages/experiences rather than number of network calls and such, because while the latter is correlated, the former (frustrating slow experiences) is really the bar and the higher priority.
Exactly: you aren't even trying to understand what people are telling you. These metrics you ask for and then dismiss entirely are the primary, core, systemic reason for frustrating slow experiences that you pretend are "high priority". No, frustrating slow experiences have not been a high priority for years (if ever).
If you need to do 200 requests and load 27.5 MB of data to display an empty page, therein lies your problem. You, and other PMs at Atlassian fail to understand these basic things, and yet we get platitudes like "performance is our top priority". It is not. You're good at hiding information and buttons behind multiple layers of clicks, each of which needs another 200 requests and 5-15 seconds to execute.
> I'm a PM for Confluence Cloud and we're always trying to make it better.
Can you guys please make Ctrl-S save and not exit editing? My muscle memory is costing me 10+ seconds of load times every time I type a paragraph and reflexively save, getting dumped back to the view mode of a document. The slow load times exacerbate the problem tremendously. I honestly don't know a single product that treats Ctrl/Cmd-S as "Save and Exit" so this is just a baffling UI/UX design decision.
I would say the right place for the performance team to apply resources is looking for bugs or missed optimizations that affect everything or nearly everything on the site. Everything is uniformly slow, so there must be a lot of this.
Atlassian products in general spray out a huge number of requests to dozens of hostnames for even the most basic of actions. It scares me to think how their organisation is structured internally given the outwardly visible result.
If you’d like to see it for yourself, run Little Snitch in alert mode and try to sign into bitbucket.org - it’s almost comical how many hoops your browser jumps through.
I'm very curious about where the slowdown is coming from. Is it mostly JS on the client or Java on the server? When I ran my own Confluence server on a Digital Ocean VM, it was slow but not unbearable. I assumed it was Tomcat's fault* or the fact that I wasn't using a "real" database on the backend (a configuration Atlassian frowns upon).
*Confluence is built on Tomcat. Don't know if this is also true for Jira.
Now that my Confluence server is on Atlassian's cloud, it seems much slower still. So I have to assume it's not client-side JS because that hasn't changed much; there's some kind of resource starvation going on with Atlassian's servers.
Over here, at least, a lot of the time is spent just waiting for content. Even static content from CDNs. I'm guessing they're not geolocating properly.
Doesn't Oracle sue if you benchmark them and release the results publicly or is that an old wives tail?
On a YouTube lecture at CMU the Materialize guys seemed to try very hard to not even land in the same zip code as that discussion to the point it was awkward, and they seem pretty smart.
Are these large organizations really that petty? Ad absurdism, would it be legal if Ford said we couldn’t drag race their car after we bought it?
If you are looking for a fast alternative, we're building www.kitemaker.co (I'm one of the founders). We're part of the upcoming YC batch, and I'd be happy to help you onboard and import existing projects if needed.
>you will not and you have no right to: ... (f) perform or publish any benchmark tests or analyses relating to the Cloud Services without Cloudflare’s written consent;
It’s amazing what legal gets away with at most companies and how little actual engineers and management gets to see of this part of their company. I am sure any self-respecting Cloudflare engineer would be horrified to see that this is in their ToS and yet it exists.
Are these terms really that nefarious or just a way to terminate some customer who decides to load test your system and ends up bringing it down? Legal documents are typically written to be as broad as possible.
Perhaps it should be more narrowly written, but prohibiting certain kinds of testing without permission is reasonable.
As a software engineer who has been woken up in the middle of the night while oncall because some random user wanted to run their own performance tests against our system, I can completely understand why companies want to prevent this from happening without their awareness.
"Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues" - Their ToS may prohibit it, but that is in no way going to stop me from doing it - I don't give a shit about some document they write. Atlassian products suck hard and their performance characteristics are horrible. I hate being forced to use their crap at work.
The problem with Atlassian's Terms of Service is that most of their end-users are not paying for the software and do not really care if they violate an agreement they were either forced to make or which someone made on their behalf.
I don't think it applies to us. Our employers can sign whatever they like and constrain us from speaking in official company-related capacities, but we're no more bound to that as individuals then we're bound to anything else our companies sign as individuals. As individuals, we're not in a relationship with Atlassian at all.
They will suddenly care when Atlassian locks them out of being able to access anything. Then, we'll see posts on Twitter or here or elsewhere about some user crying about not getting access to "their" stuff on a 3rd party's site.
I read HN every day, I never post, I signed up for an account just to post this. I'm a senior PM at a large e-comm company, I was EXTREMELY frustrated with the horrible performance of Jira Cloud, I submitted support tickets to no avail. It's obviously an over-architected broken system.
I moved my team to clubhouse, even-though it created an element of fragmentation considering all other teams are using JIRA. I'm so happy though with clubhouse, I can actually get my work done without mindlessly waiting for every interaction.
Icing on the cake: I was considering moving the company over to Jira on a self hosted AWS instance, I've read that it can be a little faster. but.. they're discontinuing the self hosted option. Nail in the coffin for me.
I've tried to convince a particular manager to try GitLab Issues. (We already use GitLab for git/CI anyway).
Seeing that I'm not just the one who thinks it's so ridiculously frustratingly bad-slow [as in, it's impossible to be this slow even after multiple rewrites unless it's some kind of bizarre experiment by Douglas Adams' ghost] will likely lead to us dropping JIRA for good.
This is not surprising: anyone who’s used Atlassian products knows that quality has been job number 97 for years. That doesn’t happen by accident – someone’s made the decision that they’ll make sales anyway and cut the QA budget.
One of the most obvious examples: they have multiple WYSIWYG editor implementations which aren’t compatible. When you format something in Jira it’ll look fine in the preview and then render differently on reload. It’s been like that for years, nobody cares.
I spend 10 minutes to make a detailed bug report, just to have it fall apart after submitting. How does that happen in a software made to show bug reports?
Just use standard markdown instead of your own bullcrap formatting that doesn't ever seem to work.
Best I can say here (as a Confluence PM not a Jira one, and in a public forum) is that customers are not the only ones that experience this pain, and the appropriate folks are notified on a regular basis.
I think the genesis of this is historically many different editable fields might had different modules behind them (not every single one a different one, but maybe a handful of common ones). It looks like for whatever reason we (Atlassian) haven't fully migrated all of them to the newest common editor modules -> I don't know anything for sure though
That’s the cause. Normally that’d be caught in testing — the same input producing different outputs isn’t hard to test — and it’s commonly reported by users. Maybe they each think the other team should fix it but who cares: from the user’s perspective it’s broken.
Yep Confluence is an amazingly overly complicated thing! I had it on modern windows server that boots up in 60 seconds. From that time, confluence starting up take no less than 10 minutes before it responds to web requests. Fortunately we switched to Teams this year, no more exorbitant confluence renewal fees and clueless support.
"Yep Confluence is an amazingly overly complicated thing" - yeah,with an incredibly slow editor that screws up even simple page edits constantly. It's a complete shit show. There's a reason we call it "cuntfluence" at my workplace.
SharePoint Server is an absolute beast with a bunch of legacy code yet it has no issues being responsive as soon as it JITs (which can take ~30 second so or so after an App Pool startup).
SPO is also responsive (the last thing to load is typically the SuiteNav which doesn't impact working with the site/content).
I'm not sure why a company like Atlassian would have these persistent performance issues.
Sorry to hear it's been a frustrating experience. I'm a PM for Confluence Cloud and we're always trying to make it better. Would you be willing to share more specifics, such as: - Pages with content X are the slowest - Trying to do A/B/C is annoyingly slow - etc ?
(edit: looks like HN is severely limiting my reply rate so apologies for delays)
"My boss told me to generate a bunch of JIRAs in reaction to the recent accurate discussions on HN of how poor our performance is, so I need specific dit-dot issues to buff our team metrics rather than address the cause of the issues, which is a political non-starter"
As a product manager, are you allowed to discuss performance and benchmarks without violation of your contract? Or, is it just customers that are prohibited from this?
(i) publicly disseminate information regarding the performance of the Cloud Products;
But can we take a minute to talk about the combination of these two :
(h) use the Cloud Products for competitive analysis or to build competitive products;
(j) encourage or assist any third party to do any of the foregoing.
Does this mean as a jira user I can’t help build a jira competitor for a client of mine ( we are a tech agency). If this is the case I would really have a hard time using jira and being compliant. After all, who is the arbiter on what jira is exactly?But does this also mean people can’t do reviews on the platform as means to compare to other platforms? I’m a bit speechless here, it’s a wtf sort of thing.
Imagine if products prior to the 90s or outside software had these sorts of “agreements.” Every store in a mall would have them and every piece of fruit in a grocery store would require you to agree to arbitration clauses and privacy policies and non disclosure and non competition. Consumer reports and class action suits would not exist, and nobody would really be allowed to talk about it because of the NDAs. Automated facial and voice recognition in smart home devices could sell data to companies to enforce it. The news would not be able to talk about it. It would be a good setup for a dystopian movie, no?
Readit News
I was actually thinking about doing a write up on the issues I've had but this seems to make me think I should do so AFTER I find someplace else to go. Right now GitHub is the likely destination but would love to hear other suggestions.
(edit: looks like HN is severely limiting my reply rate so apologies for delays)
We're trying to focus on frustrating pages/experiences rather than number of network calls and such, because while the latter is correlated, the former (frustrating slow experiences) is really the bar and the higher priority.
In terms of the ToS I'm not from legal so can't say (still looking into it), but have definitely had conversations with users on public forums about performance issues, and afaik no one has been accused of violating their ToS.
(edit: since I can't reply due to HN limits I'll try to add some stuff in this edit)
------- @plorkyeran "target things that are easier to fix than those with highest impact" -> this is a good point and something we're trying to do. Engineers know the former (easier to fix) pretty readily, but identifying "highest impact" requires some work, so I'm (as a PM) always trying to find out. It's of course some combination of these two (low hanging fruit, high impact items) that forms the priority list.
------ @igetspam (moved followup into a reply to trigger notification)
------@core-questions "perf to take over company for 6mo-1yr" I'm not in the position to make that level of decisions, but can certainly pass the feedback up the chain. The perf team is trying their best though, so any info anyone can provide us can help us apply our resources in the right place
On a cloud-based classic software project (which has less than 200 issues) opening a link to an issue it takes 4.8 seconds for the page to complete rendering and the progress bar at the top of the screen to disappear.
Opening a Kanban board with 11 issues displayed? 4.2 seconds for the page to load.
Click an issue on the board? 2.5 seconds for the details to pop up.
Close that task details modal - literally just closing a window? 200 milliseconds. Not to load a page - just to close a modal!
In case I'm being hard on cloud Jira by insisting on using a classic project, I also checked with a 'Next-gen software project' with less than 2000 issues.
I click a link to view a particular comment on an issue. 4.8 seconds until the issue, comment and buttons have all loaded.
I choose to view a board? 9.9 seconds from entering the URL to the page load completing.
I'm viewing the board and I want to view a single issue's page. I click the issue and the details modal pops up - and just as I click on the link to the details, the link moves because the epic details have loaded, and been put to the left of the link I was going for, causing me to click the wrong thing. So this slow loading is a nontrivial usability problem.
View a single issue, then click the projects dropdown menu. The time, to display a drop-down menu with three items? 200 milliseconds.
This is what people mean when they say the performance problems are everywhere - viewing issues, viewing boards, viewing comments, opening dropdowns, closing modals? It's all slow.
And if you imagine a backlog grooming meeting that involves a lot of switching back and forth between pages and updating tickets? You get to wait through a great many of these several-second pageloads.
When faced with long-tail performance problems, it's often better to target the things which are easier to fix rather than the highest impact fixes. Making 20 relatively low-impact things faster can easily be better than improving 10 individually high impact things.
It's not really a problem with a certain page or a certain action: it's a systemic issue, that can only be solved with a systemic change.
This has come up before here in HN [1]. From my point of view, ignoring the issue around number of calls/performance and all feedback regarding it is the root cause for the slowness.
[1] https://news.ycombinator.com/item?id=24818907
You've got to be kidding me. Have you used your own product? Going from my carefully tuned Server install to cloud Jira or Confluence is a night-and-day difference. The Cloud product is virtually unusable in comparison for any heavy Jira user.
You don't need "specifics", you need your performance engineering team to literally take over the entire company for 6 months to a year. No new features - nobody fucking needs them, the features 99% of your users use have been in the product for 5+ years already. Whatever you're PM'ing, cancel it, it's a waste of time in comparison to making the product not suck. The biggest source of losing users to some other product is going to be the sheer pain of continuing to use Atlassian....
Just make it usable. Halve the number of requests. Cache more things client-side. Do more server-side pre-processing so that a round-trip is not needed when I click on a menu.
I'm not looking forward to when I am forced to migrate my users to a more expensive and less performant experience. I and hundreds of thousands of other administrators will be experiencing months of user complaints because of the forced migration as it is; this is Atlassian's real chance to make it suck less in time.
That's something you could easily figure out yourself. E.g., just grabbing some random JIRA:
https://hibernate.atlassian.net/jira/software/c/projects/HV/...
Opening an issue in that tracker takes 24 seconds for me. Twenty-four.
1. I click a link to an issue 2. I need to do something on that issue, so I attempt to click on a particular section to go make a modification 3. Bam, some background script has loaded, some new piece of content was shoved in, and what I clicked wasn't the thing I was expecting to click
Also, certain interactions within JIRA take far too many steps, and each one takes far too long to load, so it makes me dislike JIRA even more.
Project managers love JIRA, but engineers don't, because each time you make us wait we are less inclined to deal with the software that PM's need us to use so they know how things are going, so instead we get more meetings. If JIRA were fast, we could cut down on meetings.
Please make JIRA fast.
I spun up a free-tier account and created an empty issue. No data. No history. Nothing in any form fields. As blank as possible.
The only positive aspect is that most of the traffic is coming from a CDN that enables: Gzip, IPv6, HTTP/2, AES-GCM, and TLS 1.3. That's the basics taken care of.
Despite this, reloading the page with a warm cache took a whopping 5.5 seconds. There's an animated progress bar for the empty form!
This required 1.2 MB of uncacheable content to be transferred.
With the cache disabled (or cold), a total of 27.5 MB across 151 files taking 33 seconds is required to display the page. This takes over 5 MB of network traffic after compression. (Note that some corporate web proxies strip compression, so you can't rely on it working!)
For reference, it takes 1.6 seconds on the same computer to start Excel, and 8 seconds to load Visual Studio 2019 (including opening a project). That's four times faster than opening an issue ticket with a cold cache!
Meanwhile, the total text displayed on the screen is less than 1 KB, which means that the page has transfer-to-content efficiency ratio exceeding 1000-to-1. This isn't the animated menu of a computer game, it's a web form!
To render the page, a total of 4.35 seconds of CPU time was required on a gaming desktop PC to with a 3.80 GHz CPU. Having 6-cores doesn't seem to help performance, so don't assume upcoming higher-core CPUs will help in any way.
A developer on an ultraportable laptop running on battery over a WiFi link with a bad corporate proxy server in a different geo-region would likely get a much worse experience. Typically they might get as little as 1.5 GHz and 20 Mbps effective bandwidth, so I can see why people are complaining that Jira page loads are taking 10+ seconds!
In perfectly normal circumstances your customers are likely seeing load times approaching a solid minute.
PS: I do development, and I've avoided Atlassian products primarily because there's been a consistent theme to all discussions related to Atlassian, especially Jira: It's slow.
Stop asking your customers if they're running plugins, or what configuration they're using. Start asking yourself what you've done wrong, terribly, terribly wrong.
1. Viewing a board. This can take 10+ seconds to load.
2. Dragging an issue from one column to another. This greys out the board, rendering it unreadable and unusable for 5-ish seconds.
3. Editing a field. I get a little spinner before it applies for 2-3s for even the simplest edits like adding a label.
4. Interacting with any board that crosses multiple projects. A single project board is bad enough, as in point 1, but we have a 5 project board that takes 20+ seconds.
Actually, I found an action that's pretty ok: Search results are fast, even if clicking into any of them is not. I'm not sure why rendering a board is so different performance wise.
Not just the Cloud service, the self-hosted versions are also painfully slow no matter what resources you throw at them.
That makes the other UX issues worse because the feedback loop has so much lag.
I would... but Atlassian TOS prohibit me from doing so :(
That's the problem. It's beyond repair since many, many years. You can only make it worse.
Ditch it! Throw it away, and rewrite from scratch. If you don't bungle it again (here lies the risk, as we're still talking about Atlassian) you'll have a better product then ever in one year.
And the first answer to your comment in this thread profiling performance for an empty page with almost no data on a small project should give you even more data than you ever would want.
And this one for an empty project: https://news.ycombinator.com/item?id=25616069
However, having personally experienced "upgrades to Jira and Confluence experiences" over the past few years, I can safely say: no one at Atlassian gives two craps about this. All the talk about "We are definitely working on generalized efforts to make 'most/all/everything' faster" is just that: talk. There's exactly zero priority given to performance issues in lieu of flashy visual upgrades which only make the actual experience worse.
> We're trying to focus on frustrating pages/experiences rather than number of network calls and such, because while the latter is correlated, the former (frustrating slow experiences) is really the bar and the higher priority.
Exactly: you aren't even trying to understand what people are telling you. These metrics you ask for and then dismiss entirely are the primary, core, systemic reason for frustrating slow experiences that you pretend are "high priority". No, frustrating slow experiences have not been a high priority for years (if ever).
If you need to do 200 requests and load 27.5 MB of data to display an empty page, therein lies your problem. You, and other PMs at Atlassian fail to understand these basic things, and yet we get platitudes like "performance is our top priority". It is not. You're good at hiding information and buttons behind multiple layers of clicks, each of which needs another 200 requests and 5-15 seconds to execute.
Oh. You're also good at adding useless crap like this: https://grumpy.website/post/0TcOcOFgL while making sure that your software is nigh unusable: https://twitter.com/dmitriid/status/888415958821416960 I imagine all performance tickets get dismissed because no one can see the description even on a 5k monitor
Can you guys please make Ctrl-S save and not exit editing? My muscle memory is costing me 10+ seconds of load times every time I type a paragraph and reflexively save, getting dumped back to the view mode of a document. The slow load times exacerbate the problem tremendously. I honestly don't know a single product that treats Ctrl/Cmd-S as "Save and Exit" so this is just a baffling UI/UX design decision.
Deleted Comment
If you’d like to see it for yourself, run Little Snitch in alert mode and try to sign into bitbucket.org - it’s almost comical how many hoops your browser jumps through.
*Confluence is built on Tomcat. Don't know if this is also true for Jira.
Now that my Confluence server is on Atlassian's cloud, it seems much slower still. So I have to assume it's not client-side JS because that hasn't changed much; there's some kind of resource starvation going on with Atlassian's servers.
See https://community.atlassian.com/t5/Jira-questions/How-to-swi...
I've used many others including Github, GitLab, Phabricator, Redmine, etc., and Clubhouse does a great job IMO.
On a YouTube lecture at CMU the Materialize guys seemed to try very hard to not even land in the same zip code as that discussion to the point it was awkward, and they seem pretty smart.
Are these large organizations really that petty? Ad absurdism, would it be legal if Ford said we couldn’t drag race their car after we bought it?
You may not: disclose results of any Program benchmark tests without Oracle’s prior consent
It sounds like a bad business decision to not support open discussion on performance, it makes me think that they have something to hide.
>you will not and you have no right to: ... (f) perform or publish any benchmark tests or analyses relating to the Cloud Services without Cloudflare’s written consent;
https://www.cloudflare.com/terms/#react-modal:~:text=(f)%20p...
Perhaps it should be more narrowly written, but prohibiting certain kinds of testing without permission is reasonable.
Deleted Comment
I moved my team to clubhouse, even-though it created an element of fragmentation considering all other teams are using JIRA. I'm so happy though with clubhouse, I can actually get my work done without mindlessly waiting for every interaction.
Icing on the cake: I was considering moving the company over to Jira on a self hosted AWS instance, I've read that it can be a little faster. but.. they're discontinuing the self hosted option. Nail in the coffin for me.
Good bloody riddance.
Seeing that I'm not just the one who thinks it's so ridiculously frustratingly bad-slow [as in, it's impossible to be this slow even after multiple rewrites unless it's some kind of bizarre experiment by Douglas Adams' ghost] will likely lead to us dropping JIRA for good.
Thanks!
One of the most obvious examples: they have multiple WYSIWYG editor implementations which aren’t compatible. When you format something in Jira it’ll look fine in the preview and then render differently on reload. It’s been like that for years, nobody cares.
I spend 10 minutes to make a detailed bug report, just to have it fall apart after submitting. How does that happen in a software made to show bug reports?
Just use standard markdown instead of your own bullcrap formatting that doesn't ever seem to work.
I think the genesis of this is historically many different editable fields might had different modules behind them (not every single one a different one, but maybe a handful of common ones). It looks like for whatever reason we (Atlassian) haven't fully migrated all of them to the newest common editor modules -> I don't know anything for sure though
I self-host a confluence install, and it’s performance is poor even with a good sized VM and absolutely zero other traffic to it.
If you ban objective criticism, I guess all you're left with is FUD.
SPO is also responsive (the last thing to load is typically the SuiteNav which doesn't impact working with the site/content).
I'm not sure why a company like Atlassian would have these persistent performance issues.
I also got no response (or even an acknowledgement) for the feedback I gave. Like most people here, I too am forced to use it at work.
(edit: looks like HN is severely limiting my reply rate so apologies for delays)
it is more like a general feeling all the time for many of us.
I'm using the latest Firefox on Windows, a developer laptop with 32GB memory that was brand new this spring as well as 500/500 fiber.
(i) publicly disseminate information regarding the performance of the Cloud Products;
But can we take a minute to talk about the combination of these two :
(h) use the Cloud Products for competitive analysis or to build competitive products;
(j) encourage or assist any third party to do any of the foregoing.
Does this mean as a jira user I can’t help build a jira competitor for a client of mine ( we are a tech agency). If this is the case I would really have a hard time using jira and being compliant. After all, who is the arbiter on what jira is exactly?But does this also mean people can’t do reviews on the platform as means to compare to other platforms? I’m a bit speechless here, it’s a wtf sort of thing.