Sprintly

PERFORMANCE REFACTOR

We helped Sprintly launch a dramatic increase in front-end performance. We are built on Backbone.js and, over time, our rendering times have slowed down. Using some of the latest technologies found in Chrome, we finely tuned the Sprintly front-end. Quick Left was able to leverage technical expertise to build great results for Sprintly’s application.

Sprintly

"We’ve noticed palpable difference in performance and have been hearing the same from some of our customers already. We stress-tested Sprint.ly over the last couple of days a few times with multiple people searching/browsing/editing all at once. It went really smoothly - thanks for the great product updates!"

Rob Munro, CEO of Idibon

Sprintly

Better Tooling

The new Flame Chart view for CPU profiling made it easy to spot areas in our app that needed a dose of micro-optimizations. Given that many of the performance enhancements focused on customers with the most items, relatively small improvements can have a big impact on the intensive parts of the rendering stack: smooth scrolling/lazy-loading, resorting, switching between the dashboard and the items view.

Sprintly

Performance Booster

JavaScript and browser rendering “frame budget” were a focus of our refactor. Speed improvements came from recognizing when the Backbone application was attempting to overload during a given frame. Actions that trigger rendering/repainting, requesting data from local cache or the API, or even binding events to the DOM are the most common culprits when trying to improve frame-rate.

Sprintly

Monitoring and Measurement

We were able to consistently and accurate measure performance characteristics, which greatly influenced how we went about re-writing how item columns and item cards were being rendered to address these framerate, load time and rendering concerns. Following the performance release, average rendering time was decreased on average of 30%, with an 11% decrease in 90th percentile rendering time and a 6% decrease on the median response. We’re going to continue measuring and quantifying frontend performance—and still have more speed improvements in the works.

Sprintly

Rendering Data Sets

Item column views do a lot of heavy lifting in Sprintly. We sped them up primarily by optimizing how columns rendered. We then cached the individual cards that go into columns--rather than re-rendering column content when changes happen. Cards are then inserted, removed and re-rendered individually, leading to better overall performance everywhere item columns are in play.

Sprintly

Performance Analysis

Lethargic performance in large item-sets, or columns, proved to be the culprit of much of the rendering slow-down in the application. Item columns consist as containers for groups of item cards (stories, tasks, items and defects). Through testing and analysis of the cause, and not the symptom, we were able to accurately and effectively resolve performance issues across the board.

Sprintly

Like what you see? Then let's get started on your project!

Contact Us