This library is large
As it stands now, posthog-js v1.3.0 is about 52.4kb of minified code.

While nowhere near as bad as some of our competitors (mixpanel-browser is 95KB and segment's analytics.js is 187KB), this can still be improved upon.
Should we improve on this and with what priority? We've covered the low hanging fruit and the next step is to refactor and modernise the library's internals. This would greatly help writing proper tests as well.
I was wondering, would it be possible to "split" this package. For example if I don't need some of the features. I for example don't need the Toolbar or Session Recording at the moment. That could help to minimize the size for people who only need a part of the features.
I think this stream of work likely would be beneficial to start prioritizing... We just upgraded from 1.13.13 to 1.17.3 and it essentially added 2k to what webpack bundle analyzer is reporting for the g-zipped size.
Before:

After:

OMG!
It's growing!
1.3 was 16kb, 1.5 is 30kb.
Is there a way to reduce the bundle size?
This package is huge and leaving us with wondering whether posthog is worthwhile given we're eating very real consequences from Google on mobile LCP. Any updates on this?
It's getting bigger. +1 for prioritising the size of this library. This is a big consideration for us while choosing Posthog vs something else. Size reduction or a "lite" version would be much appreciated.
PS: the new segment library is 0.5 KB and mixpanel is 20 KB compared to 38 KB for posthog.
Just discovered this - https://github.com/PostHog/posthog-js-lite/tree/master/posthog-web Happy to see that effort is being made in this direction 🙌
another instance of that https://posthog.com/questions/posthog-js-lite