Building applications for speed
Responsiveness is an important aspect of a good user interface. Unfortunately, it is a shame how few Notes/Domino applications are built with speed in mind. Today, I had to fill in a web/notes query which went back to the server for each question, and every time it took between 14 and 32 seconds. My Notes web mail interface is not much faster: it takes between 12 and 17 seconds before it opens. This makes you wonder if it is even possible to build a fast Notes application.
Perception of speed
- Merely opening a new page should be almost instantaneous, within 0.2 seconds. From a 2 seconds delay onwards, you should provide a 'loading' message. Just by having this message waiting time seems much less.
- Users seem to accept delays when they know there is work involved: comparing things, building a report, saving a document, preparing a search result.
- Older people seem to be prepared to wait much longer than young ones before they loose their interest. People new to a site decide if they like it or not within 5 seconds.
Building fast responding applications is not only a matter of keeping users happy. How much time is lost with a 10 second delay on a mail application which 500 users open 3 times a day, 400 days a year?
Things that makes you slow
- WebQueryOpen agents, especially on home- and index pages
- Views with documents containing Reader fields
- View Column formulas, especially those involving time
- Lots of @DbLookup formulas on a form
- Too many views
Getting global data fast
My Database profile document contains all the global settings of my application. It is a single document from a DbProfile form. I didn't want to make it a ProfileDoc, because they are cached and it can take minutes before changes are visible. Instead, I stored the DocumentUnid in a profile field. On the DbProfile document itself, I collected all the information in one single computed field, formatted as an XML fragment.To retrieve this data, I used @GetProfileField to get the DocumentUnid and @GetDocField to get all the global data I need in one go, without one single @dblookup.
Store HTML or XML fragments
Instead of computing HTML or XML in the view with column formulas, I prepare complete chunks of HTML or XML and store them in computed fields on the documents themselves. This technique is called 'pre-rendering'. The benefit: view columns contain just the field value. To make my views as fast as possible, I pre-render all column values that way. After all: they only change when a document is modified and saved.
Re-use lookup views
Instead of making a new view for every @dblookup I have to make, I made one very abstract lookup view that enables me to look up all sorts of things by pre-rendering different things for the fields used for every form:
- column 1, categorized: field vKey
- column 2, sorted: field vSort
- next columns: the values (pre-rendered)
Other speed tricks
With Ajax, you can load part of the page, display it and fill in the details later. Also, you can update only parts of the page without refreshing the complete page over and over again. These techniques can give a far richer and more consistent user experience.
If you do DOM scripting, modifying the content of a page directly causes the page to refresh itself all the time. Just clone the node, work on the clone and replace the original node with the modified clone as a last step. This will cause the page to repaint only once instead of every time you changed something.