Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,360,333
Community Members
 
Community Events
168
Community Groups

Performance for Jira’s team-managed projects just got snappier!

Hi everyone,

I'm Ivan, a Product Manager in Jira Software Cloud. We take customer feedback seriously at Atlassian, and we want you to know that we’ve heard you loud and clear! Performance improvement is always top of mind for us, and our teams have been working hard to identify new methods that will make Jira Software faster.

We are excited to share that we’ve made significant performance improvements in team-managed projects' Time to Interactive (TTI) measurement for page loads and interactions, between June 2020-July 2021.

TLDR, here’s a summary of how performance has improved over the last year. The larger your team-managed backlogs, boards and roadmaps, the more noticeable the improvements!

* TTI improvements for Team-Managed Projects' Backlogs:

Experience

TTI Improvement

Opening a backlog 51% faster
Seeing results from quick filters on the backlog 50% faster
Opening the embedded (side panel or modal) issue view in the backlog 34% faster

* TTI improvements for Team-Managed Projects' Boards:

Experience

TTI Improvement

Opening a board 35% faster
Seeing results from quick filters on the board 50% faster
Opening the embedded (side panel or modal) issue view in the board 30% faster
Creating issues inline on the board 50% faster

* TTI improvements for Team-Managed Projects' Roadmaps:

Experience

TTI Improvement

Opening a roadmap

44% faster

We worked hard to improve performance, and we’re glad that you are already noticing the fruits of our labour!

Screen Shot 2021-09-15 at 9.52.24 AM.png

Screen Shot 2021-09-15 at 9.04.48 AM.png

We know our performance journey doesn’t end here. It remains a top priority to continue improving the customer experience, but we wanted to bring all of you along for the ride. Read more to deep dive into the specifics, and learn how we were able to achieve performance gains in a variety of areas.

Spoiler: It gets really technical from here!

Some context on our technology stack:

  • React.js, with a Redux store

  • Frontend components from Atlassian’s AtlasKit

  • Using a GraphQL API backend

Faster to load your team-managed projects' backlogs, boards and roadmaps

* Graphs show relative improvements and trends over time. The origin of the y-axis is not zero.

Team-managed backlog TTI performance:

aaa.png

Team-managed board TTI performance:

bbb.png

Team-managed roadmap TTI performance:

Screen Shot 2021-09-27 at 5.18.51 PM.png

#1: Deferring rendering hidden components for backlog and board

  • Problem: We were rendering every element on every issue, even those that were hidden during page load. This caused a linear increase in page load time as the number of issues grow.

  • Solution: We deferred rendering hidden components to upon a mouse hover over an issue, which signals an intent to interact with an issue. There is less code to download for page load, and browser has less code to parse and execute on the UI thread (or rather, the TTI thread).

Rendered during mouse hover:

Backlog

Board

Card Meatball Menu

Screen Shot 2020-07-30 at 9.04.39 AM (1).png

Card Meatball Menu

 

 

Screen Shot 2021-09-22 at 10.51.03 AM.png

Inline Edit Status, Assignee, Story Points

 

 

 

Screen Shot 2021-09-13 at 6.04.56 PM.png

Card Context Menu

Screen Shot 2021-09-22 at 10.51.15 AM.png

Inline Issue Create

 

 

 

 

 

 

Screen Shot 2021-09-23 at 10.06.45 AM.png

 

Inline Issue Create

 

Screen Shot 2020-11-06 at 3.22.49 pm.png

#2: Truncating number of issues for Jira’s Server-Side Rendering (SSR) for backlog, board and roadmap

  • Problem: We were rendering all the issues in the backlog/board/roadmap through Server-Side Rendering via Jira’s Servers for First Meaningful Paint (FMP), which caused SSR timeouts when it was not possible to do it within the timeout threshold of 3 seconds for larger backlogs/boards/roadmaps. 3 seconds were wasted for overall page load during a timeout, as it results in the skeleton being flushed and everything being restarted on the client side resulting in a 2nd data fetch.

  • Solution: We truncated the number of issues rendered for the First Meaningful Paint (FMP) through Server-Side Rendering (SSR) to 50 issues, in order to prevent SSR timeouts that added 3 seconds. The user’s browser will do the work to render FMP for the issues beyond the initial 50 issues. It keeps the render time for SSR constant with any number of issues.

Screen Shot 2021-03-11 at 8.11.17 AM.png

#3: Parallelization of database queries for fetching issues' data for backlog and board

  • Problem: When fetching the data for the lists of issues for epics, sprints, subtasks etc., they are queried sequentially from the database. Hence, they are blocking one another and adding up to a longer time to fetch the data required, which results in a longer TTI (Time to Interaction).

  • Solution: We parallelized the database queries for issue data on the backend for the backlog and board views, so that they are not blocking each other from executing.

Previous fetching strategy

Screen Shot 2020-10-28 at 9.11.42 am.png

Concurrent fetching strategy (our change)

Screen Shot 2020-10-28 at 9.13.01 am.png

#4: Virtualization of backlog and board

  • Problem: We were rendering all issues upfront, even when they are not within the viewport of the user’s browser. This caused a linear increase in render time for larger backlogs and boards, as well as impacted filtering and drag and drop TTI.

  • Solution: We used a React virtualization library that allowed us to only render issues that are within the viewport of the browser as a user scrolls vertically, plus a buffer of 10 issues outside the viewport.

Backlog Virtualization

Board Virtualization

Screen Shot 2020-09-04 at 11.15.55 AM (1).png
Screen Shot 2020-09-29 at 4.37.35 PM (1).png

Other changes with larger impact on large backlogs, boards and roadmaps:

  • Backlog, board and roadmap:
    • Loading frontend bundles async
    • Jira Query Language (JQL) backend optimizations
  • Backlog and board:
    • Skip redundant permission backend checks
    • Use QueryDSL instead of ActiveObjects framework
  • Roadmap only:
    • Switch from React class to function components
    • Eliminate extra React higher-order components

Faster to filter your issues on the backlog and board

Screen Shot 2021-09-14 at 8.59.29 AM.png

Filtering TTI for team-managed backlogs and boards also improved by 50% due to virtualization.

  • Filters work by filtering issues that are in memory.
  • Pages will still need to be re-rendered upon the filters' change, but there will be less issues that require re-rendering when filters change now due to virtualization.

Faster to view your embedded issue views on the board

We also heard your feedback about embedded (side panel or modal) issue views that you have to open during team activities like daily stand-ups and sprint planning.

Embedded Issue Views.png

There was latency when the backlog and board components tried to mount the embedded issue view, so we targeted that mount time.

  • Backlog’s issue mount time improved by 47% (resulting in overall TTI of backlog’s embedded issue open to improve by 34%)

  • Board’s issue mount time improved by 54% (resulting in overall TTI of board’s embedded issue open to improve by 30%)

The improvement is even more pronounced for larger backlogs and boards.

  • Issue mount time for bigger boards with > 200 issues dropped by ~80%!

  • We refactored the codebase to eliminate the re-rendering of the entire board whenever an interaction happens, which has downstream effects on mount time.

  • Virtualization also helped.

Screen Shot 2021-10-15 at 9.42.11 AM.png

Faster to create issues inline on the board

We also improved the Inline Issue Create TTI on the board by ~50%!

Inline Issue Create.png

The improvement is even more pronounced for bigger boards > 200 issues, where it dropped by 80% to being almost similar to small boards < 200 issues now.

  • First, we eliminated redundant API calls on the software gateway backend.
  • Next, instead of updating the entire board (fetch all issues' data on backend) when creating issue inline, we only update the issue that got created (only fetch the new issue ID on backend).

Screen Shot 2021-10-15 at 9.42.44 AM.png

Conclusion

If you’re keen to hear more about other performance improvements across wider Jira teams tackling platform experiences that impact multiple Jira products, please take a look at our blog on 7 recent performance improvements in Jira !

We’ll be continuing our focus on performance and scale over the next year so stay tuned.

Have you noticed our performance improvements? We’d like to know!

6 comments

Great writeup! Congrats on the results, and the methodology. My team did similar improvements(except virtualisation) few years ago in self hosted Jira Software (link to my talk about this).

 

Question on #4: Virtualisation

Virtualisation solves many problems, and can be beneficial, but I wonder if you considered leveraging native browser features like `content-visibility: auto`? It is supposed to bring similar benefits, at lower cost of implementation and maintenance for websites.

Like Ivan Teong likes this
edwin vasquez Community Leader Oct 28, 2021

Great improvements! Great job to you and your team!

Like Ivan Teong likes this

@Grzegorz Tańczyk _Appfire_ Great to know that you've attempted similar-ish initiatives!

Re: your question `content-visibility: auto`, we did attempt it with Chrome v85 which has that native feature, but ultimately, our conclusion was that virtualization is a better approach:

  • UX risk: content-visibility isn’t really feasible for objects that don’t have a fixed height. The card heights for team-managed projects change according to the content. Card will jump/jank when coming on/off screen, because of the size changes.

  • Technical risk: Adding JavaScript to a CSS solution will be required to store the value of card heights to prevent the above jump/jank, which is not ideal due to the added complexity in the codebase.

  • Impact: Browser rendering time is mainly driven by JavaScript, so the ROI (return on investment) for a CSS solution is not worth it.

Hence, it is better to just write a custom virtual/recycled list implementation (virtualization).

Our project has experienced serious lag since reaching the 500+ ticket level.  We adopted the team-managed platform 3 months ago because it better suited our needs but now wondering if we should have adopted the company-based version instead- which does not seem to have performance issues with larger-sized projects.  Any thoughts/suggestions?

@Stéphane Leduc When looking at the performance of backlogs and boards of 300-500 issues as a specific cohort for comparison:

  • Team-managed backlogs have around the same load time as company-managed.
  • Team-managed boards are around 28% slower than company-managed boards.

We have improved the performance of the team-managed board view of 300-500 issues by 61% between July 2020 and October 2021, and will continue to work on initiatives such as board caching to improve the performance of larger boards.

If you're willing to bear with us in the meantime as we focus on performance, we will be working hard to improve it. Otherwise, you can switch to company-managed if it is not possible for you to work with it day-to-day. Sorry for the inconvenience caused.

Like Pedro Yamada likes this

Thank you for the quick response (and effort) Ivan.

Like Ivan Teong likes this

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Jira

Online AMA this week: Your project management questions answered by Jira Design Lead James Rotanson

We know that great teams require amazing project management chops. It's no surprise that great teams who use Jira have strong project managers, effective workflows, and secrets that bring planning ...

192 views 1 6
Read article

Atlassian Community Events