Why you should reconsider prefetching in Remix
Remix makes prefetching too easy when using its <Link />
component by allowing you to specify when to prefetch (on render or hover/focus). It also gives you more control via its <PrefetchPageLinks />
.
Prefetching everywhere
When I first got my hands on those components, I started prefetching:
- public routes that are frequently visited on render
- public routes that are less frequently visited on hover/focus
- private routes on hover/focus (since caching them for long might cause stale data to be sent)
- search results on search input change (first saw on Remix vs Next.js)
I was so proud when I implemented all of those in an app that I extracted some of them into this "Remix table with search and pagination" demo
Whom is it good for?
Since I was mostly focused on how to use this new shiny way to make things faster and feel better myself, I didn't stop to think if it was better for the users.
Reflecting
A couple of weeks ago, I stumbled upon this tweet:
I encourage you to read it as well as the replies on there as they made me reflect on how many times a prefetch didn't happen because I clicked quickly or the temporary private cache expired.
Even though prefetching makes most route transitions instant, when they're delayed, it feels unexpected as it's not consistent with the previous instant transitions when navigating between the same routes.
On top of that, prefetches might produce 2x, 3x or 10x requests to your server depending on how much you use them. This hits your server, database, and other third-party APIs you might have and eat through the resources.
Conclusion
Better meeting user expectations and saving resources made it a no-brainer for me to ditch every prefetch I have.