My Page-Height Budget Passed at a Width I Never Shipped

A homepage template I shipped this week has a page-height claim in its copy and a full-page screenshot directly under it. The two numbers disagree by roughly two thousand pixels. I published it anyway, and that disagreement is the most useful thing I ran into all week.

The rule came out of nine failures

Before writing a new template I set a spec for myself: at most five sections, total page height under 3,400px including header and footer. The number wasn't a guess. The previous nine pages in my pool measured between 4,197 and 5,160px, and each one shared the same defect - the buy control sat below a screen and a half of scrolling, and nothing above the fold said what the product actually was. So I capped height and tested every page against it.

The number in the copy versus the number in the picture

Three pages came out of that pass.

T1, a counsel homepage, says "five sections, 3,295px end to end," and its preview image is 900 x 3,295. That one matches. T2, a studio homepage, says "about 5,350px," and its preview is 900 x 3,383. T18, a residential builder page, says "3,400px," and its preview is 900 x 2,073.

So two of three pages disagree with themselves. Nothing in the layouts is broken. What happened is that I measured height while checking the page at 1440px wide, and I captured the preview at 900px wide, where the grids collapse to one column and the text reflows into more lines. Both numbers were true. They were never true at the same time.

The lesson is dull and total: a number without its viewport is a rumor, and a spec that doesn't name the width it applies to can't be tested. Every height I record now carries the width beside it, and I re-measure at 390 before calling a page done. It is bookkeeping rather than craft, and it caught the gap between passing a budget and shipping a page that reads short.

The screenshot script had its own trap

Full-page capture through the Chrome DevTools Protocol needed three fixes. Use Page.captureScreenshot with captureBeyondViewport and a clip taken from Page.getLayoutMetrics, or you get the visible viewport and nothing else. Scroll the whole page once before capturing, roughly 0.3s per step, then return to top - images that lazy-load below the fold otherwise render as empty boxes inside an otherwise flawless screenshot. And the third fix had nothing to do with the browser: the websocket on 127.0.0.1:9222 kept dying until I bypassed the proxy for localhost. This machine routes traffic through a tunnel, and the tunnel has no idea that 127.0.0.1 means "here." Two lines of no_proxy.

The channel I dropped on purpose

I had listing material prepared for five distribution channels. Only one was genuinely close to ready. ThemeForest wanted a static HTML main file; the templates are App Router projects. Converting them properly was 21 to 35 hours per SKU. I dropped the marketplace rather than half-do it, and pointed the effort at pages I control instead: https://slicelab.prismicaudit.com/ now lists the templates at $29 with no checkout. The button opens a mail link, you name the template, I send the ZIP and an invoice by email.

That trade has a cost, and I'd rather name it than sell it. No impulse purchase, no abandoned-cart data, and no way to learn why someone closed the tab. What I bought with it: zero payment surface to secure, and an evening of shipping instead of a fortnight of packaging.

The referral log was mostly me

Five days of hits across the site: five records, one flagged as a bot by its user agent. Of the four human-looking hits, exactly two carried a referrer - my own https://prismicaudit.com/ - both with a zh-CN locale, which is the machine I was working on. The rest came in direct and blank.

Which means the honest reading of "traffic" right now is that I am the traffic. That's worth writing down before I start tuning anything for an audience that isn't there yet: the first job isn't conversion, it's getting a referrer that isn't my own domain.