the link above disables Google Analytics on that page, which would otherwise add an extra 50ms of js time (and would account for the majority of the js on the page).
(it uses domvm w/SSR, not Mithril)
To me, it seems like Incremental Static Regeneration is the best of both worlds - you get a static site without huge build overhead and SSR niceness.
However, peeking in dev tools, sure enough your site is a bit faster in nearly every lighthouse metric compared to static-tweet.now.sh despite being decidedly more complex.
Could you expand on how Gatsby and Next are doing SSR wrong and what it takes to do it right (i.e. what is DOMVM doing instead).
I'm sorry if you've answered this elsewhere in the thread, I looked around and didn't find anything.
please read through the whole Reddit thread i linked. i compare a minimal Next.js hello-world page to domvm-rendered e-commerce page. what specifically they do to produce such a sub-optimal result will remain a mystery to me because i don't particularly care to investigate. no one has given me a bare-minimum Gatsby site to evaluate so i have no idea how it compares besides looking at one of their slow showcased apps in the reddit thread: https://airbnb.io/
i think a lot of your questions may be answered by reading the Reddit thread.
> SSR can be done correctly, even with React
This stands out to me, and I agree completely.
I dug around in devtools and found a few interesting things looking at the static-tweet.now.sh (Next w/ Incremental Static Regeneration). It seems like the performance is more or less on par with domvm as far as network usage EXCEPT for the initial bundle (which is mostly react & dependencies). For subsequent visits, this is cached and performance is great, but devtools tests with a clean cache so this is hidden.
Admittedly, that's a huge qualifier. It doesn't seem like Next is doing anything wrong with SSR other than using a framework with a huge bundle. As a result, the huge bundle ends up getting sent even for a page (or entire site) with no interactivity.
In theory, it might be possible to avoid sending the bundle for routes that don't need it, but this ends up being a fundamental limitation of react afaik.
Vercel (the folks behind Next) put it really well
> React at Facebook is… > …unlike React at ${anywhereElse}
The large initial bundle pays off for a site like facebook or a web app which really takes advantage of all React has to offer (wether that's performance, tooling, or dx), but definitely deserves more second guessing than it recieves.
if you add to the cart and reload the page, it pulls the live cart from the db.
Just a heads up, there is a NaN showing at the end of the page.
