feat: measure why lessons load slowly, and give a technician the same tool

Measured before changing anything, and nothing about loading changed,
because the evidence does not point at Wonder Ink. Same lab, same page,
timed by each engine until the sign-in form exists: Wonder Ink 2.86-3.00 s
cold and 2.20-2.49 s warm, Chrome 2.79-3.48 s and 1.96-2.15 s. The site is
the weight — 119-160 requests and 3.2 MB for a sign-in form, and its
console reports loading the Google Maps API twice. Memory about 610 MB
for one tab, 115 MB per further tab; idle CPU about 1%.

The lab draws in software for both engines, so it cannot show the one
likely cause it has no hardware for: QtWebEngine failing to use a
classroom's GPU where Chrome succeeds. classroom-wonderink --diagnose,
run from the maintenance terminal in the teacher's session, prints the
engine versions, the scale, the WebGL renderer (a driver, or software),
and the sign-in page's time from a cold cache, in a throwaway profile
beside any running Wonder Ink.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/wonder-ink.md

@@ -338,7 +338,50 @@ The lab's injected keyboard does not reach its nested session, so the
 check delivers keys through Qt's own key path to the focused page; a
 physical Ctrl+Plus on a classroom keyboard is a hardware check.
 
-## Turning it off
+## Why lessons load slowly
+
+Measured before anything was changed, and nothing about loading was
+changed, because the evidence does not point at Wonder Ink.
+
+In the lab, on the same connection, the same page, timed by each
+engine's own Navigation Timing until the sign-in form exists (the site
+is a 3.7 KB shell that builds itself in JavaScript, so its load event is
+not the moment a teacher can use it):
+
+| Until the sign-in page is usable | Wonder Ink | Chrome |
+| --- | --- | --- |
+| cold cache, 3 runs | 2.86 – 3.00 s | 2.79 – 3.48 s |
+| warm cache, 3 runs | 2.20 – 2.49 s | 1.96 – 2.15 s |
+| window on screen after launch | 0.33 s | 0.42 s |
+
+* **The site is the weight:** 119 – 160 requests and 3.2 MB for a sign-in
+  form, about 430 KB warm. Its console says it loads the Google Maps
+  JavaScript API *twice*, synchronously. That is Wonder Ink's to fix.
+* Wonder Ink is about a quarter of a second slower warm: it revalidates
+  the page shell (62 – 87 ms to first byte) where Chrome serves it from
+  its cache. Not the "very long time" teachers describe.
+* Memory: about 610 MB for one tab and 115 MB more for each further tab —
+  eight tabs, 1.4 GB — one renderer each. Idle CPU about 1%: nothing
+  spins in the background.
+* The network: from the lab, 0.14 – 0.22 s to first byte; from the
+  development host, 0.42 – 0.44 s. Cloudflare in front, uncached.
+
+What the lab **cannot** show is the machines: it draws in software for
+both engines. A classroom whose graphics fail in QtWebEngine but work in
+Chrome would look exactly like the complaint. So there is a command for a
+technician, run from the maintenance terminal inside the teacher's
+session (Meta+Ctrl+Alt+Shift+K):
+
+    classroom-wonderink --diagnose
+
+It prints the engine's versions, the scale, **what WebGL reports as the
+renderer** — a real driver's name, or "none … drawing in software" — and
+times the sign-in page from a cold cache in a throwaway profile, beside a
+running Wonder Ink without touching it. Compare its time with the lab's
+2.9 s, and its renderer with Chrome's on the same machine (open
+`chrome://gpu` there).
+
+
 
 One future device is a laptop that will not have Wonder Ink at all.