There is a modern UX concept, which I hope you are all using, called perceived performance. While I call this a UX concept, it’s not something you will see on wireframes, redlines or a SketchFlow demo. This is something that typically has to be architected into an application and built out by a developer. It is also something that is difficult to quantify so explaining it to your clients can be difficult at times.
Definition
According to WikiPedia:
Perceived performance, in computer engineering, refers to how quickly a software feature appears to perform its task. The concept applies mainly to user acceptance aspects.
The amount of time an application takes to start up, or a file to download, is not changed by showing a startup screen or a file progress dialog box. However, it satisfies some human needs: it appears faster to the user as well as providing a visual cue to let them know the system is handling their request.
Practice
What this means in practice is using various means to decrease the time in which the user cannot interact with the app / site. This is typically done using one of a few techniques.
The most common approach is to not download the entire app at one time but to download parts of it in the background. The issue with this approach is that it is sometimes hard to predict what parts of the app the user is going to want next. Sometimes the downloading of deeper pieces of the application are dependent on user action (i.e. don’t download a section until it is asked for.
Another variation on this approach is to break a large app into numerous smaller apps. That way only one piece at a time are downloaded and each is (hopefully) small enough that the user does not experience ‘bad’ performance.
Problems
While using these techniques generally make a site more user friendly, sometimes there are issues that come up as well. I’m not talking about technical issues but client / management issues. For years, the most common measurement of site performance has been something known as TTLB (time to last byte). What TTLB measures is the amount of time from the initial page request until the final bit is downloaded to the browser, this includes markup, images, xap files any anything else. The problem comes when you add a solution taking advantage or perceived performance to a client that is used to using TTLB to measure site performance. Their stats are going to show those pages as performing poorly when the “bad” number is by design.
Solutions
How do we go about addressing this problem? This isn’t a problem you’re going to find a technical solution for. I’m not going to be able to give you a code sample to make the client’s stats look better. The solution in this case is education. You need to make sure that the client understands what you are doing before you even start, and that their TTLB stats are not going to tell the entire story. You also need to be ready for a few weeks after the site is live and he brings out his numbers telling you how bad those pages are preforming. He’s a client, I’m sure he’s busy so he has undoubtedly forgotten all about you explaining that bit to him. Be patient, expect that it is coming and explain it again.
