Bundle size too large for js-web

[vjsamuel]

• This only affects the JavaScript OpenTelemetry library
• This may affect other libraries, but I would like to get opinions here first

We have been in the process of doing instrumentation for our frontend applications. As a first step, the team has done some boiler plate instrumentation for events/exceptions using the logs SDK. However we see that the bundle size is way too large for us to ship it out without impacting page speed. The size can be seen in the screenshot below:

Is there any opportunity to some short/mid/long term iterations to make sure that we substantially bring this number down?

Thank you for the great work that is being done here :)

[pichlermarc]

Hi @vjsamuel thanks for reaching out. We're aware of the issue but we have not formulated a plan yet. I think now is a good time to formulate that plan so that people can get working on it.

I have some ideas around the topic that (I think) we can implement to reduce the size of these bundles:

• introduce a size-limit workflow step for workflows that run on PRs (this is crucial for us to verify that future PRs that are targeting bundle size actually do what they're promising, I'd consider this a required first step before doing anything else).
• pick priority packages that get some treatment around the topic
  • my proposal (at first) would be to focus on experimental packages (@opentelemetry/api-logs, @opentelemetry/api-events, @opentelemetry/sdk-logs) as there we can make breaking changes to improve bundle size they're still in semver 0.x range)
  • my suggestion would be excluding exporters from that first step (that's mainly @opentelemetry/otlp-exporter-logs-otlp-proto, @opentelemetry/otlp-exporter-logs-otlp-http, @opentelemetry/otlp-transformer, @opentelemetry/otlp-exporter-base). I am actually currently working on re-structuring them so that we can apply bundle-size and performance improvements in the future (See [exporters] OTLP Exporter stabilization plan #4585, [otlp-transformer] reduce public API surface #4583, [otlp-exporter-base] refactor exporters to use a pluggable transport layer #4116). Their code does interweave a lot of different concepts which makes PRs extremely difficult to review and test. These issues need to be addressed first before we can consider working on bundle-size improvements.
• apply improvements to these priority packages
• use leanings from the priority packages to improve bundle size impact in the rest of the packages in the repo.

Questions about your specific situation:

• which exporter are you using at the moment? The @opentelemetry/otlp-exporter-logs-otlp-proto is very large, while @opentelemetry/otlp-exporter-logs-otlp-http is significantly smaller. They are quite different and the JSON exporter does not have to pull in generated code and protobufjs.
• which @opentelemetry/* packages are you using in your bundle at the moment? Knowing this may help us get a first list of priority packages.

Please let me know what you think of the proposed steps, I'll then create the issues for the tasks and will bring it up in the SIG meeting so that we can have a broader discussion on it before starting to work on it. 🙂

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stale for 14 days with no activity.