Web response times

Have you ever spent your time just sitting and waiting for your computer to finish something? I know I have. Heck, my machine is taking so much time to boot that I'm keeping it on as much as possible, just to avoid the wait.
As a developer, I spent a lot of time making sure that users of my applications won't complain about response times. As it turns out, response time limits are already well researched:

• 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
• 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
• 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

Now, as you may notice, these refer to wall clock time.
Loading speed for a web page depends on time required by web server to prepare the response, time needed to transmit it over the network and time needed to present it to the user. As a rule of thumb,

Make it as fast as possible...

If preparing the response is slow, no delivery mechanism can make the application instant again. Here the usual rules apply:

• Profile your code to see which part is taking up the most time, then improve it until you're satisfied.
• Alternatively, get more powerful hardware

If transmission is slow and user's connection is the problem, there are still a few things that can be done, for example:

• Separate static and dynamic content to make use of HTTP caching
• Minify static files
• Compress all responses

If users are physically distant from your server, response times won't improve past certain point; the information travels over the internet with a limited speed. As a rule of thumb, every 100 kilometres of distance add at least 1 millisecond to round-trip (ping) time. Lookup charts are available - for example this page lists distances and ping times between most areas in the world.
Browser rendering speed can also be improved to some extent. YSlow can scan any page for areas that are known to cause slow rendering.

And then even faster

In the end, users care about how much time it takes them to complete their task. So even if all individual interactions are lightning-fast, they might still be unsatisfied with the end result. And conversely, even if their interaction takes hours to complete, they may be satisfied. Some examples:

1. Windows installation used to follow these steps:
   • Initial configuration (hard disk choice, file system etc.)
   • File copying (slow)
   • Additional configuration (language, keyboard, time zone etc.)
   • More copying (slow)
   For the users it meant 2 slow interactions with the system. Today all configuration happens before the lengthy processes. From operator perspective the process is finished when the configuration is done, the rest happens automatically.
2.  Sending mail with file attachments using web interfaces. The easiest way to implement this is by putting a file input on the form, then submitting the file together with the rest of the message. Unfortunately it has a few drawbacks:
   • Uploading file attachments is often a lengthy operation, especially on slow connections
   • In most implementations server can validate the submitted form only after it is fully uploaded. Therefore, user is informed that his message could not be sent only after he spent a lot of time on the upload.
   • Worse yet, after correcting the validation errors, user had to select and upload the file again.
   Today most (if not all) web mail interfaces implement uploading file attachments as a separate (preferably background) operation that happens in parallel with mail editing. Attachments can be validated before the message is written, and submitting the smaller form happens almost instantly.
3. Obnoxious advertisements. If you're looking for certain content on a page, but every link you click directs you to yet another advertisement, loading times on these ads won't matter much - you won't like the experience.

Reducing the number of user interactions needed can be just as important as reducing the time needed to finish any individual interaction.