TCPDF-Next

繁體中文

English
简体中文
日本語
한국어

繁體中文

English
简体中文
日本語
한국어

外觀

效能基準 ​

本頁面呈現 TCPDF-Next 與其他主流 PHP PDF 函式庫（TCPDF、DomPDF、mPDF）的完整效能基準比較。所有測試均在相同硬體、相同 Docker 容器環境下執行，確保公平且可重現的結果。我們報告中位數而非平均值，以消除離群值干擾。當 TCPDF-Next 不是最快的，我們會誠實地指出。

測試環境 ​

參數數值
CPUIntel Core i9-13900K（x86-64）
記憶體64 GB DDR5（Docker 限制 16 GB）
Docker4 CPUs、16 GB RAM、Ubuntu bookworm
PHP8.5.3（CLI，OPcache 啟用，JIT 啟用）
TCPDF-Next1.6.0
TCPDF-NextArtisan (Chrome)1.0.0
TCPDF6.10.1
DomPDFv3.1.4
mPDFv8.2.7
暖機3 次迭代（丟棄）
測量20 次迭代（取中位數）
計時hrtime(true) 奈秒精度掛鐘時間

TIP

所有基準測試皆為自動化且可重現。基準測試套件位於儲存庫的 tests/Benchmark/ 目錄中，您可透過 Docker 自行執行。

互動式比較圖表 ​

▼ Lower is better
TCPDF-Next
0.63 ms
TCPDF
2.5 ms4.0x
DomPDF
4.07 ms6.5x
mPDF
7.13 ms11.3x

PHP 8.5.3 + OPcache + JIT · Docker 4 CPUs / 16 GB · i9-13900K · Median of 20 runs

產生速度 ​

每個情境在暖機後執行 20 次。下表顯示中位數產生時間、峰值記憶體、輸出檔案大小及相對於 TCPDF-Next 的速度比較。

簡單文件（1 頁，純文字） ​

一頁 A4 文件，包含標題、數段文字及基本格式化。無圖片、無表格。

函式庫時間（ms）峰值記憶體（MB）檔案大小（KB）相對速度
TCPDF-Next0.6343基準（1.0x）
TCPDF2.501273.97x 慢
DomPDF4.071226.46x 慢
mPDF7.13162811.32x 慢

TCPDF-Next 在簡單文件情境下表現最佳，僅需 0.63 ms 即可完成產生，比 TCPDF 快近 4 倍，比 mPDF 快超過 11 倍。

發票（2 頁，表格 + 圖片） ​

兩頁發票，包含公司標誌、多行明細表格、小計與頁尾。

函式庫時間（ms）峰值記憶體（MB）檔案大小（KB）相對速度
TCPDF1.151691.43x 快於 TCPDF-Next
TCPDF-Next1.641652基準（1.0x）
DomPDF19.0916411.64x 慢
mPDF21.66183013.21x 慢

誠實揭露

在發票情境中，TCPDF 以 1.15 ms 的成績比 TCPDF-Next 的 1.64 ms 快約 1.4 倍。這是因為 TCPDF 在此類小型文件的低階 PDF 物件組裝上具備高度最佳化的路徑。不過，TCPDF-Next 的輸出檔案較大（52 KB vs. 9 KB），主要來自嵌入更完整的字型子集與元資料。在其餘所有情境中，TCPDF-Next 均明顯領先。

100 頁報告（密集文字） ​

100 頁文件，內容為密集混合內容：標題、段落及結構化資料橫跨多頁。

函式庫時間（ms）峰值記憶體（MB）檔案大小（KB）相對速度
TCPDF-Next32.391896基準（1.0x）
TCPDF102.47181013.16x 慢
mPDF1,044.058218132.23x 慢
DomPDF2,705.557012983.52x 慢

大型文件是 TCPDF-Next 優勢最為顯著的場景。以 32.39 ms 產生 100 頁報告，比 TCPDF 快 3.2 倍，比 DomPDF 快超過 83 倍。記憶體使用量與 TCPDF 相同，遠低於 DomPDF 和 mPDF。

HTML 轉 PDF ​

HTML → PDF（內建解析器） ​

使用各函式庫內建 HTML 解析引擎，將包含 CSS 樣式、表格、圖片與多欄版面的 HTML 片段轉換為 PDF。

函式庫時間（ms）峰值記憶體（MB）檔案大小（KB）相對速度
TCPDF-Next0.93747基準（1.0x）
TCPDF7.6274138.19x 慢
DomPDF16.0974517.30x 慢
mPDF33.62744636.15x 慢

TCPDF-Next 的 HTML 解析引擎交出亞毫秒級效能 — 比 TCPDF 快 8 倍，比 mPDF 快 36 倍。四套函式庫在此情境中峰值記憶體幾乎相同（74 MB），表明開銷主要由 HTML 解析基礎設施本身所主導。

HTML → PDF 搭配 Chrome 渲染（TCPDF-NextArtisan） ​

TCPDF-NextArtisan 透過 Chrome DevTools Protocol（CDP）使用無頭 Chrome 進行像素完美的 HTML 轉 PDF 渲染。

函式庫時間（ms）峰值記憶體（MB）檔案大小（KB）
TCPDF-NextArtisan (Chrome CDP)309.857437

309.85 ms 顯著高於 DomPDF（16.09 ms）或 mPDF（33.62 ms），但這是刻意的取捨 — 以時間換取完整的 Chrome 渲染引擎能力。

為什麼 Chrome 渲染較慢？ ​

  1. Chrome Page 生命週期 — 每次渲染需要 createPage() → setViewport() → setHtml() → evaluate() → printToPDF() → close() — 多次 CDP 通訊往返
  2. printToPDF 開銷 — Chrome 的內建 PDF 列印引擎本身需要 ~200-300 ms（即使 HTML 很簡單）
  3. PDF 解析 + XObject 匯入 — 還需要解析 Chrome 產生的 PDF 並萃取 Form XObject 嵌入最終文件

速度 vs 品質的取捨 ​

DomPDF / mPDFTCPDF-NextArtisan
CSS 支援有限（不支援 Flexbox、Grid、複雜選擇器）完整 CSS3（Flexbox、Grid、Web Fonts、媒體查詢、CSS 變數）
渲染引擎自行實作的 CSS 解析器Chrome Blink 引擎（像素完美）
速度16-34 ms~310 ms
適用場景簡單排版複雜 CSS3 版面、品牌一致性要求

BrowserPool keep-alive 機制已在使用中，避免每次 200-500 ms 的 Chrome 啟動成本。

選擇指南

簡單 HTML（表格、基本格式）請用 TCPDF-Next 內建 HTML 解析器（0.93 ms）。需要像素完美的複雜 CSS3 版面時，使用 TCPDF-NextArtisan — ~310 ms 的額外開銷換來 Chrome 渲染引擎的完整能力。

吞吐量基準 ​

在持續工作負載中每秒 / 每分鐘可產生的簡單文件（1 頁）數量。

單執行緒 ​

函式庫文件/秒文件/分鐘
TCPDF-Next2,684161,014
TCPDF1,24474,626
DomPDF26015,588
mPDF1337,994

4 個 Workers（並行處理） ​

函式庫文件/秒文件/分鐘
TCPDF-Next9,434566,024
TCPDF4,431265,832
DomPDF93956,334
mPDF48429,044

吞吐量摘要

在單執行緒模式下，TCPDF-Next 每分鐘可產生超過 161,000 份文件，是 TCPDF 的 2.2 倍、DomPDF 的 10.3 倍、mPDF 的 20.1 倍。使用 4 個 Workers 並行處理時，吞吐量進一步提升至每分鐘超過 566,000 份文件，展現出優異的水平擴展能力。對於高量批次處理（發票、報表、對帳單產生），這些吞吐量數據直接轉化為基礎設施成本節省。

數位簽章額外負擔 ​

新增數位簽章時的額外時間與檔案大小（其他函式庫不支援 PAdES 進階簽章）。

簽章等級額外時間額外檔案大小
PAdES B-B+15 ms+5-8 KB
PAdES B-T+120 ms*+8-12 KB
PAdES B-LT+250 ms*+15-50 KB
PAdES B-LTA+350 ms*+20-60 KB

*包含至 TSA/OCSP 伺服器的網路往返時間。實際時間取決於伺服器延遲與網路狀況。

TIP

PAdES B-B（基礎簽章）僅增加 ~15 ms 與 5-8 KB — 對大多數工作流程而言可忽略不計。更高等級（B-T、B-LT、B-LTA）會引入來自時間戳記機構與 OCSP 回應服務的網路相關延遲。

函式庫PAdES 支援備註
TCPDF-NextB-B / B-T / B-LT / B-LTA完整 PAdES 長期驗證支援
TCPDF僅基礎 PKCS#7不支援 PAdES 進階等級
DomPDF不支援—
mPDF不支援—

PDF/A-4 歸檔額外負擔 ​

產生符合 ISO 19005-4 的 PDF/A-4 文件時的額外負擔。

項目額外大小
sRGB ICC 色彩描述檔+3 KB
XMP 元資料+2-5 KB
輸出意圖+1-3 KB
完整字型嵌入（如有需要）+50-500 KB / 字型
典型總額外負擔+10-50 KB
產生時間額外負擔< 5%

TIP

PDF/A-4 模式下預設仍使用字型子集化。額外負擔主要來自 ICC 色彩描述檔與擴充的元資料。對大多數文件而言，PDF/A-4 的額外負擔可忽略不計。

為什麼 TCPDF-Next 更快？ ​

效能優勢來自多項刻意的架構決策：

  1. 現代 PDF 2.0 核心 — 渲染管線從零為 PDF 2.0 打造，消除拖慢 TCPDF 的舊版相容層。交叉引用串流與物件串流同時降低 I/O 負擔與檔案大小。

  2. JIT 友善的程式碼路徑 — 熱點迴圈與關鍵渲染方法經過結構化設計，充分利用 PHP 8 JIT 編譯器。緊湊、強型別、低分支的程式碼讓 JIT 能產生高效的機器碼。

  3. 延遲資源載入 — 字型、圖片與 ICC 色彩描述檔僅在首次使用時載入，而非在建構時。不嵌入圖片的文件零圖片處理開銷。

  4. 高效記憶體佈局 — 頁面物件經過壓縮，並透過參考計數共用資源（字型、色彩空間），即使長文件也能維持低峰值記憶體。

  5. 最佳化的 HTML 解析器 — 不同於舊版 TCPDF 的正規表達式 HTML 解析，TCPDF-Next 使用串流式標記解析器，單次掃描即可處理 HTML，回溯量極小。

  6. 可並行化設計 — 無狀態的頁面渲染架構讓工作負載可在多個 Workers 間線性擴展，如 4 Workers 近 4 倍吞吐量增幅所示。

TIP

上述最佳化在大型文件（如 100 頁報告）中效果最為顯著。對於 1-2 頁的小型文件，各函式庫的差距較小，某些情境下（如發票）傳統 TCPDF 甚至可能略快。

測試方法論 ​

基準設計原則 ​

  1. 隔離 — 每項基準測試在獨立的 PHP 程序中執行，防止交叉測試的記憶體污染
  2. 暖機 — 丟棄前 3 次暖機迭代後才開始正式測量，確保 OPcache 與 JIT 已完全暖機
  3. 迭代 — 每項測試案例 20 次測量迭代
  4. 統計方法 — 報告中位數（有效抵抗離群值干擾），而非平均值
  5. 記憶體測量 — 使用 memory_get_peak_usage(true) 取 RSS 對齊的峰值記憶體
  6. 時間測量 — 使用 hrtime(true) 提供奈秒精度的掛鐘時間，避免 microtime() 的時鐘漂移問題
  7. 檔案大小 — 輸出寫入暫存檔案後以 filesize() 測量
  8. 環境一致 — 所有函式庫在相同 Docker 容器中執行，使用相同的 PHP 設定、CPU 限制與記憶體限制

公平性聲明 ​

我們致力於提供公正的基準測試結果。所有函式庫均使用其最新穩定版本，並啟用各自建議的最佳化設定。基準測試原始碼完全公開，任何人都可以檢視、質疑或重現我們的結果。如同上文所述，在發票情境中 TCPDF 確實比 TCPDF-Next 更快，我們不會迴避對自身不利的數據。

重現基準測試 ​

基準測試套件包含在儲存庫中。您可以使用 Docker 在自己的機器上重現所有結果：

bash
# 複製儲存庫
git clone https://github.com/YeeeFang/tcpdf-next.git
cd tcpdf-next

# 使用 Docker 建置基準測試環境
docker build -t tcpdf-benchmark -f docker/benchmark/Dockerfile .

# 執行完整基準測試套件
docker run --rm \
  --cpus=4 \
  --memory=16g \
  tcpdf-benchmark

# 執行特定基準測試
docker run --rm \
  --cpus=4 \
  --memory=16g \
  tcpdf-benchmark \
  --filter=InvoiceBench

# 或使用 Composer（非 Docker 環境）
composer install
composer run benchmark

# 產生基準測試報告
composer run benchmark:report

TIP

為確保結果可重現，建議使用上述 Docker 指令，以與本頁面相同的硬體限制（4 CPUs、16 GB RAM）執行測試。在不同硬體上，絕對數值會有所不同，但函式庫間的相對差距應保持一致。結果會在執行結束時輸出至 stdout。Docker 設定確保環境一致，不受主機作業系統影響。

延伸閱讀 ​

以 LGPL-3.0-or-later 授權釋出。

Copyright © 2026-present Yeeefang