Comment by bastawhiz
4 years ago
> Practical SPA's have many more network roundtrips than the equivalent server-rendered web interface. Every AJAX request is an extra roundtrip, unless it can be handled in parallel with others in which case you're still dependent on the slowest request to complete.
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.
What they're meaning is that the total time is longer for the SPA if you don't go all out (and nobody does).
SPA:
Vs traditional:
Also if there are sequential ajax calls required to build the page (like a list -> detail view), it goes up a lot without speed oriented (very bad code style) API design. For instance you need a separate "GetListOfUsersAndDetailsOfFirstUser()" (or more general "getEverythingForPageX" calls). You can't do "GetListOfUsers()" and "GetUserDetail()" separately.
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?
> For instance you need a separate "GetListOfUsersAndDetailsOfFirstUser()" (or more general "getEverythingForPageX" calls). You can't do "GetListOfUsers()" and "GetUserDetail()" separately.
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.
> 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.
Can you link to a tutorial for this? I'd be most interested.
You eliminate #3 by having data preloaders inline it into the html response and move it into #1. But without SSR your rendering still starts after #2 instead of #1.
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.
Yes, but most of the time (getting the HTML and all the Javascript etc) is only at startup time. Let it take a second or two. From then on the user is in the application, and everything is much faster than it used to be with getting entire new pages from a backend every other click.
The more something behaves like an actual application and the higher the number of user interactions per visit, the more sense the SPA approach makes IMO. This is because the initial load overhead of an SPA gets amortized over subsequent interactions.
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.
I wrote a post very similar to this comment that you might be interested in reading. I broke down what takes time to load, how fast the browser determines something has loaded, and how fast the user can perceive the page loading. I ended up having to take a high speed video and measure frame by frame the time it took to load for user perception.
https://www.ireadthisweek.com/author/ireadthisweek/post/2022...
The TLDR is it takes longer than reported.