Making Slack Faster By Being Lazy: Part 2
Article Summary
Slack's desktop client was grinding to a halt as teams scaled. The culprit? An over-reliance on browser LocalStorage that seemed smart at first.
Scott Schiller from Slack Engineering breaks down how refactoring their desktop client's data fetching strategy exposed critical caching pitfalls. This is part 2 of their journey from eager loading to lazy loading message history.
Key Takeaways
- LocalStorage's synchronous I/O caused multi-second UI freezes on the main thread
- Network requests often proved faster than retrieving data from LocalStorage cache
- lz-string compression via web workers added CPU costs and garbage collection pauses
- Lazy loading message history revealed bugs in auto-scroll, unread markers, and display logic
- Solution: Remove message history from LocalStorage entirely, keep only ephemeral UI state
Critical Insight
Slack eliminated message history from LocalStorage and embraced lazy loading, proving that less aggressive caching can actually improve performance at scale.