Hono root · under 14KB
Fast by default, tiny on first load.
Single route, single HTML response, no external assets. This keeps the initial payload lightweight and predictable.
Tip: add more routes or assets later, but keep the landing shell lean.
Why the payload is deliberate
This page adds visual polish and real content while staying inside a strict first-load budget. The goal is to ship a usable landing surface without hiding behind heavy scripts, late-loading stylesheets, or third-party fonts.
Instant paint
Inline CSS keeps rendering predictable and avoids extra network hops.
Readable hierarchy
Scaled headings, soft contrast, and a warm palette build trust.
Clear intent
No hidden assets. What the user sees is what they download.
- Zero external requests on initial view.
- Body text tuned for longform reading and small screens.
- Design tokenized with simple CSS variables.
- Layout adapts from a single column to a multi-card grid.
- Background uses a soft radial wash for depth.
Payload meter
===============================
Budget target : 12,000 bytes
Current shape : HTML + inline CSS
Network calls : 0
Font requests : 0
Script bytes : 0
------------
The smallest product is the one that renders.
The fastest page is the one the browser can paint immediately.
Keep the core readable, keep the shell light, and only add what earns its bytes.
Let content pull weight.
Let contrast guide the eye.
Let speed be the feature that users can feel.
------------
Notes
- If you add images, compress and pre-size them.
- If you add scripts, defer and keep them tiny.
- If you add fonts, self-host and subset.
===============================
Short manifesto for tiny pages
Every kilobyte is a promise. It is a promise that the user will see something immediately, before their attention slips or their connection stutters. Keeping the first view slim is a design decision as much as an engineering one.
Lightweight does not mean empty. It means intentional: the first screen carries the story, the tone, and a path forward. A page like this should feel finished even when it is only the beginning.
We can trade fancy effects for clarity, and we can trade a font file for a line of copy that lands. That is the tradeoff: bytes for meaning. Choose meaning whenever possible.
Small pages are honest. They show what matters, hide what does not, and load as fast as the browser can paint. There is no second guess, only the reality of what was sent.
Speed is a product feature. It is the difference between a user who keeps reading and a user who closes the tab. Treat the budget like a set of guardrails, not a constraint.
When you do add weight, make it count. Every script should earn its place. Every image should tell the story. Every style should help the reader move.
Designers can lead this shift by composing systems that work without dependencies. Engineers can help by removing the invisible glue and shipping fewer files.
Measure, then decide. The act of measuring teaches you where the bytes go. It turns the page into a map, and the map shows the shortcuts.
For this demo, the shortcut is simple: one request, one response, one render. It is not the end state of an app, but it is the cleanest possible start.
If you keep the root lean, every other route starts with a head start. That is the advantage of a tiny first impression.
Field notes from the 12KB edge
The easiest way to ship fast is to remove invisible work. That means no font waterfalls, no oversized frameworks, and no extra round trips for pieces that can be delivered in a single response.
The second easiest way is to make choices that are gentle on the network. A warm background gradient costs almost nothing. A pattern of words can do the work of a hero image if the words are honest.
When the budget is tight, typography becomes the hero. Choose a readable serif that already exists on the system and you get elegance without downloads. Choose comfortable line length and spacing, and users stick around.
Finally, remember that first load is a handshake. It does not need to explain everything, only enough to feel trustworthy. The rest of the story can unfold after the user chooses to keep going.
Budget checklist
01 Inline critical styles, avoid unused rules.
02 Prefer local fonts and resilient stacks.
03 Keep the HTML semantic and stable.
04 Compress copy; write for clarity.
05 Skip auto-playing media on entry.
06 Avoid render-blocking scripts.
07 Use lightweight gradients for depth.
08 Keep layout simple, responsive by default.
09 Measure raw bytes, not just gzipped size.
10 Send only what you can justify in a review.
11 Render above-the-fold instantly.
12 Add enhancements after the first paint.
13 Make every animation purposeful.
14 Prefer static SVG over heavy bitmaps.
15 Save images for when the story needs them.
16 Be explicit about cache behavior.
17 Test on a slow connection, every time.
18 Remove anything the user does not notice.
19 Document the budget like a feature.
20 Celebrate when the page loads instantly.
Byte diary
Think of this as a logbook. Each entry is a reminder that performance is cumulative, and the page gets heavier the moment we stop paying attention. The diary keeps us honest.
Small, direct, and confident pages earn trust. They tell the reader that the team cares about time, bandwidth, and attention, and that care is visible in every byte shipped.
It also gives us a place to record intent. Why was a byte added? What did it earn? If the reason is not clear, it is a hint that the byte should probably be removed.
By keeping the narrative close to the markup, the page can serve as its own documentation. That is the real trick: the design explains itself without extra tooling.
When we hit the budget, we stop. We choose to edit, not expand. That restraint is what keeps the experience crisp and the payload small enough to feel instant.
Entry 001 A single route ships a complete page.
Entry 002 No external fonts; the system stack does the job.
Entry 003 The background gradient gives depth with zero images.
Entry 004 Cards are just boxes and copy, nothing more.
Entry 005 A manifesto earns bytes because it clarifies intent.
Entry 006 The checklist keeps scope creep in check.
Entry 007 The layout survives small screens without extra code.
Entry 008 Performance is the north star, not an afterthought.
Entry 009 Every line of CSS should change the outcome.
Entry 010 If the page feels slow, remove before you add.
Entry 011 The budget is a design tool, not a constraint.
Entry 012 A clear first screen beats an ornate one.