The functionality for this module sounds very similar to the Quicklink module.

Can we compare the two in the interests of avoiding duplicated efforts, combining best features/practices, and improving information and research for potential users.

Pros/Cons & Differences - how is this module fundamentally different from Quicklink? What does it do better or worse? Is it simpler or more complicated? What are the key differences that would enable a prospective user to choose between the two?

Merge - is there potential to review the two implementations, and then combine resources/efforts to put forth a single, best recommended module?

Alternatives - Should 'Speculative Loading' and 'Quicklink' be listed as alternative options for each other?

Comments

w01f created an issue.

jurriaanroelofs’s picture

jurriaanroelofs commented

Thank you for pointing this out. I wasn't previously aware of the Quicklink module, and it does appear to overlap with the goals of Speculative Loading. At a high level, Quicklink prefetches in-viewport links during idle time, while Speculative Loading provides a more flexible, standards-based approach using the browser's native speculation rules, including support for prerendering.

It’s possible that the two modules could be consolidated, and Quicklink might be a more appropriate home given its maturity. However, I haven’t had the time to do a detailed technical comparison or evaluate its current implementation. Until then, I’ll position Speculative Loading as an alternative approach and update the documentation accordingly.

Since the quicklinks module does not mention Speculative Loading I think it only uses the older prefetch tech, here is a quick comparison of the 2 technologies:

Feature Quicklink (Prefetch) Speculative Loading (Browser-native)
Standard JavaScript-based (custom logic) Based on speculationrules
Trigger In-viewport links during idle time User interaction (hover, focus), or DOM-based rules
Fetch type fetch (preloads HTML as text) prefetch, prerender, or preload (native browser support)
Prerendering support No Yes
Customizability Medium (via JS options) High (via JSON rules, selectors)
Browser support Broad (uses standard JS APIs) Limited (currently Chromium-based browsers only)
Performance impact Low Medium to high (due to prerendering resource usage)
Implementation complexity Low Medium
Best for Simple prefetching in SPAs or link-heavy pages Fine-grained predictive navigation in modern apps
capellic’s picture

capellic
he/him/his
Location Austin, Texas
commented

I just realized this is cross-posted over here: https://www.drupal.org/project/quicklink/issues/3519746

tunetheweb’s picture

tunetheweb commented

FWIW, a few updates since that table was posted:

  • Quicklink now includes Speculation Rules allowing it to do a full prerender on supporting browsers.
  • Safari has a partial implementation of Prefetch rules (enabled by default in Tech Preview, but not yet released to stable).
  • Firefox are also experimenting with an implementation of the API for prefetch.
  • Speculation rules (on Chromium) now includes viewport heuristics on mobile for middle eagerness settings.
  • We are introducing prender_until_script to speculation rules to allow a middle-ground between prefetch (low risk, but low reward) and prerender (high reward, but higher risk if there are unintended consequences of running JavaScript before activating the page).


As far as implementations/platforms go:


More details here:


Let me know if you have any questions!

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

You might like adding Dries article: https://dri.es/speculation-rules-changed-my-mind-about-prefetching