Speed and benchmarks

What "fast" should mean

Fast should mean responsive to the user, not simply impressive in a benchmark chart.

Framework benchmark contests are often misleading because they optimise for artificial workloads rather than for the actual behaviour a user experiences in a real application.

Where performance is necessary

The places that usually deserve attention are:

• slow queries
• heavy rendering
• oversized assets
• too many network round trips

These are all practical bottlenecks that a user can feel.

Practical performance guidance

Measure user-facing operations first. Optimise after you have found a real bottleneck. Simplicity, clear architecture, and avoiding unnecessary work are often the biggest performance wins.

WebEngine's static-first pages, thin page logic, and server-rendered HTML all help because they reduce the amount of work that needs to happen before a useful response can be shown.

---

Finally, let's move to the repository-entity pattern page to complete the further reading chapter.