過去掲載画像の混在コンテンツが解消されたようです【追記あり】

ちょっと状況は複雑なようです

こんにちは。Akiraさん。

過去掲載画像の混在コンテンツですが、現時点でおそらく状況は変わっていないと思います。

GoogleChromeで混在コンテンツ指摘されている過去記事の一例です。

https://blog-imgs-110.fc2.com/m/o/c/mochi1999/mixed-contents-min.png

HTMLソースとしてはhttpsアドレスに書き換えられています。
でもGoogleChromeデベロッパーのNetworkで見た時に、該当記事とは異なる要因(Initiator:Other)でhttpアドレス画像が読み込まれているようです。
その後、あらためて該当記事によってhttpsアドレス画像が読み込まれています。

そしてコンソールには「httpアドレス画像はプリロードされた」とあります。
勿論テンプレート・記事中においてもそんなことはしておりませんし、その場合はInitiatorが該当記事になるはずです。

GoogleChromeには「予測サービスを使用してページを迅速に読み込む」という設定がありますがそれをOFFにしても状況は同じでした。

上記の症状が出る記事と出ない記事があり、またそれは不定期のようでして、先日混在コンテンツ指摘されていたものが次の日は解消されたり、その逆もあります。

この画像がプリロードされるのは過去記事に限らず最近投稿記事でも起きておりますが、記事中の画像はhttpsアドレスになっているため問題なく済んでいるようです。

過去記事内の表示画像もhttpsアドレスに書き直してあげれば、仮にプリロードされた場合でもhttpsアドレス画像なので混在コンテンツには解消されることになります。

いずれ記事ネタにしようと思って、なぜこのようなことになっているのか自分なりに調べてみているのですが今のところはお手上げ状態です。(;・∀・)

To mochiさん

おはようございます  ﾟρﾟ)ﾉ

mochiさん、ダメだー。私の方も状況が後退しています。再度混在コンテンツに(笑)
preloadなんですが、今のところスマホデバイスでは無効のはずなんですよ。メモリの関係もあるので。なのでios Safariで必ず確認するんですけど、やはりこちらも再び…。

今フと思ったことが。パソコンを開ける環境になったらちょっと検証してみますね。

規則性が見られない

Akiraさん mochiさん　おはようございます。

私も同じで、必死こいて古い記事をいま手動で書き換えつつ、いろいろと考えております。
http:// → https:// に置き換わらない原因に「何か、規則性があるんだろうか？」と DevTool（ディベロッパーツール）だったり、多方面から追いかけているんですけど「ないよねぇ、規則性なんて」ってのが、いま現在の思いです。

タグ表示の ブログURL/?tag=○○○○○ のリンク外れは、なんとか直ったようでホッとはしてるんですけど (^^ゞポリポリ

To ぼっちんさん&mochiさん

こんにちは ('0')/
mochiさんも読んで頂けると嬉しい ^^:

ちょっとしばらくパソコンは使えないので頭の中でアレコレやってるところなんですが、混在コンテンツの対象になっている画像ってえhttp2で通信できてないと思うんですよ。
過去画像で同じhttpスキームでも混在にならない画像はhttp2で通信できているのではないかと。preloadを絡めるとそういう予想が立つんですがどうでしょう。
どうでしょうって、自分で今調べられないのでお二人に聞いてる(笑)
いい加減ですみません ^^;
取り急ぎのお返事ですー。

----
あと今思いました。
私が残している混在ページの画像ってたぶんアップローダーで自動生成しているサムネイル(sが付くやつ)の気がする。
あ。そんな気がするな(笑)
みなさんどうですか？
もしかしたら「s」つき画像はhttp2通信できない？「s」つき画像は混在コンテンツ？違うかなー (´・ω・｀)

----
ごめんなさい。sついてなかった。忘れてください(笑)
ただhttp2通信の方はたぶん間違ってない… はず (´・ｪ・｀)

あっ　遅かりし

確認してみました（笑）

Akiraさんの「ごめんなさい。sついてなかった。忘れてください(笑)」で正解です（笑）
スクショ撮ってみましたよ (^^ゞポリポリ
この例は、サイズ0で記事欄にアイキャッチ画像として書き込んでいたものですけど。
https://blog-imgs-113.fc2.com/o/o/p/oops0011/2018-11-30-1c-comp.png

確認してみました

こんにちは。Akiraさん。

先にプリロードされているhttp画像はhttp1.1通信。後から読み込まれているhttps画像はhttp2通信になっています。
https://blog-imgs-110.fc2.com/m/o/c/mochi1999/mixcontents-blog-entry-222-1-20181130-min.png

最近の投稿記事でプリロードされているhttps画像はhttp2通信となっています。
https://blog-imgs-110.fc2.com/m/o/c/mochi1999/blog-entry-1694-1-20181130-min.png

プリロードされたときの画像は、記事編集で書かれている画像アドレスがそのまま（過去記事はhttp→httpsへの変換が行われないまま）になっているようです。

Android携帯のGoogleChromeでもPC版と同様の過去掲載画像の混在コンテンツ現象が起こります。(混在コンテンツになる記事・ならない記事も一緒)

なおEdgeHTML:Ver17.17134、Firefox:Ver63.0.3では混在コンテンツ現象は起こっておりません。
速度チェックサイトGTmetrixでもhttp画像がプリロードされる現象は確認できているので、GoogleChromeの問題ではなく画像に対する<link rel="preload">へのブラウザサポートの差ではないかと考えています。
https://blog-imgs-110.fc2.com/m/o/c/mochi1999/gtmetrix-blog-entry-222-1-20181130-min.png

プリロードによる混在コンテンツ記事が日々ランダムで変わるなどの症状から、FC2ブログシステム側でプリロードを指示するような何らかの原因があると推測しています。

To ぼっちんさんamp;mochiさん

ご協力ありがとうございます。
混在コンテンツの画像ってhttp1とhttp2で2回読み込まれてないですかね。
自分で確認できないので頼んでばっかですみません (m´･ω･`)m
もちろん自分でも確認しますが遅くなりそうで。時間が取れない… （￣∀￣；）

---
ごめんなさい。mochiさんのコメントに答えありましたね。
やっぱ二度読み込まれてるんですね。
ありがとうございますー！

To mochiさん

あらためまして。

> FC2ブログシステム側でプリロードを指示するような何らかの原因があると推測しています〜

resource hints(prefetch, preload, prerenderなど)はブラウザが勝手に行うことはありませんので、FC2のシステムですよね。
で、警告文の末尾が
it is preloaded intentionally
になってますよね。これ「意図的にpreloadされています」という意味ですし、ユーザーがheadなどでresource hintsを使っていて何らかのミスが有った場合には
it is preloaded intentionally か it was not preloaded for nothing のどちらかになります。FC2の場合は前者。

昨日一旦混在コンテンツが解消されたじゃないですか。というか私がたまたま目にしただけで調整中だったのかもしれませんが、それ以前の状態と一時的解消を挟んで、現在の状態が以前と違うことに気が付きました。

iOSのSafariだと混在コンテンツ有り、iOSのFirefoxだと混在コンテンツ無し、なんですね。
以前はSafariでもFirefoxでも混在コンテンツでした。以前というのはほんの2日前です(笑)
その間OSアップデートもブラウザアップデートも記事編集も何も無いという環境下で、です。

これもう何らかのシステム不備と結論づけて良いですかね (´・ω・｀) ←
つか、そんなの始めからわかっちゃいるけども(笑)
htaccessのような気がするなぁ (´・ｪ・｀)
サーバー単位かとも思ったんですけど、どうもそういうわけではなさそうな。

いずれにしても過去画像ほぼ全滅じゃないかしら。一転して(笑)
昨日わざと混在ページを5件ほど作ったんです。それ今見ると全滅(笑)もちろん古い記事で残しておいたのもダメ。

ぼっちんさん&mochiさん

お二人にここで頂いたコメントですが、記事に引用しても良いでしょうか。
昨日の記事内容を否定する記事を書かないといけないのでーあぁぁぁー （￣∀￣；）
お返事頂ければ幸いです。

その通りでした（笑）

Akiraさんの
『 いずれにしても過去画像ほぼ全滅じゃないかしら。一転して(笑) 』
このお言葉通りでしたよ～ (^_^; ｱﾊﾊ…
運営さんの対処じゃ待ちきれなくて、今朝からず～っと、混在コンテンツあり記事を一番過去記事から手動で手直ししてまして、もうもう「全滅状態」でした（爆）
以前に「何かのついでに」http:// → https:// と修正してあったものは大丈夫でした（それでなければ泣いてしまう）けど、もう疲れました (^_^; ｱﾊﾊ…

とりあえずは、もう混在コンテンツは全部潰せたつもり (^^ゞポリポリ

お二人にここで頂いたコメントですが、記事に引用しても良いでしょうか。
えっえっ？ mochiさんコメントは私にもとても参考になっておりますが、私のはあまり参考にはなってないと思いますけど、、、論点視点が違いすぎって気がしますが、こんなんで良かったら端っこにでも付記なさって下さい（笑）

コメントの記事引用OKです

こんにちは。Akiraさん。

僕の拙いコメントでよろしければどうぞ使ってあげてください。(^▽^)/

過去記事で混在コンテンツと指摘されているものであってもHTMLソース自体はちゃんとhttpsに書き換わっていますので、Akiraさんの仰るようにシステム側でhttp→https変換処理が行われる前に「何かやらかしている」んでしょう。(;・∀・)

たぶんコード上のちょっとした間違いなんだろうと思うけど、こちらからは手が出せない領域なのがもどかしいです。

僕のブログの場合、1000記事を超えているので手動でhttp→httpsに書き換えていくのは物理時間的に無理なので、エクセルVBAでブラウザコントロールして自動で記事編集で書き換えていくようなものを考えてみようと思っています。（冬休みの宿題）
それよりもせっかくアイキャッチ画像にWebP形式を取り入れたのに、代替表示用のJpeg画像が先にプリロードされちゃっていることの方がショックだったりしています…　(´;ω;｀)

To mochiさん&ぼっちんさん

こんばんは (●'0'●)/

今記事を書きました。なんともスッキリしない内容だけど （￣∀￣；）
もうなんか。何故？どうして？とかも大事だろうけど「頑張って修正して！」の方が良い気がしてきた(笑)
無為に時間がすぎるというかなんというか。

------
WebPとheicなんですが、動画のH264コーデック問題みたいにならないか心配(笑)
どちらもオープンですから利用料云々というのではなく、Appleのheic、GoogleのWebPみたいな図式がちょっと不安ですよね。
Appleが「WebPは採用しません」とか言い出したらどうしよう、とか(笑)

-----
お二人ともご協力ありがとうございます。また何かあれば情報共有お願いします。
いつもありがとうございます :)

とても良くまとめられていて分かりやすかったです。(^▽^)/

こんにちは。Akiraさん。
記事拝見しました。お疲れさまでした。

僕も現時点では過去記事のhttpsアドレスへの書き換え推奨派です。
待っていて症状が解消されるという根拠がない以上は変に期待を持たせるわけにもいきませんし、仮にいずれ解消されたとしてもまた同様の問題が起きる可能性が無いとはいえませんし。（…というかどうせまたやらかすだろうと思ってます　(;・∀・)）
システムに依存しない対応ってのが一番無難で手堅い手法なんだと思います。

僕の場合は趣味ブログなんで、とりあえず全ページのSSL化に拘らず、パレートの法則的に検索流入上位20%の記事を対応しておけば80%の検索流入分はフォローできるかな？とテキトーに考えています。ﾆｬﾊﾊ(*^▽^*)

>Appleが「WebPは採用しません」とか言い出したらどうしよう、とか(笑)
そうなる可能性はあると想定しています。
各ブラウザの対応状況を考えると今のところWebP優勢のように思っていますが、個人的にはパフォーマンス的にheicの方が上だと感じています。
時代が何を選択していくのかは分かりませんので、それに合わせて都度対応していくだけと割り切ってやっている感じです。
まぁ趣味でやってるからこんな呑気な事言っていられるのだと思いますが… ﾆｬﾊﾊ(*^▽^*)

To mochiさん

mochiさん、こんばんは。

いつもご協力とご指導ありがとうございます。
記事の多い方にとってはキッツい状況になってしまいましたね （￣∀￣；）
なんとか解決して欲しいところではあります。

容量削減は拡張子が一番確実ですが各社の足並みがなぁ (´・ω・｀)
WebPやheicが当たり前、になるもの相当時間かかりますよね。きっと。