Web Bundle Sizes – Are React and Tailwind Really Over the Top?
Break down bundle sizes and real world applications
One of the complaints I often hear regarding the usage of React and Tailwind is the sheer size of the bundle you create when you start using those, especially in combination :)
For nearly 18 years, I have worked with early JavaScript-based applications or WebApps, mainly in the B2B sector. Web apps were always treated differently than the classical website. The traits of the website were to be fast-loading and SEO optimized, while WebApps served the tool's purpose. People were more forgiving regarding loading times, but it had limits, and we often met those back then.
Let me show you a very negative example:
In our legacy systems, roughly 5–15MB of JavaScript was transferred to the browser in a single go. There wasn’t any rendering going on, before all resources were downloaded and unpacked.
Additionally, around 1–2MB of CSS is needed. Both were mostly minified but not gzipped due to a limitation in the hosting environment.
I mean vanilla JavaScript and CSS applications to clearly understand what I am discussing when speaking of legacy systems.
One of the biggest complaints by users was, of course, the performance. The following images show a negative example, leading to a legacy migration to a newer stack based on React and Tailwind.
That led to the development of a newer version of the Frontend part of the legacy application, which significantly reduced the necessary JavaScript and CSS loads.
NextJS built-in features and PurgeCSS with Tailwind helped a lot out of the box.
But still, there was a way to get the user experience where it needed to be.
Fast and reliable WebApps NextJS, React & Tailwind
We released the first version of cloudbar, a business platform solution based on the mentioned stack, a month ago. It’s basically a result of the combined experience over the last decades.
🔴 So far, we haven’t focused on optimizing performance and accessibility. Especially performance would include the newsletter topic “bundle sizes” as well.
Several pages aren’t performing as well as the screenshot, which shall be improved. We will start to monitor and improve and will share our results.
The following steps are on the TODO list:
Monitor and Optimize Runtime Performance (Sentry.io)
Bundle Analysis & Minification and Compression
Tree Shaking
Code Splitting & Lazy Loading
Optimize Tailwind CSS
Image Optimization
Static Site Generation (SSG) and Incremental Static Regeneration (ISR)
Service Worker and PWA Optimizations
Accessibility Improvements
Comparing vs. a modern “Vanilla Approach”
Join me on this optimization journey.
Cloudbar’s Frontend is based on NextJS, Tailwind, and React, and I want to create a content track especially for the part to optimize the WebApp, which will include performance updates of the API-side as well (NestJS, PostgreSQL, Redis, GraphQL, Prisma, BullMQ).
In the coming weeks, you can expect several newsletter issues, podcasts, and a live stream about this.
The goal is to get the application optimized and go deeply into the following questions:
Was the tech stack a decent pick?
Performance:
How does the current performance of our application compare to benchmarks and user expectations?
Are significant performance bottlenecks directly attributable to our choice of Next.js, React, and Tailwind CSS?
What improvements in load times, responsiveness, and overall user experience have we observed with the new stack compared to our legacy systems?
Have we made mistakes in the early stages that we can avoid in the future?
Initial Setup and Configuration:
Did we optimize the initial setup and configuration of our tools sufficiently?
Were there any oversights in configuring our build tools, package management, or deployment pipelines that caused issues later?
Frontend Development:
Would it have been better to go with vanilla technologies instead of a complex stack?
Did we adhere to best practices in structuring our codebase and writing frontend code?
Were any architectural decisions made early on that led to technical debt or hindered scalability?
How effectively did we implement lazy loading, code splitting, and other performance optimization techniques?
How can we improve our front-end development workflow to incorporate performance monitoring and optimization better?
Were there gaps in our testing coverage that led to bugs and regressions in production?
Conclusion
The complexity of modern frontend development, epitomized by tools like React and Tailwind CSS, is a double-edged sword. While they can introduce additional overhead, their development speed, maintainability, performance, and scalability benefits often outweigh the drawbacks.
By carefully managing and optimizing bundle sizes, businesses can leverage these powerful tools to build sophisticated, performant, scalable web applications that meet modern user expectations; this is what I can prove to be true.
Ultimately, the question isn't whether these tools are "over the top" but how effectively we can balance complexity with performance. Properly configured, Next.js and Tailwind CSS offer a robust foundation for building high-quality web applications without compromising efficiency.
Adrian