Closed mikhael28 closed 1 year ago
Hi @mikhael28 - One of our areas of focus is reducing bundle size for this year. We are doing exploratory work at the point to evaluate where our biggest areas of opportunity are. Thank you for this feedback, it is extremely helpful (and timely!)
I hope you don't think I sound like an a**hole, I am just desperate to lower my bundle size. When you identify a roadmap of sorts, please let me know. Otherwise, I will be forced to migrate to alternate solutions in the next 2 months.
@mikhael28 - that is not at all the impression we have gotten, we understand your frustration, and we will provide an update on this issue once we have a roadmap. Would you be available for a call with our engineering team, we need as much feedback as we can to prioritize the right areas. If so, please email me at awshaban@amazon.com, and I can coordinate finding a timeslot for us to speak.
Sounds great, I will send a quick email to set up a time slot.
To give a simple example for my scenario. I need to determine on all pages on my website if a user is logged in or not (to show a logout button). Importing Auth to call currentAuthenticatedUser to do this adds 333.82kb to my bundle size for all pages. While adding Hub to listen to auth events only adds 6kb. So Hub is good, but Auth is not. I am using Angular with lazy module loading. To optimize bundle sizes in pages where no amplify status is needed except login status, I might have to persist login status in a cookie, and save to that cookie in login pages that import amplify, and have pages that don't need amplify read this cookie to get login status. That is work I'd like to avoid.
@hisham - thank you for the feedback! We will explore this further! FYI @chrisbonifacio
@abdallahshaban557 I just did a fresh install on the repo & branch that this issue was initially opened on.
With the latest versions of all @aws-amplify
packages, the minified api-rest (the component I'd been focusing on) is now exactly the size that I was expecting - ~9 kb instead of ~52kb.
The build & file structure issues seem to have resolved. WebPack is no longer duplicating several of the core scripts as node_modules like it was before, and the overall minified @aws-amplify bundle size has gone down 16%.
It still feels like the overall Amazon profile in the bundle is a little high (close to 30% total of tree-shaken node_modules when there are 40+ other dependencies) but since we've gotten the API module down from ~100kb to ~9kb I'm hopeful some closer attention on our end to the other areas will yield similar results. Plus there are plenty of other areas to focus on outside of node_modules for reducing bundle size.
I'm not sure if some config changes were made to the core build scripts or if it's simply an issue of an error in a dependency being fixed in a newer version, but either way - thank you!
@jayeclark - it is great to hear that our latest changes have given you a substantial reduction in the bundle size. For the additional Amazon profile bundle issue you mentioned, can I get a bit more feedback on where some of your modules appear larger than you would expect?
Sure @abdallahshaban557 , happy to comment here as I go through them. My next focus is going to be on exploring the source code of the Storage module.
The ParetOS project uses a single method from that Amplify Storage module, to upload photos to an S3 bucket. The module alone is 37kb in the build source map. Right off the bat it seems unusual for a single API call to require 37kb of code (plus whatever additional modules are required from Amplify Core & AWS-SDK).
On a personal project I’ve been working on recently (https://github.com/jayeclark/my-dev-interview/), I use two S3 methods (put & delete) directly using the AWS SDK instead of via the Amplify package. On that build, I haven’t even been able to find the S3-related methods in the source map (I could be wrong, since it’s a different stack & source map explorer, but not being able to find them in the map seems to indicate to me that they’re trivial in size after tree-shaking.)
Objectively 37kb isn’t very large… but 3kb would be way better. And extra 34kb across three modules is 100kb… add that up across the 70+ dependencies and sub-dependencies in the repo and it’s easily 50% of the node_modules portion of the bundle. (My personal mission is to get the bundle under 1MB, so I’m being frugal with module size wherever I can be!)
Hi @jayeclark ! Appreciate the thorough feedback! I'm gonna take this back to the team to figure out if there is something we can do here. I'd appreciate you providing me with any feedback you find as you go through the rest of the modules!
Hello everybody, our team has been focusing on reducing the bundle size of the Amplify library, and starting v 5.2.5, we have been able to reduce the bundle size for the below use cases:
* Amplify core + Auth category: 73kB → 54kB (-26%)
* Amplify core + Analytics category: 56kB → 30kB (-46%)
This is only the first step in our bundle size reduction efforts. In our next major version of Amplify JavaScript, we are going to provide better mechanisms for tree-shaking that will substantially reduce the bundle size. Stay tuned - we will provide updates on this issue when we have expected timelines mapped out.
Please try out the newest version of Amplify, and let us know if you are seeing the improvements I've mentioned! Your feedback is essential to helping us improve our library!
Whoah! Rock on, I will try it out - ty!
I just updated, and our angular app raw build size was reduced by 2kb. Not much but I'll take it :). We use auth + analytics + storage.
Hi @hisham - that seems odd and much smaller than we would expect in terms of improvements to the bundle size. Can you please share your package.json file here with us?
"dependencies": {
"@angular/animations": "^15.2.4",
"@angular/cdk": "^15.2.4",
"@angular/common": "^15.2.4",
"@angular/compiler": "^15.2.4",
"@angular/core": "^15.2.4",
"@angular/elements": "^15.2.4",
"@angular/forms": "^15.2.4",
"@angular/material": "^15.2.4",
"@angular/platform-browser": "^15.2.4",
"@angular/platform-browser-dynamic": "^15.2.4",
"@angular/router": "^15.2.4",
"@ng-select/ng-option-highlight": "0.0.7",
"@ng-select/ng-select": "^10.0.3",
"@ngneat/until-destroy": "^9.2.2",
"@scullyio/init": "^2.1.41",
"@scullyio/ng-lib": "^2.1.41",
"@scullyio/scully": "^2.1.41",
"@scullyio/scully-plugin-puppeteer": "^2.1.41",
"@sentry/angular-ivy": "^7.45.0",
"@sentry/tracing": "^7.45.0",
"angular-cc-library": "^3.1.0",
"aws-amplify": "^5.3.3",
"document-register-element": "^1.7.2",
"file-saver": "^2.0.5",
"fractional": "^1.0.0",
"json_encode": "^0.1.0",
"libphonenumber-js": "^1.10.14",
"lodash-es": "^4.17.15",
"mdn-polyfills": "^5.20.0",
"ng2-pdf-viewer": "^9.1.3",
"ngx-webcam": "^0.4.1",
"object.fromentries": "^2.0.5",
"pluralize": "^8.0.0",
"rxjs": "~7.8.0",
"s-ago": "^2.2.0",
"tslib": "^2.3.0",
"uuid": "^8.3.1",
"vivus": "^0.4.6",
"yaml": "^1.10.2",
"zone.js": "~0.11.4"
}
Hey @hisham would you mind trying cleaning out node_modules
and re-installing your dependencies? We're still seeing smaller bundle sizes when we try to reproduce this. Any bundle analysis info you can provide (e.g. from utilities like webpack-bundle-analyzer
) would be helpful as well!
rm -rf node_modules
yarn/npm install
Hi @jimblanc, ok so upon closer examination, the bundle size reduction of 2kb I reported was only in the main.
Looking specifically at the biggest aws-amplify bundles, one is graphql stuff (@aws-amplify/api-graphql) and the other is auth. The graphql bundle went from 802.73kb to 801.85kb. The auth one went from 341.65kb to 212.89.
Below is screenshot of analyzer. Left is 5.3.3. Right is 5.0.22. Project-specific stuff is redacted.
Hi, @hisham
We just launched further bundle size reduction change to the Storage
category. It should result in more reduction for your app. Can you try the latest versionaws-amplify@5.3.4
and see if it shows better results?
Hi @AllanZhengYP - yes the module where we use storage went down from 476.07kb parsed code to 258.19kb. Great work, thanks! :). Now GraphQl + Auth are the biggest amplify bundles left, especially graphql...
Hello everyone, We have made some additional changes to reduce the bundle size which include reduction to the Storage category as part of aws-amplify@5.3.4
. Below are our updated reduction numbers for the gzip bundle size.
The results are generated using size-limit tool v8.2.6 and bundler webpack 5.88.0.
Please let us know if you are seeing these reductions in your apps.
Make sure to delete your node_modules folder and then re-install your dependencies to validate the bundle size reduction.
@abdallahshaban557 wow, that is great work!
With the release of the latest major version of Amplify (aws-amplify@>6), this issue should now be resolved! Please refer to our release announcement, migration guide, and documentation for more information.
@cwomack great job team! Thank you so much for listening to your users.
Is this related to a new or existing framework?
React
Is this related to a new or existing API?
Authentication, Storage, Internationalization
Is this related to another service?
No response
Describe the feature you'd like to request
I am wondering if we can get an update (in April, 2022) of Amplify's roadmap towards improving the bundle size of the aws-amplify and @aws-amplify/core or api or storage or auth libraries. The fact of the matter, is that I love using AWS for many things, and Amplify is one of them. But for the love of God, I cannot figure out why the bundle size is so large
It's getting to the point where Amplify is the worst offender in my project, literally generating 50% of the bundle size to handle Auth, S3 storage and Internationalization.
Now - I can migrate away from these services. It will be unfortunate, but I can send a blob to a Node/Python API, and upload to S3. I can send a request to a REST API to authenticate and send back an authorization token for API requests. I can find an I18n alternative. But I don't want to. But the crazy bundle size is making me consider it, because sending HTTP requests takes like ZERO kb. An I18n package that works extra nicely with React will take a bit of space, but not anywhere close to 900kb.
Is there some tree shaking or alternative strategy that I'm missing? Because I tried just using the
aws-amplify
library and noticed that the bundle sizes were essentially identical/a little bit higher. So, your tree shaking game seems fine - but it's all the other cruft that is dragging everything else down.As a developer who cares and is focused on performance, I am worried Amplify does not share my concerns.
Describe the solution you'd like
Dynamic imports of some sort. Why am I importing React Native code to my react.js project? I saw that within 5 seconds of inspecting the node_module, I'm sure there are more.
Why are we importing a bunch of random stuff? I just... don't understand, and I haven't seen any improvements on this in 2 years. And, if you google 'aws amplify bundle size' you will see so many posts talking about this - and I haven't seen anything from the team in 2022 addressing this.
Describe alternatives you've considered
Literally just creating a Node API and receiving HTTP requests to handle all the use cases mentioned above. Finding any I18 library. this will reduce my bundle size on the front end by 80% easily.
Additional context
No response
Is this something that you'd be interested in working on?