1. The Back button had a noticable half-second lag.
2. When I temporarily lost connection and a link I clicked was taking a long time to load, I wasn't given the option to stop loading it like I am when I click a normal link.
I tried disabling JavaScript like a sibling comment suggested, and the website was indeed faster and still flicker-free. (Where do front-end devs get this idea that you need tons of JavaScript to do flicker-free page navigation? Have they never used Hacker News?) But then I wasn't able to see the interactive code examples on the homepage, because those genuinely needed JS to work.
This is because disabling JavaScript is an all-or-nothing proposition. There's no "throw out bathwater but not baby" button or "allow JavaScript only for things it should actually be used for, and not clumsily reimplementing browser features while forgetting half the edge-cases" toggle-switch.
Yes, instant page navigation without flickering is better than the alternative - instant being what you get from reloading a static HTML page, alternative being React.
Seriously, fetching, parsing and displaying a tiny bit of HTML is fast. As fast or faster than the React virtual DOM shenanigans, once you account for the computational load the framework adds on top of your simple page.
If I can make it easier for me and anyone working with my site in the future by sacrificing 50-150 KB then I will take that deal any day of the week. That is what abstractions are for. That is why we do not work in byte-code. We pay for convenience in clock-cycles and disk space.
HTML and CSS are not bytecode. They're high-level abstractions, hiding a very complex renderer underneath. Sometimes you need to build another tower of abstractions when this doesn't suffice - like when you're trying to build an application with complex GUI in the browser and you need an adapter between DOM and a more suitable GUI pattern. But displaying text and images communicating a message is not one of those cases.