## 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
```
## Summary
Changed import path for Kibana Core Public imports, previous was not
working. New import path reflects what I found elsewhere in the
codebase, and works.
## Summary
- Fixes an issue where the container would not be setup or start
properly if the repo wasn't name `kibana`
- Adds limitations section to docs
## Summary
- Closeselastic/kibana-operations#101
This PR adds a [Dev Container](https://containers.dev/) to utilize for
Kibana local development in an isolated environment. The original
intention was to create a local environment for FIPS development because
setting up Kibana in FIPS mode is complicated and has the potential to
break the user's OS. However, it has been altered to allow for general
development if an engineer chooses as well. The idea is for this be a
cost efficient replacement for
[kibana-remote-dev](https://github.com/elastic/kibana-remote-dev)
eventually.
### Testing
- In VS Code you should be able to use the `Dev Containers: Clone GitHub
Pull Request in Named Container Volume...` command from the Command
Palette (F1) to easily test this PR.
- See the
[docs](bd125fc230/dev_docs/getting_started/setting_up_a_development_env.mdx (using-the-kibana-dev-container-optional))
for additional information on setting up the Dev Container.
### Bazel
I tried many different solutions to copy the local Bazel cache into the
container to speed up bootstrap, but it either would break Bazel or
didn't provide any meaningful boost in performance. I opted to forgo
keeping it in this PR due to the complexity and since we're planning to
phase out Bazel in the future anyways.
Fixing very minor issues in the Kibana dev docs that I found as I was
getting bootstrapped:
- fixing bad markdown syntax
- adding first startup info (url + credentials)
* docs(NA): drop support for windows native development
* docs(NA): improve previous written instructions around windows de
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* docs(NA): windows wsl development
* docs(NA): update titles for the documentation created
* chore(NA): update dev_docs/tutorials/development_windows.mdx
Co-authored-by: Jonathan Budzenski <jon@budzenski.me>
* docs(NA): updated guide to include info around GUI apps support
* docs(NA): updated guide to include info around GUI apps support
* docs(NA): include win10 GUI workaround
* docs(NA): run a first sudo command before running others
* docs(NA): added remote code wsl extension
* docs(NA): mentioned NVIDIA does now includes vGPU drivers for WSL within the common drivers
* docs(NA): update sudo commands separation
* docs(NA): added hardware virtualization prerequisite awareness into the guide
* docs(NA): update wording on guide recomendation for win11
Co-authored-by: Jonathan Budzenski <jon@budzenski.me>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Update the slugs to improve google analytics drilldown tracking
* more slug updates
* Fix some formatting issues in building blocks
* update paths
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Add a new hello world plugin and adjust the welcome message.
* update and move files
* Update CODEOWNERS
* add a tsconfig.json file
* update tsconfig.json
* fix type check
* address code review comments
