SPA:
1. get html from server (1 roundtrip)
2. get resources (js/jpg/movies/gifs/favicon/...) from server (1 roundtrip)
3. get ajax calls from server (1 roundtrip)
4. process answer from server + update page (not a roundtrip, but not zero)
1. get html from server (1 roundtrip)
2. get resources from server (1 roundtrip)
So to match traditional webpage total load time you cannot do any ajax calls in your SPA until after the first user action. And even then, you only match traditional website performance, you don't exceed it.
Time until the first thing is on screen however, is faster in SPA's. So it's easy to present "a faster website" in management/client meetings, despite the SPA version actually being slower.
You can make SPAs faster than traditional websites ... but, for example, you cannot use javascript build tools. Since you need to do the first calls server-side and have javascript process them, and only send the result of the preprocessing, and the resulting dom to the client, after optimization and compression. After that you need to then do image inlining, style inlining, etc. I know react can do it, but does anyone other than facebook actually do that?
This is literally a core use case of GraphQL. But you probably also want to fan out to preload all of the other user data in one API call: that's the whole point of doing it on the client. If you are trimming the handful of kilobytes on the first request, you're paying the price for that on each subsequent load.
> I know react can do it, but does anyone other than facebook actually do that?
Yes. Every job I've worked at professionally since 2016 (when this became mainstream) has done this. I do it in my side hustle. It's really not that hard.
> 2. get resources (js/jpg/movies/gifs/favicon/...) from server (1 roundtrip)
This doesn't go away with traditional sites.
Can you link to a tutorial for this? I'd be most interested.
I think your point is still correct. SPA by default are a huge regression and you have to build and maintain sophisticated web infra to reclaim it.
Blog or corporate/news website on one end and an interactive game or video editor in the other, with a site like FB somewhere in the middle.
It’s not a hard rule and I can already think of counter-examples but this line of thinking is useful when architecting a new project.
https://www.ireadthisweek.com/author/ireadthisweek/post/2022...
The TLDR is it takes longer than reported.
This is largely solved with innovations like GraphQL (which you don't need a SPA to use). Pages that require multiple API calls can show their UIs progressively with appropriate loading indicators. For SPAs that have ~long sessions, it's arguably a good thing to have multiple API calls, because each can be cached individually: the fastest API call is the one you've already cached the response for. This is stuff we were doing at Mozilla in 2012, it's nothing new.
There's also nothing stopping you from making purpose-built endpoints that return all the information you need, too. Your proposed solution (SSR) is literally just that, but it returns HTML instead of structured data.