site-check

Site check

An animated page can look perfect in the one browser tab it was built in and fail everywhere else: a blank canvas in Safari, a crop on phones, a seam in a scroll film, a 40 ms frame on a laptop. This skill looks at the page the way visitors will, in several real browsers at several sizes, and reports what broke with pictures.

Tool

scripts/check.py drives headless Chromium (on the real GPU) and WebKit through Playwright.

python3 scripts/check.py http://127.0.0.1:8000/ --out shots \
  --widths 1440,768,390 --browser both \
  --query "view=front" "view=aerial&light=night" \
  --scroll-steps 6 --ready "window.__ready === true"

Option	Meaning
--query	Query strings appended to the URL, each shot at every width. Give pages deep links (?view=, ?light=, ?step=) so every state is reachable
--widths	1440 (laptop), 768 (tablet), 390 (phone, emulated with touch and DPR 2)
--browser	chromium, webkit (Safari's engine) or both
--scroll-steps N	Also shoots N evenly spaced scroll positions, for scroll-driven pages
--ready	JS expression that is true once the page has rendered for real
--wait	Seconds to let things settle before measuring

Output: one PNG per shot, report.json, and sheet.jpg with every shot labelled; problem shots are labelled in red. The script exits 1 if any shot had a page error, a failed or 4xx/5xx request, a blank canvas or horizontal overflow. Each shot also gets a reduced-motion pass at the widest width.

Needs Python 3.9+, pip install playwright pillow, and python3 -m playwright install chromium webkit. Serve the page over HTTP (ES modules and video seeking need it) with scripts/serve.py DIR --port 8000; it answers Range requests, which python3 -m http.server does not.

Reading the report

• ms per frame is measured over 60 real frames. Under 16.7 is 60 fps; headless on a laptop GPU should sit near 16.7 (vsync), so a higher number means real cost. Compare runs with each other. If the report says the renderer is SwiftShader or llvmpipe, the GPU was not used and frame times mean nothing.
• calls / triangles come from window.__app.renderer (three.js), counted for a whole frame including every post-processing pass. Expose the renderer there so the check can see it.
• ready_s is how long the page took to set its ready flag. Over 3 s on a fast machine means the loader is visible for too long on a phone.
• blank canvas means a visible canvas was one flat colour: a WebGL context that failed, a shader that did not compile in that browser, or a frame drawn before assets loaded.

Then look

The numbers catch breakage; your eyes catch ugliness. Open sheet.jpg and check each shot for:

• The subject cropped or tiny on the phone shot. 3D scenes should widen their vertical field of view on portrait screens; layouts should restack.
• Text over busy imagery without contrast.
• UI covering the subject, or sitting under the phone's home indicator.
• Lighting states that crush to black or clip to white.
• WebKit shots that differ from Chromium: colour (Safari ignores some colour-space hints), missing transparency (VP9 alpha video does not play in Safari), fonts.

Checks the script cannot do alone

Run these by hand or with frame-capture at a low frame rate (--fps 8), which is fast and exact:

• Seams and loops. Scrub every scroll film up and down fast; watch each join and the wrap of every loop. scroll-film/scripts/prep.py seams scores joins numerically.
• Pins release. At the end of every pinned section the page must scroll on without a jump.
• Long sessions. Leave the page running for a minute, switch light presets back and forth, resize the window a few times; frame time should not creep up (leaked geometries and textures show in report.json as rising counts).
• Throttled first load. With network throttling, the first paint should be the hero's poster or first frame, not a blank page.
• Interaction. Orbit, zoom, hover states, keyboard focus on every control, and touch on a phone.

Environment traps

• An embedded browser preview that is hidden, or a background tab, throttles or freezes requestAnimationFrame. A page that "does not animate" there may be fine. Headless browsers do not have this problem.
• python3 -m http.server ignores Range requests, so videos cannot seek and scroll-scrubbed video freezes. Use a server that answers them.
• A missing Playwright browser build after an upgrade: the script falls back to any Chromium in the Playwright cache; CHROME_PATH overrides it.

Report back

Lead with what is broken, ranked by how many visitors it hits: errors and blank canvases first, then phone layout, then Safari differences, then performance, then polish. Attach the contact sheet. Say what was not checked (no real phone, no Windows GPU, no slow network) rather than implying it was.