Prefetch HTML When Hovering Over Links and/or Load Pages w/o Hard Refresh
callowaysutton opened this issue · comments
Hey,
Just wondered if ya'll had looked at Unpoly.js, or similar projects, which provide a means for loading in new pages without a hard refresh. It makes everything feel a lot quicker especially combined with prefetching. If you're viewing this issue then you've already seen it in action when switching between the "Issues" and "Code" tabs 😎
It'll take page load time on subsequently visited pages down to a couple milliseconds and feel instantaneous to users, if you would want to go even further you could have links redirect before the user even releases their mouse for an even more dramatic affect.
The only issue is that, for things like Unpoly, you would have to identify what the different fragments are per page and add a special class so that it knows what to differentiate. But you can start off with huge fragments (basically the whole page minus the navigation bar wrapped in a div with a unique class) and then slim down overtime to reduce the load time.
If ya'll have already explored this I was also curious as to why you may have dropped it?
Best,
Calloway
I made a very rough proof of concept just hardcoding in the up-targets and using the body as the only fragment here.
Here is a demonstration, although it can be somewhat hard to see how much more responsive it is given that the delay from when I click to when the website reloads is obscured...
Changelog.Unpoly.mov
Both pages had their caches cleared beforehand and the local demo was given a 50ms delay as that was my average latency to the TTFB of changelog.com, cache wasn't disabled globally because that's unrealistic.
I'd heavily recommend trying it out for yourself to see! I would appreciate some guidance in how you guys would like to include external dependencies since in the POC I'm just linking to their CDN directly via the app.html.heex file. There does exist an Unpoly Elixir package however I'm not an Elixir developer nor have I ever used it before so I'm not really sure how to use it...
Hope you guys like it,
Calloway
@callowaysutton thanks for the thoughtful suggestion!
We are well aware of the technique, having employed it via Turbolinks for many years on this very site.
I removed it earlier this year for a few reasons:
- We no longer have a news feed, making the persistent player much less compelling. When we first designed the site, we imagined folks perusing the newsfeed, clicking around on different things and reading them all while listening to some pods. This didn't actually play out in reality, though.
- There are many small "uncanny valley" bugs you bump up against when you aren't doing full page refreshes. One that hit us all the time was CSS/JS loading/unloading when switching between templates that use different bundles.
- Less code and complexity is less code and complexity.
I understand the benefits, but ultimately we decided to do things the traditional way, at least for now.
- There are many small "uncanny valley" bugs you bump up against when you aren't doing full page refreshes. One that hit us all the time was CSS/JS loading/unloading when switching between templates that use different bundles.
Could you elaborate on this point? I'm thinking about developing a data heavy application and am curious if this is an issue with Turbolinks or this form of refreshing
I don't think it's a Turbolinks specific problem.
There's just a lot of things you have to account for when you are faking a page refresh but not actually doing it. 99% of those issues have been accounted for, but there are things that slip through the crack intermittently (e.g. the back button not working as expected every time).
That being said, it's a valid approach and I'm not against it. The alternative (SPA) is often a worser-of-two-evils when it comes to browser oddities. We just didn't really need it anymore, so I yanked it.