-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize bundle chunks #784
Conversation
Bundle ReportChanges will decrease total bundle size by 12.8kB (-0.13%) ⬇️. This is within the configured threshold ✅ Detailed changes
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #784 +/- ##
==========================================
+ Coverage 83.41% 83.45% +0.03%
==========================================
Files 240 242 +2
Lines 4752 4763 +11
Branches 1275 1265 -10
==========================================
+ Hits 3964 3975 +11
- Misses 754 755 +1
+ Partials 34 33 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
73ca5b4
to
9a58271
Compare
9ed58b1
to
71a688b
Compare
a0f2792
to
0cd6fcf
Compare
We can't properly extract lodash into a separate chunk because *many* modules in formio import lodash as a whole rather than just the modules they need, breaking tree shaking. It also turns out (via 'npx vite-bundle-visualizer') that formio itself is quite chonky and for the initial SDK load/routing we don't need Formio yet, so we can defer loading that with a dynamic import. This dynamic import ensures the formio-init code ends up in its own chunk.
Couldn't find any references anymore that use(d) this function, and since it imports Formio utils (which loads lodash too), it's better to remove it to avoid bundling lodash in the main bundle.
Moving this away from the formio scope/namespace allows us to use it in the rest of the non-formio related code without pulling in all of lodash into the main bundle, allowing us to defer loading and have a faster time-to-first-interact for end-users. The utility itself is of questionnable importance, but that's a refactor for another day.
More dead code that relied on Formio utils which caused our bundles to be larger than necessary. The backend has been updated a long time ago to provide the summary data to display, rather than having to do this client-side. The benefit is that no longer load anything from formio outside of the formio-init chunk, which should result in better perceived performance for end users.
Our React map component is now dynamically loaded, resulting in a separate chunk of Javascript code that only gets loaded if/when map components are used in the form, saving quite a bit of bytes for other forms.
0cd6fcf
to
c9abd72
Compare
Most forms won't need this code, so we can lazy load it instead.
c9abd72
to
4bc9dc4
Compare
Closes #76 - probably wise to wait until #782 is merged.
Some nice wins - our main chunk has now gone from 3.4MB -> 0.98MB. We have a 2MB chunk for everything Formio related, and then separate chunks for the appointments route (a modest 25kB) and the leaflet map stuff (360kB).
The generated assets:
Bundle analysis with
npx vite-bundle-visualizer
:Tested with a production build in the backend with our e2e test suite and manual testing of course.