Lighthouse 100s as a build target

Fri, 15 May 2026 00:00:00 GMT

Most teams treat Lighthouse like a quarterly health check. astro-ignite ships with the assumption that performance is a test, not a metric — your build fails before the regression ships. The mechanics aren't novel; the discipline is.

This piece walks through the budget contract, what we learned migrating four projects to it, and why agents tend to handle this kind of constraint well.

The budget contract

Each route can declare its perf budget next to the route itself, not in a global config file. CI runs Lighthouse against the production build and refuses to merge if any score drops below 95 or the JS bundle grows by more than 5%.

export const budget = {
  lcp: 2500,    // ms
  cls: 0.1,
  inp: 200,     // ms — was FID pre-2024
  js:  18000,   // bytes, gzipped
};

Keeping the budget in the route means changing it is a code review, not an ops conversation. The reviewer sees the budget delta in the same diff as the feature that needed it. That alone catches most regressions before CI does.

What we learned

Hitting 100 once is not the hard part. Keeping the 100 as features land is. Treat perf the way you treat types: an invariant the build enforces. The first month of any project gets noisy; people will hit the budget on accident. After that the team self-edits. PR descriptions start including budget deltas without anyone asking.

Failure modes

The most common false-positive is a flaky LCP measurement on cold cache. Run Lighthouse three times per route and take the median. The most common true positive is a new image without an explicit width × height. A lint rule catches that one cheaply.

Performance is a feature. The moment you make it failable, you can stop arguing about it.

Why this is agent-friendly

Agents are good at small, local optimizations and bad at remembering global constraints. Budgets-as-code give them a feedback loop they can act on — fail, read the diff, fix, re-run. In practice agents converge to a passing perf budget in two or three iterations without human intervention.

One gotcha: if you let an agent dynamically adjust the budget to make a failing build pass, you'll end up with a slow site over time. Budgets must be human-edited. The build enforces the contract; the contract itself stays out of the agent's reach.

Closing

Lighthouse 100s aren't a marketing number. They're the artifact of treating performance as an invariant. astro-ignite ships with these budgets pre-wired — eject them, tighten them, swap the metrics, but please don't delete the check.

What is astro-ignite?

Tue, 12 May 2026 00:00:00 GMT

astro-ignite is a CLI for starting Astro projects that should feel closer to a finished product than a blank starter. It gives you a real Astro site with routes, content collections, SEO plumbing, i18n, legal pages, analytics consent, and a working contact flow already wired together.

The important part is ownership: the generated site is just code in your repository. There is no runtime dependency on astro-ignite after scaffolding, no hidden framework layer, and no upgrade treadmill. You can keep the conventions, change them, or delete them.

Why it exists

Most new Astro sites repeat the same early work: choose a structure, wire metadata, add content collections, configure images, build navigation, think about legal pages, add a cookie banner, and keep performance from slipping while doing all of that.

astro-ignite packages those decisions into a scaffold so you can start from a strong baseline instead of a todo list. The defaults are opinionated because production quality requires decisions, but they stay visible because the output belongs to you.

What it creates

A generated astro-ignite site can include:

A marketing homepage with production-ready layout patterns.
A blog powered by Astro content collections and MDX.
Project or case-study pages for portfolio-style work.
Native Astro i18n with default-locale routes at / and translated routes under /[lang]/.
Typed Schema.org JSON-LD composed into a single graph.
Responsive images with stable dimensions and optimized output.
A dark-mode toggle, locale switcher, cookie banner, RSS, sitemap, robots, and manifest.
A contact form using Astro Actions, validation, honeypot protection, and your chosen email transport.

The goal is not to hide complexity. The goal is to put the right pieces in place so you can inspect them, learn from them, and ship with fewer missing basics.

What makes it different

astro-ignite follows the same spirit as shadcn: you do not install a black box component library, you copy code you can own. The CLI is the installer. Your app is the product.

That approach matters for small teams and AI-assisted development. Agents can work better when the project has clear conventions, typed data, predictable folders, and local examples to copy. Humans get the same benefit: fewer decisions are implicit, and the site remains editable without learning a private abstraction.

Who it is for

astro-ignite is built for developers who want a serious Astro starting point for marketing sites, blogs, documentation-adjacent sites, portfolios, and small product websites. It is especially useful when SEO, speed, internationalization, and owned code matter from day one.

It is not trying to be a CMS, a design tool, or a full application framework. It gives you the production foundation. You bring the product, the content, and the parts that make the site specific.

Where it is heading

The current focus is a strong v1: templates that are complete enough to ship, a CLI that asks the right setup questions, and a registry of Astro-first UI primitives. More templates and blocks can come later, but the core promise stays the same.

Run the CLI, get a site, own every line.