| Metric | OLD | NEW | Improvement | |------------------------------------------|----------|----------|------------------------| | Blank screen until first content (FCP) | 15.0 s | 9.1 s | −5.9 s (≈40% faster) | | Page usable (LCP) | 16.2 s | 10.3 s | −5.9 s | | Main bundle download done | 13.8 s | 7.5 s | −6.3 s | | Data downloaded | 2,258 KB | 1,213 KB | −1,045 KB (~half) | ## Problem All 12 locale files were statically imported into `locales/index.ts` and spread into a single `messages` object. Static imports get inlined, so the entire set of translations landed in the entry chunk — every user downloaded and parsed all 12 languages in order to use 1. ## Fix Only the `en-gb` fallback stays bundled. The other 11 are code-split via `import.meta.glob` and fetched on demand; `main.ts` loads the active locale before mounting, falling back to the bundled `en-gb` if that chunk fails. ## Impact (measured — prod builds of `main` vs this branch) | `index.js` | main | this PR | delta | |---|---|---|---| | raw | 7,335.9 KB | 4,276.0 KB | **−3,059.9 KB (−41.7%)** | | brotli | 1,468.2 KB | 874.6 KB | **−593.6 KB (−40.4%)** | - **English users** (most traffic): −594 KB transfer, ~3 MB less JSON to parse before first render, no extra request. - **Non-English users**: same entry saving, plus one cacheable ~71 KB (brotli) locale chunk — net ~−523 KB. The parse-time saving matters more than transfer: decode cost scales with decoded size, not compressed size, and it blocks first render. ## Also - Removed `hi.json` — unreachable since #1857 (absent from the language picker and `localeFileMap`, referenced nowhere) and incomplete: 658 keys missing vs `en.json`, 1,905 of 5,280 still holding the English source string. - Added guard tests asserting the locale registries stay in sync — a file with no mapping, a mapping with no file, and a locale missing from the number-format map all now fail CI. Each was verified to fail against an injected regression. - `GeneralDangerZone.spec.ts` set the i18n locale directly and relied on all locales being preloaded. It now awaits `loadLocaleMessages()` first, mirroring `main.ts`. Assertions unchanged — it still catches keys missing from a translation (#13092). --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
web
This template should help get you started developing with Vue 3 in Vite.
Recommended IDE Setup
VSCode + Volar (and disable Vetur) + TypeScript Vue Plugin (Volar).
Type Support for .vue Imports in TS
TypeScript cannot handle type information for .vue imports by default, so we replace the tsc CLI with vue-tsc for type checking. In editors, we need TypeScript Vue Plugin (Volar) to make the TypeScript language service aware of .vue types.
If the standalone TypeScript plugin doesn't feel fast enough to you, Volar has also implemented a Take Over Mode that is more performant. You can enable it by the following steps:
- Disable the built-in TypeScript Extension
- Run
Extensions: Show Built-in Extensionsfrom VSCode's command palette - Find
TypeScript and JavaScript Language Features, right click and selectDisable (Workspace)
- Run
- Reload the VSCode window by running
Developer: Reload Windowfrom the command palette.
Customize configuration
See Vite Configuration Reference.
Project Setup
npm install
Compile and Hot-Reload for Development
For stand-alone UI development environment, create .env file and which contains below environment variable
VITE_OPENOBSERVE_ENDPOINT=http://localhost:5080/
npm run dev
Type-Check, Compile and Minify for Production
npm run build
Run Unit Tests with Vitest
npm run test:unit
Run End-to-End Tests with Cypress
npm run test:e2e:dev
This runs the end-to-end tests against the Vite development server. It is much faster than the production build.
But it's still recommended to test the production build with test:e2e before deploying (e.g. in CI environments):
npm run build
npm run test:e2e
Lint with ESLint
npm run lint