I opened DevTools on all 72 of our pages and the console said one thing, 72 times

Everything on PubTrivia that a visitor can reach without logging in is 72 URLs. I drove Chrome through all of them with the Log, Runtime, Audits and Network domains enabled, waited 2.6 seconds on each, and collected everything the browser had to say.

The headline numbers:

• 0 console.* calls, on any page
• 0 uncaught exceptions
• 0 responses with a status of 400 or more, out of 3,410 requests (24 to 62 per page)
• 21,139 elements rendered across the 72 pages
• 1 browser warning, and it is the same warning every time

A static marketing site with no analytics, no tag manager and no third-party widgets is a quiet place. That is most of the value of this sweep: it establishes that anything the console does say is worth reading, because nothing else is competing with it.

The one warning

<meta name="apple-mobile-web-app-capable" content="yes"> is deprecated. Please include <meta name="mobile-web-app-capable" content="yes"> 

Seventy-three entries across 72 pages, which is to say every page plus one double-fire during a navigation. It comes from two hand-written lines in our root layout:

<meta name="apple-mobile-web-app-capable" content="yes" /> <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" /> 

Those lines predate our use of Next's metadata API for everything else on the page, they are the only two <meta> tags on the site written by hand, and the standardised replacement Chrome is asking for appears on exactly 0 of 72 pages. The second line is not deprecated but only does anything in standalone mode, which for us means after somebody installs the site from the manifest. Two legacy iOS hints, one of them now shouting on every page load in the browser with the largest market share.

It is a two-line fix and nobody had noticed, because nobody opens a console on a page that works.

What the Issues panel adds

The Audits domain is the protocol behind DevTools' Issues tab, and it reports things the console never prints. Two issue classes are ours.

LazyLoadImageIssue, on 69 of 72 pages. Chrome flags an image that is in the initial viewport and marked loading="lazy", because the attribute delays a request that is needed immediately. The image is our 606 byte header logo, which carries loading="lazy" and no priority. The three pages that escape are the privacy policy, the terms and the cookie policy, which use a different header with a text wordmark and ship no image at all. So the issue count is not 69 pages doing something unusual, it is one component on 69 pages and three pages that do not use it.

GenericIssue, on exactly one page. The round planner produced 12 of FormEmptyIdAndNameAttributesForInputError and one of FormLabelHasNeitherForNorNestedInputError, and no other page on the site produced a single form issue.

The page has 15 controls. Three of them (start time, break after round, break length) have ids and real <label for> pairs. The other twelve, six number inputs and six selects, look like this:

<input type="number" aria-label="Round 1 questions" min="1" max="20" value="10" /> <select aria-label="Round 1 type"> ... </select> 

Every one of those has an accessible name, which is why our own accessibility audits have always reported this page as clean, and Chrome is complaining about something else: with no id and no name, the control has no identity for autofill, and would submit nothing if it were ever inside a form. For a calculator that keeps its state in React and posts nowhere, the practical cost is zero. The reason it is still worth knowing is that aria-label quietens the accessibility linter while leaving the autofill contract empty, so the same shape on a real form is a silent bug rather than a loud one.

The thirteenth issue is more straightforward. The page has a fourth <label> whose text is "Rounds", used as a heading above the six round rows, pointing at nothing:

<label class="text-sm font-medium ...">Rounds<span ...> 

A <label> with neither for nor a nested control is a heading wearing the wrong element.

For completeness, the login page is not in the sitemap and so not in the 72, but it reports its own pair: FormInputAssignedAutocompleteValueToIdOrNameAttributeError, plus a verbose log suggesting autocomplete="current-password". The auth forms carrying no autoComplete attributes is a thing we already knew and wrote about; it is reassuring that Chrome agrees without being asked.

The issue class I nearly filed against myself

One more issue appeared on 71 of the 72 pages: PerformanceIssue of type DocumentCookie, which Chrome raises when something reads or writes document.cookie synchronously. On a site that sets no cookies at all, that looked like a genuine find.

It is not ours. The evidence took three steps:

1. The issue's sourceCodeLocation carries a scriptId with an empty URL, so it is not any file we serve.
2. I installed a getter and setter trap on Document.prototype.cookie through Page.addScriptToEvaluateOnNewDocument, which runs before any page script. It recorded zero cookie accesses on three different pages.
3. The same trap on Storage.prototype.getItem caught a stack frame from chrome-extension://.../webext-ad-filtering-solution/content-main.js reading a key called ab-filters-config, which is an ad blocker in my browser profile.

Content scripts run in an isolated world, so a page-world trap cannot see their cookie access, but Chrome's instrumentation can, and it reports the issue against the page the extension is running on. Two lessons: sweep in a clean profile when you can, and before you fix an issue the browser reports, confirm the code it points at is yours.

If you want one number out of all of this: on 72 pages, the browser raised four distinct complaints, one of which belonged to an extension, one of which is two hand-written meta tags, and two of which live in a single free tool.

Check it yourself

Open the console on any page of pub-trivia.app and you will see the deprecation warning on its own. Switch to the Issues tab and you will see the lazy logo. Then open the round planner, inspect any of the six round rows, and look for an id on the number input: there is an aria-label where you expect one.