CorTeX の LaTeX コンパイルが速く感じられる理由

ローカルコンパイル、パッケージの事前取得、チェックポイント、図の再利用によって、編集内容が新しい PDF に反映されるまでの時間をどう縮めているかを紹介します。

LaTeX のコンパイルには、エンジン、文書クラス、パッケージ、フォント、 PDF ビューアーが必要です。CorTeX は、繰り返す必要のない処理を省くことで、 編集してから新しい PDF が表示されるまでの時間を短縮しています。

ここで大切なのは、コールドコンパイルとウォームコンパイルの違いです。 コールドコンパイルでは、ツールやファイルの取得が必要になる場合があります。 一方、ウォームコンパイルでは、準備済みのものを多く再利用できます。

これらの処理経路は自動的に選ばれます。速度と引き換えに正しさを諦めたり、論文の下書き用に別版を管理したりする必要はありません。

違いを試すには、一時的な LaTeX 論文を開き、最初の PDF を待ってから、末尾に近い一文を変更します。その更新と初回のコンパイルを比べてください。結果はプロジェクト、ブラウザー、端末、キャッシュ済みファイルによって変わります。以下では、処理経路によって所要時間が違う理由を説明します。

用語集#

• エンジン: ソースを読み取る pdfLaTeX などの TeX プログラムです。
• TeX Live スナップショット: プロジェクトが使うクラス、パッケージ、フォント、ツールを固定した集合です。
• コールドコンパイル: エンジンまたは TeX ファイルをまだ取得する必要があるコンパイルです。
• ウォームコンパイル: ブラウザーですでに準備したものを再利用できるコンパイルです。
• チェックポイント: 互換性のある後の編集で処理を再開できる、安全に保存されたエンジン状態です。

コンパイラはエディターのすぐそばで動く#

通常の LaTeX 組版はブラウザー内で行われます。CorTeX は wasmtex を使い、 TeX エンジンを WebAssembly としてパッケージ化しています。WebAssembly は、 コンパイル済みのプログラムを最新のブラウザーでも実行できる、移植性の高い形式です。

ウォームコンパイルでは、TeX の主要な処理のために、ソースをリモートサーバーへ アップロードし、そこでコンパイルしてから結果をダウンロードするという往復を 避けられます。共同執筆者による変更はネットワークを通じて届く場合がありますが、 組版がその通信を待つ必要はありません。エディターとコンパイラは、\input や \include で読み込むファイルも含め、ブラウザー内にある同じプロジェクトファイルを 参照します。

研究者にとっては、通常の文章や数式を編集した際、最初に原稿全体をコンパイルサーバーへアップロードしなくてもプレビューを更新できるということです。

初回のコンパイルで再利用できる作業環境を整える#

ブラウザーには TeX Live があらかじめ入っているわけではありません。 コールドコンパイルでは、選択した TeX エンジンを読み込み、その文書で使う パッケージ、フォント、フォーマットファイルを取得する必要があります。 学会用テンプレートのほうが、1 ページの文書よりも多くのファイルを必要とするのは 自然なことです。

これらのファイルは、変更されない TeX Live スナップショットから取得されます。 特定のアドレスにあるファイルが予期せず変わることはないため、ブラウザーは安全に キャッシュできます。同時に、プロジェクトは選択した TeX 環境に結び付いたままです。

プロジェクトを開いている間、CorTeX は準備済みのエンジンを使い続けられます。 タブを閉じるとエンジンは停止しますが、ダウンロードした TeX ファイルは ブラウザーのキャッシュに残る場合があります。ブラウザーデータの消去、キャッシュの 自動削除、またはプロジェクトの TeX 環境の変更によって、次回のコンパイルが再び コールドコンパイルになることがあります。

プロジェクトに必要な TeX ファイルを記憶する#

必要な TeX ファイルがブラウザーにないとき、エンジンは取得が終わるまで停止します。 これを 1 ファイルずつ繰り返すと、組版そのものよりネットワークの待ち時間が 長くなることがあります。

コンパイルに成功すると、CorTeX はプロジェクトで使用した TeX Live ファイルの名前を 記録します。対象には、クラス、パッケージ、フォント、フォーマットファイルなどが 含まれます。この記録に論文の本文は含まれません。次にプロジェクトを開いたとき、 エンジンが各ファイルを個別に要求する前に、既知の一式を並行して取得できます。

CorTeX は現在のコンパイルに必要なものを改めて確認しますが、前回使ったファイルは 先回りして準備します。対応している組み込みテンプレートにはテスト済みの一覧が 用意されているため、初めて開くときにもこの仕組みを利用できます。

この準備は、効果が見込めるときだけ始めます。アクティブなワークスペースが表示されるまで待ち、 タブが非表示のとき、データセーバーが有効なとき、または接続が非常に遅いときは、 不要かもしれないファイルを先回りしてダウンロードしません。ユーザーが要求した コンパイルは常に優先されます。

この最適化は、パッケージを多く使う投稿先テンプレートを再度開くときに特に効果が見えます。並列で準備することにより、同じファイルをネットワークリクエストで一つずつ再発見せずに済みます。

ひと続きの入力を一度の有用なコンパイルにまとめる#

単語を一つ入力する間にも、ほんの一瞬に複数の変更が発生します。1 文字ごとに TeX を実行すると無駄が生じるだけでなく、古い結果が新しいプレビューを上書きする おそれもあります。

CorTeX は短時間に続いた編集をまとめてからコンパイルします。コンパイル中に、 それより新しい要求の処理が優先された場合、古い結果でプレビューを更新することは ありません。最後に成功したコンパイルへの入力が何も変わっていなければ、同じ入力を 再コンパイルせず、その PDF を使い続けられます。

エディターはまずキー入力を処理し、その後でソースの検査と PDF の処理を別々に スケジュールします。そのため、コンパイルがエディターの即座の応答を妨げません。

チェックポイントを使って編集箇所の近くから再開する#

互換性のある pdfLaTeX プロジェクトでは、コンパイルに成功した後、カーソルの近くに チェックポイントを準備できます。チェックポイントには TeX エンジンの状態が 保存されます。

次の編集がその位置より後ろにあり、それより前の入力が変わっていなければ、 エンジンはそこから処理を再開し、残りを組版できます。その場合も完全な PDF を 生成します。検証していないページの断片をつなぎ合わせるわけではありません。

CorTeX はコンパイルに成功した後の短い待機時間にチェックポイントを準備し、 ユーザー操作による次のコンパイルに準備のコストを持ち越さないようにします。 まだ準備を始めていなければ、新しい編集が入った時点で取り消します。

この近道を使うのは、安全な場合だけです。設定用コマンド、ラベル、引用、必要なファイル、 メイン文書、エンジン、プロジェクト構成を変更すると、フルコンパイルが必要になることが あります。一部の古い TeX 環境はチェックポイントに対応していません。 安全に再開できると CorTeX が確認できなければ、フルコンパイルを実行します。

実際には、安定した原稿の後半で行う編集ほど、最短の処理経路を使える可能性が高くなります。プリアンブルの修正や引用の変更では、完全な処理経路になるのが想定どおりです。

コンパイルに時間のかかる図も結果を再利用できる#

TikZ や pgfplots の図は、コンパイル中にグラフィックを描く小さなプログラムです。 図が多い論文では、図をもう一度描くほうが本文の組版より長くかかることがあります。

TikZ の外部化が有効で安全に使える場合、CorTeX は図を別々のジョブとして コンパイルします。その後は TikZ 自身の内容チェックにより、本文だけを編集したとき、 変更されていない図を再利用できます。端末に十分なメモリがあれば、複数の図の コンパイルジョブを同時に実行できます。

すべての図を安全に分離できるわけではありません。オーバーレイや一部のカスタム環境では、 文書全体の情報が必要です。CorTeX はこうした場合を検出し、完全なコンパイルに戻ります。 図のジョブが失敗した場合も同様です。

一部の補助ツールはサーバーを使う#

参考文献や索引を処理するツールの中には、ブラウザーで実行できないものがあります。 文書が Biber または Xindy を必要とするとき、CorTeX はその段階に必要なファイルだけを 隔離されたサービスへ送ります。TeX の主要な処理は引き続きローカルで実行され、 同じ入力に対する補助処理の結果も再利用できます。LaTeX をコンパイルしてプレビューするでは、 エンジンを選び、これらの処理段階を確認する方法を説明しています。

範囲を限定した補助処理への入力には、参考文献、索引、必要なソースデータが含まれる場合があります。これは通常のブラウザー内組版経路の例外です。文書が要求していない補助処理へプロジェクトファイルが送られることはありません。

高速経路でも正しい PDF を作る#

どの最適化にも、完全なコンパイルへ戻る仕組みがあります。キャッシュしたファイルは TeX 環境ごとに分けられます。CorTeX が結果を再利用するのは、ソース、必要なファイル、 エンジン、環境が引き続き一致している場合だけです。古いコンパイル結果が新しい プレビューを上書きすることもありません。正しさは速度と引き換えにするものではなく、 すべての高速経路で満たすべき条件です。

制御された測定から分かること#

2026年9月3日に行ったアプリ内ワーカーの内部トレースでは、検証済みの tl2026-20260826-4f5a814 プロファイルで24ページの論文を使いました。互換性のあるチェックポイントからの再開にかかったコンパイラ時間は、このトレースのフルコンパイルのおよそ10分の1でした。この記録には、絶対時間の再現に必要なブラウザーのバージョン、端末の CPU とメモリ、キャッシュのウォーム状態が残っていません。そのため、これは仕組みを示す証拠であり、利用者向けのベンチマークや速度の保証ではありません。また、測定したのはコンパイラの処理であり、ページの読み込みや最初の PDF ページが描画されるまでの時間ではありません。結果は文書、ブラウザー、端末、キャッシュ、ネットワークによって異なります。

CorTeX は、コンパイラが使えるようになるまで、PDF が生成されるまで、PDF の最初の ページが表示されるまでの時間をそれぞれ測定します。また、ビルド時には、ワークスペースを 最初に開く際にダウンロードするコンパイラコードの量を制限しています。そのため、 コンパイルを高速化しても、エディターが開くまでの時間は長くなりません。

執筆中に気づくかもしれないこと#

特に初めて使うブラウザーやファイルの多いプロジェクトでは、初回のコンパイルに時間が かかることがあります。ブラウザーでのコンパイルには手元の端末を使うため、大きな論文は 古い端末やメモリの少ない端末で遅くなる場合があります。 CorTeX はリソースの限られた端末では並行処理を制限し、近道を安全に使えないときは 完全なコンパイルを行います。

違いは自分で確かめられます。一時 LaTeX プロジェクトを開き、 最初の PDF が表示されるのを待ってから、文を一つ変更し、次のコンパイルを確認してください。 次に、プリアンブル内のパッケージを変更し、完全な処理経路と比較します。実際の時間は環境ごとに異なりますが、コールドコンパイルとウォームコンパイルの違いは確認できるはずです。

設定用コマンド、ラベル、引用を頻繁に変更するとフルコンパイルが増えることがあります。 複雑な図を多数作り直す場合も同様です。実践的なヒントについては、 LaTeX プレビューを高速に保つと LaTeX プロジェクトを複数のファイルに分けるを参照してください。

自分の編集で所要時間を比較する際は、初回の準備、ソースの依存ファイル、図のどれが変わったかを記録してください。条件を併記すると時間の意味が分かり、プレビュー速度のガイドで次に確認すべきことを判断しやすくなります。