[Operations] Tighten page load bundle size limits#227742
Merged
mbondyra merged 5 commits intoelastic:mainfrom Jul 14, 2025
Merged
[Operations] Tighten page load bundle size limits#227742mbondyra merged 5 commits intoelastic:mainfrom
mbondyra merged 5 commits intoelastic:mainfrom
Conversation
mbondyra
added
Team:Operations
Contributor
|
Pinging @elastic/kibana-operations (Team:Operations) |
mbondyra
force-pushed
the
limits/update_limit_to_target_limits_to_high
branch
from
8c01bf9 to
b9702f0
Compare
mbondyra
force-pushed
the
limits/update_limit_to_target_limits_to_high
branch
from
b9702f0 to
dc14d9c
Compare
delanni
approved these changes
Jul 14, 2025
Contributor
💚 Build Succeeded
Metrics [docs]
History
|
Bluefinger
pushed a commit
to Bluefinger/kibana
that referenced
this pull request
Jul 22, 2025
# Summary Hi Operations team! 👋 Recently I've worked on a [few](elastic#227593) [PRs](elastic#226052) that reduce our page load bundle size, and while doing so I noticed that many of our limits are much higher than the actual page load sizes. It made me think: these limits should be realistic, because they’re one of the main ways we protect page load performance. Right now, based on the current limits, we theoretically allow up to 11,452,104 bytes (~11 MB) to load upfront. But when we check the real page load, it’s only 5.192.979 bytes — about half of that. We already have a `--update-limits` flag for the `node scripts/build_kibana_platform_plugins.js --update-limits` command, but it only bumps limits up when the size grows above the limit, adding a flat 15 KB buffer to the bundle size. I’d like to propose: 1. Allowing the `--update-limits` to allow folks to also lower limits when the bundle shrinks drastically 2. Replacing the flat 15 KB buffer with 10% of the plugin’s size, so the buffer scales realistically. Right now, with ~197 plugins, `--update-limits` allows for an extra (15KB*197=) 3 MB above the total page size — which is way too much in my opinion! ## What’s in this PR ✅ Adds logic to let us lower limits automatically, not just bump them up with `node scripts/build_kibana_platform_plugins.js --update-limits` ✅ Replaces the flat +15 KB bump with a 10% buffer relative to each plugin’s size when using `node scripts/build_kibana_platform_plugins.js --update-limits` ✅ Updated the limits.yml with the result from the above script ## Why it matters 1. Keeps bundle sizes tight 2. Protects us from accidental regressions
kertal
pushed a commit
to kertal/kibana
that referenced
this pull request
Jul 25, 2025
# Summary Hi Operations team! 👋 Recently I've worked on a [few](elastic#227593) [PRs](elastic#226052) that reduce our page load bundle size, and while doing so I noticed that many of our limits are much higher than the actual page load sizes. It made me think: these limits should be realistic, because they’re one of the main ways we protect page load performance. Right now, based on the current limits, we theoretically allow up to 11,452,104 bytes (~11 MB) to load upfront. But when we check the real page load, it’s only 5.192.979 bytes — about half of that. We already have a `--update-limits` flag for the `node scripts/build_kibana_platform_plugins.js --update-limits` command, but it only bumps limits up when the size grows above the limit, adding a flat 15 KB buffer to the bundle size. I’d like to propose: 1. Allowing the `--update-limits` to allow folks to also lower limits when the bundle shrinks drastically 2. Replacing the flat 15 KB buffer with 10% of the plugin’s size, so the buffer scales realistically. Right now, with ~197 plugins, `--update-limits` allows for an extra (15KB*197=) 3 MB above the total page size — which is way too much in my opinion! ## What’s in this PR ✅ Adds logic to let us lower limits automatically, not just bump them up with `node scripts/build_kibana_platform_plugins.js --update-limits` ✅ Replaces the flat +15 KB bump with a 10% buffer relative to each plugin’s size when using `node scripts/build_kibana_platform_plugins.js --update-limits` ✅ Updated the limits.yml with the result from the above script ## Why it matters 1. Keeps bundle sizes tight 2. Protects us from accidental regressions
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Hi Operations team! 👋
Recently I've worked on a few PRs that reduce our page load bundle size, and while doing so I noticed that many of our limits are much higher than the actual page load sizes. It made me think: these limits should be realistic, because they’re one of the main ways we protect page load performance.
Right now, based on the current limits, we theoretically allow up to 11,452,104 bytes (~11 MB) to load upfront. But when we check the real page load, it’s only 5.192.979 bytes — about half of that.
We already have a
--update-limitsflag for thenode scripts/build_kibana_platform_plugins.js --update-limitscommand, but it only bumps limits up when the size grows above the limit, adding a flat 15 KB buffer to the bundle size.I’d like to propose:
--update-limitsto allow folks to also lower limits when the bundle shrinks drastically--update-limitsallows for an extra (15KB*197=) 3 MB above the total page size — which is way too much in my opinion!What’s in this PR
✅ Adds logic to let us lower limits automatically, not just bump them up with
node scripts/build_kibana_platform_plugins.js --update-limits✅ Replaces the flat +15 KB bump with a 10% buffer relative to each plugin’s size when using
node scripts/build_kibana_platform_plugins.js --update-limits✅ Updated the limits.yml with the result from the above script
Why it matters