respect reduced data settings for rel=preload assets

[ryanflorence]

(prefers-reduced-data) doesn't have great support yet, but we can start using it anyway.

We can also add a check to navigator.connection.saveData before rendering the links on script transitions until the media query has more support.

This post has lots of practical stuff about browser support/APIs etc. https://polypane.app/blog/creating-websites-with-prefers-reduced-data/

[jrestall]

Bump. It's almost 3 years later and global support is at 75%. This should be a simple boolean check to implement along with a few lines of docs. PR welcome?

https://caniuse.com/mdn-api_networkinformation_savedata

function usePrefetchBehavior<T extends HTMLAnchorElement>(
  ...
  return [
       // @ts-expect-error connection is still experimental
      shouldPrefetch && !navigator.connection?.saveData,
      ...

[brophdawg11]

It feels a bit odd to use this setting internally on an API that is already opt-in by default. You could do this today with <Link prefetch={!navigator.connection.saveData}>?

If Remix were to add this internally - then there would be no way for an application to ever leverage <Link prefetch> if navigator.connection.saveData were enabled - which seems overly restrictive.

I think Remix should definitely check this on any behavior that performs an unnecessary fetch by default. Off the top of my head the upcoming Lazy Route Discovery is likely going to default to prefetching route definitions on link render so that would be a candidate where the default behavior should probably be disabled when prefers reduced data is set.

[jrestall]

I feel having it built-in means every Remix site would respect the user's data usage preference rather than each developer having to be aware of this standard and adding their own checks to prevent all their prefetch links using their user's data, especially prefetch="render".

Not prefetching data and code when the user has asked to keep data usage as low as possible should be the default and I'm curious why a dev would want to override this behavior to prefetch anyway. That said, there could be a Link prop like ignoreSlowConnection (from Astro) to prefetch anyway, but I do think having a default that respects the web standards and user's preferences is the way to go.

Other frameworks have opted to have this built-in for their prefetch functionality.

NextJS - https://github.com/vercel/next.js/packages/next/src/client/route-loader.ts#L428
SveleteKit - https://kit.svelte.dev/docs/link-options#data-sveltekit-preload-data
Astro - https://github.com/withastro/astro/packages/astro/src/prefetch/index.ts#L292. Docs on ignoreSlowConnection.
Qwik - https://github.com/BuilderIO/qwik/packages/qwik-city/runtime/src/link-component.tsx#L42

[brophdawg11]

I guess the way I see it is that the setting is defined as:

Indicates that user has expressed the preference for lightweight alternate content

We're not even considering alternate content here - just "less" content in the form of "don't load content you don't need".

I agree that prefetch="render|viewport" likely make no sense when saveData is enabled since all rendered links won't be followed so that means more data was sent than necessary, so I agree a default behavior there makes sense 👍

intent feels different to me - I should have limited my comment above to that setting. If a link is clicked (which we expect many/most of intent links would be) then the prefetch adds no additional data over the wire but provides a significantly better UX. I don't think it goes against the preference because it doesn't add any extra data (most of the time)?

I'm probably in the minority here, but it feels somewhat overly restrictive to say "you, as a Remix developer, cannot improve the UX for this link click even if you are 95% sure it will be clicked.". If/when those cases arise, it feels like adding this as the default for intent opens up future requests for API bloat like <Link prefetch="intent" noReallyEvenOnSaveData> when users could just not opt into intent in the first place. Or, said another way, we provided an opt-in behavior, turned it off when opted-in due to a browser setting, and gave you another opt-in flag. The docs could be very clear on the proper way to use intent in combination with saveData etc. if we decided this didn't make sense for intent.

Astro's ignoreSlowConnection seems like a different concept - they don't seem to have a way to opt out of "data saver mode"?

[jrestall]

Agreed, not checking saveData in the case of prefetch="intent" makes sense to me given the user is highly likely to download that data anyway.

Astro's ignoreSlowConnection seems to check both slowData and 2g networks, so to opt out of data saver mode you also ignore 2g networks. Not the best naming.