Web development

Performance is not a finishing touch, it is a design constraint

You do not make a slow application fast: you rebuild it. Speed is decided at architecture time — what is rendered on the server, what ships to the browser, what never needs to exist at all.

It is also measurable, and public. Google assesses every site on three indicators, at the 75th percentile of real visits over a rolling 28 days — in other words on what three quarters of your visitors actually experience, not on a lab test:

• LCP — main content rendered: under 2.5 s
• INP — responsiveness to interaction: under 200 ms
• CLS — visual stability: under 0.1

These thresholds are our starting commitment, not a target to negotiate at the end of a project.

Choosing the right amount of JavaScript

Most slow sites are slow for one reason: they ship an entire program to the browser where a page would have done. We decide page by page.

• Static page — editorial content, presentation pages, articles. Rendered at build time, served as is. Nothing to execute on the client.
• Server rendering — personalised content, or content that changes on every visit. The browser receives complete HTML and waits for nothing.
• Interactive islands — only the components that need it ship JavaScript: a form, a filter, a map. The rest of the page loads none.

This site is the illustration: it is built with Astro, and most of its pages load no application script at all.

An application is judged over five years, not at launch

The cost of an application concentrates after delivery. Three choices weigh more than all the others:

1. Types end to end. TypeScript from the data model to the interface. A schema change that breaks something says so at compile time, not in production six weeks later.
2. Tests that describe rules, not states. A test asserting "the home page lists twelve articles" breaks at every publication. A test asserting "every published article appears in its index" holds.
3. Dependencies you can remove. Every library is future debt. We take few, chosen for their stability and for the possibility of leaving them.

Measuring delivery, not activity

We track the four reference indicators from the DORA programme, which separate teams that ship from teams that look busy: deployment frequency, time from commit to production, share of releases that cause an incident, and time to recover.

They have an unusual property: they do not reward caution. A team that ships rarely to "limit risk" shows up as exactly what it is — a team for which every release is a risky event.

Reworking what exists rather than rewriting everything

A full rewrite is almost always the wrong call: it freezes progress for months and replays the same mistakes on newer technology. We prefer to isolate what causes trouble, replace it behind a stable interface, and leave the rest in place for as long as it earns its keep. A system that works deserves better than a rewrite on principle.