How Slack Makes Slack Faster By Being Lazy: Part 2
Original post Making Slack Faster By Being Lazy: Part 2
Article Summary
Scott Schiller from Slack reveals how their desktop client refactor exposed a painful truth: aggressive caching and LocalStorage were making the app slower, not faster.
This is part 2 of Slack's engineering deep-dive into refactoring their desktop client's message fetching architecture. The team shares hard-won lessons about what went wrong when they tried to cache everything, the hidden costs of LocalStorage, and how lazy-loading transformed their approach to client performance.
Key Takeaways
- LocalStorage I/O blocked the main thread for several seconds during load
- Compression via lz-string and web workers added complexity without solving core issues
- Dropping message history from LocalStorage eliminated significant performance bottlenecks
- Lazy-loading channels meant handling incomplete data models throughout the UI
- Mobile constraints drove API efficiency improvements that desktop clients later adopted
Slack's team learned that avoiding LocalStorage entirely and lazy-loading data beats aggressive caching every time, even when it requires more upfront engineering work.
Continue reading
Deloitte
Mar 16, 2026
More from Slack
Inside Slack: Overcoming Challenges to Craft a Seamless Mobile App
Slack
Sep 12, 2023
Also on iOS
Engineering Real-Time Mobile Personalization Across iOS, Android, React Native, and Flutter
Salesforce
Sep 11, 2026
This page summarizes “Making Slack Faster By Being Lazy: Part 2” by Slack, published Jun 29, 2020. All credit for the original work goes to the authors.
