Revised October 9, 2026. This article now centres on a documented Luminesca release. The previous framework-led introduction and old byte totals were not a current measurement of these pages. We retain the distinction between vendor benchmarks, local laboratory tests and real visitor experience. AI assisted drafting; the published evidence below records the scope.
Choose a visible failure before choosing a framework
Our October 9 GitHub Lighthouse run failed because the Tools homepage scored 90 for accessibility against a required 95. Category counts were rendered with reduced opacity, and a link in the privacy explanation depended on colour for identification. We removed the opacity reduction and added a persistent underline. Those changes addressed actual elements reported by the audit.
The original check also warned about oversized homepage images and other categories. We treated these as separate findings. A successful functional test would not correct weak contrast, and clearer text would not reduce image transfer. Keeping a small list of concrete symptoms made it possible to review each change without introducing a new framework or rewriting the tool interface.
When investigating your own page, record the URL, exact element, viewport, browser version and failing audit. Save the report before editing. If the visible page does not match the source you are reading, resolve that deployment or cache mismatch first. Otherwise you may repair a file that the visitor is not receiving.
Provide cover sizes that match the layout
We added responsive WebP choices to 23 raster image positions across the Games, Travel and News homepages. The release contains 60 distinct variants. Existing alt text and original files were retained, and the crop followed the existing cover layout. An image-size optimisation does not establish permission to use the underlying photograph or game image; that requires separate provenance evidence.
The file-size inventory illustrates the opportunity without pretending to measure every visit. The Travel positions totalled 1,150,380 bytes in their original resources; the smallest listed versions totalled 121,336 bytes. A browser can select a larger variant for a wider or denser screen. Therefore the difference between those totals is not a universal per-visitor saving or a controlled before-and-after speed measurement.
For a reusable check, inspect the image's selected source at several widths. Confirm that the picture is sharp enough for its displayed size, retains a useful crop and has dimensions that reserve space. Test the actual published URL, since a correct local file cannot prove that the deployed page references it.
Read the dated laboratory results with their limits
The following values are from three runs per public homepage on October 9, using Lighthouse 11.4.0 with desktop settings in local Chrome Canary. Performance is the median category score; CLS is the maximum observed value across those three runs. They are snapshots of these runs, not a claim about every device or visit.
| Homepage | Performance | Accessibility | SEO | Maximum CLS |
|---|---|---|---|---|
| Main | 98 | 100 | 100 | 0 |
| Games | 98 | 100 | 100 | 0.024 |
| News | 95 | 100 | 100 | 0.006 |
| Tools | 99 | 100 | 100 | 0.009 |
| Travel | 91 | 100 | 100 | 0 |
Download the dated measurement summary to see the URLs, run counts and exact recorded metrics. The independent GitHub job for the same release also passed its existing blocking checks. We did not lower the thresholds. Best practices remained at 81, with a warning linked to deprecated browser APIs in Cloudflare's security script; the security protection was retained.
Google's Lighthouse scoring explanation describes how performance measurements become scores. A category score is not a transaction success rate or an editorial quality assessment. Google's Core Web Vitals methodology treats LCP, INP and CLS as field metrics, assessed at the 75th percentile. Our short laboratory sample is not that field population, and lab TBT is not a substitute for observed visitor INP.
Verify the file the visitor receives
Shared resources can remain cached after the source changes. We changed the version in the resource URL and compared the published bytes with the intended release. That check covered 67 resources: six privacy scripts, the Tools stylesheet and 60 image variants. A response status of 200 alone would not have detected an older stylesheet returning successfully.
The verification also exposed a useful limitation. An initial ordinary Python request received 403, while the existing Node HTTP client could read the resources. We recorded both outcomes and did not change security settings to make the first probe green. Neither test proved how Google's genuine crawler was treated; that would require the corresponding service or verified request evidence.
Check the network behaviour behind a privacy promise
A page can wait for a statistics choice while a hosting-layer feature injects a measurement script earlier. We found an enabled Google Tag Gateway with automatic tag setup, disabled that feature and checked six anonymous domain visits. No gateway injection or Google Analytics, Ads or DoubleClick measurement request was observed in those default visits.
The separate functional checks covered choices, withdrawal, GPC/DNT and representative tools. Receivers were intercepted to inspect attempted requests; this does not establish what data a remote service deleted. It also does not turn our statistics choice interface into a certified advertising consent platform. A privacy statement must describe the actual scope, including hosting and security processing.
A release sheet you can reuse
- Save the original failure and identify the exact page and element.
- Make the smallest relevant change and keep the existing acceptance rule.
- Publish an independently checked release; version changed shared resources.
- Read back the real resource and compare it with the intended file.
- Check narrow and wide layouts, then perform the main user action.
- Read the remote CI result and list remaining warnings separately.
Our responsive checks covered 390, 768 and 1440 pixel widths, and the Tools test exercised category selection, no results and reset. These are useful acceptance examples, not exhaustive accessibility certification. Keep a separate field for tests you did not perform, such as a real advertising fill or an extended field-performance sample.
Historical measurement boundary: the October 9 laboratory results and 67-resource check describe that dated release. Subsequent October 10 image replacements changed the assets. Those older byte totals and tests are retained as historical evidence, not a measurement of the current pages. Current release checks must compare the resources actually referenced today.
A worked release record: keep the failure and the retry
Suppose a mobile menu opens but Escape does not close it. A successful HTTP response has not tested that action. Record the failed action, repair its keyboard handler, then repeat the action on the published page at the original viewport. Separately compare the changed script's published bytes with the release file. These are two different results: behaviour and release identity.
| Check | Record | What remains unproven |
|---|---|---|
| Menu interaction | URL, viewport, open state, Escape result and focus after closing | Every keyboard path, screen reader and physical device |
| Published script | Actual versioned request URL, expected and observed SHA-256 | That every user or region received this response |
| Loading timeout | Initial error, request still pending, retry conditions and result | Long-term availability and real-user loading speed |
| Content check | Claim, named source, date and review boundary | That unreviewed claims became correct because layout passed |
Keep an initial timeout in the record even if a later retry succeeds. If the retry changes concurrency, browser or network, state that change. A retry may show that a page loaded under the new conditions; it does not establish the cause of the first failure. A recurring failure needs a resource or runtime investigation before it can be closed.
For an editor that previews a user's document, count the tool page heading separately from headings inside that labelled preview. Keep the document's own structure intact. For an ordinary article, an accidental second visible page title remains a defect.
Download the blank release record (CSV). One row represents one page, viewport and check. Fill in observed values; leave unsupported conclusions blank. A hash comparison is appropriate for controlled static files, while an API result needs its own status, data date and input validation.
When reusing the sheet, begin with the failing action rather than a score target. After the fix, repeat the same conditions, then add a published-resource check. Record a remaining limitation as a limitation. This worksheet was added on October 11, 2026; the October 9 measurements above remain historical.