Comment by candiodari

4 years ago

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:

    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)

Vs traditional:

    1. get html from server (1 roundtrip)

    2. get resources from server (1 roundtrip)

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.