desktop: load noVNC as one bundle instead of 42 modules
public/novnc is unbundled noVNC source. The dynamic import pointed at rfb.js, so the browser walked the module graph natively: fetch a file, parse it, discover its imports, fetch those, repeat. The graph is 42 modules and six levels deep, so opening the desktop cost six SEQUENTIAL round trips and 42 requests before the VNC handshake could even start — and a hard refresh pays it in full every time. Over the tailnet that is the "takes a long time to load", not the pixels. Bundled with bun: 52 modules to one 190 KB file, 56 KB gzipped, one request. The regeneration command is in a comment next to the constant so a future noVNC bump does not silently keep serving a stale bundle. The source tree stays: it is what gets bundled, and keeping it makes the diff of a version bump readable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
File diff suppressed because one or more lines are too long
@@ -8,7 +8,15 @@ export type DesktopViewProps = {
|
||||
style?: CSSProperties;
|
||||
};
|
||||
|
||||
const NOVNC_URL = '/novnc/rfb.js';
|
||||
// The BUNDLE, not public/novnc/rfb.js. That entry is unbundled noVNC source: 42 ES modules whose
|
||||
// imports nest six levels deep, so a native dynamic import made the browser walk the graph — fetch,
|
||||
// parse, discover the next level, fetch again. Six sequential round trips and 42 requests before the
|
||||
// desktop could even begin connecting, which over the tailnet is seconds, and a hard refresh pays it
|
||||
// every time. One file is one round trip.
|
||||
//
|
||||
// Regenerate after updating vendored noVNC:
|
||||
// bun build public/novnc/rfb.js --outfile=public/novnc/rfb.bundle.js --format=esm --minify --target=browser
|
||||
const NOVNC_URL = '/novnc/rfb.bundle.js';
|
||||
|
||||
const buildWsUrl = () => {
|
||||
const protocol = window.location.protocol === 'https:' ? 'wss:' : 'ws:';
|
||||
|
||||
Reference in New Issue
Block a user