Unless their cache is cold and then they navigate back before your first render completes. Often we are not the sole source of a piece of information and first load time counts.
> Unless their cache is cold and then they navigate back before your first render completes.
This doesn't matter. It's an SPA - my js context hasn't been wiped because I'm not letting the back button eat the whole thing and start over. I just complete the request and store in cache either way, and next time they hit it, it will be there.
> Often we are not the sole source of a piece of information and first load time counts.
Sure - caching is hard (full stop - it's really hard). But I think if you actually consider most applications, there's not really much difference between an SPA rendering from cache and a server-side page that a user hasn't refreshed in a bit.
Basically - it's not going to solve all your problems, but in my experience developers really underestimate how much usage is "read only" and a cache works fine.
SPAS push giant gobs of logic and CSS ahead of the Time To Interaction and cross their fingers that nobody will notice because it’s not supposed to happen the next time due to magical cache thinking.
People have been ignoring actual research on caches for the entire time SPAs have been around. First time visitors have this as their first time visit. Occasional visitors show up after the last deploy, or like and enthusiastic web users get evicted between loads. And then don’t convert because your site is “always slow”.
P95 statistics don’t tell you if 5% of your users are having a bad experience. Or if new users are massively over represented in the P95 time. You are flying blind and shouting for other people to follow you.
Look - I understand that I'm making a tradeoff here, and I'm very clear that not all sites are the right fit for an SPA.
But yes - I explicitly handle offline-only use cases, and god-damned terrible connections (think <1kb/s). In these situations, users are going to wait a long time for the first load either way.
They call in excited as all get out when they realize they only have to wait once with my application, and not once every page load. It's the difference between having a chance to grab a coffee at the start of the day, vs pulling your fucking hair out all day long.
Your application seems to be a magical unicorn (not being sarcastic!). Most SPA websites I use on a regular basis end up having to reload all of their page components every visit, and frequently on every 'back'.
I'll be really honest here - it helps that it was a direct requirement from day one, and we have financial incentives aligned with handling the offline-only case.
If you handle offline up front - you mostly get bad connection speed wins by default.
It also helps that our app really isn't intended for casual use - ex: we have very few users who just load a page or two and then leave. Mostly they'll be interacting with the page for a duration of between 30 minutes and 2 hours (sometimes as often as once a second).
So yes - very much not a "blog" or "news" or "social media" site, and I think the value proposition for most companies might be harder to sell.
But I personally find it very, very nifty that we can do this at all in a browser. 10 years ago it would have required an installed application, or a port to each mobile platform. Which is sadly still a hard sell in some of the particularly poor school districts we worked with (mostly computers from the early 2000s, if you're lucky a really cheap tablet - like a kindle - floating around)
To be fair, there are SPA frameworks that try to minimize the amount of logic that's shipped to the client, Svelte is an example, which should be as lean and efficient as any hand-coded JS. It's more of a side effect of what frameworks you use than SPA per se.
It's still a specialty sub-discipline though. Getting the base size down is a wonderful goal for a framework. But for the behavior the company is adding, there are both diminishing returns and a lot of surface area for bugs.
