Speed vs the Appearance of Speed
By giving your users a sense of progress, you can hide away the unoptimised parts of your system
When talking about optimising your serverless application's performance it can be tempting to begin by tackling the "highest effort, biggest reward" areas.
These may include things like reducing Lambda's cold starts, or improving DynamoDB's performance by implementing Single Table Design, etc.
While improvements in such areas can often bear noticeable results, they are arduous and time-consuming, particularly if you're working on an existing application.
Recently, we set out to improve the performance of one of Trilo's user-facing applications. We decided to give this project a one week Appetite.
The aggressively short timeframe would force us to stay away from any complex re-architecting.
As I began to dig into the performance issues and reflect on the best way to achieve a win in just a few days, a key distinction occurred to me.
I realised that what we wanted was for the whole user experience to feel reasonably fast. It didn't have to be actually fast.
In other words, it wasn't Speed that I was after. Rather, it was what I've come to call the Appearance of Speed.
The key to achieving the Appearance of Speed is to demonstrate progress. You want things to be happening in relatively quick succession.
Here's a simple example of an Appearance of Speed technique: remove any loading spinners from your page and display your basic page layout to the user immediately. Then, as the data becomes available, show it to them without making much of a fuss.
Here's another one: avoid server-side rendering (SSR). Server-side rendering in serverless is a bit of a waste of time anyway. Given Lambda's cold starts1, server-side rendering is not going to deliver the fast experience that the original SSR languages and frameworks got famous for.
In both examples, the key takeaway is to show something to the end user as quickly as possible, and to continue updating the page as more and more data from the backend is returned.
***
I am in no way arguing that the Appearance of Speed is a replacement for actual Speed. Eventually, optimising your Lambda's performance or your DynamoDB table's design may well be inevitable.
But before you're tempted to get deep into what is possibly going to be a time-sinking activity, take a good look at your application. More than likely, there are small changes that you can make which will give the user a sense of progress. A feeling that your application is not slow.
Give your application's users the gift of the Appearance of Speed.
I am, of course, aware that Lambda's cold starts can be reduced and mitigated. That's not always as easy to achieve as the marketing might lead us to believe. Moreover, in this post I'm considering ways to improve the Appearance of Speed, rather than actual Speed. If you want to use something like Provisioned Concurrency to reduce cold starts, it definitely won't hurt!