mirror of
https://github.com/elastic/kibana.git
synced 2025-06-27 18:51:07 -04:00
65bdf1ff8e
## 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 ``` |
||
|---|---|---|
| .. | ||
| common | ||
| public | ||
| server | ||
| .eslintrc.json | ||
| kibana.jsonc | ||
| README.md | ||
| tsconfig.json | ||
Third party Lens visualization
To run this example plugin, use the command yarn start --run-examples.
This example shows how to register a visualization to Lens which lives along the regular visualizations (xy, table and so on).
The following parts can be seen in this example:
- Registering the visualization type so it shows up in the Lens editor along with custom edit UI and hooks to update state on user interactions (add dimension, delete dimension).
- Registering the used expression functions and expression renderers to actually render the expression into a DOM element.
- Providing a sample migration on the Kibana server which allows to update existing stored visualizations and change their state on Kibana upgrade / import of old saved objects.
To test the migration, you can import the following ndjson file via saved object import (requires installed logs sample data):
Click to expand
{"attributes":{"fieldFormatMap":"{\"hour_of_day\":{}}","runtimeFieldMap":"{\"hour_of_day\":{\"type\":\"long\",\"script\":{\"source\":\"emit(doc['timestamp'].value.getHour());\"}}}","timeFieldName":"timestamp","title":"kibana_sample_data_logs"},"coreMigrationVersion":"8.0.0","id":"90943e30-9a47-11e8-b64d-95841ca0b247","migrationVersion":{"index-pattern":"8.0.0"},"references":[],"type":"index-pattern","updated_at":"2022-01-24T10:54:24.209Z","version":"WzQzMTQ3LDFd"}
{"attributes":{"description":"","state":{"datasourceStates":{"formBased":{"layers":{"f2700077-50bf-48e4-829c-f695f87e226d":{"columnOrder":["5e704cac-8490-457a-b635-01f3a5a132b7"],"columns":{"5e704cac-8490-457a-b635-01f3a5a132b7":{"dataType":"number","isBucketed":false,"label":"Count of records","operationType":"count","scale":"ratio","sourceField":"Records"}},"incompleteColumns":{}}}}},"filters":[],"query":{"language":"kuery","query":""},"visualization":{"column":"5e704cac-8490-457a-b635-01f3a5a132b7","layerId":"f2700077-50bf-48e4-829c-f695f87e226d"}},"title":"Rotating number test","visualizationType":"rotatingNumber"},"coreMigrationVersion":"8.0.0","id":"468f0be0-7e86-11ec-9739-d570ffd3fbe4","migrationVersion":{"lens":"8.0.0"},"references":[{"id":"90943e30-9a47-11e8-b64d-95841ca0b247","name":"indexpattern-datasource-current-indexpattern","type":"index-pattern"},{"id":"90943e30-9a47-11e8-b64d-95841ca0b247","name":"indexpattern-datasource-layer-f2700077-50bf-48e4-829c-f695f87e226d","type":"index-pattern"}],"type":"lens","updated_at":"2022-01-26T08:59:31.618Z","version":"WzQzNjUzLDFd"}
{"excludedObjects":[],"excludedObjectsCount":0,"exportedCount":2,"missingRefCount":0,"missingReferences":[]}