I was chatting with Yoav Weiss this past week and it sounds like navigation transitions for multi-page applications (I’m old enough to remember when we called them “websites”) is finally going to happen. It’s early, and there’s nothing to really play with, but there’s been work happening this past week around building the specs for how they’d work.
He reminded me that the two of us first chatted about the idea of “navigation transitions” way back in 2014, at WebPerfDays (RIP) in New York.
This time it seems like it might actually land? Maybe?
View transitions for single-page-application’s has been out since Chrome 111. And Jake Archibald (happy birthday, Jake!) built a demo of what it could look like for traditional navigations (to view the demo in action, you’ll need to load Chrome with the view-transition-on-navigation flag enabled (chrome://flags/#view-transition-on-navigation).
It’s best viewing that demo as very experimental—they’re still working on the best way to actually implement this and it’s certainly going to change.
I hope this time it sticks.
Well-thought out transitions are a powerful tool for what I like to call “performance choreography”. Far behind just “eye candy”, they can help to create a connection between the before and after states, helping to ease the cognitive load for users trying to recognize what changed and how it’s connected to what they were just looking at.
It’s also a great way to convert what was a passive waiting state (the user is waiting with no control over the waiting duration, and nothing to mentally process, etc) to an active state (the user has an active mental state—they can start to process what is happening as they’re waiting for it to complete).
It’s taken nearly a decade to sort, but if this lands, it’s going to be a very powerful tool for everyone to provide more seamless navigations for the folks using our sites.
🐌 Offline is just extreme latency
In the accessibility community, they talk about situational impairments: situations in which a users ability to hear, see, use their hands, concentrate, understand instructions, etc are impacted temporarily. The big emphasis here is that all of us will find ourselves in situations like these, many times, often frequently. So accessibility features are best viewed as a something we all will benefit from at times.
In his talk on “Local-First Software” (https://www.youtube.com/watch?v=KrPsyr8Ig6M), Peter Van Hardenberg frames offline as “just having really high latency”.
It reminds me of those situational impairments and it’s a very healthy way to view offline not as a consistent state of being, but a scenario we all bump into at times intermittently and that needs to be accounted for in the way we design and build our applications.
📈 Increasing revenue by 15% with better perf
The Shopify performance team has really been rocking it lately with some impressive work and case studies.
The one that they just published today is a great example.
They helped Carpe reduce their Largest Contentful Paint by 52% and their Cumulative Layout Shift by 41%. In turn, Carpe saw:
- A 5% improvement in their store conversion rate
- A 10% increase in traffic
- A 15% increase in revenue
There’s some great information on how they analyzed the site and some of the improvements they made in the post—well worth your time!
This one is going on wpostats.com in just a little bit.
Take care,
Tim