Web performance is a huge complicated topic. There are metrics like total requests, page weight, time to glass, time to interactive, first input delay, etc. There are things to think about like asynchronous requests, render blocking, and priority downloading. We often talk about performance budgets and performance culture.
How that first document comes down from the server is a hot topic. That is where most back-end related performance talk enters the picture. It gives rise to architectures like the JAMstack, where gosh, at least we don’t have to worry about
index.html being slow.
For a moment, let’s assume we’re going to build a site and we’re not going to server-side render it. Instead, we’re going to load an empty document and kick off data API calls as quickly as we can, then render the site with that data. Not a terribly rare scenario these days. As you might imagine, >we now have another major concern: handling the loading experience.
I mused about this the other day. Here’s an example:
Client side rendering is so interesting. Look at this janky loading experience. The page itself isn't particularly slow, but it loads in very awkwardly. A whole thing front-end devs are going to have to get good at. pic.twitter.com/sMcD4nsL98
— Chris Coyier (@chriscoyier) October 30, 2018
I’d say that loading experience is pretty janky, and I’m on about the best hardware and internet connection money can buy. It’s not a disaster and surely many, many thousands of people use this particular site successfully every day. That said, it doesn’t feel fast, smooth, or particularly nice like you’d think a high-budget website would in these Future Times.
Part of the reason is probably because that page isn’t server-side rendered. For whatever reason (we can’t really know from the outside), that’s not the way they went. Could be developer efficiency, security, a temporary state during a re-write… who knows! (It probably isn’t ignorance.)
What are we to do? Well, I think this is a somewhat new problem in front-end development. We’ve told the browser: “Hey, we got this. We’re gonna load things all out of order depending on when our APIs cough stuff up to us and our front-end framework decides it’s time to do so.” I can see the perspective here where this isn’t ideal and we’ve given up something that browsers are incredibly good at only to do it less well ourselves. But hey, like I’ve laid out a bit here, the world is complicated.
What is actually happening is that these front-end frameworks are aware of this issue and are doing things to help manage it. Back in April of this year, Dan Abramov introduced React Suspense. It seems like a tool for helping front-end devs like us manage the idea that we now need to deal with more loading state stuff than we ever have before:
At about 14 minutes, he gets into fetching data with placeholder components, caching and such. This issue isn’t isolated to React, of course, but keeping in that theme, here’s a conference talk by Andrew Clark that hit home with me even more quickly (but ultimately uses the same demo and such):
Just the idea of waiting to show spinners for a little bit can go a long way in de-jankifying loading.
Mikael Ainalem puts a point on this in a recent article, A Brief History of Flickering Spinners. He explains more clearly what I was trying to say:
Plus, he offers some solutions!
See the Pen Flickering spinners by Mikael Ainalem (@ainalem) on CodePen.
We’ve got to get better at this.
Simple AF: unless a website is an entire webapp, AVOID making ’em bloated and full of ajax stuff.
What if it is a web app?
Odd… I remember first being excited at least a decade ago when I felt I’d really nailed a loading experience that was semi-challenging. It involved dynamic content, a few scattered asyc widgets, some high impact content photography (some in autorunning carousel), and lots of complex glossy lighting effects underneath text (before CSS gradients) and with more photography layered on top too. Some of these aspects pulled in different directions. Some photo sizes were very controlled, so would have been friendly enough to hard-coded dimensions all around, but the dynamic content had enough variability that some expand/contract tolerance had to be built in. Think at the time it was about 6 files max concurrent download and there were all these large photo and several blocks of content not delivered from server side. With the images, some were essential for text readability and comprehension (in the form of both background images and iconography) and some as important as any content and leaving big gaping holes in the layout (or pushing it suddenly over or down). The async widgets and their content of course had similar issues and begged the questions: do you show an empty placeholder, or a loading placeholder, or what later became known as skeleton state, or nothing until it was ready, at which point things jumped around disruptively. Could the designers be brought to agree with my choices there and in treating high impact visual elements as progressive enhancements to apply as they loaded?
It’s a definitely gotten at least a little more challenging since then, though more in amount than in fundamental problem space. And more in tooling than in fundamental solution space. After all, the issues of queued distribution over the network and the client having to load pieces of itself over that network are pretty fundamental internet and web. And unlike most software with GUIs before the last 20 years, you don’t get to prime the pump. The user doesn’t download your site before they visit for the first time–and you get one chance to nail that uncached loading experience or a lot of people will bounce.
I dunno. I look at an experience like that and know exactly what I’d do without, given my assumptions about it from watching how it loads now… if I wasn’t forced by co-workers to use client side rendering only, React, and Webpack. None of those things is bad, but the way they all come together and where they’re all at in their state of the art here–combined with web designers being pushed out of the industry–make it harder (at least on me, and perhaps if it’s getting worse out there, for a lot of people…but YMMV).
Is it just me who thinks all this hullabaloo over extreme performance is pointless? Of course, nobody wants to wait around for 10 seconds for a page to load. But I can’t help but think that having a page interactive in < 2 seconds is plenty fast—definitely fast enough for that 80%—and that trying to optimize things much beyond that is basically pointless, and definitely time that could be better spent elsewhere.
I’d like to think that some of this can be addressed by CSS (assuming the browser gets it quickly enough), but something as simple as min-height for a container can go a long way in heading off jankiness. Not to mention, placeholder background color, or other techniques that don’t cost much as far as effort.