Make Bilibili Great Than Ever Before: a TypeScript userscript fork that fights platform throttling

A rewrite of a userscript, not a new client

Make Bilibili Great Than Ever Before is a fork of the userscript Make Bilibili Great Again by kookxiang, rewritten in TypeScript. The README is explicit about the intent: the project tries some experimental features and experimental APIs, and it says some of those will eventually be merged back into the original script. The repository description says the same thing with a slightly different wording, describing the fork as having some experimental features.

The audience is narrow and the tooling tells you what it is. The source is TypeScript, the build runs through rollup with the swc3 plugin, and the output is a single .user.js file with the metadata block generated by rollup-plugin-userscript-metablock. The package name is make-bilibili-great-than-ever-before and the published entry point is the dist directory. This is a script that runs inside a browser, injected by a userscript manager, and it modifies one specific site.

The name, as the README explains, comes from a 2024 United States presidential campaign slogan. The project is MIT licensed, and the copyright line credits Sukka as author and maintainer with help from contributors.

Installing is one URL handed to a userscript manager

The installation section is a single URL and nothing else, which is the standard shape for a userscript distributed through a CDN.

https://unpkg.com/make-bilibili-great-than-ever-before@latest/dist/make-bilibili-great-than-ever-before.user.js

The URL points at the latest tag on unpkg and at the built user script inside the dist folder. Opening it in a browser with a userscript manager installed triggers the manager's install prompt, and the script manager then keeps the file updated according to its own settings.

Three managers are named as supported: Tampermonkey, Violentmonkey, and AdGuard used as a browser extension rather than as a standalone app. The AdGuard case is worth separating out, because an extension based manager intercepts page requests in a different place than a Tampermonkey or Violentmonkey sandbox does, and a script that depends on the page context existing in a particular way can behave differently there.

The path is deliberately unpinned, using the latest tag, so the script a viewer runs today is the newest build the author has published. The repository has no GitHub releases, so the version marker that appears in the script metadata comes from package.json, which currently reads 1.9.1.

What the script does to requests, playback and the page

The feature list is the substance of the project, and it falls into a few groups. The first group removes platform behaviours that cost the viewer. The infinite request retry storm for log reporting and user tracking is disabled completely, and useless tracking parameters are stripped from URLs. Homepage ads are removed along with a style optimization pass, the story list is reorganized, and the black filter effect on the page is removed.

The second group changes how the video is delivered, and this is where the engineering is. The script blocks AV1 codec playback, on the reasoning that the platform picks it to save money and it burns the viewer's CPU and GPU. It blocks PCDN, the cheap peer assisted delivery the platform uses, and it blocks WebRTC peer to peer traffic, which the README frames as the platform stealing the viewer's bandwidth. Thread Ripper splits the video into even smaller pieces and races them from many CDN hosts in parallel to raise throughput and reduce buffering.

The third group touches quality and comfort. Live is enhanced to force the original stream quality plus other fixes, the 4K player is force enabled even on low-end devices such as a Chromebook or a Linux machine, article clipboard prevention is defused so copying is free, the player width is fitted to the viewport, and HarmonyOS fonts are removed in favour of the system default font.

Thread Ripper trades server load for parallel requests

The Thread Ripper feature deserves its own look because it is the one with real engineering content, and because it is the one that changes the relationship between the viewer and the platform's infrastructure.

The mechanism described in the README is straightforward: split the video segments into even smaller pieces, and race them from downloading via many CDN hosts in parallel, to get maximum throughput and minimize buffering. This is a client side change to how range requests are issued and reassembled. The user's connection and the client do the parallelising, which is why throughput can rise on a link where a single stream was limited.

The reason to be careful is that the same technique is what makes peer assisted delivery attractive to the platform in the first place. Moving the fan-out to the viewer's own requests keeps the benefit and removes the platform's share of the load, but it also means the client is issuing many more concurrent requests, and the feature list shows the project is deliberately hostile to the platform's own peer distribution.

The dependencies in package.json hint at the implementation. There is a fake-indexeddb package, which suggests a client side storage layer for request or segment state, fast-percentile for latency measurement, flru and foxts for a data structure and a functional utility library, and xbits for bit manipulation that would fit segment and range arithmetic. None of this is documented in prose, so the details of the race are in the source rather than in the README.

Blocking codec and peer delivery is a blunt instrument

Two of the features are pure blocks, and they carry the trade-off the project makes explicit. Preventing AV1 use and preventing PCDN and WebRTC traffic are presented in the README as preventing the platform from saving money at the viewer's expense, and the phrase about coffins is the author's own phrasing.

The viewer benefit is real but conditional. Blocking PCDN and WebRTC removes a source of unpredictability, since peer assisted segments arrive from other users' connections whose speed the viewer does not control. Blocking AV1 removes a decode cost on hardware that cannot afford it. Both help most on the hardware the README names, low-end devices like a Chromebook or a Linux machine, and on networks where peer delivery is slow.

The cost is that the viewer no longer chooses. There is no configuration described in the README for making AV1 available on a machine that handles it well, and no fallback ordering between the remaining codecs, so the script picks for everyone. The project also has no option list in the documentation at all, which is a documentation gap rather than a defect: the feature list is presented as a set, and the settings that decide which items are enabled are in the code and in the script manager's own interface.

A build pipeline that produces one distributable file

The repository is a pnpm workspace with the source in src and the build configuration in rollup.config.ts and userscript.meta.json, which holds the metadata that gets compiled into the script header. The TypeScript configuration and an eslint configuration sit alongside them, and there is a .node-version file pinning the Node version used for development.

The scripts in package.json describe the release flow. Lint runs eslint with a custom formatter named sukka. Build runs rollup with the rollup.config.ts configuration, the swc3 plugin, and the bundleConfigAsCjs option. A prerelease script runs lint and then build in sequence, which means a release cannot skip the lint step. Release uses bumpp to bump the version, commit it and tag it, across all packages, and the packageManager field pins pnpm at 12.11.2.

The build output is a single file, and the distribution model is the unpkg URL in the README. That is a straightforward CI to unpkg path, and it means the person who installs the script gets exactly what the author built, with no signing or packaging step in between. The published package exposes only the dist folder through the files field, so the src tree is not what a consumer receives.

Maintenance without releases, and the upstream relationship

The last push was on 2026-10-15, so the repository is receiving work. The repository has no GitHub releases, which is consistent with the bumpp based release script, where the version is committed and tagged in git rather than published as a GitHub release object.

The upstream relationship is the more important thing for a user to understand. The project describes itself as a fork that will feed features back into Make Bilibili Great Again, which means there are two codebases with different feature sets and different update cycles, and the site underneath is changing for both of them. A userscript that patches a specific site breaks when the site changes, and the failure mode is a script that silently stops doing anything rather than an error message.

The MIT licence covers the fork, and it also covers the original work it is derived from, since that script is distributed under the same permissive terms on Greasy Fork. For a viewer, the licence question is not the interesting one. What matters is the update path, and that is the unpkg latest path in the installation section, which resolves to whatever the author last published.

Editorial conclusion

This userscript fits a single viewer who watches Bilibili on a connection where peer assisted delivery and transcoding cause stalls, and it does not fit a team that needs a maintained, supported video client, since it patches one site from the browser with no release tags and no versioned downloads. Before installing it, read the feature list and disable the pieces you do not want, because the project disables platform features globally rather than per video, and pin a specific version instead of the latest unpkg path if you care about a script that keeps behaving the same after an upstream site change.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. SukkaW/Make-Bilibili-Great-Than-Ever-Before on GitHub