Please review bundle size

[jairo-campos-JD]

[megoth]

A note on this: This is hard hit when checking https://dev-generator.inrupt.com with Lighthouse.

We might want to make Lighthouse an integral part of our setup. Any thoughts on this?

[megoth]

We might also want to automate performance values that Lighthouse gives us with services such as https://treo.sh/

[justinwb]

Great suggestions. I agree it makes sense to include lighthouse audits as part of the dev flow and surface issues as they get identified.

I wonder if treo.sh is something we recommend as a best practice once they build out the rest of their app (post-generation), or if we really benefit from it above and beyond lighthouse tests in the generator output?

[james-martin-jd]

This ticket was opened because we discovered that the package size for the library was much larger than we thought it should be. Upon some investigation there's two root causes: the first is that the favicon is using a large svg file instead of a small icon. The second is that the js map file is very large, so we need to check out why that would be the case and optimize it.

[mrkvon]

Thank you for your effort on this.

I'm building a solid react app, and the bundle has 3.4 M, out of which a major part is @inrupt/solid-react-components, @solid/query-ldflex, @solid/react and rdflib. And the application just took me 30 seconds to load with suboptimal internet connection. The first-time users will likely be discouraged by this. (On subsequent loads the bundle is cached, so things are fast...)

Why are these packages so large? Can they be further reduced, or split so we can use only the needed parts?

I believe a long loading time can be a single point of failure of solid react apps using these packages.

The app is still an early proof of concept. Expect bugs and unfriendly ui.

edit: this is the actual bundle size overview, derived with source-map-explorer.