Super-preloader joins paginated pages and preloads links from a userscript

The script joins pages by matching each site against a rule

Super-preloader is a userscript, which means it runs inside a page you already have open rather than as a separate application. Its stated purpose is to auto load paginated web pages, joining pages together based on the rules, and the project description calls it a userscript to enable autopagerizing as well as preloading.

The mechanism is a rule match. For a given site, a rule describes how the pagination works, where the next page link sits and how the pages should be stitched together, and the script applies that rule when the page loads. The same rule set also describes what should be preloaded, which is the second half of the tool: links on the page are fetched ahead of time so that clicking them feels instant.

That design has a clear consequence. The script is generic, and the knowledge about any particular site lives in the rules rather than in the code. This is what separates it from a browser extension written for one service, and it is also why the rule data is the part of the project that matters most in practice.

The credits name swdyh as the origin of the autopager and preloader idea, and note that the same author keeps improving the rules, which are hosted separately at wedata.net. The original idea is therefore not contained in this repository, and the rules live somewhere else again.

The rule set lives in wedata.json rather than in the script

The top level of the repository makes the split visible. Two data files sit at the root, wedata.json and wedata_detail.json, alongside the source in src/ and the built userscript in dist/. The rules are data, and the script consumes them.

The README describes the project as forked from the Greasy Fork script 10433, a super-preloaderplus-one script, and says it has been refactored since v6.8.xx. What the refactor adopted, in the README's own framing, is new techniques, the features of ES6, and rollup to pack the script in place of webpack.

Keeping the rules outside the script has an effect on how you update it. A rule set changes far more often than the code, and a user script manager that updates the script on every save can pull in new rules without a code change at all. The cost is that a broken rule is harder to diagnose, because the symptom appears in the page rather than in a version number you can check.

The repository also keeps older generations of the project in separate directories, including legacy/, deprecated/ and archive/. For a project that has been refactored across major versions, that is a reasonable way to keep the old script available for users who cannot move, and it also means the current tree contains history that a newcomer has to read past.

Installation is a userscript URL from one of four hosts

There is no package to build for the end user. The README's installation table points at four places to fetch the built script: the project's GitHub Pages site, a Vercel deployment, the raw file on GitHub, and a JS Delivr CDN link to the dist folder. All four deliver the same file, Super_preloaderPlus_one_New.user.js.

The repository's package.json names that file as the entry point of the package:

  "name": "super-preloader",
  "version": "8.0.1",
  "description": "Super-preloader",
  "main": "dist/Super_preloaderPlus_one_New.user.js",
  "author": "Mach6",
  "license": "GPL-3.0",
  "type": "module",

Any of those URLs can be handed to a userscript manager, which recognises the file and asks whether to install it. After that, the script applies to the pages its rules cover.

For anyone working on the project rather than using it, the scripts section of the manifest gives the shape of the development loop, with a rollup watch mode for development and a plain rollup build for a release:

    "test": "cd test && node test.js",
    "dev": "rollup -c --dev -w",
    "build": "rollup -c",

The test script runs a Node script in the test directory, and a separate win test entry installs a Chrome binary through puppeteer before running the same suite, which suggests the tests are browser-based rather than unit tests over the rule engine.

Browser support is really userscript manager support

The compatibility table in the README is not really about browsers, it is about combinations of browser and userscript manager. Firefox with Violentmonkey or Greasemonkey 4 is listed, Chrome and Microsoft Edge Dev with Tampermonkey, Waterfox with Greasemonkey 3 or 4, and Safari on iOS with the Stay extension.

The script is described as tested under four specific combinations: Firefox latest with Violentmonkey, which the README marks as the recommended combination, Microsoft Edge Dev with Tampermonkey, Waterfox 56.3 with Greasemonkey 4.9, and Chrome 48 with Tampermonkey.

Those version numbers are old, and they say something about the support matrix rather than about the current state of the browsers. A user reading the table today should treat the four tested pairs as the minimum the maintainer has confirmed, not as a limit of what the script can do.

The repository supports this range on the build side as well. A .browserslistrc file at the root tells the transpiler which browser targets to compile for, and a polyfill/ directory sits alongside it, with babel.config.json handling the transformation. The legacy/ directory and the .node-version file suggest the old builds are kept runnable for the older managers in the table.

The toolchain requires pnpm and refuses npm installs

The build setup is where this project is most modern, and it is also where a contributor can trip over something. The manifest opens with a preinstall script that runs npx only-allow pnpm, which makes any npm install fail on purpose. The repository ships a pnpm-lock.yaml rather than a package-lock, and the scripts are written as pnpm invocations.

The rest of the workflow is familiar. A lint script covers the built JSON in dist, the source JavaScript, the CI scripts and the rollup configuration, with a matching fix script, and prettier handles formatting with separate write, check and staged variants. A check script chains lint, typecheck and format check together, and it runs automatically before a version bump through the preversion script.

The versioning scripts show how a release is assembled. The version script builds with rollup and stages the built JavaScript and JSON in dist, and the postversion script stages the manifest and runs the tests. Separate publish scripts bump the patch or minor version without creating a git tag, which means the tags in the repository are managed outside npm's version command.

That said, the version history of the project lives in npm rather than in GitHub releases. The repository has no tagged releases, so a user who wants to pin a version has to look at the npm version, currently 8.0.1, rather than at a release page.

Site rules need maintenance, and that is the weak point

The failure mode to expect is a site whose markup changed. Because the rules encode how a particular site's pagination and links are structured, any redesign can turn the rule into a no-op or into something worse, a loop that keeps joining pages that are not actually sequential, for instance. Nothing in the described design protects against that, since matching a live page structure is the whole job.

The second failure mode is quieter and affects the preloading side. Preloading issues requests for links before you follow them, which is the point of the feature and also the reason a site might throttle you or treat the traffic as automated. The script is a userscript running in your authenticated session, so those requests look like yours.

The third is scope. This is a pagination and preload tool for one page at a time, not a downloader. It does not schedule, it does not queue, and it does not keep a library. If your need is bulk retrieval, this is the wrong shape of tool.

On the flip side, the alternative is worth stating plainly. A general purpose extension with a rule database maintained elsewhere does exactly this for sites where the maintainers keep the rules fresh, and it saves you the rule authoring work entirely. The reason to choose Super-preloader instead is that it is a single file, it is inspectable, and its rule set is plain data in a public repository that you can read, correct or extend yourself.

Editorial conclusion

Adopt Super-preloader if you browse sites with infinite-scroll-like pagination and would rather join the pages yourself than click a next button, and if you already run a userscript manager such as Violentmonkey. Do not adopt it as a general downloader or for sites whose markup changes often, since the rule set has to be maintained per site and the project publishes no releases that map rules to a version. Verify first by installing the userscript from the GitHub Pages link and checking one site with a known rule before enabling preloading, because preload requests are the part most likely to annoy a site and to get an account rate limited.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. machsix/Super-preloader on GitHub
4. Project website
5. README