LibreChat/e2e/lighthouse

Serial database latency Lighthouse CI

Run from the repository root with Node 24 and Chrome installed:

npm ci
E2E_CHROMIUM_CHANNEL=chrome npm run lighthouse
# Reuse the production build:
E2E_CHROMIUM_CHANNEL=chrome npm run lighthouse:run
# Negative control: this MUST exit nonzero with an LCP assertion failure:
E2E_CHROMIUM_CHANNEL=chrome npm run lighthouse:regression

E2E_BASE_URL=http://localhost:3098 selects another local port. Each run starts a disposable MongoDB and the real Express server, registers a local user, and seeds a conversation. No model inference is needed. Do not point this test at a deployed service. Playwright refuses to reuse an existing server.

The existing benchmarks/mongoose-latency-hook.cjs adds 250 ms per Mongoose Query/Aggregate execution in the server process. Independent queries can overlap; serial queries compound. This is a deterministic approximation of remote database latency, not a replica topology or network emulator. It also delays query-based writes; native driver calls, bulk operations and cursor batches are outside its coverage. Use a TCP latency proxy if those paths need coverage.

Lighthouse CI makes three cold browser navigations to a populated conversation, using the production client build and real authentication, config, file and message routes. It uses desktop settings with throttlingMethod: provided so Lighthouse does not replace the measured server delays with simulated network timing. Median budgets are LCP 4,500 ms, CLS 0.1, and TBT 500 ms. These are lab regression budgets, not field web-vitals percentiles; Lighthouse does not measure INP. The test also requires the seeded transcript to be the LCP element, so a fast login page, spinner, or empty shell cannot pass.

When the gate fails

1. Read the failed audit's actual value and limit in the job log or .lighthouseci/assertion-results.json.
2. Open a .lighthouseci/lhr-*.html report. The console also prints API request start/end times. A late request start suggests a browser dependency; a long request suggests server work or serial database reads.
3. Inspect the relevant path before changing the budget:

Request / symptom	Code to inspect	Performance change this protects
Config waits for repeated user lookups	packages/api/src/app/service.ts, api/server/middleware/config/app.js	#14101
Message authorization and read run serially	api/server/routes/messages.js, packages/api/src/middleware/messageValidation.ts	#14101
Messages wait for the file map	client/src/data-provider/Messages/queries.ts, client/src/components/Chat/ChatView.tsx	#14188
Startup repeats auth user reads	api/server/controllers/AuthController.js, packages/api/src/auth/userDocCache.ts	#14187, #14343, #14747

Reuse already-loaded user/config data. Start independent reads together, but keep every read scoped to the authenticated user/tenant and wait for authorization before returning data. Do not raise a threshold to hide added round trips.

Adding another scenario

auditPage({ url, cookies, configPath }) in audit.ts collects the reports, redacts authentication headers, prints API timings and enforces the selected LHCI budgets. It returns the reports so each scenario can assert its expected final URL and LCP content. load.spec.ts owns local login state, conversation seeding and transcript assertions; the runner does not depend on them.

A downstream fork can import this runner from a separate launch spec, supply cookies from its own authentication fixture and use a separate LHCI config for launch budgets. The database delay hook can be preloaded by that fixture's server configuration. Keep provider-specific authentication and provisioning in that spec. For launch flows that navigate across documents, also measure entry-to-ready time with Playwright: LCP resets on a new document, so final-page LCP alone does not cover the entire launch. This lane does not exercise OpenID/Redis cache priming.

lighthouse:regression preloads a test-only hook that adds 16 real, sequential user reads before message retrieval (at least four extra seconds). It uses the same page and LHCI assertions, and never modifies production source. Confirm that largest-contentful-paint fails, rather than treating any process error as proof. Run the normal command again to restore baseline reports. Reports stay local or in GitHub job artifacts; session cookie values are redacted before upload. Same-repository pull requests also receive the last 80 log lines as a failure comment.