Pterodactyl vs Aquadactyl benchmarks

On 2026-10-16, the reviewed Aquadactyl frontend emitted 48.5% less dashboard JavaScript and CSS under gzip than the reviewed Pterodactyl release. Its median production frontend build was 1.489 s, compared with 15.790 s for Pterodactyl, a 10.60× build-duration ratio (Pterodactyl ÷ Aquadactyl).

These are local measurements of built frontend artifacts and build duration. The separate runtime benchmark measures browser load time, authenticated API throughput and memory use. Neither comparison measures Wings or game-server performance.

Interactive showcase · Raw results and file hashes · Build output

Compared sourceCopy Anchor Link

Pterodactyl is pinned to v1.15.1. These results apply to these exact commits. Both source checkouts had no tracked changes and no installed third-party addons. Aquadactyl's bundled Blueprint framework was included as shipped.

The older before/after numbers in Aquadactyl's own performance notes describe a different comparison. They were not used as a Pterodactyl baseline here.

Dashboard assetsCopy Anchor Link

Pterodactyl's CSS is carried inside its JavaScript through style-loader. Zero separate CSS bytes does not mean it has no styles. The headline includes JavaScript and separately emitted CSS to account for this difference.

For Aquadactyl, the script follows the Vite manifest's entry and dashboard route, recursively adding their static imports and CSS. It does not add unrelated dynamic routes. For Pterodactyl, it reads Webpack's main entry files and dashboard chunk group from the actual compilation. Shared files are counted once.

Each file is gzipped individually at level 6, then the sizes are summed. This is a transfer-size estimate, not an HTTP measurement. Fonts, images, translations, HTML, API payloads and transport headers are outside this asset count. Payload totals come from the final measured build; per-build payload samples and every counted filename/SHA-256 are in the raw report.

Production build timeCopy Anchor Link

Each panel had one discarded warm-up and five measured builds. After warm-up, run order alternated by round: Aquadactyl/Pterodactyl, then Pterodactyl/Aquadactyl. Builds ran sequentially in fresh Node processes with production mode and each repository's default production bundler configuration.

Timing includes loading the bundler and its configuration, compiling assets and compiler shutdown. It excludes dependency installation, package-manager startup and the script's artifact analysis. Upstream's JS/map clean step runs before its timer; Vite performs its normal output cleanup during the build. The results compare the shipped toolchains, rather than swapping both to the same bundler.

Locked dependencies were installed first, with lifecycle scripts disabled for both installs. The build itself ran normally. No package versions or optimization settings were changed. This shared development machine was not CPU-isolated; background processes and operating-system caches were not controlled. Repeat the test on your build host when estimating deployment time.

Test environmentCopy Anchor Link

ReproduceCopy Anchor Link

Use clean, separate source checkouts. The benchmark writes generated build assets in those checkouts. It does not connect to a running panel or require PHP, a database, administrator credentials or a game server.

git clone https://github.com/Aquadactyl/aquadactyl.git aquadactyl-bench
git -C aquadactyl-bench checkout --detach b5cc74ecb11d031c33582ef257a189efc9f3178c
git clone --branch v1.15.1 https://github.com/pterodactyl/panel.git pterodactyl-bench

cd aquadactyl-bench
pnpm install --frozen-lockfile --ignore-scripts
cd ../pterodactyl-bench
yarn install --frozen-lockfile --ignore-scripts

From the website repository, using the absolute paths to those checkouts:

node scripts/benchmark-panels.mjs /path/to/aquadactyl-bench /path/to/pterodactyl-bench
node scripts/verify-panel-showcase.mjs

The script saves the raw JSON, build output and this guide. The homepage reads the same JSON so its numbers update together. Preserve the source revisions and lockfile hashes when publishing a new comparison.