Reduce the bundle size

[baharev]

I have a small React web app, and the bundle size (optimized build) is ca. 2.0 MB, most of which comes from amplify and aws-sdk (at least ca. 1.7 MB as far as I can tell). As a result, loading the application on slow networks and/or older devices is unacceptably slow.

I looked around in the bundle js file, and in the corresponding source map (ca. 9MB) to figure out why, and I am under the impression that almost everything from the aws-sdk ends up in the bundle:

• Various AWS services that I do not use in my app: DynamoDB, VPC, Redshift, Polly, Lex, Rekognition, CodeCommit, Gaming stuff (as far as I can tell it is this product: https://aws.amazon.com/gaming/), EC2 stuff (EC2, spotfleet, auto scaling group), etc.
• French and Spanish text (for the sign in / sign up, etc), although I did not ask for it (i18n).
• MFA stuff which I explicitly disabled.
• I disabled analytics and messaging (which I currently do not need) but it did not make an impact on the bundle size. Mobile analytics still leaks into the bundle.
• The closed issue AWS SDK use #25 also asked for smaller bundle size, but as far as I can tell, he did not get it.

I could go on, but I think you see the problem. I get this bundle with create-react-app, and using the default settings.

How can I reduce the bundle size?

How can I put only that code into the bundle that I actually need? Is there a way to automate this process?

Is there a way to do code splitting to make the initial load of the application faster?

[jonsmirl]

Currently there are several megabytes of unneeded junk getting brought in due to the inclusion of the full aws-sdk. My hope is that when things settle down we can stop including the general purpose aws-sdk module which contains 10,000 APIs and instead switch over to one specifically generated to match the needs of this project.

This tool will make much smaller SDK packages.
https://sdk.amazonaws.com/builder/js/

But even that tool could be significantly improved by letting you only pick the functions you need instead of every function in the service.

These pointless, multi-megabyte SDKs are an enduring mess when using AWS. In two of our projects we have stopped using the AWS SDKs and instead build the function calls in our own code. The AWS CPP SDK is the worst. Due to it's use of virtual functions there is no way to shrink it. That's the one we stopped using.

If Amazon would put their SDKs up on a free CDN URL like Google and FB do I think we'd see the SDK size shrink very quickly. Instead us customers have to deal with the bills from these bloated downloads.

[baharev]

@jonsmirl Thanks for your feedback! My primary concern isn't the bill but the very poor user experience. As I said, loading the application on slow networks and/or older devices is unacceptably slow.

Huge bundle sizes are bad for hobbyists like me, and for users with high traffic (where I do see the bill as a problem).

[jonsmirl]

Is this the problem? Check out the mobile analytics SDK.
https://github.com/aws/aws-sdk-mobile-analytics-js/blob/master/lib/MobileAnalyticsClient.js

Top of the file... isn't it including the entire SDK? Shouldn't that be require('aws-sdk/global') instead?

var AWS = require('aws-sdk');
var AMA = global.AMA;
AMA.Storage = require('./StorageClients/LocalStorage.js');
AMA.StorageKeys = require('./StorageClients/StorageKeys.js');
AMA.Util = require('./MobileAnalyticsUtilities.js');

Is anyone even maintaining this Mobile Analytics SDK?
The home page hasn't been updated in two years......

Amazon Mobile Analytics SDK for JavaScript

Developer Preview: We welcome developer feedback on this project. You can reach us by creating an issue on the GitHub repository or posting to the Amazon Mobile Analytics forums:

https://github.com/aws/aws-sdk-mobile-analytics-js

[mlabieniec]

Thanks for the feedback @jonsmirl and @baharev. Reducing the dependancies and trimming the bundle is top of our backlog. PR #101 already removes the AMA sdk dependency and I hope to get that merged this sprint.

[baharev]

@mlabieniec I am relieved to hear that trimming the bundle has high priority. Looking forward to the new release of the amplify library!

[baharev]

@jonsmirl Thank you for looking into the issue. As Michael says, they will hopefully get rid of this dependency soon.

I do not care about the AMA: I tried it, but I find its reports utterly confusing. Let's leave it at that.

My app is a React + Redux app, where literally everything is recorded anyway. By submitting the user's session to the cloud, I could replay the session on my machine, etc.

[jonsmirl]

I have no need of AMA either, but there is no way to turn it off. Plus it made me add support for unauthenticated users to my identity pool to keep it from generating piles of error messages. That makes me end up with thousands of unathenticated user ids created in my pool since they get created before the user has a chance to authenticate.

[baharev]

@jonsmirl This particular issue will hopefully go away very soon.

[undefobj]

@baharev can you give a bit more feedback on confusion with reports in Pinpoint? We'd be happy to give the feedback to that team.

[baharev]

@undefobj Sure, but it really doesn't below to the amplify project. Should I open an issue at

https://github.com/aws/aws-sdk-mobile-analytics-js

and give feedback there? It would be my pleasure to do that.

[baharev]

@undefobj Oops, I was so disappointed that I deleted all the analytics in Pinpoint. :( Well, I vaguely remember what my problems were, but it will make my feedback less useful. Sorry...

[baharev]

@mlabieniec @powerful23 Awesome, thank you for acting so promptly! Dropping AMA reduces the bundle size from 2.0MB to 775kB, and the source map from 8.9MB to 4.8MB, that is pretty good!

[baharev]

@jonsmirl The new version of amplify halves the bundle size! I am so glad we got this quickly.

Could you give me some advice how to reduce the bundle size with https://sdk.amazonaws.com/builder/js/ further?

I guess I select the packages I need, then download the generated file, and then how do I proceed from there?

Sorry if it is a dumb question but I am beginner in JavaScript (I have a background in C++ and Python).

[jonsmirl]

It is not worth the effort needed to push the size down any further. The SDK builder tool is not going to make things smaller unless it is enhanced to allow picking specific APIs in a service.

775KB is small enough it does not matter. If you really want to shrink the next most obvious thing to remove is the S3 support from amplify. S3 support adds about 80KB compressed and I am not using it. Hopefully amplify will get modularized in the future.

You can use this to poke around in webpack and see where the space is going.
webpack/webpack#690

[baharev]

@jonsmirl Thanks for the advice! I use React, and I also need S3 (user files are being uploaded there). It is probably difficult to reduce the bundle size further, you are right.

[baharev]

For future reference, here is how to enable gzip compression in CloudFront:

• Follow the instructions here: https://aws.amazon.com/blogs/aws/new-gzip-compression-support-for-amazon-cloudfront/
• Add to S3 > Bucket > Permissions > CORS Configuration:
  <AllowedHeader>Content-Length</AllowedHeader>
• It unclear whether a complete cache invalidation is necessary, I did it with *.

After these 3 changes, the bundle is transferred gzipped, so the size is now down to 187KB from 2.0MB, and the page loads pretty fast!

[mlabieniec]

@baharev @jonsmirl going to close this now as the AMA dep is merged, we are also working towards more enhancements on bundle size and deps in general. Please feel free to open this again if you fee necessary.

[baharev]

@mlabieniec Should I open an issue to add how one can enable gzip compression on CloudFront? See above. This was the final piece, and now I am OK with the 187KB gzipped bundle size.

[mlabieniec]

@baharev thanks, I'll get this added to the docs.

[baharev]

@mlabieniec Great thanks! Also many thanks for acting so promptly with this issue, and reducing the bundle size!

[quangv]

+1 for CDN

[dnutels]

You guys seriously stopped at this?

775KB is small enough it does not matter.

775KB is ENORMOUS. It TRIPLES the size of my application, even when gzipped and minified.

Besides, most normal people bundle their applications today, so the bundle builder is a really messy way of going about it. It doesn't allow dependency or version management and is MANUAL.

The amount of disappointment in AWS FE team is at an all time high.

[mlabieniec]

@dnutels we are absolutely not stopping here. We are actively working on decoupling the categories so that users can include only parts (just Auth, or just Storage). The majority of the size is the aws-sdk for javascript. We have a few PRs already in review here to decouple the Auth credentials piece specifically, which was more the "most" difficult part. We plan on completing this asap. Lately we've been very focused on stability and framework support. Everything being included does make the bundle size larger than we'd like, and we are continuing to actively work on this as you can see in some of the modularization labeled PRs. Gzipped is better, and if you compare to something like Angular (min is about 650k and dev is about 5mb), the size IS comparable, but we are also not happy with this and should have the modularization complete in the next couple sprints.

[dnutels]

Looking forward to it @mlabieniec

[Ajji11]

I'm running into the same issue with Angular 6 when I do ng build --aot.

ERROR in node_modules\aws-amplify-angular\lib\components\interactions\chatbot\chatbot.component.core.d.ts.ChatbotComponentCore.html(20,43): : Expected 1 arguments, but got 0. node_modules\aws-amplify-angular\lib\components\interactions\chatbot\chatbot.component.ionic.d.ts.ChatbotComponentIonic.html(59,19): : Expected 1 arguments, but got 0.

I just wanted to use the API service to connect to API Gateway, I'm not using the chatbox component.

I followed the tutorial and imported this into Main.ts

//------Main.ts--------
import Amplify, { API } from 'aws-amplify';

Amplify.configure({
  Auth: { //auth configs here  },
  API: { //api configs here  }
});

//-------App.Module
import { AmplifyAngularModule, AmplifyService } from 'aws-amplify-angular';
@NgModule({
  ...
  imports: [
    ...
    AmplifyAngularModule
  ],
  providers: [AmplifyService],
})

[edgarelc]

Same issue here as @Ajji11 and @kwoxford. Looks like it's an issue with the angular components in aws-amplify-angular. I'm not using any of the chat bot components neither.

[haverchuck]

@edgarelc Thanks for your input. We've pushed a fix for this to the unstable branch, and it should become part of the stable release shortly.

[otbe]

Mh....I try to use @aws-amplify/auth to signUp/signIn users into my Cognito User Pool, but adding this lib as a dependency adds 379kb (uncompressed, ~110kb gziped) to my prod bundle. Code coverage before

(not good) and after

(even worse). I guess this is related to the aws-sdk.

Any hints on reducing the bundle size (maybe some webpack hacking or so?)?
Its a very nice and easy to use lib, but that (optimized, uglified) prod bundle size just kills my PWA :/

[AbdullahAdeeb]

@edgarelc @Ajji11 @kwoxford I had the same issue. fixed in v1.0.3
run: npm i aws-amplify-angular@1.0.3 -S

[aldarund]

380kb just for auth seems excessive. Is there any plans to make it smaller?

[mlabieniec]

My lighthouse score for Auth+Analytics with gzip compression is around 199 KB and scores 100 on performance for PWA @aldarund @otbe

Non-Gzip still scores 100

I ran these on chrome with 3g network throttling. What use-case/size target are you going for?

[otbe]

199KB is almost my entire budget for a chunk and I need some more stuff to go (react, apollo-graphql...). Yes I can split out all these deps in extra chunks but at the end of the day the user has to load all chunks on an initial hit. Please also check the code coverage before/after adding @amplify/auth.

But maybe thats not too bad comapred to auth0
https://bundlephobia.com/result?p=auth0-lock@11.9.0
vs
https://bundlephobia.com/result?p=@aws-amplify/auth@1.1.1

[mlabieniec]

@otbe thanks for the info, understood. This is definitely something we are continuing to work on, will keep this thread up-to-date as we make more progress

[ehorodyski]

I have to +1 the need for better documentation on tree-shaking this massive library. Especially when you already have AWS services created, and do not want to start a Mobile Hub project from scratch. I'm not a fan of the auto-naming scheme, and most of my services are created by other teams -- without our developers having access to do so.

Edit: I can't use AmplifyService for angular because it needs aws-amplify. How can I thin down aws-amplify-angular?

[dimitarrusev]

@ehorodyski You can't. By opting to use modular imports, the aws-amplify-angular package is rendered useless. You have to write your own custom version.

Obviously, they won't state this publicly because it's already advertised that the library has "first-class support for Angular" (whatever that means) which makes things even more confusing in addition to their half-baked documentation. Smh.

[roborourke]

Is it right just with the following lines my production bundle size is over 400kb? It's much higher than other analytics scripts I've looked at.

import Analytics from '@aws-amplify/analytics';
import Auth from '@aws-amplify/auth';

[afraser]

I'm including only "@aws-amplify/auth": "^1.2.18", and amplify is taking up an enormous chunk of my bundle:

Auth.js appears to only constitute 68K (or 13%) of that 522K, 8% of the gzipped output. There has to be a way to reduce this.

[danawoodman]

Same here, we added @aws-amplify/auth import and our bundle went from ~30kb to 130kb 😩

[johhansantana]

Following some of the suggestions here using @aws-amplify/auth instead of aws-amplify reduced our bundle where we use the login form by almost 90% I would say:

Using aws-amplify

vs

Using @aws-amplify/auth and @aws-amplify/core

and this is without importing any aws-amplify package

I also used @aws-amplify/core to configure the region userPoolId etc

[j0b0sapi3n]

So just to confirm, instead of doing this which my app current does:
import { Auth, API, Storage } from 'aws-amplify';

I should do this:
import Auth from 'aws-amplify/auth';
import API from 'aws-amplify/api';
import Storage from 'aws-amplify/storage';

Or should I also be changing my package from aws-amplify to adding each individual package from @aws-amplify? Thanks for the help!

[mlabieniec]

@j0b0sapi3n you would want to do this:

// import the modules
import Amplify from '@aws-amplify/core';
import Auth from '@aws-amplify/auth';
import API from '@aws-amplify/api';
import Storage from '@aws-amplify/storage';

// import the config file that's generated by the CLI
import AWSConfig from './aws-exports';

// configure amplify with it
Amplify.configure(AWSConfig);
Auth.configure(AWSConfig);
API.configure(AWSConfig);
Storage.configure(AWSConfig);

See example here:
https://github.com/mlabieniec/photo-translate/blob/master/src/main.ts#L7-L16

[waleedshkt]

Both aws-amplify and firebase sdk quicken and ease the web-app development. But they come at the expense of large bundle size. Same goes for Expo which allows rapid react-native app development but adds many MBs of unwanted code

[srchulo]

I'm still seeing this issue with huge bundle sizes. My app takes a few seconds on initial load largely due to many AWS libraries that end up being included in my build that I don't think are actually needed. Would be great to have this reduced! I love the convenience of the amplify libraries, but now I'm trying to think about what parts I can rewrite so I can reduce my app size.

[betimer]

Same issue, and I can not fast debug online, cause it complain too large

[oleg-codaio]

@betimer perhaps you can use Lambda layers.

[ZalgirisKaunas]

For some reason, my aws-sdk dependency is this heavy..

[github-actions]

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels or Discussions for those types of questions.