My sign-in page loads from three hosts I do not own and the rule against that is green

A two minute check, and the answer is probably a page you have never thought of as a page.

List every URL a logged out stranger can reach on your site. Then find whatever rule you keep about what those pages are allowed to load: no third party hosts, no analytics before consent, a content security policy, whatever yours is. Now look at what that rule actually iterates. Not what it says. What it loops over.

Mine is a test that forbids any public page from blocking its own render on a host I do not own. It reads its page list out of the application rather than from a hand picked array, which was already a fix once, because the hand picked version had left three legal pages unchecked. Seventeen pages. Green for weeks.

Here is what a stranger can reach that is not among the seventeen: sign in, sign up, forgot password, reset password, delete account, the first screen of the signup wizard, and the page a customer of my customer lands on after paying an invoice.

The sign in page, measured against production this morning: a CSS framework at thirty one kilobytes gzipped, an icon stylesheet at thirteen, and a JavaScript bundle at twenty four, all render blocking, all from one CDN. Beside them a font stylesheet from a second host behind two preconnects. The icon stylesheet then asks for a font file of a hundred and thirty kilobytes, which the browser cannot know about until the stylesheet has parsed, so it is a third hop.

Three details make it worse than the total. The JavaScript bundle drives nothing at all: no component attribute anywhere in those views and no call into the library. The font stylesheet fetches three weights of a typeface that is already sitting in my own directory, self hosted, in the same format. And the icon font is a hundred and thirty kilobytes for six glyphs.

The payment return page is the one I would least like to have written. Two glyphs, a hundred and thirty four kilobyte font, and a different version of the same icon set than the sign in page uses, so somebody who meets both pages downloads two complete icon fonts. That page is not even read by my own user. It is read by the person who was just asked to pay them.

My entire public stylesheet is three point three kilobytes gzipped. That is the number that makes this embarrassing rather than academic. The pages I optimised are tiny, and the page where the account actually gets created pulls twenty times that much from three hosts I do not own, before the icon font is even discovered.

Why it survived is the part worth taking away. The rule was written about public pages, and the list is the marketing pages, because those are the ones somebody thought of as public. A sign in page is public in every sense except the one the list measures. The same thing happened once before here and was caught on the error page, and the fix was to name the error page explicitly in the test, which is to say the fix stopped at the page that prompted it.

So: which page does a stranger reach on your site that your own definition of public does not include, and does your rule iterate a list somebody wrote, or the route table itself? I have not found a way to make mine iterate the route table that does not immediately drown in endpoints that render nothing.