cloudflare
Slow navigation
The docs no longer appears to use pushState navigation—so there is a hard reload on every link click as opposed to using JavaScript to load in just the content that changed.
In terms of performance, by my estimation this is adding around ~500ms to time-to-interactive for each page load on a modern device and ~1.5s more on a phone or other device with a slower connection/processor. In terms of the user experience, the fluid animations that used to appear in the sidebar to add helpful context as you navigate are gone.
Was this an intentional regression? I suspect https://github.com/cloudflare/cloudflare-docs/commit/607d9ffe84fdcc879d1b076901fd4b5cda669d96 was at or around when the breaking change occurred.
Hi @lukeed @codewithkristian - Is this something y'all could take a look at or close the issue if it is expected behavior? Thanks!!
Took about 2 hours fiddling around with it. Definitely worth evaluating and noticed some of the speed improvements in preview builds..... but also beyond my skills as a quasi/not really FE person to sort out.
TL;DR, we can get the faster navigation work for internal links + nav items... but there are current issues with the history (probably fixable) + scrolling behavior (to top of page or anchors, tried a few easy fixes and sorta stumped atm) + some refactoring of our mermaid / littlenote / other JS libraries to fire on a different trigger than page load (not sure where to begin on that one).
All in all, probably worth doing... but I'm not the one to do it.
Would definitely need someone like @codewithkristian or @lauragift21 to push it over the finish line.
We had a branch in progress during the rebuild that attempted to preload & swap the same-site navigation links as well (on hover). While there was some success in perceived speed increase, it came with a significant amount of bugs, only some of which Kody mentioned here. Nearly everything is achievable, but it's a lot of JS code to rebuild behaviors that the browser provides for free.
As for the new docs site being slower than the previous Gatsby site, that's simply not true. Initial page load was excruciatingly slow, to the point where relatively modern handhelds would freeze while loading a docs page. Subsequent page loads were quick, but that's because Gatsby "prepays" so much of the cost upfront.
The lowest hanging fruit here is to fetch() same-site links in the background on mousehover so that the network request 1) gets a 100-300ms head start before "click" fires 2) has probably finished by the time "click" fires, which means the response can load from disk cache.
The only real thing that was lost was the sidebar navigation animating while the new-page was transitioning.. but that's not worth MBs of JS nor the struggles that many people were facing trying to make/develop changes locally. Instead, the sidebar animates while you interact with it on PageA and matches on PageB's load. There can be a disconnect when following a content link to another section, in which case the sidebar wasn't animated into position pre-pageload.... but again, not worth the MBs. If this is really bothersome, a "click" handler can be added that serializes the sidebar state tree into local/session storage & then add an inline <script> tag that (if found) updates the markup so that you can schedule the necessary transitions to go from before->current state.
Believe this is mostly solved by the new page speed improvements we've made by switching to the new routing for CF Pages.
Huge page speed improvements, thanks @WalshyDev