Lock: Find a way to reduce the 556KB minified version

[IvanRave]

[cristiandouce]

yes.

[cristiandouce]

Related:

auth0/lock#66
auth0/lock#102

[benjipott]

610 ko for login widget in production , wouch !!!

[romainbessugesmeusy]

Any news here ? Auth0 lock represents 50% of my front-end JS :-(

By the way, I'm using jQuery, does anyone here knows if there is a way to avoid the double download of sizzle ?

[moravcik]

is it possible to modularize the lock into lock core + bunch of optional modules? with bundled-all module as well
as for me, for some projects I don't need social identity providers at all

[gnandretta]

We are working on the modularization @moravcik suggests. You'll be able to bundle the Lock without the support for the connections you don't need (social, enterprise, etc.) and also without the CSS.

Having that said, the Lock is intended to be a drop in solution for our customers. It has a lot of features that you may not need and supports extensive customization. For that reason, we recommend users to build their own UI when they want to keep the resources of their web sites as small as possible.

[MicahZoltu]

I just ran into this. Auth0 is 50% of my front-end app right now as well. :/

Suggestion: Load as much as possible lazily rather than up-front. Most web applications that are going to use the drop-in widget won't be popping it up to the user immediately, though some JavaScript on the page may require the API be available during startup. By only pulling in the basic JS up front and lazily downloading the UI later would allow the user's application to be available immediately and at worst they get a small spinner if they get the auth pop-up too quickly after page load.

[NiXXeD]

We just ran into this as well, however the CDN minified version is ~155k. Using browserify with a require('auth0-lock') gets me the 556kb version. We're sticking with the CDN for now.

[jzaefferer]

Any idea how the CDN version is built?

[gnandretta]

Hi @NiXXeD and @jzaefferer,

The script in the CDN is built with the grunt task that is published in this repo. It uses browserify to make the bundle and uglify to minify it. The script is bigger than the ~155k that are actually transferred because the response is compressed with gzip. You can configure your web server to do the same.

[jzaefferer]

Turns out the non-gzipped size (which is a lot easier to compare here) is 729kb. So the CDN build is even worse.

[jfromaniello]

some ideas

I think it will help to know where is the size going, like having a graph.. for instance which dependency is bigger. I just tried to remove underscore and I think the result doesn't worth the hassle:

• auth0-lock.min.js: 692K
• auth0-lock.min.js.gz: 148K

what can we do to figure where is the space going?

The inlined css does takes a big chunk of this:

• lib/css/main.min.css: 182K
• lib/css/main.min.css.gz: 33K

Is there a way to write this css better? is there something we can remove from there?

[woloski]

I would put focus on Lock10 at this point

[jzaefferer]

I would put focus on Lock10 at this point

Is there any way to track that? I found a v10 label, but its not in use, and there are no milestones.

[mikeesouth]

Any news here?

I want to use Auth0-Lock (v10.0.2) with my Aurelia application. I'm not using React at all but including auth0-lock from NPM installs React as a dependency. When analyzing the size of my minified application I get this result:

react: 672.58 KB (21.4%)
auth0-lock: 470.15 KB (15.0%)
auth0-js: 72.42 KB (2.30%)

If I understand correctly, the minified output from auth0 is 1215 KB (excluding React dependency results in a 542 KB auth0 package). That is LARGE.
The CDN file is "only" 670 KB in a minified version. It includes the React dep so how come my NPM installed auth0-lock weighs in at a massive 1 215 KB?

At the moment I'm only using a very simple embedded login form with one social media connector. Can I create this buttom myself and install some bare minimum auth0 package without UI?

[woloski]

yes https://github.com/auth0/auth0.js

[dcworldwide]

+1 for modularising lock. We are only using the most basic username/password login/reset features. 500kb is crazy and like many businesses, we don't have the time to roll our own lighter weight alternative.

[jvbianchi]

any news? Because this module is really huge.

It could have something like a light version, because is not everybody that needs all of the features.

[luisrudge]

@jvbianchi not yet. Lots to figure it out still.. 😅

[jvbianchi]

Is there another issue blocking this issue?

[luisrudge]

@jvbianchi A few. We can't change from react to preact/react-lite/inferno without breaking LOTS of customers. It also sucks if you're using Lock and React because you'd have to have another JS framework added to the stack. Also, replacing react by other alternatives doesn't gives us expressive results. They average -100kb before gzip, so it's not a huge size reduction. Immutable js is also a BIG factor in our codebase. Removing it would have a huge impact, but removing it means rewriting almost everything. Here are some analysis I've made with different js frameworks:

react

preact

react-lite

So, we're very aware of this issue, but it's a super complex problem to fix. We have some mitigation plans until the next major release, which is having different cdn builds like:

<!-- only lock, no react -->
<script src="http://cdn.auth0.com/js/lock/vNEXT/lock-no-react.min.js"></script>

<!-- only lock, no react and no css -->
<script src="http://cdn.auth0.com/js/lock/vNEXT/lock-no-react_no-css.min.js"></script>

<!-- full lock, like today -->
<script src="http://cdn.auth0.com/js/lock/vNEXT/lock.min.js"></script>

Maybe we can do something like that for NPM:

<!-- just the css -->
<link href="http://cdn.auth0.com/js/lock/vNEXT/lock.min.css" rel="stylesheet" />

Then you can just import Lock without the css like:

import Lock from 'auth0-lock/no-css';

We're still thinking, but what do you think about this?

[jvbianchi]

What do you think about using https://github.com/developit/preact-compat or maybe https://github.com/infernojs/inferno/tree/master/packages/inferno-compat?

[luisrudge]

As you can see in the image, I tried preact-compat and the result was -100kb before gzip (after gzip would be something like 20~30kb less). Not worth the effort.

[jvbianchi]

How about lazy loading?

[luisrudge]

how would that work with npm modules and the CDN?

[jvbianchi]

The way I see it (which is possibly wrong) you have to modularize lock by feature (something like: core, login, signup...), and then, load these modules according to the user configuration

[luisrudge]

Yup. Again, this would be a big refactor and the experience might be sub-par. Imagine if Lock is open in the login section and you click "Sign up" and then you have to wait for it to load. So, we need to iterate a lot on how to fix the issue and this is not something we're planning to do in the near future.

[motin]

@luisrudge

We can't change from react to preact/react-lite/inferno without breaking LOTS of customers. It also sucks if you're using Lock and React because you'd have to have another JS framework added to the stack.

You don't have to SWITCH to preact/react-lite/inferno etc, merely make the code working with those libraries work as well. Many things already work when using preact-compat (see https://github.com/auth0/lock/issues/964#issue-218670951)

Also, replacing react by other alternatives doesn't gives us expressive results. They average -100kb before gzip, so it's not a huge size reduction.

For users that actually use preact to begin with (yours truly), adding auth0-lock to the codebase means that react is added to the codebase, resulting in a whopping 611kb added (raw, according to webpack analyzer stats), and since true size-hunters are probably using a more lightweight alternative to react already, this may be the case for most concerned users in this thread.

Immutable js is also a BIG factor in our codebase. Removing it would have a huge impact, but removing it means rewriting almost everything.

Do you need all of immutable js features? Otherwise try one of the smaller alternatives like https://github.com/scottcorgan/immu - 1 kb gzipped.

Also, how much does webpack 2 and tree-shaking reduce the bundle size, have you experimented with that?

[luisrudge]

@motin

You don't have to SWITCH to preact/react-lite/inferno etc, merely make the code working with those libraries work as well. Many things already work when using preact-compat (see #964 (comment))

making the lib work with react and all the lightweight alternatives is a losing battle. How do you pick the libs? If I pick preact, tomorrow someone will ask "why this doesn't work with inferno/react-lite/new-super-tiny-framework?".

For users that actually use preact to begin with (yours truly), adding auth0-lock to the codebase means that react is added to the codebase, resulting in a whopping 611kb added (raw, according to webpack analyzer stats), and since true size-hunters are probably using a more lightweight alternative to react already, this may be the case for most concerned users in this thread.

Indeed. That's what we're trying to fix, but, as I stated before, it's a super complex problem to solve when you have millions of users loading your library via a CDN.

Do you need all of immutable js features? Otherwise try one of the smaller alternatives like https://github.com/scottcorgan/immu - 1 kb gzipped.

It doesn't have the same API as immutable, so that's a non-starter.

Also, how much does webpack 2 and tree-shaking reduce the bundle size, have you experimented with that?

We're using webpack 2 with tree shaking. It didn't improve a lot.

webpack 1

webpack 2 with tree shaking

[jvbianchi]

Why don't you try rollup?

[luisrudge]

Because we use a huge api surface or our dependencies. Tree shaking won't help us much. First step is get rid of immutable, but, as I said, it's a huge issue, since we use it pretty much everywhere.

[motin]

@luisrudge Awesome answer, thank you!

Also, replacing react by other alternatives doesn't gives us expressive results. They average -100kb before gzip, so it's not a huge size reduction.

I don't understand, since the gzipped sizes of each framework ought to be as follows: React (43kb) (https://gist.github.com/Restuta/cda69e50a853aa64912d) vs Preact (3kb), Inferno (9kb), React-lite (13kb) (source: https://niteco.com/blogs/react-alternatives/)

Naively calculating, if we have 188kb gzipped lock today, we ought to be able to shave off up to 40kb with preact? That is a huge difference.

making the lib work with react and all the lightweight alternatives is a losing battle. How do you pick the libs?

For instance:

1. Pick out the top two-three libs based on github stargazers
2. Try out the codebase with each one's "-compat" wrappers and evaluate the effort required to make auth0-lock work with each.
3. Investigate the actual gzipped sizes of each build
4. Choose the framework with the best popularity vs gzipped size-saving vs effort potential

If I pick preact, tomorrow someone will ask "why this doesn't work with inferno/react-lite/new-super-tiny-framework?".

Be transparent with whatever process you used for picking and it should be fine. It is much better to have to answer that question than to have answer "Why this doesn't work with any lightweight react alternative?" as is the situation now.

[motin]

Regarding lazy-loading:

Imagine if Lock is open in the login section and you click "Sign up" and then you have to wait for it to load. So, we need to iterate a lot on how to fix the issue and this is not something we're planning to do in the near future.

That sounds much better than to have to wait for it to load on every page load, regardless whether or not sign-up/login/forgot-password is ever to be used on that page load.

Also, you could make it lazy-load after the site first has rendered, so that the site renders fast AND sign-up renders fast when the user has requested it.

[guenam]

I just wanted to share the result for my project using node / angular4 / webpack2 with AoT : installing Auth0Lock through npm adds 1.7 Mo to the code send to the client. So I rolled-back to using the CDN version.

[luisrudge]

Thanks everyone in this issue for the valuable feedback. As we move forward, I have a few points I want to make on behalf of Auth0.

We take this issue very seriously, but there's no magical solution. We tried a few things, but, sadly, our internal codebase is big because we handle so many use cases. We could change react for a lightweight alternative, but this would require an extensive rewrite and we can't possibly make that decision based on popularity. We tried preact-compat to avoid adding a lot of changes to the codebase, but that yielded little size reduction.

Most of our dependencies are a "must have". We can, maybe, remove immutable, but this would require a full rewrite of Lock's internal state management and we'd probably have to either bring a state management library or write one ourselves.

The majority of the code in the minified build is from our codebase. As I mentioned, our codebase is huge and takes more than half of the bundle size, since we support A LOT of features and customizations, and also the CSS adds some weight to the bundle.

Finally, I'd like to add that Lock is a drop-in widget, ready to handle ALL authentication features Auth0 supports. Sure, it sucks to weight 188k gzipped, but this is not meant to be lightweight. It's made to be complete. If you want to squeeze every possible bit, we strongly suggest everyone to build your own customized pages and use auth0-js.

This is not to say we are not doing anything about this, we have some old ideas to revisit like a modular Lock (something we tried internally but didn't like the results), lazy loading parts of Lock, some ideas you guys submitted and alternatives to react, but we will tackle them carefully while continuing to support what we have now and adding new features of Auth0's platform.

[moravcik]

As for me, I need only basic features with username/password, so building my own customized pages with auth0-js is a way to go. And this may be the use case for many others too. Haven't you thought about lock-lite version or something which support only basic stuff?

[hzalaz]

We have but there are some features like i18n, UI customizations, etc that are independent of the type of Auth you use, and they each takes a toll in the bundle size so it could be smaller but not that small. Also we have a lot of customers using enterprise and social connections so there is no clear trend.

And I agree, with just basic db connection support Lock is overkill if you care a lot about bundle size

[moravcik]

Yes, I understand the current version is, let's say a maximum version which is good for many enterprise customers.

I was talking about a possibility to have a minimum version, with most basic features. But yes, maybe it is easier if I create one by my own. In my case I don't use React but Angular2 with custom theming and i18n support.

Bundle size is always an issue, however some lazyloading might help.

[bialad]

I'd like to add that I "solved" this by putting the account handling on a seperate lazy loaded page of my app. By using client caching for this page the lock-download is excluded once a user is logged in. This works well for me, and the lock-bundle saves alot of time when developing account handling.

[guenam]

I feel like @bialad has the right attitude about it. I'll try and find a solution inspired by his/her way of handling it.

[hzalaz]

Also you could redirect to your tenant hosted login page to perform the AuthN/AuthZ there with the OAuth2 flow

[jvbianchi]

Have you tried the closure compiler?

[luisrudge]

Nope

[cyberabis]

Hi @luisrudge , I am using auth0-js and I see it takes ~91kb, a lot better compared to the original issue. I see that in this module, passwordless-authentication.js takes up ~54kb. I don't use passwordless auth, so is it possible to shake off this 50kb? I am on Angular2+ and import the library like: import * as auth0 from 'auth0-js', possible to exclude passwordless and import?

[luisrudge]

@cyberabis hi, auth0.js' repo is located here: https://github.com/auth0/auth0.js - but no, you can't remove that part from the lib unless you build the library yourself.

[cyberabis]

Thanks @luisrudge, in that case I'll live with what's available!

[dcworldwide]

If anyone has written or is interested in writing a lightweight react alternative please pm me. I will be working on one for my project.

My scope

• React
• User login form
• Password reset form
• Password change form

[motin]

@dcworldwide If you link to the github repo for your initiative I'm sure you'll get some contributors onboard :)

[camacho]

for anyone using Yarn, it is possible to reduce the bundle size by nearly half by using selective dependency resolution. this was also referenced in #1096 and #1148. i am using React 16, so my resolutions property in package.json looks like this:

"resolutions": {
  "react": "^16.0.0",
  "react-dom": "^16.0.0"
}

[joshystuart]

Has there been any progress on this? It's still a significant part of our entire JS payload.

[franciscop-invast]

For Auth0: if you try to make sure to use the latest version of react and react-dom, then at least those will not be duplicated on node_modules for those of us who keep them up to date. If react-dom was ^16 in auth0-lock, it would reduce 15% of the library size in my code.

[luisrudge]

@franciscop-invast the react version is more complicated than it seems. If you're using yarn, you can use only 16 with resolutions. More context here: https://github.com/auth0/lock/blob/master/CHANGELOG.md#-notice-

[franciscop-invast]

@luisrudge what do you mean? Why not updating Lock to use React and ReactDOM ^16 since it's compatible, while also getting rid of that dependencies: out of date error? It sounds really scary for a library that handles the Auth of WebApps. It doesn't need to be performed in a single step, specially if it is compatible and recommended:

1. Update to React 16+ and bump Lock's minor version.
2. Publish a new Lock major version with React as a peerDependency.

_"We're trying to figure it out how"_ do you have an order of magnitude estimate? Is it matter of days, weeks, months or years? Seems that the issue surfaced on Oct 2017.

PS, we are not using Yarn.

[luisrudge]

Because we're not using peerDependencies right now, we can't upgrade to react@16 without releasing a breaking change, otherwise current customers that have auth0-lock as a dependency and need to stay on react@15 would have their react apps upgraded to react@16.
We have no ETA for the new major.

[zachguo]

@luisrudge Is it possible to make a separate beta or rc release which moves react stuff to peerDependencies?

In this way, you don't need to break your internal process for your next major release, and size-sensitive customers can also at least have a workaround without changing team setup and CI/CD pipeline to yarn.

[luisrudge]

Sorry, but there are no plans to start developing Lock@12. Creating a pre-release right now would only be confusing to everyone and might complicate future updates if we need to add a breaking change for security reasons.

[franciscop-invast]

What I've seen many times is not to treat major versions as marketing; releasing Lock@12 with just two small changes (React 15 => 16, Lock 11 => 12) in the package.json is the benefit of following semver. This would benefit quite a lot of developers trying to use Lock.js, while keeping the cost and time quite down on your side.

Now some data. We are considering alternatives as well, since there are quite a few more dependencies that we do not currently need being included. Everything visible here is included only because of Lock (click to expand):

For the sake of it, we tested removing Lock and mocking it out and this is the resulting size (~50% decrease):

npm run build confirms it when displaying the gzipped size, these are the before and the after:

| With Auth0 Lock | Without Auth0 Lock |
|---------------------|------------------------|
| | |

[cg-rsands]

Any update on this issue? 3 years!

[franciscop-invast]

4 years in a couple of months, @cg-rsands ;)

There have been 11 minor versions for Lock 11 though, so kudos on that.

Meanwhile I'm considering searching into the new React lazy() to load Lock dynamically as soon as it is available:

import React, { lazy, Suspense } from 'react';
const Auth = lazy(() => import('./Auth'));

export default () => (
  <Suspense fallback={<div>loading...</div>}>
    <Auth>
  </Suspense>
);

[luisrudge]

@franciscop-invast I think you have the right approach. Every modern framework supports code splitting and this is the best way to mitigate this specific issue.

[NullVoxPopuli]

Is there any traction on this? or does auth0 not care / want us all to make custom forms? (this is fine, I just want an answer) :)

https://github.com/sillsdev/appbuilder-portal/issues/184

auth0-lock is about 1/5th of my dependencies -- in production.

[luisrudge]

@NullVoxPopuli seems like you're loading two instances of react. See this comment to use only one version.

With that being said, the closing comment still holds true. As of today, we have a lot of other priorities. We'll have a lot of good things coming in Q1 2019 and, hopefully, it will lay down the path to a new version of lock that actually solves this issue.

[zachguo]

Can we reopen this issue?