The page returned 200. The title was right, and the case studies were on it. The request was still marked, because one SQL shape had already run more than twice.
That mark is not a complaint about a slow statement. It is a complaint about a question the request already knew how to answer.
The shape is the unit
An N+1 is usually told as a loop: load the parents, then load each parent's children. The public site had a quieter version. Every CMS page was read with the same statement, select * from cms_pages where slug = ?, and a different slug.
Home asked for home, about, and research. The SEO document then asked again for the current page, for about (the topics on the person record), and for research (the ORCID). Six executions of one shape. A contact page did four. The sitemap walked every public route and asked once per slug.
| Surface | What repeated | Times |
|---|---|---|
| Home | A CMS page by slug | 6 |
| A public page | A CMS page by slug | 4 |
| Sitemap | A CMS page by slug | 12 |
| Every request | Whether integrations exists | 3 |
None of those statements was expensive alone. Together they were the same question, asked again because each caller owned its own lookup.
Load the set the response will read
The pages a public response needs are known before the first one is touched. Home needs home, about, and research. A case study needs about and research for the shared document. The sitemap needs every public slug.
slug = ? -> slug in (home, about, research)
Those slugs go into one query. The models stay on the request. A later read of the same slug does not query again, and a slug that does not exist is remembered as missing so a 404 does not become a second lookup.
The sitemap and the llms file do the same thing before they walk the routes. The walk still happens. The database work does not.
A schema check is the same kind of repeat
Every request also asked whether the integrations table existed: once while applying Pusher, once while finding that row, and once while applying Google Calendar. The statement was an information_schema probe, not a CMS page, but the shape was identical.
A missing table is not remembered. A migration can create it later in the same process, and a stored “no” would hide the table after it appears. A stored “yes” only skips the probes that would have returned yes again.
The page was already correct
The change did not alter what the public pages say. It changed how many times a request may ask for the same fact.
A loaded page is not evidence that the query path is finished. The evidence is the set of statements, and whether any shape had to be repeated because two parts of the response did not share what they had already read. That is the same discipline as the engineering notes: a limit should be visible before the next change turns it into an incident. The note on operational visibility makes the adjacent point. A successful response should not be the first place a repeated question becomes obvious.