You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm a senior FED consultant, I get added to different companies' boards, and I've noticed sluggish performance on some of the boards, those which have really long lists, and they can't archive them, either:
Just a really long backlog list
Imported a huge list of tasks from Jira and now sits in ToDo/Backlog
So I've decided to profile some performance with Chrome DevTools...
Conclusions:
When testing in Incognito or fresh browser, Trello is quite fast, even on mobile :-)
When using extensions like Scrum for Trello (very popular), performance goes to the toilet
At least 1 reason:
Scrum for Trello goes through all cards in all lists, parses their title and adds a badge on it if needed.
Since there's a huge list of cards (mostly invisible, but still in the DOM), this is super heavy.
They also do this every few seconds.
So I have a suggestion:
Implement a Virtual List
A list should keep in the DOM only the visible cards, plus some buffer before and after.
When scrolling, the next buffer of cards gets added to the DOM based on the scroll position and previous buffers are removed from the DOM.
This allows keeping the DOM light and when used correctly, doesn't sacrifice scrolling experience, even makes it better.
I've used this technique on several projects (Angular/React) and it proved to be very useful.
What can we do?
I was thinking maybe we can go over cards that are only visible (using jQuery :visible Selector).
Notes
I understand that if not all cards are in the DOM, we won't see correct number of points on the list level, and maybe other features will suffer as well.
But, the performance issue is really bad.
Attaching a short video showing how bad it is.
Side note
I wanted to say thanks for the hard work you guys put into this project, it's truly a valuable extension
for Trello.
Probably something like not having an infinite loop, and instead having smart action listeners to trigger the recalc. I'm working on something similar on a fork branch. Will update here if anything good comes up. 😃
Here's a ticket I opened on Trello support:
Hi Guys,
I'm a senior FED consultant, I get added to different companies' boards, and I've noticed sluggish performance on some of the boards, those which have really long lists, and they can't archive them, either:
So I've decided to profile some performance with Chrome DevTools...
Conclusions:
At least 1 reason:
Scrum for Trello goes through all cards in all lists, parses their title and adds a badge on it if needed.
Since there's a huge list of cards (mostly invisible, but still in the DOM), this is super heavy.
They also do this every few seconds.
So I have a suggestion:
Implement a Virtual List
A list should keep in the DOM only the visible cards, plus some buffer before and after.
When scrolling, the next buffer of cards gets added to the DOM based on the scroll position and previous buffers are removed from the DOM.
This allows keeping the DOM light and when used correctly, doesn't sacrifice scrolling experience, even makes it better.
In the wild:
https://material.angularjs.org/latest/demo/virtualRepeat
http://bvaughn.github.io/react-virtualized/#/components/List
https://github.com/sergi/virtual-list
I've used this technique on several projects (Angular/React) and it proved to be very useful.
What can we do?
I was thinking maybe we can go over cards that are only visible (using jQuery :visible Selector).
Notes
I understand that if not all cards are in the DOM, we won't see correct number of points on the list level, and maybe other features will suffer as well.
But, the performance issue is really bad.
Attaching a short video showing how bad it is.
Side note
I wanted to say thanks for the hard work you guys put into this project, it's truly a valuable extension
for Trello.
Cheers.
Trello-with-Scrum.mp4.zip
The text was updated successfully, but these errors were encountered: