tanayasu99(たなやす)です。
先日、Bloggerの新しいインターフェースに関する記事を投稿したのですが、案の定これまで見たこと無いスコア(表示速度の点数)になっていました(笑)。
「モバイル」表示を模したテスト結果で...7点...(苦笑)。「パソコン」表示を模したテスト結果では67点。他の記事だとざっくり、モバイル40、パソコン80ぐらいは出ているようです。
参考：新しいインターフェースの挙動を少しだけ確認してみた(2020/08/06)
1つの記事が遅いぐらいなら、別に良いだろうと思っていたのですが、ホーム画面がやたら遅くなったことが我慢の限界でした。
一気に表示されるはずの記事一覧が、スクリーンショット出来るぐらい遅い。
該当記事が無い2ページ目はあんまり遅くなかったこともあり改善させようかと。
たぶん、記事を一覧表示させるため、投稿されている記事を読み込む際にHTMLコードが多い記事は足枷となるようです。
原因は、分かっているつもりなので、改善してみたいと思います。
何がどう悪いんですかね
せっかくの悪いサンプルなので、この際表示速度は前述のとおり(モバイル7点、パソコン67点)。とあるサイトでURL検査したり、HTMLコードのテストでもしてみますかね。
GoogleSearchConsoleで「URL検査」してみた
HTMLの長さ(サイズ)で怒ってくれないようですね。
体感できる程、表示が遅いことは初めての事なので、何かしら警告が出るかなぁと思ったんですが。。。HTML容量の判定が、GoogleSearchConsoleにあるか分かっていませんが。
モバイル フレンドリー テストしてみた
これもGoogle系のツール。今回のことは、モバイルに適しているかどうかという問題ではないように思えるが、表示速度という点ではやはり何らかの判定をくらうのではないだろうかと推測。モバイルはお友達だと判定してくれました(笑)。HTMLコードの長さというかサイズには関係しないのか。。。
「ページの読み込みに関する問題」の詳細も見たけど、特に関連する問題は無く、robots.txtに阻まれたとか、JavaScriptが読み込めなかったとか、いつもどおりのことだった。
Bing Webmasterで「URL検査」してみた
Microsoft系のBing Webmasterといえば最近BETA版から、ほぼ正式版になったみたいで、GoogleSearchConsoleよりも使い勝手が良い感じです。Bingの検索結果がイマイチなので、検索では使いませんけどね。(URL検査だけBETAだった...。)っで、問題のページをURL検査にかけてみると...。「HTMLのサイズが長すぎます」と表示されました。でしょうね(笑)。
適格に「ここ長い！！」というのは、教えてくれないみたいです。1行当たりの文字数は判定してくれても良いじゃないかと思ったけど...世の中には1行に詰め込む考え方もあるみたいだから無理か。
Bloggerで画像を挿入すると、通常でも画像URLが長いと思います。乱数英字だし...。画像をいっぱい配置してしまうと、それだけで怒られるかもなぁと思い、最近投稿したゆりパークの記事(73枚の画像を挿入)を「URL検査」してみました。
意外なことに長すぎないみたい。
参考：栃木県ゆりパーク(ゆり博)に行ってみた
ちなみに、Googleスプレッドシートからコピペで表を入れている記事だと...。
やっぱり「HTMLのサイズが長すぎます」という判定をくらいます。
41行もある表を組んでいるせいもあると思いますが、表1行当たりのコードが多いです。
無駄なコードが多いと思うのですが、表をコピペで挿入できる最大の利便性に甘えたいので、このままにしています。
...もしかして、体感できるかできないかの微妙な表示速度だったりするのだろうかと気になり、急遽測定してみることに。。。
モバイル51点？！思ったよりマシな結果でした。うちとしては平均的な点数です。パソコンは94点でした。という訳で、表に関してはGoogleスプレッドシートからのコピペで良さそうです。...未来永劫、問題無しという訳ではないだろうから、何かしら軽量化はしたいですが、HTMLコード見たくない。
参考：国指定天然記念物となっている桜の樹齢をざっくり一覧化してみた。
ちなみに、長い画像URLを含んだ記事の内容をHTMLとして保存してみたら、1749KBというサイズでした。そりゃダメだわな。。。
表が大きい代表でピックアップした記事は、表のコードが長いとはいえ、152KB程度でした。しかし、Bing Webmasterには、125KBでどうたらこうたらって書いてあったから、たぶんそれで指摘入ってるんだろうな(笑)。インデックス登録はされているようだし、都合が悪いことは起きないと思うが、ちょっと心配か。
ここで必要になるHTMLコードの保存方法を備忘録しておく。※Chrome前提
①該当ページを開く
②ブラウザ上の「デベロッパーツール」(F12キー)を表示させる
③Elements内の「<html>」タグで右クリック→表示されたメニューから「Copy」→「Copy outerHTML」の順にクリックする。
読み込み済みの結果ではあるが、おおむね全部のコードがコピーできる。
HTMLコードについて「Markup Validation Service」、「Dirty Markup」でHTMLコードの確認をしてみた。結果、特に面白いことは無かったです。
HTMLのルールとしては、画像URLが長かろうが関係ないみたい。オプション設定は見ていないので、何か判定させるものが、あったのかなぁ。
改善策
画像編集ソフトからコピペした(長い画像URL)画像を削除して、通常の「画像を挿入」を行うだけです。ところが、作成ビューから、画像を選択、「削除」をクリックしたら、画像枠がポインタの動きにくっ付いてきた(笑)。消せないし、配置も出来ない、戻すボタンも機能しない状態になった。
久々のバグにみたいな挙動にキレそうになる(笑)。結局、更新ボタンで解決した。
該当する画像を削除し、通常の方法で画像を挿入した。
編集画面に収まりきらなかった画像URLは、いつもどおりの長さになりました。画像に関するHTMLコードで考えても赤枠の範囲だけ。
改善後の結果
さすがに、良くはなりましたね。モバイル表示が48点、パソコン表示が92点です。
Bing WebmasterのURL検査でも良好な結果が得られました。「HTMLのサイズが長すぎます」の殲滅に成功いたしました。
before, afterでまとめてみたいと思います。(また、いつもの方法で表を入れるという愚策。こんな涼しそうな表なのに、HTMLビューで見ると吐き気がする(笑)。)
ホーム画面を表示させてみましたが、ほぼ瞬間的に表示するようになりました。見た目はスキがありそうに感じましたが、以前のようにスクリーンショットを取得するのは無理かな。元通りです。
HTMLコードのサイズも、だいぶスッキリしました。...それでも105KBもあるのかと思う事もできる。ゆりパークの記事も危ないのかと思い、調べてみると...案の定118KBもありました。画像を多用するのも、気を付けないとダメだなぁ。
後記
自身が体感した遅さによって、改善させてみたという流れでしたが、どうせならGoogleSearchConsoleに怒られて改善した方が筋は通っているような気がする。今回は怒られることなく、インデックス登録出来ちゃっていたみたいだし。BingWebmasterの方で気付かなかったなぁ...登録の依頼を飛ばして、あとは放置するからなぁ。今回、気付いた記事のサイズで、気を付けないといけないことを以下にまとめる。
・通常の画像挿入(Blogger固有URL？)において、画像URLが長いから、画像を張り付け過ぎないこと。目安として、1記事あたり多くても40枚以下にしておく。
・Googleスプレッドシートからのコピペで、表のコードが長くなりがちである。
・1記事のサイズ過大で、一覧表示が遅延することがある
おわり。
0 件のコメント:
コメントを投稿