業務用PDFが重い原因をファイル容量と画像の画素数で分ける

結論

PDFの「重い」は、保存容量が大きいことと、表示に時間がかかることを分けて考える必要があります。 画像を圧縮して保存したバイト数だけでは、画像を展開する際のデータ量や、ページを描く処理の全体は分かりません。

Adobeの容量の調査機能は、画像、フォント、テキストなどを分けて示します。

これは保存ファイルの内訳を調べる機能の説明です。その項目の割合が大きいことだけで、閲覧時に一番時間を使う処理だとは確定しません。

同じ幅・高さの画像でも、保存形式や絵柄によってファイル容量は変わります。 一方、画像を赤・緑・青の各1バイトという同じRGB形式へ展開して並べると、画素数×3バイトになります。

300×300画素なら90,000画素、3000×3000画素なら9,000,000画素です。縦横がそれぞれ10倍になると画素数は100倍で、縦横を足した20倍ではありません。

PDF内の画像は、文字や線と別のデータとして格納される場合があります。画面で小さく配置されていても、元の画像の画素が多いことがあります。ただし、内部のすべての画像が同時に同じ形式で展開されるとは限りません。

同じ配色の格子図を2種類の寸法と2形式で作り、PDFへ変換しました（n=4）。 2026-10-01、300角・3000角それぞれのPNGとJPEGを、当サイトの画像PDF変換でA4縦1ページ・余白ありに配置しました。JPEGの作成品質は0.9です。

入力画像	保存されたPDF	画像の画素数	RGBへ展開した画像データ
300×300 PNG	2,282バイト	90,000	270,000バイト
300×300 JPEG	7,383バイト	90,000	270,000バイト
3000×3000 PNG	58,641バイト	9,000,000	27,000,000バイト
3000×3000 JPEG	82,728バイト	9,000,000	27,000,000バイト

別のPDF読取処理で、全4件が1ページ・画像1個、画像の寸法が入力と同じであることを確認しました。抽出画像をRGBへ展開し、得られたバイト列の長さも数えています。PDFの全4ページを描画して目視しました。

同寸法の2形式はPDFの容量が違っても、RGBに展開したバイト数は同じでした。今回の格子図ではPNG由来のPDFが小さくなりましたが、写真でも同じ順になるという比較ではありません。

27,000,000バイトは抽出画像のRGBデータ量で、ブラウザが使ったメモリー量ではありません。 PDF全体の処理には他のデータや作業領域もあり、今回その使用量は測っていません。

画像の解像度を落とす方法と、保存時の圧縮方式を変える方法は、別の調整です。 Adobeは画像のダウンサンプルについて一次資料の節に引用したとおり説明しています。

低解像度化は細かい文字や図の情報にも影響します。提出先が解像度を指定する書類では、その条件とファイル上限の両方が比較対象になります。

また、PDF.jsのFAQは、高解像度で多くのページを一度に描く話の中で、一次資料の節に引用したとおり述べています。

これは表示ページのキャンバスを保持する処理の説明で、上表の抽出画像のRGB量とは別です。閲覧ソフトが同時に描く範囲や倍率も関係するため、保存容量だけを速度の指標にはできません。 当サイトやすべての閲覧ソフトが、このデモと同じ方式という意味でもありません。

本文で参照した一次資料の引用と出典をまとめます。

「各要素のサイズをバイト単位」

「画像の解像度を低くすることによってファイルサイズを縮小します。」

“The demo viewer creates, renders, and holds canvases only for visible pages to reduce the amount of used memory.”

— Mozilla PDF.js「Frequently Asked Questions」、100ページの高解像度描画 https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions（2026-10-01 到達）

表示時間、実際のメモリー使用量、ネットワーク速度、端末ごとの差は測っていません。 4条件は自作の単純な画像で、実務PDF全体を代表しません。圧縮後の速度改善、写真や複雑なベクトル図、文字の読める解像度、特定の書類が遅い原因も判定していません。

困っているのが送信上限なのか、表示待ちなのかを分けることが入口です。保存容量の圧縮例は前者を比較する材料になります。後者の判断には、同じファイル・端末・閲覧条件での確認が別に必要です。