How Discord Boosts Performance With Code-Splitting
#20: Read Now - Fantastic Frontend Engineering (3 minutes)
Get my system design playbook for FREE on newsletter signup:
This post outlines how code-splitting works. If you want to learn more, scroll to the bottom and find the references.
Share this post & I'll send you some rewards for the referrals.
Discord is a voice and text chat app with 10 million+ daily active users.
This post outlines how Discord code splits to improve performance.
Software Bloat
A software bloat is a code that makes the app slower, consumes extra memory, or needs more CPU cycles. A new feature is a software bloat if it has similar problems.
The app is susceptible to feature creep if it serves a diverse marketplace. Yet most users will likely need only a subset of the features. So unused features can be considered bloat.
A simple approach to reduce bloat is through running split tests to identify the most used features. And then removing the unused features.
But the essential complexity of the app is unavoidable. So code split is a potential technique to reduce bloat. The Discord app code splits to maintain performance while adding new features.
Code Split
The technique of loading code only when needed is called code split.
The Discord app needs code and styles to run. But it takes memory and CPU cycles to parse them. So the server code splits and sends only minimal code and styles needed to run the Discord app. Put another way, code split makes the Discord app faster and consumes less memory.
The Discord app gets only the necessary JavaScript, CSS, fonts, and images on start. And the server sends the remaining assets as the user navigates through the Discord app.
There are many ways to code split. A good place to start code split is at the app route level. The routes can be bundled into separate chunks using an automation tool like Webpack.
Some web assets that can be code split are:
Stylesheets
Translations
Fonts
The code split chunks get lazy-loaded for high performance. The Discord app receives only the relevant translation file through code split. And it allowed them to add many translation files without having a performance impact.
Some benefits of code split are:
Improved performance on mobile clients in an unreliable network
Reduced content delivery network (CDN) costs
Improved search engine optimization (SEO)
The CDN gets charged based on the bandwidth and number of HTTP requests. So it is important to keep a balance between the number of requests and bandwidth consumed.
Yet code split has the following drawbacks:
Overhead due to an increased number of requests
Degraded latency due to many requests
Code splitting via HTTP streaming is a potential solution to avoid overhead and improve latency.
The key takeaway is code splitting allows adding new features without bloating the app.
Consider subscribing to get simplified case studies delivered straight to your inbox:
Thank you for supporting this newsletter. Consider sharing this post with your friends and get rewards.
References
https://discord.com/blog/how-discord-maintains-performance-while-adding-features
https://userguiding.com/blog/feature-bloat
https://www.freecodecamp.org/news/code-splitting-with-higher-order-components-4ac8f094b059/
https://crystallize.com/blog/frontend-performance-optimization-react-code-splitting
Interesting read, NK!
For small apps this may seem overkill. E.g. some back-office that a few internal people use
But for larger apps at scale, growing more means degrading user experience. I found that Amazon really takes it into account: I have had to create investigate increases of sub millisecond latency in the retail Search page to ask leadership support on launching a feature. I imagine Discord also found the same, people would leave if they can't access information fast
Some interesting read about it: https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales
What every happened to modularization? If you spend half a day thinking about how a software project is going to grow, it should be pretty clear, pretty quickly that the only way to have a sliver of a chance to stay ahead of the impending success disaster is to PLAN for it. Spend a bit of of effort understanding where the ticking bombs lie. Finally, what ever happened to the understanding that Programming is not “coding” and it is not done with an IDE, or anything else with a keyboard. Rome was not built by “running fast to get away from things that are breaking.” But don’t mind me - I’m a Geezer, and I Geeze professionally.