2 ms·

I highly recommend front end devs add a step to their CI pipeline which extracts bundle size information from the build and includes it in pull requests, or som

I highly recommend front end devs add a step to their CI pipeline which extracts bundle size information from the build and includes it in pull requests, or something similar. It's great to have eyes on how heavy your bundle is, and keeping an eye on how it changes over time (easy to add as part of the pipeline) can help the team understand when things are trending the right way or not. It's usually a call you need to make based on what you're shipping, but at the very least, it'll ensure you don't blow up your performance because something slipped by. Finally, looking at the components of your bundle if you haven't already is well worth it. Like the people over at Linen noticed, they were shipping a ton of icons they were never using. This is happening all over the internet, and it's a real drag on the network, parsing, and executing phases in a browser. If you benchmark, you'll see significant differences when you trim things back. If you have customers using lower powered devices, this is even more crucial.

tommoor 4y ago
I recommend RelativeCI for this, have used them for several projects – https://www.relative-ci.com https://www.relative-ci.com You can get a feel for what it looks like here on an active project here: https://app.relative-ci.com/projects/TMqufq6bi8qzsOjEHSWY https://app.relative-ci.com/projects/TMqufq6bi8qzsOjEHSWY – but mostly you end up using the status pushed to GitHub PR's
- steve_adams_86 4y ago
  This is really sleek, thanks for linking it! I’ve always rigged these up myself, and this is quite a bit nicer.
vio 4y ago
RelativeCI founder & bundle-stats maintainer here, thank you for the mention, Tom! I totally agree with the need to run bundle analysis checks often for medium/large-size applications. It will help to notice the issues when they are introduced, otherwise, the optimization task becomes really challenging. Actually, I built bundle-stats & RelativeCI after spending weeks on optimization tasks running hundreds of slow builds, staring at multiple webpack-bundle-analyzer reports, and using google spreadsheets to track asset/module changes. One thing I noticed in the last 2-3 years is that we got better as an industry at managing the bundle size bloat: - improved libraries - new light versions for popular libraries - new and improved bundlers - new and improved meta frameworks - better tooling & more resources However, the web applications we are building now are larger and more complex than before, with hundreds of bundled libraries and tens of thousands of modules. The increased complexity has made the bundle analyzing and optimizing even more complicated. One of the most common feedback I received was to better integrate the bundle analysis and insights during the code review phase and allow developers to detect and fix the issues as soon as they are introduced: - [done] Pull request comment with bundle analysis insights & summary (https://relative-ci.com/documentation/setup/configure/integrations/github-pull-request https://relative-ci.com/documentation/setup/configure/integr...) - [in progress] pending/approve/reject review flow based on custom rules

tommoor 4y ago

I recommend RelativeCI for this, have used them for several projects – https://www.relative-ci.com https://www.relative-ci.com You can get a feel for what it looks like here on an active project here: https://app.relative-ci.com/projects/TMqufq6bi8qzsOjEHSWY https://app.relative-ci.com/projects/TMqufq6bi8qzsOjEHSWY – but mostly you end up using the status pushed to GitHub PR's

steve_adams_86 4y ago
This is really sleek, thanks for linking it! I’ve always rigged these up myself, and this is quite a bit nicer.

vio 4y ago

RelativeCI founder & bundle-stats maintainer here, thank you for the mention, Tom! I totally agree with the need to run bundle analysis checks often for medium/large-size applications. It will help to notice the issues when they are introduced, otherwise, the optimization task becomes really challenging. Actually, I built bundle-stats & RelativeCI after spending weeks on optimization tasks running hundreds of slow builds, staring at multiple webpack-bundle-analyzer reports, and using google spreadsheets to track asset/module changes. One thing I noticed in the last 2-3 years is that we got better as an industry at managing the bundle size bloat: - improved libraries - new light versions for popular libraries - new and improved bundlers - new and improved meta frameworks - better tooling & more resources However, the web applications we are building now are larger and more complex than before, with hundreds of bundled libraries and tens of thousands of modules. The increased complexity has made the bundle analyzing and optimizing even more complicated. One of the most common feedback I received was to better integrate the bundle analysis and insights during the code review phase and allow developers to detect and fix the issues as soon as they are introduced: - [done] Pull request comment with bundle analysis insights & summary (https://relative-ci.com/documentation/setup/configure/integrations/github-pull-request https://relative-ci.com/documentation/setup/configure/integr...) - [in progress] pending/approve/reject review flow based on custom rules