Performance

Performance is part of the experience

Speed shapes comprehension, trust, accessibility, and conversion. It also determines who can use a service under constrained devices, networks, batteries, and data plans.

Performance work begins with architecture and content choices. Optimisation at the end cannot fully compensate for unnecessary complexity introduced at the beginning.

Default priorities

HAAM evaluates performance in this order:

1. Deliver meaningful content quickly.
2. Keep primary interactions responsive.
3. Prevent unexpected movement during loading.
4. Preserve essential use under slow or interrupted networks.
5. Limit code, media, and third-party execution to what serves the purpose.

Measurement

Field data is preferred because it reflects real devices and conditions. Laboratory testing remains useful for diagnosis and comparison.

Reviews should consider:

• Core Web Vitals at representative percentiles;
• JavaScript transferred, parsed, and executed;
• image and font payloads;
• cache behaviour;
• third-party requests;
• server response time;
• behaviour on constrained mobile hardware and networks.

A single perfect score is not the objective. The objective is reliable performance across the journeys that matter.

Budgets

Important projects should define budgets before implementation. Budgets may cover page weight, JavaScript, image size, fonts, third-party scripts, server latency, or interaction delay.

A budget should have an owner and a consequence. A number that can be exceeded without review is only a measurement.

Resilience

Essential content and actions should remain available when optional scripts, analytics, animation, personalisation, or external services fail. Progressive enhancement is preferred for critical tasks.

Computational restraint

Every request and computation consumes infrastructure, energy, and attention. Reducing unnecessary work often improves performance, accessibility, maintainability, and environmental impact at the same time.