What this is

Latency instrumentation was added to the sessions table: two permanent fields, server_latency_ms and image_sent, recorded on every session from this release forward. The first datapoint: Haiku averaged 5.6 seconds text-only, with about 2 seconds of overhead. Latency was dominated by Haiku, not by the extension pipeline.

The @container cap, which had been shipping in every version without ever working, was fixed. The original check used containerRule.type === 12, which was incorrect: container rules are post-freeze CSS rule types that return 0 in current Chrome, not 12. The check never matched, so the cap never fired. The fix used instanceof CSSContainerRule. Verified via a 3-point fixture test at 150, 200, and 250 container queries.

Performance instrumentation was built into the diagnostics page: last_capture_timings, a pass/fail panel, and per-sub-step timing. The PERF sweep on a 121-stylesheet stress fixture showed PERF-1 and PERF-3 passing, and PERF-4 (ancestor traversal) exceeding its budget at 192 to 234 milliseconds against a 200-millisecond budget.

What it answers

– how fast is loupely lens css diagnosis
– does loupely lens measure diagnosis latency
– what was wrong with the loupely lens container query cap
– how does loupely lens measure performance
– what is the loupely lens ancestor traversal speed

Why we built it

You can’t fix what you don’t measure. The latency instrumentation built the data moat. The performance sweep found the one budget that was failing.