shakyShane

Agent Prompt: Rebrand BTF → turbo-shared (static-pages only)

Goal

Move (not copy) static-pages rebrand below-the-fold into packages/turbo-shared/src/btf/, then rewire static-pages only (mobile + desktop homepage variants) to consume it. home-mobile is out of scope for this task.

The refactor must surface and remove implicit environment coupling. BTF sections must not depend on static-pages-only contexts, stores, or global hooks. Side effects and consumer-specific behaviour belong at the composition boundary, injected via props, slots, or small effect components — not inside leaf sections.

Success = static-pages mobile + desktop homepages render BTF identically to today, with BTF living in turbo-shared and ready for home-mobile later without further architectural work.

shakyShane

Below-the-Fold Port Plan (v3)

Target: apps/home-mobile async chunk → @staticpages/turbo-shared/btf
Source: static-pages rebrand only (home-rebrand/, rebrand/, pages/app/)
Future: apps/home-desktop imports the same export
Gist: https://gist.github.com/shakyShane/aab408f0552fe7d692970ef4ee64a060

---

What we're actually building

shakyShane

How This Monorepo Builds, Merges, and Ships Static Pages

This repo is a Turborepo monorepo (npm workspaces + Turbo task orchestration). It does not run a long-lived Node server in production. Everything is pre-rendered at build time into plain HTML/CSS/JS files, bundled into a tarball, uploaded to S3, and served by nginx on DuckDuckGo's edge.

---

The Big Picture

flowchart LR

shakyShane

nextssg architecture experiments — comparison

Gist-style summary of two structural experiments on the DuckDuckGo nextssg homepage rebuild.
Baseline context: static export + experimental.inlineCss: true, three HTML products (noai, mobile promo, desktop stub).

---

What we are trying to solve

1. Cross-entry CSS bleed (performance)

shakyShane

nextssg homepage cross-entry CSS impact (engineer reference)

Build setup: experimental.inlineCss: true, static export compare (apps/benchmark/compare-static-export.mjs).
Baselines: origin/main @ 33f9144; mobile promo branch @ adfd823; thin-ATF experiment (no DS on mobile sync/lazy tagline edges) @ local thin-atf-exp.

---

Compressed HTML (gzip) — all three entry points

| Entry HTML | main (33f9144) | Branch + DS (adfd823) | Δ vs main | Thin-ATF (local) | Δ vs main | Δ thin vs branch+DS |

shakyShane

nextssg inlineCss and why lazy islands do not lazy-load CSS

Context: DuckDuckGo apps/nextssg static export with experimental.inlineCss: true (next.config.ts). This document explains why mobile homepage work inflated the noai homepage (/en-US → en-US.html) and why next/dynamic({ ssr: false }) does not keep CSS off the critical HTML path.

Measured on branch shane/mobile-promo-rebased-on-main vs main (33f9144 → adfd823), static export compare only:

Page	gzip (main → branch)	What changed
noai en-US.html	45.9 → 70.7 KiB (+24.8)	~78 KiB of new inline `

shakyShane

Homepage as static output vs self‑hosted Next (why the “not trivial in prod” warning aged well)

TL;DR: We already said self‑hosting Next for real traffic is not plug‑and‑play—especially if you want defense‑in‑depth at the edge (nginx allow‑lists, document caching, hiding Node). Recent work on this stack bore that out: caching alone spans nginx, HTTP semantics, Next’s output model, and (if you enable them) Cache Components. For a homepage that is not dynamic—many pre‑renderable variants, no request‑time personalization—the right tool is usually static build output + a CDN (or static bucket). You avoid runtime Node, Express, RSC flight plumbing, and the whole class of cache‑correctness debates that only exist when HTML is generated on demand.

This note is for folks who were on the fence when we chose static output for the homepage and heard pushback that “it’s all easy if we just use Next.”

---

What this repo already is (baseline complexity)

shakyShane

Deferring Next.js Cache Components (Express + custom handler phase)

One-liner: Cache Components are deferred until we’re off Express + custom Next; nginx + our existing Next usage are enough for now.

---

Decision

We are not adopting Next.js Cache Components (cacheComponents in next.config, 'use cache', cacheLife, etc.) while the application runs Express with the custom Next request handler.

shakyShane

Next.js behind closed-by-default nginx — notes for SRE / backend

What you’re optimizing for

Traffic hits nginx first. Node/Express is not on the raw internet path in the sense that:

• Unknown URLs stop at nginx (public/ file or 404); they never reach Express.
• Only explicit locations forward to the app (documents, /_next/image, health/debug, etc.).
• Heavy caching (especially /_next/static/ from disk, document proxy_cache for allow‑listed HTML/RSC paths) reduces origin load and absorbs a lot of read traffic before it touches Node.

shakyShane

Duck.ai Performance Comparison — 3G + 6x CPU

Date: 2026-03-24
Tool: Playwright (Chromium, headless)

	Production (current)	Candidate
URL	030c2a27bdaf.ngrok.app	5cc2bb9fdebc.ngrok.app

---