Speed & benchmarks

The speed of your application is incredibly important to keep on top of, as a slow application is one of the main reasons why users lose engagement.

Most web frameworks come with a page showing off benchmarks of speed, but this page is not going to be that. It's more of an explanation as to why chasing benchmark scores is not healthy for real world application development.

When a measure becomes a target, it ceases to be a good measure.

Goodheart's law

As a rule of thumb, WebEngine considers applications "fast" if they perform an operation within 200 milliseconds of the user's click. Any slower than this, WebEngine emits a warning to the console, warning the developer that there is a slow page. This is as high resolution as WebEngine cares about when it comes to speed: if something is "fast" or "slow" is whether or not it can be easily performed within 200 milliseconds. Going any deeper into the numbers is purely academic.

This decision is important to maintaining an efficient workflow, and what makes WebEngine so fast at getting an idea out of your head and into a web browser: 99% of all user interactions will be well within this speed, so any optimisations to most operations will be worthless in the eyes of the user. Only worry about optimising page speed when pages actually become slow.

Why do pages become slow?

There are two reasons for a page to perform slowly, and you are in control of both of them:

1. The user's internet connection is slow, flaky, or unreliable.
2. The page is trying to do too much at once.

If the user's internet connection is to blame, you still have control over how your application performs. It's possible to make a WebEngine application blazingly fast on a GPRS connection using [modern web technologies][service workers], as long as you follow the rule of a distinct logic authority.

If your page is trying to do too much at once, the first way to keep the page fast is to try and do less. Is your database query performing unnecessary nested joins? Are you loading an entire file into memory when all you need is a single row from a CSV? Do you make a remote connection every time the user visits the page? You may want to [cache parts of the page][caching], so you only have to do the work once every so often, or only when underlying data changes.

Once you've made a good assessment to what is actually necessary on your page, and you are confident that the page's code is as efficient as possible, but the page is still triggering a speed warning, you can make the page feel faster by using multi pass rendering - this is simply performing the operations that make up the page concurrently, rather than at the first render, and is often referred to as "ajax" or "background fetch".

Read more about WebEngine's core principals that drive these decisions.