wkhtmltopdfの次どうするか問題2026

by Shinichi Maeshima

Embed

Start on current slide

Slide 1

Slide 1 text

wkhtmltopdfの次どうするか問題2026 Shinichi Maeshima(@willnet) RailsTokyo#6 2026/09/17

Slide 2

Slide 2 text

wkhtmltopdfの次どうするか問題2026

Slide 3

Slide 3 text

wkhtmltopdf知ってる人🖐

Slide 4

Slide 4 text

wkhtmltopdfとは • HTMLからPDFを生成するツール • Qt Webkitというブラウザエンジンを利用してHTMLを描画し、その結果を PDFとして出力する • Qt(デスクトップアプリや組み込みアプリを作るためのフレームワーク)の中のプロジェクトの一つがQt Webkit • 主にユーザに「今見ている画面のPDF版」をダウンロードさせたいときに使われる • Rubyからだと主にwicked̲pdfやpdfkitなどのgem経由で使われる

Slide 5

Slide 5 text

wicked̲pdfを利用したときのコード例

Slide 6

Slide 6 text

wkhtmltopdfはPDFをレンダリングするときの第一候補だったが…

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

This repository was archived by the owner • Qt webkit自体がメンテナンス終了してしまったことにより、Qt webkitに依存しているwkhtmltopdfもメンテナンスが終了した • QtはQtWebEngineというchromiumベースのプロジェクトに移行している • wkhtmltopdfが依存しているのはQt4系であり、2012年のブラウザエンジンである

Slide 9

Slide 9 text

2012年のブラウザエンジン

Slide 10

Slide 10 text

wkhtmltopdfを利用したときに使えないjsの記法や機能 • アロー関数 • let, const • async, await

Slide 11

Slide 11 text

wkhtmltopdfを利用したときに使えないcssの記法や機能 • FlexBox • Grid • CSS変数

Slide 12

Slide 12 text

セキュリティの問題 • CVE-2022-35583 • 最新のwkhtmltopdf(0.12.6)に見つかったSSRFの脆弱性 • iframeなどのsrcを外部入力できると任意のURLの情報をPDFの形で得ることができてしまう • 外部からの入力をエスケープしない、というのが条件なので一般的なRails アプリケーションでは成立しづらいとは思います

Slide 13

Slide 13 text

wkhtmltopdfから他の何かに移行したい!!!!

Slide 14

Slide 14 text

次どうします？ • というのを以前(3年半前)ブログに書いた • 要約: ferrumやgrover、Thinreportsなんかがいいんですかね？

Slide 15

Slide 15 text

続編も書いた • 要約: ferrumを利用してPDF変換するferrum̲pdfが便利で良さそう

Slide 16

Slide 16 text

2026年現在 • まだまだwkhtmltopdfを使い続けているプロジェクトは残っている印象

Slide 17

Slide 17 text

なぜなのか • 工数が足りない • 情報が足りない • その他(もし知ってたら後で教えて!)

Slide 18

Slide 18 text

工数が足りない • 僕にはどうにもできないので頑張ってください＞＜

Slide 19

Slide 19 text

情報が足りない • どの選択肢を選ぶといいのかがわからない、知見が足りていないのでは？という仮説 • 例1: wkhtmltopdfから(任意のツール)に移行するとどのくらい負荷がかかりますか？ • 例2: 候補となるツールの比較

Slide 20

Slide 20 text

選択肢とそれに関する知見を話していきます

Slide 21

Slide 21 text

選択肢1: 運用でカバーする

Slide 22

Slide 22 text

運用でカバーする • ユーザに対して、macなら⌘+p、pcならctrl-pを押してもらい自分でwebページをPDFに保存してもらう • 自社の社員が触る管理画面である、という前提なら割と現実的かつ楽な選択肢じゃないかと思います

Slide 23

Slide 23 text

選択肢2: 一からPDFを生成する

Slide 24

Slide 24 text

一からPDFを生成する • 「HTMLをPDF変換」ではなく、Thinreportsなどのツールを使って一から PDFを生成する • HTMLをPDF化する必要がないなら考えることが減って楽

Slide 25

Slide 25 text

選択肢3: chromiumをアプリケーションサーバ内で使う

Slide 26

Slide 26 text

chromiumをアプリケーションサーバ内で使う • groverとferrum̲pdfが候補 • groverはpuppeteer経由でchromiumを動かす • ferrum̲pdfはRubyから直接chromiumを動かす

Slide 27

Slide 27 text

puppeteer経由だと何がどれくらい違うんですか？ • puppeteerを使うにはアプリケーションサーバにnodeが必要、というのはあるけど、それ以外で具体的にどう違うんですかね • メモリ消費量など変わったりするんですか？？？

Slide 28

Slide 28 text

具体的に知るためにベンチマークをとった • willnet/html-to-pdf-benchmark (https://github.com/willnet/html-to-pdf-benchmark) • dockerがあればお手元でも試すことができるようにしています • 利用マシン: M1 Max MBP • wkhtmltopdf、Grover, Ferrum(ferrum̲pdf)で次の環境を用意して32のPDF化リクエストを割り振り、その時のCPU、メモリ、スループットを見た • 1スレッド1プロセス • 4スレッド1プロセス • 1スレッド4プロセス • 4スレッド4プロセス

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

なぜこのような違いがあるのか • ferrumはプロセスごとに1つのchromiumブラウザインスタンスを使い回す • (ただしPDFへの変換はロックを用いて1スレッドのみ実行できるようにしている) • groverはPDF生成を1回実行するごとに新しいchromiumブラウザインスタンスを起動してPDF生成後に終了する • なので単純なベンチマークだとferrumの方が優れているように見える

Slide 32

Slide 32 text

運用も考えるとgroverの方が安定していそう • 毎回chromiumブラウザインスタンスを作成→終了する方がメモリリークやメモリの断片化の影響を受けにくい • chromiumがクラッシュしても影響はその時1回だけに限定される

Slide 33

Slide 33 text

groverとferrumの比較をしたものの • そもそもの話としてchromiumで500MB以上のメモリ消費量がアプリケーションに上乗せされるのってどうなんですかね • アプリケーションサーバの台数を増やす必要が出てくる • アプリケーションサーバの依存ライブラリも増える

Slide 34

Slide 34 text

選択肢4: 別のアプリケーションサーバでchromiumを動かすものを作る

Slide 35

Slide 35 text

HTML→PDFの専用アプリケーションを作る • 「HTMLを投げたらPDFを返すアプリケーション」があるとアプリケーションサーバのメモリ問題等をある程度緩和できる • SaaSは検索すると色々出てくるけど、大体においてPDF化したいHTMLは帳票などの外に出したくない情報なので自前で持ちたい

Slide 36

Slide 36 text

自社で作っている例1: ANDPAD社 • PDF 生成との終わらない戦い、あるいはデータ量の見積もりミスの話 ANDPAD Tech Blog (https://tech.andpad.co.jp/entry/ 2026/06/30/100000) • 専用アプリケーション内でgroverを使ってHTML→PDF化 • 運用中に起きた問題点を共有してくれてありがたい🙏

Slide 37

Slide 37 text

自社で作っている例2: Gusto社 • Building Virtuous PDF: How Gusto Replaced a Deprecated Library with a Modern PDF Microservice (https://engineering.gusto.com/ building-virtuous-pdf-how-gusto-replaced-a-deprecated-library-with-amodern-pdf-microservice-b37c481eaa03) • wicked̲pdfに対するvirtuous̲pdfを作った • 専用アプリケーションでferrumを利用している

Slide 38

Slide 38 text

自社で作るという選択肢 • 素朴な実装であればサッと作ることはできそう • ただし長期にわたって運用するのであれば巨人の肩に乗れると楽では

Slide 39

Slide 39 text

選択肢5: 別のアプリケーションサーバでchromiumを動かすものを使う

Slide 40

Slide 40 text

Gotenberg • Dockerベースのgo言語製PDF生成ツール • HTMLを受け取りPDFを返すHTTPアプリケーションサーバ • 内部ではchromiumを利用 • PDF生成ツールとしてはだいぶ有名

Slide 41

Slide 41 text

gotenbergのRubyクライアント • sanzstez/gotenberg-ruby • しかし個人的に書き味が好みではない

Slide 42

Slide 42 text

gotenberg-rubyの書き味

Slide 43

Slide 43 text

自分好みにしたくて自作してみた • willnet/gotenberg-rails

Slide 44

Slide 44 text

gotenberg-rails • 諸々準備しておけば↓だけでpdfを返せる

Slide 45

Slide 45 text

ここまでのまとめ • wkhtmltopdfの代替方法としていくつかの手法を紹介しました • 運用でカバーする • 一からPDFを生成する • アプリケーションサーバ内で変換する • PDF変換用アプリケーションサーバを作る • PDF変換用アプリケーションサーバを使う

Slide 46

Slide 46 text

おしまい？ • 応募時点ではそのつもりだったのですが… • sghtmltopdfという超新星が8月に現れてしまった

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

sghtmltopdfとは • rust製 • chromiumを使わず、servo(OSS webレンダリングエンジン)内の各ツールを利用してHTMLをレンダリングし、それをPDFに変換している • wkhtmltopdfとメモリ容量がほぼ同等で速い( https://waka.github.io/ sghtmltopdf/ ) • wkhtmltopdf(wicked̲pdf)からの移行ドキュメントがある • アプリケーションサーバから使う、もできるしgotenbergのような形でも使える • ストリーミングモード(PDFを作りつつクライアントにレスポンスを返す)ができる

Slide 49

Slide 49 text

sghtmltopdfを使うときに考慮すること • 現時点でJavaScriptは使えない • タグは無視される • CSSもchromeと同等ではなく、使えないものがある • 他にもいくつか制限あり( https://waka.github.io/sghtmltopdf/appendix/ limitations.html ) • ただしwkhtmltopdfからの移行、という前提ならおおよそ問題ないはず？

Slide 50

Slide 50 text

まとめ • wkhtmltopdfからの移行であればsghtmltopdfをまず検証してみましょう • どうしてもchromiumが欲しい時にはgotenbergかferrum̲pdfがいいんじゃないでしょうか • アプリケーションサーバでPDF生成する、と外部サービスとしてPDF生成機能を外出しするかを検討しましょう • 自分たちでコントロールしたいぞ、というのであれば自作も選択肢として良さそうです