Should bundle size be a higher priority for the JS SDK?

[Samuel Elgozi]

Hi everyone, yesterday I submitted a feature request for the firebase team to make it the main priority for their JS SDKs to reduce the bundle sizes.

I tried to explain why this is so important for websites and web apps, and why the firebase team should care.

In the response, I've been told that this will be forwarded and that it might be a good idea to post it here to see what you guys think.
I'll paste the feature request verbatim, but one note before reading it; The loading times were calculated based on the average smartphone performance of 2017, I couldn't find updated data, but smartphone sales have been down, and people don't upgrade as often as they used to, so I believe that the numbers didn't change much, but if you have updated data please let me know.

One last thing, please comment if this is important to you, and also if you think this shouldn't be a high priority at all, and I would like to know why.

Subject: Make it higher priority to reduce the JS SDK's size

Hi, I suggested this about a year or two ago, and here I am again trying to convince you guys to make size a bigger priority for the JS SDK, please hear me out.

Here is a very good article about the cost of JS, and how it's different than an equivalent sized Image:
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/javascript-startup-optimization

I'll spare you the long read; JS is different than other resources because it blocks the page rendering, and it takes additional time in order to parse and execute after it was downloaded.
In my tests using an average smartphone(with the data provided in the article) and 3G download speeds, it will take 4 seconds to download and parse just the Auth + Firestore(and firebase/app) javascript code, not even including the code of the app itself. If we add a hello world app using react we should add another second to that, and that itself is without redux or a router.

Sizes used to calculate this, all are minified + gzipped.
firebase/app is 9KB
Auth is 50KB
Firestore is 95KB

My point is that Firebase JS SDK cripples the ability of a developer to offer a reasonable loading time to the end-user.

According to many studies done about loading times of a website, you should aim at 2~3 seconds for showing content. It differs depending on what the website/web app offers, but an average of 3 seconds is recommended overall on mobile(In average I mean for the average user).

Here are few articles(with links to articles withing them), all based on google data(but not limited to):
https://www.semrush.com/blog/how-fast-is-fast-enough-page-load-time-and-your-bottom-line/
https://developers.google.com/web/fundamentals/performance/why-performance-matters/
(I can link more, but you get the point).

You might have a few questions about the possible current solutions:

Q: What about code splitting?
A: Code splitting doesn't work with the libraries as they are now. I believe that that's the reason you split the libraries.

Q: What about lazy loading?
A: For most apps using firebase that won't be possible, the reason is that if you use Firestore to store the main data of the app, then it will need to load with the main bundle. Lazy loading it will make it worse because the download will start after the main bundle is downloaded, parsed, compiled and executed, but there won't be any data for the app to render because they probably use Firestore to retrieve that.

Q: What about cache?
A: First load time will still be awful, and parsing + execution will still be too slow(if we assume that the user uses react and a router) even on consequent visits.

Q: SSR?
A: Time to interactive stays the same even with SSR on most apps.

At this point, I hope I managed to convince you that it is a problem. And I would like to share what I think will be the possible solutions, and if It's even possible to shrink the size without compromising on functionality.

Let's start with the second one.
I do believe that the size of the SDKs can be much smaller. For my personal projects, I built from zero a library for Firebase auth and a second one for Firebase firestore, they don't have the full functionality that the official SDKs offer, but they do have the main functionality of each one.
My auth library is 1KB and the Firestore one is 3KB.
The caveats are, as mentioned above, they don't cover all of the functionality of the official apps, but I believe that if written correctly, Firestore shouldn't surpass the 10KB, and Auth shouldn't surpass the 5KB mark.
And that is without changes to the backend API, with some delegation to the backend API, it could be much less.

Possible solutions will be to rewrite the whole SDK with performance and size as the main priority(because on the web that should be the main priority), and I understand that it might not be feasible.
The second solution would be to start working on an additional set of SDKs targetting only modern browsers(ie 11 is going to die anyway) and deprecating the old one but with the security updates for a few years.

If you manage to offer the leanest JS library from all other cloud solutions, that will be a huge selling point for everyone who cares about performance.

I hope this wasn't too boring. It was important for me to suggest this because I genuinely love firebase.
Thanks and have a nice day!

[Kato Richardson]

Hi Samuel,

Thanks for sharing this. Not sure why you were directed here, but I definitely think our SDK team would be extremely interested in the analysis. The ideal place to get their attention would be on the GitHub issue tracker for the web SDK.

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/16e2e39d-e5f2-4c43-a072-726596bd963e%40googlegroups.com.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Sebastian Schmidt]

Hi Samuel,

Thanks for sharing this. While I can't promise much yet, the SDK size for Firestore is a known issue and something that I will personally focus on over the next couple of weeks/months.

Thanks

Sebastian

[Samuel Elgozi]

Kato, I don't know either why I was direc here, but I had to try :)

And thanks Sebastian, it's good to know that its a known issue, I just built a firebase storage library, and I saw a lot of redundant code there, so if you don't have a specific place to start from I would suggest looking there.

To be honest It would be helpful if some documentation of the internal REST APIs for Storage and Auth were public, I had to reverse engineer everything, If it was I might have contributed directly to the official repo.

[Joseph Szili]

Hi Samuel, if the SDK support tree shaking (you'd have to check with the dev team) you could use https://svelte.dev/ as Svelte complies your JS and prunes what you don't use out of your bundle.

Just a thought.

[Samuel Elgozi]

Thanks for the reply Joseph.

I do use Svelte for a production app I have. Its tree-shaking capabilities are limited to the bundler you are using with it, they are not specific to svelte.
That aside, the Firebase SDK is not very "tree-shakeable", right now I don't know about any bundler that can help with it.