This has not been my experience, considering all HTML is ready to go from last byte so that other than blocking CSS, rendering can begin ASAP. At this point, no JS is required to interact with the page so things are generally pretty snappy while we wait for React hydrate to kick in.
First paint: 4.1 Seconds. Time to interactive: 11.5 Seconds.
I wouldn't say that's very fast.
Edit: I didn't check the other three.
ca.braun.com gets 77
bejamas.io gets 96
So implementation dependent I guess
camp 1) at best, a TCP connection is re-used, and the HTML for "page 2" is fetched over the network, parsed, the CSS OM is applied, and then the whole caboodle* is "painted on screen".
camp 2) the CSS OM is applied and "page 2" is painted on-screen (possibly even faster if the browser cached "page 2" in a texture on the GPU, so the CSS OM application step may be optimized away)
So I genuinely don't understand how fetching a "page 2" from a CDN
(we use Cloudfront & GCP's CDN at https://mintdata.com, so I'm basing my experience on this)
is faster than the SPA approach?
I am genuinely curious on the above -- not trying to start a flame war :D
* Yes, apparently caboodle is a word?! I had to Google it just like you to make sure :)
(2) is both overstated and overvalued. It's overstated because loading a static HTML page from a CDN is extremely fast. Too many people who point at this advantage for SPAs are thinking back to pre-CDN usage with slow origin servers. Of course there are still use-cases where going to network is not wanted, but these aren't the primary use-cases that Gatsby covers.
It's also overvalued in that most users are not getting to a page by navigating in a loaded site, they are coming from a social or search link (again, for the sort of use-cases that Gatsby pages are built for).