feat: support routing prefetching and trustless gateways preconnects

[aschmahmann]

Support routing prefetching and trustless gateways preconnects

Description

Closes #979. The idea here is to parallelize requests the service worker is likely to make with the installation of the service worker itself.

Notes & open questions

Some todo / outstanding items:

• The DNSLink prefetching assumes the configured resolvers cover all domains which is currently the case for all configured build options, we could add the logic to properly handle this
• None of these prefetches / preconnects are necessary if the page is just a simple identity multihash of a raw cid. Should we specially handle this case (even if not other cases like a tiny unixfs object inlined in an identity multihash)

Note: This was generated with LLM help, if there's a better way to solve #979 or if we want to start with something small like hard-coded preconnects instead of the complexity involved with the prefetches that's fine by me. There are some tests here, but idk if there are reasonable ways to do end-to-end testing here.

Change checklist

• I have performed a self-review of my own code
• [ ] I have made corresponding changes to the documentation if necessary (this includes comments as well)
• I have added tests that prove my fix is effective or that my feature works

[achingbrain]

Interesting, I wonder if we could first try it with rel=preconnect for delegated-ipfs.dev (since we'll almost certainly query it for providers) and rel=dns-prefetch for trustless-gateway.link (since we will fall back to it if direct retrieval is not possible). That way we don't make any extra fetch requests.

[aschmahmann]

That way we don't make any extra fetch requests.

Is there any way (aside from requests where the entire data is in an identity multihash like bafkqaaka.ipfs.inbrowser.link) where we don't end up making one of the listed fetch requests? i.e.

• DNSLink resolution
• IPNS resolution
• IPFS routing lookup

wonder if we could first try it with rel=preconnect for delegated-ipfs.dev (since we'll almost certainly query it for providers)

Starting with this and then comparing the performance of prefetch vs preconnect after seems fine, but again AFAICT we're always going to hit this endpoint unless it's for identity multihash requests where no networking is needed.

and rel=dns-prefetch for trustless-gateway.link (since we will fall back to it if direct retrieval is not possible).

Seems reasonable to me, I'd rather users fetch directly when possible rather than relying on the public infra here, but IIUC we use it for most requests anyway (i.e. it will race with the delegated routing lookup which needs to happen before retrieving from anyone else).

[lidel]

We discussed this briefly during colo, I had slight concern that executing prewarm code in the main page may backfire

• due to the way JS is execurted and sheduled by V8, it may slow things down (execution, request ordering)
• we end up with redundant requests

Not against it, just noting we should measure if there is visible improvement on top of other things like hints alone (#984 etc)