The Goldilocks of Performance
I enjoy the opportunity to see family and friends over the winter break, and two conversations that I had back to back made me feel like I was in the goldilocks story.
Frontend Good, Backend Poor
I was reminiscing with a former colleague about The Old Times. We got onto the topic of a particular project where we were responsible for the frontend development but didn’t own the backend services. Between you and I, those services were fragile and unresponsive. Measurements could come back in the seconds.
What could we do about it? Well, we ended up building a tier in front of these services and doing everything we could to cache data as close to the client as possible. As you well know, caching is one of the Two Hard Things, so it brought pain upon us, but we had to do it. We had folks arguing about “Akamai Sandwiches” and all kinds of architectural contortions to squeeze the perception of performance for our end users.
We had to go through and meticulously think through each flow and decide what we truly had to wait for. This ends up with a system such as hapi’s catbox, where you can easily declare the policy of downstream services.
For example, imagine a product details screen for an ecommerce service. Do you really need to wait for all of the information on that screen before sending anything to the user? Is all of the information equally important? Of course not. Not only isn’t it equally important, but the level of staleness that you are willing to allow for is different. You want the price to be up to date, but does it matter if the absolute latest review comes back? No. This type of work can actually go nicely hand in hand with your general information architecture and UX.
The front end team had great pride on their performance. Profilers were always running. It was a touch gutting to use the system and see the latency in your face. How can we get people to really care about this?
The side by side comparison was always a great tool of choice to get the message across. On the data side we could show an increase in conversion for faster responses, but then you come with with the sucker punch. We would record a video where on one side you would see the app working against mocks with sensible response times, and next to these the same experience would hit the “real” services. I highly recommend the side by side comparison as it will kick in a distinction bias in the person you are trying to persuade.
So, that was an example where the frontend out performed the backend, but it could only fix the experience to a certain point :(
Backend Good, Frontend Poor
The other extreme is equally possible. Another friend was showing me a backend CMS system that had two frontends developed by separate teams. The average responsive time for the end user was double for one site versus the other, and they were very comparable sites.
This was a case study that Steve Souders would be proud of. The backend could sling that 200 back all nice and fast, but the front end performance varied. If you fire up Chrome DevTools you quickly see a slew of errors: loading JS in the wrong black, a lack of async/defer, and way too much being sent to the client on every page. Ouch.
RAILing on Performance
In the past there has been a large focus on initial load / paint with web performance. We are now seeing other areas of focus, as shown by examples such as RAIL, the “user centric performance model”.
Now, some people complain that each of those areas shouldn’t be considered equal (“Loading is much more important than animation!”), but it is fantastic to see the push to truly polish and perfect your work.
It is important for us to get past “load” as we have all been on those janky pages. The ones where a hamburger menu is there but it feels wonky. Scroll effects are strange. It looks like someone is trying to “copy” native but its just worse. If we want the Web to deliver more than simple content, then we need to nail the entirety of RAIL.
We want to be a smarter goldilocks and deliver the overall experience that is truly just right.
p.s. care about performance? did you check out the holiday perf calendar again this year?
