-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Performance
Yes.
Some parts of Cockpit are especially slow, such as logs, services, storage, etc.
Yes, it was mentioned several different times in various usability studies.
Some of the speed issues are due to Cockpit providing no feedback that things will take a while, others are because Cockpit takes a very long time to actually load a page or perform a task.
Most of the speed issues are related to page load times.
It's important, but be can do it in tandem with other work.
Sometimes being consious during development is enough. For existing pages, we'll need to retrofit them with various techniquest to improve speed (both actual and percieved).
- Progress indicators
- Progressive loading (page structure loads in, with placeholders; actual data is swapped in)
- Ensure all fonts are loaded on page load (instead of pulled in when needed), to prevent text flashing
- Add transitions and animations
- Identify and fix bottlenecks
- Try to load & display data async instead of sync
- Split data retrieval into chunks
- Cache and pre-cache (start loading services, logs, network card info, storage info, packages that need updating, etc. directly after the overview page loads)
- Don't duplicate CSS & JavaScript per page — have a base library that's re-used, but not recompiled into everything
- Limit # of assets to load (bundle when possible) — this should be balanced with the above
- Move per-page custom widgets upstream to Cockpit, where they can be shared (JS, HTML, CSS)
- Including page load performance in tests
- Compare metrics to previous metrics on the same hardware (relative gains / losses)
- Test on a "typical" system and ensure various thresholds are met
- Set targets for number of assets, file size (HTML, JS, CSS, compelte), speed until first paint, speed until page is completely loaded
From Nielsen Norman Group on Website Response Times on response time limits:
- 0.1 second is "instantaneous"
- 1 second is "seamless"
- 10 seconds is upper-bounds slow (way way way too slow)
From Performance is UX:
- 300ms max for interactions — anything above this threshold needs a spinner or other progress indicator
- 2 seconds max for a page load
- High load
- Network issues (VPN, remote, cell phone networks)
- Low-powered systems
- Mobile devices
As this will be an ongoing effort, we should probably have a performance tag for issues.
- The Critical Request: Good explanation of how browsers prioritize page requests and how to speed things up
- The Cost of JavaScript
- Can You Afford It? Real-world Web Performance Budgets
- Optimizing Performance in React
- React Perf Tools
- React is Slow, React is Fast
- Peeking under the hood of redesigned Gmail, an example of how to use Chrome's devtools to identify why a site is slow