変換されたページは、手作業で構築したページと同じくらい高速になることもあれば、変換中や変換後のいくつかの選択次第で著しく遅くなることもあります。
HTMLブロックよりネイティブウィジェットを優先する
これが最も大きな要因です。1つの大きなHTMLウィジェットにページを配置すると、そのページに存在しない要素向けのルールも含め、元のスタイルシート全体が一緒に読み込まれます。ネイティブコンポーネントモードでは、Elementorがページごとにスタイルを生成してキャッシュする実際のウィジェットが作成されるため、未使用のCSSを大幅に削減できます。さらに、編集可能なページも手に入ります。
元のスタイルシートをどう扱うかを決める
インラインスタイルを保持しておくことは変換中に役立ちます。クラスベースのスタイルを正しく測定できるからです。しかし、いったん各ウィジェットが独自の設定を持つようになれば、ページ上部に残るCSSブロックは冗長になることがよくあります。それを削除してレイアウトを確認してみてください。何も動かなければ、不要な重荷を一括で削除できたことになります。
画像には最も注意を払うべきです
- データURLを埋め込むのではなく、実際の画像をメディアライブラリにアップロードしてください。Base64画像はリサイズ、個別のキャッシュ、遅延読み込みができず、ページのHTML自体を肥大化させます。
- どこでも1つの大きなサイズを強制するのではなく、WordPressがレスポンシブなサイズを配信するようにしてください。
画像最適化オプションが実際に行うこと
このオプションは名前から想像されるより限定的で、その境界を知っていれば、できないことに期待してしまうのを防げます。
これは高忠実度モードでのみ、かつおよそ135KBを超えるBase64データ画像（PNG、JPEG、WebP）に対してのみ実行されます。それらはデコードされ、最長辺が最大2560pxになるように縮小されて再エンコードされます。結果画面には、処理された数と削減された容量が表示されます。
この機能が行わないこと：URLで参照されている画像には手を付けません。それらはサーバー上のファイルであり、このツールが書き換えるべきものではないからです。また、ネイティブコンポーネントモードではまったく実行されません。そこではBase64画像はメディアライブラリから入力するためのラベル付きの空スロットになります。いずれにしても、そちらの方が良い結果です。
つまり正直にまとめると、このオプションが救うのは特定の状況、すなわち画像がすべてインライン化されたページ（通常はAIツールで生成されたもの）を高忠実度インポートした場合です。画像が適切なURLであれば、このオプションは無関係であり、実際の最適化は本来行われるべき場所、つまりWordPressがレスポンシブサイズを生成するメディアライブラリで行われます。
ネストの深さに注意する
深いコンテナツリーは編集しにくいだけでなく、各レベルが追加のDOMノードと追加の生成CSSルールになります。構造マップが7〜8の深さを示している場合は、ソースを簡素化するか、ツリーのより深い位置にコピールートを設定してください。フラットな出力は、より高速で保守も容易です。
フォント
変換されたページには、ソースが使用していたフォントがそのまま指定されます。それらがサイトで既に読み込んでいるフォントでない場合は、正しく登録するか、サイトのタイポグラフィに切り替えて、ページが既に配信しているフォントを使うようにしてください。避けたいのは、インポートした1つのセクションのために2つ目のフォントファミリーを読み込むことです。
動作はネイティブに追加し直す
スクリプトは変換中に削除されます。これはパフォーマンスと安全性の両面で良いことです。スライダー、タブ、カウンターを再構築するときは、サードパーティのスクリプトを貼り戻すのではなく、Elementor独自のウィジェットを使用してください。それらは既に読み込んでいるバンドルの一部です。
変換されたページが自動的に肥大化しない理由
自動変換によってページが大量の設定に埋もれ、それらの設定がすべてCSSになってしまうのでは、という懸念はもっともです。それを防いでいることが2つあります。
第一に、レスポンシブ値はデスクトップと異なる場合にのみ書き出されます。すべての幅で同じパディングを持つコンテナには、3つではなく1つのパディング値だけが設定されます。60個のウィジェットがあるページでは、これが軽量なスタイルシートと、3分の2が冗長なルールで占められたスタイルシートとの違いになります。
第二に、何もしていないことが明らかなラッパーは変換されずに削除されます。残ったすべてのコンテナは、独自の生成ルールを持つ実際の<div>なので、スタイル効果のないものを削除すれば、DOMノードとそのCSSの両方を取り除けます。
それでも修正できないのは、元から深いソースマークアップです。コンバーターはHTMLを忠実に再現するものであり、再設計するものではありません。7階層のソースは、各階層をどれほど注意深く扱っても重いページになります。だからこそ、インポート後の整理よりも、ソースの時点でフラット化することの方が価値があります。
測定してから整理する
クリーンアップの前後に、ページのスピードテストを実施してください。通常、改善効果は3つの場所から得られます。冗長なスタイルシートブロックの削除、大きすぎる画像の置き換え、過剰なネストツリーのフラット化です。どれも時間はかからず、通常はこれらを合わせたものが差の大部分を占めます。
正しい数値に注目してください。総ページサイズとLargest Contentful Paintは画像の作業に反応します。Cumulative Layout Shiftは、画像に明示的なサイズが指定されることで改善します。メディアライブラリから入力したプレースホルダーにはサイズがありますが、Base64画像にはないことがよくあります。そして、ほとんどのレポートに表示されるのにほとんどの人が読み飛ばすDOMノード数は、ネストが制御できているかどうかを教えてくれる数値です。