パフォーマンスベンチマーク
このページでは、TCPDF-Next を TCPDF、DomPDF、mPDF と同一条件で比較した実測ベンチマーク結果を掲載しています。すべてのテストは同一の Docker コンテナ内で実行し、公正な比較を保証しています。各シナリオで 3 回のウォームアップ（破棄）を行った後、20 回の測定を実施し中央値を報告しています。TCPDF-Next が最速でないケースについても正直に開示しています。
テスト環境
| パラメータ | 値 |
|---|---|
| CPU | Intel Core i9-13900K（x86-64） |
| RAM | 64 GB DDR5（Docker 制限: 16 GB） |
| Docker | 4 CPUs、16 GB RAM、Ubuntu bookworm |
| PHP | 8.5.3（CLI、OPcache 有効、JIT 有効） |
| TCPDF-Next | 1.6.0 |
| TCPDF-NextArtisan (Chrome) | 1.0.0 |
| TCPDF | 6.10.1 |
| DomPDF | v3.1.4 |
| mPDF | v8.2.7 |
| ウォームアップ | 3 回（破棄） |
| 測定 | 20 回（中央値を報告） |
| 計測関数 | hrtime(true) ナノ秒精度ウォールクロック |
TIP
すべてのベンチマークは Docker ベースで自動化されており、どなたでも同一環境で再現できます。詳しくはベンチマークの再現セクションをご覧ください。
インタラクティブ比較チャート
PHP 8.5.3 + OPcache + JIT · Docker 4 CPUs / 16 GB · i9-13900K · Median of 20 runs
生成速度
各シナリオでウォームアップ後に 20 回ずつ測定し、中央値の生成時間（ミリ秒）・ピークメモリ（MB）・出力ファイルサイズ（KB）を報告します。値が小さいほど高速・高効率です。
シンプルドキュメント（1 ページ）
見出し・3 段落のテキスト・基本的なフォーマットを含む単一の A4 ページです。画像やテーブルは含みません。
| ライブラリ | 時間（ms） | ピークメモリ（MB） | ファイルサイズ（KB） | 相対速度 |
|---|---|---|---|---|
| TCPDF-Next | 0.63 | 4 | 3 | 基準（1.0x） |
| TCPDF | 2.50 | 12 | 7 | 3.97x 遅い |
| DomPDF | 4.07 | 12 | 2 | 6.46x 遅い |
| mPDF | 7.13 | 16 | 28 | 11.32x 遅い |
TCPDF-Next は最もシンプルなシナリオを 1 ms 未満で完了します。TCPDF の約 4 倍、DomPDF の約 6.5 倍、mPDF の約 11 倍の速度です。
請求書（2 ページ）
ロゴ画像・テーブル・小計計算・ヘッダー／フッターを含む典型的なビジネス請求書です。
| ライブラリ | 時間（ms） | ピークメモリ（MB） | ファイルサイズ（KB） | 相対速度 |
|---|---|---|---|---|
| TCPDF | 1.15 | 16 | 9 | 1.43x 高速 |
| TCPDF-Next | 1.64 | 16 | 52 | 基準（1.0x） |
| DomPDF | 19.09 | 16 | 4 | 11.64x 遅い |
| mPDF | 21.66 | 18 | 30 | 13.21x 遅い |
正直な報告
請求書シナリオでは TCPDF が TCPDF-Next より約 1.4 倍高速（1.15 ms vs 1.64 ms）でした。TCPDF はこの種の小規模テーブルレイアウトに対して長年にわたり最適化されてきたレガシーテーブルレンダラーを持っており、このシナリオではわずかに優位に立ちます。ただし、両者ともに 2 ms 未満であり実務上の体感差はほぼありません。DomPDF と mPDF はいずれも 10 倍以上遅い結果となっています。
100 ページレポート
見出し・段落・画像・ヘッダー／フッターを含む混合コンテンツの大規模レポートです。
| ライブラリ | 時間（ms） | ピークメモリ（MB） | ファイルサイズ（KB） | 相対速度 |
|---|---|---|---|---|
| TCPDF-Next | 32.39 | 18 | 96 | 基準（1.0x） |
| TCPDF | 102.47 | 18 | 101 | 3.16x 遅い |
| mPDF | 1,044.05 | 82 | 181 | 32.23x 遅い |
| DomPDF | 2,705.55 | 70 | 129 | 83.52x 遅い |
100 ページレポートは TCPDF-Next の優位性が最も顕著になるシナリオです。32.39 ms で完了し、TCPDF の約 3.2 倍、DomPDF の約 83.5 倍高速です。ページ数が増えるほどその差は拡大します。メモリ使用量でも TCPDF-Next と TCPDF は 18 MB に留まる一方、DomPDF は 70 MB、mPDF は 82 MB を消費します。
HTML → PDF（内蔵パーサー）
各ライブラリの内蔵 HTML パーサーを使用して HTML マークアップを PDF に変換するシナリオです。
| ライブラリ | 時間（ms） | ピークメモリ（MB） | ファイルサイズ（KB） | 相対速度 |
|---|---|---|---|---|
| TCPDF-Next | 0.93 | 74 | 7 | 基準（1.0x） |
| TCPDF | 7.62 | 74 | 13 | 8.19x 遅い |
| DomPDF | 16.09 | 74 | 5 | 17.30x 遅い |
| mPDF | 33.62 | 74 | 46 | 36.15x 遅い |
TCPDF-Next の HTML パーサーは 1 ms 未満で処理を完了します。TCPDF の約 8 倍、mPDF の約 36 倍の速度です。4 つのライブラリすべてがほぼ同等のピークメモリ（74 MB）を消費しており、HTML パーシングインフラストラクチャ自体のオーバーヘッドが支配的であることを示しています。
HTML → PDF（Chrome レンダリング — TCPDF-NextArtisan）
TCPDF-NextArtisan は Chrome ブラウザエンジンを利用して HTML を PDF に変換する方式です。内蔵パーサーとは異なり、CSS Grid・Flexbox・Web フォントなどフルブラウザの描画機能を活用できます。
| 方式 | 時間（ms） | ピークメモリ（MB） | ファイルサイズ（KB） |
|---|---|---|---|
| TCPDF-Next（内蔵パーサー） | 0.93 | 74 | 7 |
| TCPDF-NextArtisan（Chrome） | 309.85 | 74 | 37 |
Chrome レンダリングが遅い理由
Artisan の Chrome レンダリングは内蔵パーサーと比較して約 300 倍の時間を要します。これは以下の要因によるものです。
- Chrome Page ライフサイクルオーバーヘッド — Chrome DevTools Protocol（CDP）を介した複数回の往復通信が発生します
- printToPDF 自体のコスト — Chrome 側の PDF レンダリングに約 200〜300 ms を要します
- PDF 解析 + XObject インポート — Chrome が出力した PDF を解析し、XObject としてインポートする追加処理が必要です
- 速度 vs 品質のトレードオフ — DomPDF や mPDF は CSS の対応範囲に制限がありますが、Artisan はピクセルパーフェクトな出力を実現します。複雑なダッシュボードやメール HTML テンプレートなど、高い CSS 忠実度が求められるシナリオで真価を発揮します
- BrowserPool keep-alive 使用済み — ブラウザプロセスの再利用による最適化が適用された状態でのこの数値です
速度が最優先の場合は内蔵パーサーを、レイアウトの正確さが最優先の場合は Artisan（Chrome）をお選びください。
生成速度まとめ
| シナリオ | TCPDF-Next | TCPDF | DomPDF | mPDF |
|---|---|---|---|---|
| シンプルドキュメント | 0.63 ms | 2.50 ms | 4.07 ms | 7.13 ms |
| 請求書 | 1.64 ms | 1.15 ms | 19.09 ms | 21.66 ms |
| 100 ページレポート | 32.39 ms | 102.47 ms | 2,705.55 ms | 1,044.05 ms |
| HTML → PDF（内蔵） | 0.93 ms | 7.62 ms | 16.09 ms | 33.62 ms |
| HTML → PDF（Chrome） | 309.85 ms | — | — | — |
ピークメモリ使用量
各シナリオでの memory_get_peak_usage(true) による RSS ピークメモリ消費量（MB）を比較します。値が小さいほどメモリ効率が高いことを意味します。
| シナリオ | TCPDF-Next | TCPDF | DomPDF | mPDF |
|---|---|---|---|---|
| シンプルドキュメント | 4 MB | 12 MB | 12 MB | 16 MB |
| 請求書 | 16 MB | 16 MB | 16 MB | 18 MB |
| 100 ページレポート | 18 MB | 18 MB | 70 MB | 82 MB |
| HTML → PDF（内蔵） | 74 MB | 74 MB | 74 MB | 74 MB |
| HTML → PDF（Chrome） | 74 MB | — | — | — |
シンプルドキュメントでは TCPDF-Next のメモリ消費量が他ライブラリの 1/3〜1/4 に抑えられています。100 ページレポートでは DomPDF（70 MB）・mPDF（82 MB）が大量のメモリを消費する一方、TCPDF-Next と TCPDF はともに 18 MB で済みます。HTML → PDF シナリオでは全ライブラリがほぼ同等の 74 MB を消費しており、HTML パーシングの DOM ツリー構造のオーバーヘッドがライブラリ間の差異を相殺していることがわかります。
出力ファイルサイズ
生成された PDF のファイルサイズ（KB）を比較します。値が小さいほどコンパクトです。
| シナリオ | TCPDF-Next | TCPDF | DomPDF | mPDF |
|---|---|---|---|---|
| シンプルドキュメント | 3 KB | 7 KB | 2 KB | 28 KB |
| 請求書 | 52 KB | 9 KB | 4 KB | 30 KB |
| 100 ページレポート | 96 KB | 101 KB | 129 KB | 181 KB |
| HTML → PDF（内蔵） | 7 KB | 13 KB | 5 KB | 46 KB |
| HTML → PDF（Chrome） | 37 KB | — | — | — |
ファイルサイズはシナリオによって結果が異なります。シンプルドキュメントと請求書では DomPDF が最小のファイルを生成します。これは DomPDF が最小限のメタデータと簡素化された PDF 構造を使用しているためです。一方、大規模ドキュメント（100 ページレポート）では TCPDF-Next が最小となり、PDF 2.0 のバイナリクロスリファレンスストリームとオブジェクトストリーム圧縮の効果が表れています。mPDF は全シナリオで最大のファイルサイズとなりました。
スループット
シンプルドキュメント（1 ページ）の連続生成における秒間・分間処理数を計測しました。
シングルスレッド
| ライブラリ | ドキュメント/秒 | ドキュメント/分 |
|---|---|---|
| TCPDF-Next | 2,684 | 161,014 |
| TCPDF | 1,244 | 74,626 |
| DomPDF | 260 | 15,588 |
| mPDF | 133 | 7,994 |
4 ワーカー（並列処理）
| ライブラリ | ドキュメント/秒 | ドキュメント/分 |
|---|---|---|
| TCPDF-Next | 9,434 | 566,024 |
| TCPDF | 4,431 | 265,832 |
| DomPDF | 939 | 56,334 |
| mPDF | 484 | 29,044 |
TCPDF-Next はシングルスレッドで毎秒 2,684 件、4 ワーカー並列で毎秒 9,434 件 の PDF を生成できます。これは TCPDF の約 2.2 倍、DomPDF の約 10 倍、mPDF の約 20 倍のスループットです。4 ワーカー時のスケーリング効率は約 3.5 倍であり、ほぼリニアにスケールしています。大量の PDF 生成が求められるエンタープライズ環境（請求書、レポート、明細書の一括生成など）では、このスループットの差がインフラコストの削減に直結します。
デジタル署名オーバーヘッド（PAdES）
TCPDF-Next は PAdES（PDF Advanced Electronic Signatures）に対応しています。10 ページのドキュメントを各 PAdES レベルで署名した際の追加コストを示します。他のライブラリは PAdES 署名をサポートしていないため比較対象には含まれていません。
| 署名レベル | 追加時間（ms） | 追加ファイルサイズ（KB） | 説明 |
|---|---|---|---|
| PAdES B-B | +15 | +5〜8 | 基本署名（CMS 署名内蔵） |
| PAdES B-T | +120* | +8〜12 | 信頼できるタイムスタンプを付加 |
| PAdES B-LT | +250* | +15〜50 | 長期検証データ内蔵（証明書チェーン + OCSP/CRL） |
| PAdES B-LTA | +350* | +20〜60 | アーカイブタイムスタンプ付加（長期保存用） |
* TSA / OCSP サーバーへのネットワーク往復を含みます。実際の時間はサーバーレイテンシとネットワーク条件に依存します。
INFO
PAdES B-B は基本署名のみでネットワーク呼び出しを必要としないため、オフライン環境でも使用できます。B-T 以上のレベルでは TSA サーバーへの接続が必要です。
PDF/A-4 アーカイブオーバーヘッド
標準 PDF 2.0 出力と比較した、PDF/A-4（ISO 19005-4）準拠出力生成のオーバーヘッドです。
| 構成要素 | 追加サイズ |
|---|---|
| sRGB ICC プロファイル | +3 KB |
| XMP メタデータ | +2〜5 KB |
| アウトプットインテント | +1〜3 KB |
| 完全フォント埋め込み（必要な場合） | フォントごとに +50〜500 KB |
| 一般的な合計オーバーヘッド | +10〜50 KB |
| 生成時間オーバーヘッド | < 5% |
TIP
PDF/A-4 モードでもデフォルトでフォントサブセット化が使用されます。オーバーヘッドの大部分は ICC プロファイルと拡張メタデータによるものであり、ほとんどのドキュメントでは無視できる程度です。
TCPDF-Next が高速な理由
TCPDF-Next のパフォーマンス上の優位性は、以下のアーキテクチャ上の決定に基づいています。
1. PHP 8.5+ 最適化
TCPDF-Next は PHP 8.5 の JIT コンパイラを最大限に活用しています。ホットパスのコードはネイティブマシンコードにコンパイルされ、インタプリタのオーバーヘッドが除去されます。readonly プロパティ・enum・Fiber など最新言語機能を活用してランタイム効率を最大化しています。
2. PDF 2.0 バイナリクロスリファレンスストリーム
レガシー PDF 1.x のテキストベースクロスリファレンステーブルに代わり、バイナリストリームを使用します。これによりパース速度が向上し、ファイルサイズが削減されます。
3. ストリーミング出力アーキテクチャ
大規模ドキュメント生成時、完了したページを即座に出力バッファにフラッシュします。ドキュメント全体をメモリ上に保持しないため、数百ページのドキュメントでもメモリ使用量が安定的に維持されます。
4. 現代化された HTML パーサー
レガシー TCPDF の正規表現ベース HTML パーサーを完全に書き直しました。SAX スタイルのイベント駆動パーサーを使用し、HTML → PDF 変換速度が 8 倍以上向上しています。
5. 効率的なフォントサブセット化
使用グリフのみを埋め込む最適化されたサブセット化アルゴリズムにより、ファイルサイズを最小化します。CJK フォントでも数百 KB レベルのサブセットのみを埋め込みます。
6. 並列化対応設計
ステートレスなページレンダリングアーキテクチャにより、ワークロードを複数ワーカー間でリニアにスケールさせることができます。4 ワーカーで約 3.5 倍のスループット向上がこれを実証しています。
テスト方法論
ベンチマークの公正性と再現性を保証するために、以下の方法論に従っています。
| 項目 | 詳細 |
|---|---|
| 隔離環境 | Docker コンテナ（4 CPUs、16 GB RAM）内で実行し、ホストシステムの影響を排除しています。 |
| ウォームアップ | 各テスト前に 3 回のウォームアップを実行し結果を破棄します。これにより OPcache・JIT のウォームアップ、ファイルシステムキャッシュ、PHP 内部最適化が安定化されます。 |
| 測定回数 | 20 回の測定後、中央値を報告します。中央値は外れ値の影響を受けにくいため、平均値より信頼性が高くなります。 |
| 時間計測 | hrtime(true) によるナノ秒精度のウォールクロック時間を使用します。microtime() のクロックドリフト問題を回避します。 |
| メモリ計測 | memory_get_peak_usage(true) で実際に割り当てられた RSS ピークメモリを測定します。 |
| ファイルサイズ | ディスクに書き込んだ後の最終 PDF ファイルサイズを filesize() で測定します。OS レベルのフラッシュを含みます。 |
| 同一入力 | すべてのライブラリが同一の入力データ（テキスト・画像・HTML）を使用します。 |
| GC | 各テスト前に gc_collect_cycles() を実行し、ガベージコレクションの影響を排除します。 |
| 公正な設定 | 各ライブラリのデフォルト設定を使用します。特定ライブラリに有利なチューニングは一切適用していません。 |
公正性に関する声明
私たちは公正なベンチマーク結果を提供することに尽力しています。すべてのライブラリは最新の安定版を使用し、各自が推奨する最適化設定を有効にしています。ベンチマークのソースコードは完全に公開されており、どなたでも検証・質問・再現が可能です。上述のとおり、請求書シナリオでは TCPDF が TCPDF-Next より高速であることを正直に報告しており、自身に不利なデータを隠すことはいたしません。
ベンチマークの再現
以下の Docker コマンドで、お手元の環境でベンチマークを再現できます。
# リポジトリのクローン
git clone https://github.com/nicholasgasior/tcpdf-next.git
cd tcpdf-next
# Docker イメージのビルド
docker build -t tcpdf-bench -f benchmark/Dockerfile .
# 全ベンチマークの実行（4 CPUs、16 GB RAM 制限）
docker run --rm \
--cpus=4 \
--memory=16g \
tcpdf-bench
# 特定シナリオのみ実行
docker run --rm --cpus=4 --memory=16g tcpdf-bench \
php benchmark/run.php --filter=SimpleDocument
# 結果を JSON でエクスポート
docker run --rm --cpus=4 --memory=16g tcpdf-bench \
php benchmark/run.php --format=json > results.json
# 結果を CSV でエクスポート
docker run --rm --cpus=4 --memory=16g tcpdf-bench \
php benchmark/run.php --format=csv > results.csvComposer でも実行可能です
Docker を使わない場合は、PHP 8.5 以上の環境で以下のコマンドでも実行できます。
composer install
composer run benchmarkINFO
本ページと同一の結果を再現するには、上記の Docker コマンドで同じハードウェア制限（4 CPUs、16 GB RAM）で実行することを推奨します。異なるハードウェアでは絶対値は変動しますが、ライブラリ間の相対差はほぼ一貫します。
関連ドキュメント
- 移行ガイド（TCPDF から） — TCPDF からの移行手順
- 移行ガイド（DomPDF から） — DomPDF からの移行手順
- 移行ガイド（mPDF から） — mPDF からの移行手順
- パフォーマンス最適化 — ストリーミングモードとメモリチューニング
- デジタル署名 — PAdES 署名の設定と使用方法
- PDF/A-4 アーカイブ — PDF/A-4 準拠出力の生成
- インストールガイド — TCPDF-Next のインストールと導入