ページの他の部分が読み込まれるのに画像が一枚だけ失敗する理由
三つの条件が、ネットワーク障害とブロックされたリクエスト、レンダリングエラーを分けます。経路を変える前に、ブラウザが選んだ URL を確認してください。
ページは読み込まれ、テキストも表示されるのに、画像が一枚だけ壊れたアイコンになります。変わったのはトンネルなので、まず疑うのはトンネルです。その前に、ページの URL と画像の URL は別々の証拠なので、ブラウザがその画像に対して実際に要求した URL を突き止めてください。画像が出ないという報告の多くは、正常なリクエストを一度も受け取らなかったホストに行き着き、その答えはネットワークパネルを一度見れば分かります。
どこを見るかは三つの条件で決まる
一つ目の条件は、画像がページと同じホストから来ているかどうかです。別の画像ホストには独自の名前解決、独自の接続、独自の TLS アイデンティティが必要なので、ページが読み込めてもそのホストのことは何も分かりません。
二つ目は、ブラウザが送信前にリクエストをブロックしたかどうかです。混在コンテンツ、コンテンツセキュリティポリシー、リファラーの規則は、通常のサーバー応答を生じさせずに画像を止めることがあり、だから一覧に失敗したリクエストが現れません。
三つ目は、配信は成功したが描画に失敗した場合で、バイトは届いているのに画像が表示されないケースです。この三つの条件には三つの異なる担当者がいて、ネットワークの問題なのは一つ目だけです。
| What you see | Where the fault sits |
|---|---|
| Request absent from the list | Markup, lazy loading or a policy that blocked it |
| Request failed or timed out | Resolution, route, TLS or the image host itself |
| Request returned 200, image blank | Response type, decoding or rendering |
ブラウザが実際に選んだリソースを見つける
ページのソースで見える URL が、実際に要求された URL とは限りません。ソースセット、picture 要素、CSS の背景はどれも、ビューポートの幅、ピクセル密度、形式の対応状況に応じて別のリソースを選ばせます。遅延読み込みの画像は、ページが特定の状態になるまでまったく要求されないことがあります。
要素とリクエストを一緒に調べ、問題を報告するときはリクエストとともに開始元を残します。MDN の画像要素のリファレンスは、ソースの選択、読み込みの挙動、リファラーの制御を一か所で扱っており、どの属性が失敗した URL を選んだかを判断するのに十分です。
ホスト名、ステータス、リダイレクトの連鎖、応答のコンテンツタイプを記録します。サインインページを返す 200 は使える画像ではなく、HTML のエラーページへのリダイレクトは、タイプを読むまで壊れたファイルと見分けがつきません。
ネットワークより先にステータスを読む
タイムアウト、拒否されたリクエスト、デコードエラーでは次の手順が異なり、それを分けるのがステータスコードです。タイムアウトは名前解決、経路、応答しないホストを指します。拒否されたリクエストはポリシーや認可の層を指します。デコードエラーはバイトか形式を指します。
リクエストがまったく現れないなら、ネットワークを見るのをやめてマークアップを見てください。最も多い原因は、ブラウザが優先したもののサーバーにもう存在しないソースセットの項目で、その次にスクリプトが可視にしなかった要素が続きます。
この区別だけで、この種の報告での無駄な作業の大半を防げます。
ブラウザがブロックすると、読むべき応答はない
混在コンテンツは典型的な例で、HTTPS のページが平文 HTTP で画像を要求すると、リクエストは失敗ではなくブロックされ、コンソールが理由を記録します。コンテンツセキュリティポリシーも同じ形になり、ブロックされたディレクティブがメッセージに示されます。ヘッダーを削るリファラーポリシーも、ホットリンク対策のあるホストに画像の代わりにプレースホルダーを返させることがあります。
ネットワーク経路に触れる前に、経路が変わってもこの種のブロックは改善しないので、記録された理由を読んでください。クロスオリジンの許可を足すのも解決策ではなく、別ホストの画像を表示することと、そのピクセルを canvas で読むことは別の操作で、ヘッダーが必要なのは後者だけです。
自分が管理するサイトなら、リソースの URL、応答、ポリシーをその所有者のところで直し、認可とリファラーの要件はそのまま保ちます。管理していないサイトなら、非公開や期限切れのリソースリンクを再公開するのではなく、ページとリクエストの証拠をそのサポート窓口に送ってください。
証拠を変えずに経路を比べる
アクセス経路を本当に試したいなら、同じページ、同じアカウント、同じ選択画像で、許可された経路を一つだけ変えて、ほかを一定に保ちます。描画結果は画像が出たかどうかを示すだけで理由は示さないので、描画結果ではなくリクエストの項目を並べて比べてください。
新しい経路で読み込めた画像は、その経路が認可されている証拠にはならず、壊れたままの画像はトンネルが原因だという証拠にもなりません。画像が削除されたり、アクセスが意図的に制限されていたりする場合は、証明書の検証を切ったり他人の保護された素材を複製したりせず、サポートされている代替手段を使ってください。
作業の順序は、選ばれた URL を特定し、そのステータスとタイプを読み、記録されたブロック理由を確認し、それから経路の変更を一つずつ比べることです。