ひとことで言うと
preloadとは「このリソースを最優先で先読みしてください」とブラウザに指示するHTMLの属性です。`<link rel="preload" href="hero.webp" as="image">`のように書くと、CSSやJavaScriptの解析が終わる前に画像を取得し始めます。ファーストビューに必ず表示されるリソースに使うのが基本です。
AIが生成したHTMLではpreloadが省略されていることが多く、フォントファイルや大きなヘッダー画像の読み込みが遅れがちです。共有する前に`<head>`内を確認し、ファーストビューで使うリソースにpreloadを加えることで、受け取った相手の体験が改善されます。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
HTML共有で関係する場面
プレゼン資料をHTML形式で共有する際、カバー画像とタイトルフォントの読み込みが間に合わないと「最初だけ文字化けした」という報告が来ます。`<link rel="preload" href="font.woff2" as="font" crossorigin>`をheadに追加するだけで、フォントが適用された状態でファーストビューが表示されるようになります。
ギガサイト便のような静的HTML共有サービス経由で社外の取引先に送る場合、preloadの指定があればCDNのキャッシュと組み合わさって初回アクセスでも高速表示されます。一方でpreloadが効くのはページ内に実際に使われているリソースのみで、使わないものをpreloadするとかえって他のリソースの読み込みを妨げます。
よくある誤解
「preloadを増やせば増やすほど速くなる」という誤解が広がっています。ブラウザが並列で取得できる接続数には限りがあるため、preloadを10個以上並べると帯域を奪い合い、むしろ重要なリソースが遅れます。preloadは本当に最初の画面で必要なもの1〜3個に絞るのが基本方針です。
preloadとprefetchを混同するケースも多いです。preloadは「今のページで今すぐ使う」リソース用、prefetchは「次のページで使いそう」なリソースを暇なときに取る仕組みです。AIが生成したHTMLにprefetchが含まれていても、それは次画面の先読みであって今のページの速度とは直接関係しません。
安全に使うための注意点
crossorigin属性の付け忘れに注意してください。フォントファイルはCORSポリシーの対象で、`crossorigin`を書かないとブラウザがpreloadしたファイルを使わずに再リクエストします。その結果preloadの恩恵がゼロになり、むしろ無駄な通信が増えます。
社外共有するHTMLにpreloadで参照している外部URL（GoogleフォントやCDNのURL）が含まれる場合、そのサービスのアクセスログに閲覧者のIPが残ります。機密性の高い共有先には外部フォントをBase64埋め込みにするか、ローカルフォントを使う方法を検討しましょう。
よくある質問
preloadしたフォントが結局使われずにブラウザの警告が出る場合、原因は何ですか？
CSSで参照しているフォントファイル名とpreloadのhref値が一致していないか、crossorigin属性が抜けているケースがほとんどです。DevToolsのNetworkタブで二重リクエストが発生していないか確認してください。
preloadを追加したのにLighthouseスコアが上がりませんでした。なぜですか？
preloadで先読みしたリソースが実際にファーストビューで使われていない場合、Lighthouseは改善を認識しません。preloadの対象をヒーロー画像やWebフォントなど初期描画に必要なものに限定しているか見直してください。
AIが生成したHTMLにpreloadが含まれているかどうかは、どうやって確認できますか？
HTMLファイルをテキストエディタで開き、`<head>`タグ内に`rel="preload"`の記述があるか検索すればわかります。Chromeで開いてDevToolsのNetworkタブを見ると、Priority列が「Highest」のリソースがpreload対象です。