## Summary
This PR applies **lossless compression** to all SVG and JPG/PNG assets
across Kibana using:
- [`svgo`](https://github.com/svg/svgo) — for optimizing SVGs
- [`image-optimize`](https://www.npmjs.com/package/image-optimize) — for
JPG/PNG compression
‼️**Please scroll to ''Unknown metric groups" accordion to see what's
the gain for your code.**
<img width="542" alt="Screenshot 2025-06-18 at 13 24 20"
src="https://github.com/user-attachments/assets/191afb28-44fc-4551-9026-756a8385c66a"
/>
The goal is to reduce asset size and improve load performance without
compromising visual quality.
This PR achieves a **23 MB** reduction in asset size across all images
bundled in Kibana’s running code—meaning these compressed images
directly impact what ships in Kibana.
Some assets get bundled into chunks due to our bundling strategy but
might not actually be requested at runtime.
Additionally, I ran the same optimization script on the docs assets as a
harmless extra step, but those savings aren’t included in the 23 MB
total.
---
## Why
While working on Emotion rewrites, I noticed some SVGs seemed
unnecessarily heavy. That led to a broader investigation into our image
assets, and it turns out we’re not consistently optimizing them during
development or build.
---
## Notes
- Visual fidelity of optimized assets has been manually verified — no
visible differences
- The optimization is **lossless**, meaning no quality degradation
- Some assets (like large background images) could benefit further from
**lossy compression**
---
## Follow-ups / Ideas
1. **Automate compression in the dev/build pipeline**
- e.g. add `svgo` as a pre-commit or CI step for SVGs
2. **Improve CI reporting**
- Currently, bundle size diffs for images are hidden under "Unknown
metric groups" in the GitHub CI comment. We may want to make these more
visible.
-
3. **Audit large assets manually** — apply lossy compression where
appropriate
4. **Avoid redundant image loading**
- e.g. background images on the login page are loaded again on the space
selector page since they’re bundled twice. I’m working on a separate PR
to address that.
## Snippets I used to apply the compression
```
# Find SVG files
find . -type f -iname "*.svg" \
-not -path "*/node_modules/*" \
-not -path "*/functional/*" > svg-files.txt
# Compress SVGs
while IFS= read -r file; do
svgo "$file"
done < svg-files.txt
```
This snippet has been used for png and jpg, but the example below is for
png:
```
# Find PNG files
find . -type f -iname "*.png \
-not -path "*/node_modules/*" \
-not -path "*/functional/*" > png-files.txt
# Compress PNGs
while IFS= read -r file; do
image-optimize -f jpg "$file"
done < png-files.txt
```
- Closes https://github.com/elastic/kibana/issues/216549
- Closes https://github.com/elastic/kibana/issues/216071
## Summary
This PR allows to restore the following state for the previously opened
tabs:
- the selected data view
- classic or ES|QL mode
- query and filters
- time range and refresh interval
- and other properties of the app state
bcba741abc/src/platform/plugins/shared/discover/public/application/main/state_management/discover_app_state_container.ts (L92)
## Changes
- [x] Sync selected tab id to URL => after refresh the initial tab would
be the last selected one
- [x] Restore tabs after refresh
- [x] Restore appState and globalState after reopening closed tabs
- [x] Clear tabs if Discover was opened from another Kibana app
- [x] Store tabs in LocalStorage
- [x] Fix "New" action and clear all tabs
- [x] Populate "Recently closed tabs" with data from LocalStorage
- [x] If selected tab id changes in URL externally => update the state
- [x] Reset the stored state when userId or space Id changes
- [x] Fix all tests
### Testing
- Test that the existing functionality is not affected
- Enable tabs feature in
bcba741abc/src/platform/plugins/shared/discover/public/constants.ts (L15)
and test that tabs are being persisted and can be restored manually too.
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Davis McPhee <davismcphee@hotmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
- Closes https://github.com/elastic/kibana/issues/214554
## Summary
This PR:
- adds TabPreview component, which is visible when you hover over a
particular tab
- adds tests for TabPreview component
About TabPreview component
- EUI doesn't have a component, which would suit for our needs, hence a
custom component activated on hover
- TabPreview should activate (with 500ms of delay) after hovering over a
whole tab
- It should hide when we click action button in the tab or we open
editing name mode
- It shouldn't appear on hover when we have tab context menu open or
we're editing a title
- For now the data inside is mocked (besides of title), so you can see
random queries and statuses each time you hover over the tab
- Preview should not overflow the screen if there are a lot of tabs and
they're "touching" right side of the screen
https://github.com/user-attachments/assets/da0a47dd-b594-4c20-b76c-49e6889f3814
## Testing
Two options are possible:
1. start Storybook with `yarn storybook unified_tabs` and navigate to
`http://localhost:9001`.
2. start Kibana with `yarn start --run-examples`. Then navigate to the
Unified Tabs example plugin
`http://localhost:5601/app/unifiedTabsExamples`.
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: Julia Rechkunova <julia.rechkunova@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
