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.