元祖「はてなダイアリー」のデザインそっくりな「はてなブログ」のデザインに移行！ ～ドロップダウンする画面上部固定グローバル・メニュー追加！ ＆ＳＥＯ・表示速度対策！

拙ブログ・トップページ（最新５記事）
拙ブログ・全記事見出し一覧

[覚え書き]　〜全記事見出し一覧

元祖「はてなダイアリー」のデザインそっくりな「はてなブログ」のデザインに移行！　～ドロップダウンする画面上部固定グローバル・メニュー追加！　＆ＳＥＯ・表示速度対策！

１．旧「はてなダイアリー」のシンプルな初期デザインにそっくりな新「はてなブログ」の「デザイン・テーマ」を発見

　ケッ！　オシャレ・サブカル系の小洒落た「はてなブログ」デザインなんてヘドが出らぁ！　取り澄ましやがって！！
　汗クサさや泥クサさを過剰なまでに忌避して、デオドラント（無臭・無菌）を目指すあたり、世の中の半分だけしか見ていないような、半分だけを見て歯の浮くようなキレイごとをのたまっているような気配がして、オレさまちゃんの敵だ！　くらいに思ってしまっていたので、旧「はてなダイアリー」から新「はてなブログ」への移行にはなかなか踏み切れず。

――いやまぁ、大衆・大勢向けをねらうのであれば、オシャレ・サブカル路線を目指すのが正しいのは重々承知してるけど（笑）――

　しかし、ナンで「サイドバー」が右側にあって、しかも「サイドバー」のヨコ幅がやたらに広いんだヨ！？
　その分、「本文」の方がやたらとヨコ幅が狭くなってるヨ。「ブラウザ画面」のヨコいっぱいに、ブログ本文を表示させてくれヨ！！

　文章・本文を読ませたいのであって、ブログのデザインとかはドーでもイイよ！　特にブログのヘッダー（タイトル）とかで、「ブラウザ画面」の上部の半分の面積を占めるようなデザインなんて、サイテー最悪！！

　「ブログ記事一覧」に、記事中の「画像」をアイコン表示させる機能なんて不要だヨ。「記事タイトル」だけを表示してくれればイイよ！

　コレだったら、当方が使用しつづけている、元祖「はてなダイアリー」の元祖も元祖な基礎の基礎みたいなシンプルなデザインをギリギリまで使用しつづけたい！　と思いつづけて半年ほど。

　ついに、２０１９年春（２月２８日（木））での旧「はてなダイアリー」の「株式会社はてな」側での保守運用の終了告知に伴ない――日記更新は１月２９日（火）から不可――、観念して２月２日（土）は「はてな」側にて奨励されている新「はてなブログ」への自力での移行に伴なう前調査にいそしんでみた次第。

　それと並行して、なにかシンプルぷるぷるでも良いデザインはないかなぁと、「はてなブログ」の各種デザインが格納されている「はてなブログ・テーマストア」（https://blog.hatena.ne.jp/-/store/theme/）のあまたの「公式デザイン」や「ユーザー作成デザイン」をすべて隈なく渉猟すること半日ほど。

　ついに！　ついに！　ついに！　おそらくは奇特な御仁がネタ＆洒落で作ったのであろう（？）、元祖「はてなダイアリー」のデザインをそっくりに模した「はてなブログ」用のデザインテーマ「Hatena for はてなブログ」を発見！
blog.hatena.ne.jp

●「サイドバー」が左側にある！――左から右へ読んでいくヨコ書きの常で、「サイドバー」に眼が行きやすくなることで、ブログ内を巡回してもらえる可能性も高くなる！？――
●「サイドバー」のヨコ幅がムダに広くない！
●「本文」のヨコ幅もムダに狭くならずに、「ブラウザ画面」の拡大に応じて、ヨコいっぱいに広がる！
●ブログのヘッダー（タイトル）が、最小面積になってるヨ！

　コ、コ、コ、コレは、オレのために作られたのか！？（そんなワケはない）

　元祖「はてなダイアリー」のデザインに内心ひそかに愛着を持っていたけど、「はてなブログ」へと移行するにあたって、「はてな」側で推薦されていた、自称シンプル・自称文章中心向けデザインを心ならずもセレクトしてしまった御仁も、それなりにいたのではなかろうか？

　てなワケで、旧「はてなダイアリー」を新「はてなブログ」に移行するに際して、選択した「はてなブログ」のデザインが、不肖のキモオタのワタクシめごときの拙ブログのデザイン！――どうぞ「顔を真っ赤にして必死なデザイン！」と指さして揶揄してください（汗）――。

　「サイドバー」も旧「はてなダイアリー」時代は、「デザイン」設定画面の「ページのフッタ」項目にHTML言語をシコシコと加筆して、「サイドバー」に自ブログ記事への「リンク」を増やしていったけど、この「サイドバー」への「リンク」追加もツール化されていて、「記事名タイトル」＆その「URL」を記述するだけで済んで、HTMLを書かなくてよくなって、旧「はてなダイアリー」時代の手書きで追加していた「サイドバー」の完全復元もラクラク！
――サイドバー部分の「１行空白」や「２行空白」空けに、固定の文言に色付けした箇所にのみ、やはり「サイドバー」追加ツールを用いてのHTML言語にて記述しています――

　「はてなブログ」の人気ベスト３のデザインを採用すべし！　界隈におけるブログ・デザイン改造記事の類いも豊富であるから！　と唱えているブログもあるけれど……。当方はアレらの人気ベスト３のデザインなんて絶対にイヤですヨ（笑）。

　てなワケで、テキスト中心で見せたい、スカしたオシャレ・デザインにはまるで関心がない奇人変人の同好のみなさまには、この元祖「はてなダイアリー」のデザインそっくりの「はてなブログ」のデザイン「Hatena for はてなブログ」を強くお勧めしたいと思います！　……まぁ、ダウンロード数を見ると、つくづく人気がないデザインであることもよぉくわかりますけれど。

――ただ、「検索窓」がハミ出てて、右すぐヨコの「本文」側に少しだけ跨ってしまっているのが、おマヌケでタマにキズだけど（汗）。コレはドーやったら直せるんですかネェ。教えて！　エラいヒト！（笑）――

――２０１９年３月１３日（水）加筆：ナンと！　「はてなブログ」の当該デザイン「Hatena for はてなブログ」が２０１３年１０月５日の誕生、および同年１０月１２日のフォント変更以来、６年ぶりに神さま・造物主さまご自身がデザインストアに降臨せられて、「検索窓」がハミ出ていたのを２０１９年３月１０日（日）に直されました！　よって、「検索窓」のハミ出る問題も解消してしまったのでありやした！　ありがとうございます（平身低頭）――

　ただ、問題はナイどころか、むしろウェルカムの大カンゲイではあるけれども、ＰＣでもスマホでもタブレットでも同じデザイン画面で表示されるという「レスポンシブ対応」のデザインでもないし、拙ブログ自体の詳細設定を「レスポンシブ対応」にもしていないのに、自身所有のタブレットで拙ブログを表示させると、旧「はてなダイアリー」時代は「記事一覧」が表示されていたのに、新「はてなブログ」ではＰＣと同様の「トップページ」が表示されましたヨ！――むろん、ヨコ幅の文字数はタブレット画面に合わせて減っていますけど――

――２０１９年２月９日（土）加筆：上記でいろいろと書いていますけど、誤解・錯覚がありました。「はてなブログ」画面は「タブレット」では「パソコン」準拠で画面表示がされるのがデフォルト・初期設定であった模様（汗）。当方、実は「スマホ」を所有しておらず（２０１９年現在でのお話）、６～７年前（２０１３年）から「ガラケー」＆格安ＳＩＭの７インチ「タブレット」使いであったために、あらためて家族所有のスマホで拙ブログを閲覧してみたところ、「はてなブログ」で一律に用意されている「スマホ専用」画面（＝７件程度の最新記事見出し一覧）が表示されてしまうことが判明してガックシ……
（後日付記：　ＰＣ上でも各種ブラウザ、たとえば「Ｃｈｒｏｍｅ」のブラウザにて右クリックの「検証」⇒白い二重四角型の「スマホ」型のアイコン選択などで、「スマホ」での画面表示イメージの表示が可能ですので、スマホを所有していない方々はお試しあれ！）
（さらなる２０２５年５月の後日付記：　当該の「Hatena for はてなブログ」のデザインでスマホ用の画面を設定する場合には、「はてなブログ」で一律に用意されている「スマホ専用」画面（＝７件程度の最新記事見出し一覧）を表示させた方がイイです！　理由も後述！）。
　してみると、「タブレット」の画面サイズ端末からのアクセスの場合には「パソコン」専用の画面表示と同様の扱いで、「スマホ」の画面サイズ端末からのアクセスの場合には「スマホ」専用の画面表示の扱いとして、「はてな」側にて識別をしているといった判定ができます。そこで取った方策については後述いたします――――

追伸
　旧「はてなダイアリー」から新「はてなブログ」へのインポートに長時間～数日間を要するという、昨夏ごろの各種記事を散見しました。「はてな」側でのサーバーの増強のせいか、皆さまの引っ越しのピークがとうに過ぎていたせいか、当方は世間のブログよりも１記事あたりがはるかに長文とおぼしき約７５０の記事のインポート作業でしたけど、２０１９年２月３日（日）午前０時台に作業したところ、トータル４５分ほどで完了いたしました――家庭内Ｗｉ－Ｆｉ接続です――。

　以上、一例としてご参考までに～。

――２０１９年４月１４日（土）追記：遅まきながら、一昨日に気付いたのですけど、公式「週刊はてなブログ」２０１９年４月４日分のブログ記事にて、「２０１９年はてなブログデザインテーマコンテスト」の受賞結果が発表されています。（https://blog.hatenablog.com/entry/2019themecontests_result_）
　それで、ビックリ。拙ブログの改造にいそしんでいた２０１９年の２月中下旬に、当該「元祖はてなダイアリー」風デザインテーマ「Hatena for はてなブログ」と同じコンセプトのデザインテーマ「classic diary（日記向け）」がちょうどリリースされています。しかも、１月１６日～３月１４日募集の「２０１９年はてなブログデザインテーマコンテスト」の「銅賞」を受賞していたのでありやした！　（https://blog.hatena.ne.jp/-/store/theme/17680117126981573769）
　ウ～ム、このすでに類例のあるデザインテーマが受賞してしまってもよかったのであろうか？　……まぁ、別にヨシとするか（笑）。

　この「classic diary（日記向け）」は「パソコン」での表示ですと、「記事本文」＆「サイドバー」の活字がやや大きく行間も少々開いており、それに応じてか「サイドバー」のヨコ幅もやや広めなあたりが、個人的には少々キズ・欠点であり。
　「タブレット」での表示だと、「サイドバー」がなくなって、いわゆる「サイドバー」部分が「本文記事」の一番下に表示される、いわゆる「１カラム」表示となる。コレはまぁ、世間一般的にはフツーの表示なのですけど、個人的には「タブレット」や「スマホ」でも「サイドバー」を表示させて、過去記事にも導線を引いておきたかったので、コレがカナリちょっと（汗）。
――２０２５年５月の後日付記：　当該の「Hatena for はてなブログ」のデザインでスマホ用の画面を設定する場合には、「はてなブログ」で一律に用意されている「スマホ専用」画面（＝７件程度の最新記事見出し一覧）を表示させた方がイイです！　理由も後述！――

　もちろん、「タブレット」でも「ＰＣ版サイト」での表示に変更することは可能ですけど――「タブレット」でわざわざ「ＰＣ版サイト」での表示に変更するような奇特な御仁も滅多にいないでしょうけれど――、それで「サイドバー」を表示させると、「サイドバー」のヨコ幅がやはりやや広くてその逆に「本文」の活字はやや小さい。

　大見出し（記事タイトル）・中見出し・小見出し・小小見出し……などを表示させる「はてな記法」もビミョーに旧来のモノとはズレているようで……。
　先頭に「**」のように「*」を２文字付けて（「ｈ４」タグの見出しの意味）、その直後に「見出し」の文言を続けることで、「中見出し」――青いアンダーライン付きの見出し――とする旧来の「はてな記法」だと、先頭に青い四角が付くだけの見出しとなってしまいまして……。
　先頭に３文字の「***」で「小見出し」（「ｈ５」タグの見出しの意味）――単なる太字の見出し――とする旧来の「はてな記法」だと、先頭に青い右向き三角が付いた小見出しとなって、いろいろとズレた「見出し」表示となってしまって……（加えて、この３文字の「***」＝「ｈ５」タグ表示で、２行に渡る長い見出しになってしまうと、１行目と２行目が重なって表示されてしまうバグがあるようですけど、ブログデザイン作者さまに指摘してあげるべきか否かは悩む……・汗）。
　とにかく、ウチのブログにて多用している「はてな記法」の「**」で、「青いアンダーライン付きの中見出し」を一律に表示させておきたいよ～（笑）。

　あと、「アーカイブページ」（全記事見出し一覧ページ）が、全３０記事だか全５０記事を青い細いラインで一括して囲んだ一覧表型式の旧「はてなダイアリー」風のスタイルではなく、１記事１記事が青いラインで囲まれたスタイルであるあたりもまた、一瞥しての閲覧性でのヒキには少々欠けるようにも思えてしまって……。

　以上の事項は、改造すれば解消できる程度のことなのでしょうけれども（見出し表示の変更は右記のサイトが参考になりそうです：http://www.future-nova.com/entry/sumaho-css）、当方のように基礎知識がなくって、類例から憶測にて改造していて、しかもある程度のブログ改造が済んだら、ブログ記事の方の執筆に励みたい人間にとっては、もうメンドくさくなってきた（笑）。
　しかし、前述したブログデザイン提供のＵＲＬ（https://blog.hatena.ne.jp/-/store/theme/17680117126981573769）には、および左記ＵＲＬからもリンクされている当該デザイン作者さまが製作された他のデザインテーマ（https://blog.hatena.ne.jp/-/store/theme/-/author/blogcustomize）のページ群にも、各種のデザインカスタマイズの方法が記述されており、ブログを改造してみたい方々には実に参考にはなりそうです。

　てなワケで、拙ブログ管理人は当該の「Hatena for はてなブログ」のデザインを引き続き使用する予定ではあります――

――２０２５年５月３１日の後日付記：　……ス、スイマセン！　２０２５年５月３１日（土）から、今さらながらに「スマホ」側での画面表示の「字」の大きさなどの便宜にて、「Hatena for はてなブログ」から、同様に旧「はてなダイアリー」のデザインにそっくりの、上記でも言及しました「classic diary（日記向け）」のデザインに変更しております！　なおかつ、「スマホ」側ではいわゆるレスポンシブデザインこと、「パソコン」とも同じ画面表示で、つまりは「スマホ」で表示させても、画面の上部に「ドロップダウンする画面上部固定グローバル・メニューを追加」させたかたちに変更させました！　……サイドバーについては、記事の「サイド」ではなく、記事の「下方」に表示される形式にはなります……。しかし、以降の「グローバル・メニュー」追加の設定などは、「classic diary（日記向け）」のデザインでも共通して使用できますので！　「「***」＝「ｈ５」タグ表示で、２行に渡る長い見出しになってしまうと、１行目と２行目が重なって表示されてしまうバグがある」件についても、２０２４年にデザイン主によって、解決されていました！――
blog.hatena.ne.jp

２．「アーカイブ・ページ」（全記事見出し一覧ページ）の改造

（２０１９年２月８日（金）加筆）

「はてなダイアリー」風に、「サムネイル画像」＆「記事本文・冒頭」を非表示、「記事タイトル」のみで表示

　世間一般的にはともかく、テキスト中心種族にとっては、「はてなブログ」の「アーカイブ・ページ」に「サムネイル画像」＆「記事本文・冒頭」が表示されることも、「ブログ」の全記事の目次的な一覧の瞥見性にいささか欠けて、鬱陶しいのではなかろうか？（あくまでも私見です）

　で、ググってみたら、「はてなブログ」の「アーカイブ・ページ」も、旧「はてなダイアリー」のそれのように「サムネイル画像」＆「記事本文・冒頭」を非表示にする手法がありました！
q.hatena.ne.jp

　コレをまるパクリで、「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「ＰＣ（スパナのマーク・カスタマイズ）」⇒「デザインＣＳＳ」（スタイル・シート）欄に、既存の入力値――初期値として「はてなブログ」の採用デザイン・テーマの番号が記述されたＵＲＬのＣＳＳが記述されている――は残したままで、その後ろに以下のＣＳＳを加筆して、上方の「変更を保存する」を押下！

/*==============================================
「はてなブログ」の「記事一覧ページ」（archiveページ）の「サムネイル画像」と「記事本文」を非表示にし、「はてなダイアリー」のように「記事名」のみで一覧表示化
================================================*/
.archive-entry .entry-description, .entry-thumb {
    display: none;
}
.page-archive .archive-entries section {
    margin-bottom: 0px;
}

――ここのみ、２０１９年４月６日（土）加筆：当初、上記のＣＳＳ文は、

・当初：「.archive-entry .entry-description, .entry-thumb, .social-buttons {」となっておりました。
・改訂：「.archive-entry .entry-description, .entry-thumb {」に変えております。（末尾の「, .social-buttons」の記述を削除いたしました）

理由：上記の「, .social-buttons」（ソーシャル・ボタン）などの記述は、「記事一覧ページ」（archiveページ）に限定した設定ではなく、「本文記事ページ」にも共通で適用される設定であるためです。当初「, .social-buttons」の記述があったばかりに、これが次の行の「display: none;」命令にて各種の「ソーシャル・ボタン」が非表示扱いとなってしまい、「本文記事ページ」中の上下にも表示されるべき「はてなブックマーク」や「Ｔｗｉｔｔｅｒ」に「ＬＩＮＥ」などのマークの「ソーシャル・ボタン」群が一律に非表示になってしまっていたのでありやした（汗）――

――２０２５年５月１７日（土）加筆：上記の「記事一覧ページ」（archiveページ）の「サムネイル画像」と「記事本文」を非表示にし、「はてなダイアリー」のように「記事名」のみで一覧表示化についての「ＣＳＳ」文については、実験用の「Hatena for はてなブログ」デザイン（＝２０２５年５月３１日以前に使用していたデザイン・汗）のサブ・ブログ側ではそのとおりにはしていますけど、本体のブログ側では削除して、「サムネイル画像」と「記事本文の要約」なども表示させるようにしました。それによって、特に重たくなるような事象も発生していません――

３．「カテゴリー」ごとの「アーカイブ・ページ」（全記事見出し一覧ページ）に、「～に関する記事一覧」の文言を追加

（２０１９年２月８日（金）加筆）

　前述の「２．」にて、「アーカイブ・ページ」（全記事見出し一覧ページ）から「サムネイル画像」や「記事本文・冒頭」を除去しても、「はてなブログ」の「カテゴリー」ごとの「アーカイブ・ページ」（記事見出し一覧ページ）は、旧「はてなダイアリー」時代のそれと比すると殺風景なデザインで、そもそも「記事見出し一覧ページ」であること自体が分かりにくい！
　コレもネットサーフィンをしていたら、先達による解決策を発見いたしました。これにならって、大見出しの「カテゴリー」名の直後に「～に関する記事一覧」なる文言を追加！
focus3.hatenablog.com

　こちらのブログさまを参考に、最後の部分のみをパクらせていただき、「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「ＰＣ（スパナのマーク
・カスタマイズ）」⇒「デザインＣＳＳ」欄に、やはり既存の記述は残したままで、その後ろに以下のＣＳＳを加筆して、上方の「変更を保存する」を押下！

/*==============================================
「カテゴリー」ごとの「記事一覧ページ」の大見出しである「カテゴリー」名の末尾に、「に関する記事一覧」の文言を追加
================================================*/
.archive-header-category .archive-heading::after  {
    position: relative;/*相対位置（不要？）*/
    content: " に関する記事一覧";/*追加文言*/
    font-size: 1.2rem;/*追加文言をカテゴリ名よりも小さい字で表示*/
}

――２０２５年５月１７日（土）加筆：上記の「ＣＳＳ」文についても、実験用の「Hatena for はてなブログ」デザインのサブ・ブログ側ではそのとおりにしていますけど、本体のブログ側ではまるまる削除しています～――

４．「グローバル・メニュー」の追加

（２０１９年２月８日（金）加筆）

「ブログ・タイトル」直下に、「グローバル・メニュー」（「カテゴリー」ごとの「記事一覧」などの「リンク」集の「メニュー・バー」）を追加

　「グローバル・ナビゲーション」or「ヘッダー・メニュー」or「グローバル・ナビゲーション・メニュー」or「グローバル・メニュー」or「グローバル・ヘッダー」or「グローバル・ヘッダー・メニュー」。多数の呼び名があるようです。
　コレについては、多数のサイトを参考にさせていただき、照合の果てに、拙ブログに不要な命令文は削りに削って、以下の最小限のＨＴＭＬとＣＳＳを作成（？）してみました。ブラウザの幅の拡縮に応じて、ヨコ幅や間隔も伸縮するかたちになっています。

（しかし、これを拡張させて、「カテゴリー」下の「サブ・カテゴリ―」表示、いわゆる「ドロップダウン・メニュー」が追加表示されたり、「トグル・メニュー」に変形したり、といったことまではいたしません・汗）

　主に、以下のブログさまを参考にさせていただき、流用・改変させていただいております。
www.clrmemory.com

４－１．ＨＴＭＬ

　（「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「ＰＣ（スパナのマーク・カスタマイズ）」⇒「ヘッダ」⇒「タイトル下」欄に、以下のＨＴＭＬを加筆（⇒「変更を保存する」はこのタイミングで押下してもよいが、後続の「４－２．ＣＳＳ」側にて一括して押下するのが無難））

<!-- 通常の「グローバル・ナビゲーション・メニュー」 -->
<div class="nav">
  <ul>
    <li><a href="https://katoku99.hatenablog.com/entry/20190601/p1">ゴジラ評論６０年史</a></li>
    <li><a href="https://katoku99.hatenablog.com/entry/20200723/p1">ウルトラマンＺ序盤総括</a></li>
    <li><a href="https://katoku99.hatenablog.com/entry/20200921/p1">仮面ライダー０１総括</a></li>
    <li><a href="https://katoku99.hatenablog.com/entry/20200712/p1">キラメイジャー序盤総括</a></li>
    <li><a href="https://katoku99.hatenablog.com/entry/20210213/p1">新型コロナ禍・2020年の日本</a></li>
    <li><a href="https://katoku99.hatenablog.com/entry/20181125/p1">ＳＳＳＳ.ＧＲＩＤＭＡＮ</a></li>
    <li><a href="https://katoku99.hatenablog.com/entry/20190707/p1">ガンダムTHE ORIGIN</a></li>
    <li><a href="https://katoku99.hatenablog.com/entry/20181208/p1">宇宙戦艦ヤマト２２０２</a></li>
  </ul>
</div>

　「ＵＲＬ」と「カテゴリー名」は、各自のブログのそれに応じて読み替えてください。少々長い「カテゴリー名」は、ブラウザのヨコ幅を縮めると、両隣の「カテゴリー名」と接近しすぎてしまって見苦しいので、「グローバル・メニュー」中の表示上の「カテゴリー」名のみ半角カナに変えています。

４－２．ＣＳＳ

　（「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「ＰＣ（スパナのマーク・カスタマイズ）」⇒「デザインＣＳＳ」欄に、既存のものは残したまま、以下のＣＳＳを加筆⇒「変更を保存する」）
　（ＣＳＳは記述する位置が後半以降だと効力を発揮しない説もあったので、念のために冒頭の「はてなブログ」採用デザインテーマのＣＳＳと、先に入力した「アーカイブ・ページ」用のＣＳＳの中間に、以下のＣＳＳを加筆）

/*==============================================
「ブログのタイトル」下に、「グローバル・ナビゲーション・メニュー」追加
================================================*/
.nav>ul {
        padding: 0;/*枠線内余白*/
        margin: 0;/*枠線外余白*/
        width: 100%;
     /* margin-bottom: 30px;  枠線外・下余白（拙ブログではコメント囲いで無効化）*/
        display: block;/*ブロック要素にする*/
        overflow: hidden;/*内容が収まらない場合、非表示*/
}

.nav>ul>li {
        box-sizing: border-box;/*paddingやborder-widthの幅に関係なくwidthに指定した値優先。幅にborderとpaddingを含む？*/
        width: calc(100% / 11);/*メニュー幅÷メニューカテゴリ数（※各ブログごとでの改変対象数値）*/
        height: 20px;/*メニュー・ブロックの高さ（※各ブログごとでの改変対象数値）*/
        line-height: 20px;/*メニュー・１行の高さ（※各ブログごとでの改変対象数値）*/
     /* background: linear-gradient(#1a1a1a, #676767, #1a1a1a);  グローバルメニュー背景色（拙ブログではコメント囲いで無効化）*/
     /* border-left: 1px solid white;  要素の左辺に白いボーダー（枠線）付与（拙ブログではコメント囲いで無効化）*/
     /* color: white;  グローバルメニュー文字色（拙ブログではコメント囲いで無効化）*/
        font-size: 70%;/*カテゴリ名の文字の大きさを縮小（※各ブログごとでの改変対象数値）*/
        float: left;/*初期表示はタテ並びのカテゴリ⇒左寄せでヨコ並び化*/
        list-style-type: none;/*カテゴリ名の先頭に中点や番号なし*/
        text-align: center;/*左寄せや右寄せではなく均等配置*/
        position: relative;/*相対位置*/
     /* transition: box-shadow .3s ease-in-out;  マウスオーバー時の動き（影を付与）（拙ブログではコメント囲いで無効化）*/
}

/*first-child：要素内で最初に現れる子要素を対象にスタイルを適用*/
.nav>ul>li:first-child {
        border-left: 0;/*要素の左辺にボーダー（枠線）付与。０指定だから付与なしの意味？　不明なので残してます（汗）*/
}

/*  .nav>ul>li:hover {  （拙ブログではコメント囲いで無効化）*/
     /*   box-shadow: 0 0 50px 25px #1a1a1a inset;  マウスオーバー時に最終的にメニューのカテゴリ名のエリアの縁に影を付与（？）（拙ブログではコメント囲いで無効化）*/
/*  }  （拙ブログではコメント囲いで無効化）*/

.nav>ul>li>a {
        color: #0000FF;/*グローバル・メニューのカテゴリ名の文字色＝青*/
        position: absolute;/*絶対位置*/
        top: 0;
        right: 0;
        bottom: 0;
        left: 0;
}

　……スイマセン。知識がない人間が類推や憶測で整理して、削りに削って作成していったモノです。少なくとも拙ブログでは、コレで問題がありませんでした。
　思わぬ副産物としては、「アーカイブ・ページ」（記事見出し一覧ページ）や、「カテゴリー」ごとの「アーカイブ・ページ」にも、この「グローバル・ナビゲーション・メニュー」……というか「カテゴリー名」のリンクが表示されるために、結果論としてますます「アーカイブ・ページ」が旧「はてなダイアリー」のそれに近づきました（笑）。

　拙ブログには不要であった「グローバル・ナビゲーション・メニュー」部分の背景色を指定する「background:」命令文や、「グローバル・ナビゲーション・メニュー」部分の左辺に白いボーダー（枠線）を付与する「border-left: 1px solid white;」命令文、カーソルを「グローバル・ナビゲーション・メニュー」部分に寄せるとアニメ的なプチ動画効果を発揮する「transition: box-shadow .3s ease-in-out;」命令文などは、ググってその意味合いを調査した上で不要と判断して削っています。

　コレらの命令文ほかが必要な方々は、ヨソさまのサイトを照合して、命令文の意味もググって理解した上で、追加していってくださいまし～（汗）。

５．「Hatena for はてなブログ」（＝２０２５年５月３１日以前に使用していたデザイン・汗）は「レスポンシブ対応」公称ではないけれども、「レスポンシブ対応」設定にしてみたら、スマホでもＰＣ用のブログ画面が問題なく表示　（→：２０２２年６月、スマホでもＰＣと同じブログ画面を表示させると「字」が小さくて、「Google Search Console」で警告が出るので、「レスポンシブ対応」は「非設定」に変更・汗）　（→：２０２５年５月３１日に、「Hatena for はてなブログ」から、「レスポンシブ対応」もされている「classic diary（日記向け）」のブログ・デザインへと変更したのに伴ない、「レスポンシブ対応」も「設定」するへと再変更！）

（２０１９年２月９日（土）加筆）

　スマホからのアクセスだと、ＰＣでの「はてなブログ」の画面表示とは異なり、スマホ専用の最新７件の記事一覧（「サムネイル画像」＋「記事本文・冒頭）が表示されることは、みなさまご承知の通りだと思います。
　庶民・大衆・大勢向けにはこの方がきっとイイから（？）、このような画面が採用されているのでしょうけれども、当方は先のアーカイブ・ページ対策同様に、一瞥しての謁見性には欠けるこのスマホ専用トップページである最新７記事だけの一覧画面を好ましくは思っていません（笑）。ツカミにも弱いと思っています。

――　↑：　２０２５年５月付記：いや、今の時代の、もとい２０１０年代以降のコア層・マニア層にとっても、少なくともブログのトップページ（ホームページ）については、「はてなブログ」の「スマホ専用の最新７件の記事一覧」の方が便利であったろう……と見解を変えております（汗）――

　そこで、今どきの通信速度や端末性能であれば、スマホでもＰＣと同様の画面を表示させても、そんなに遅くはならないであろう！　そもそも短文しか読めないような人種は、お客さんとしてカウントしてないヨ！　ということで（汗）、試しに拙ブログの画面表示設定にも「レスポンシブ対応」設定を実施してみて、（タブレット使いの自身は所有していないので家族の）スマホを使用して、拙ブログにアクセスして表示内容が崩れたりしていないかの確認をしてみました。

　……特に何も「サイドバー」も「記事本文」のレイアウトも崩れてないじゃん！　「グローバル・メニュー」も崩れてないじゃん！　「スマホ」画面の幅に応じて「記事本文」の１行あたりの字数は減っているけど、キレイに「パソコン」同様に表示されてるじゃん！　表示もそんなに遅くないじゃん！
　まぁ、「スマホ」１台のみの結果をもって、「スマホ」全体には敷衍（ふえん）はできず、統計的にはイミがないやもしれませんけど、拙ブログのような単純・シンプルなデザインであれば、多分どの「スマホ」でもほぼ大丈夫であろう！　と勝手に決めつけて、当該デザイン・テーマは「レスポンシブ対応」設定でも大丈夫！　と太鼓判を押すことにいたしやす！（……だ、大丈夫なのかなぁ？・汗）

　「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「スマホ（スマホのマーク）」⇒「詳細設定」⇒「レスポンシブデザイン」欄に「レ」点を入力⇒「変更を保存する」

　ただし、「スマホ」だと、画面上部に「はてな」が挿入してくる広告が表示されることで、記事１件目の記事名タイトルが隠れてしまうという大きな問題もありますけど……。まぁ、イイや。（←イイのか？・汗）

――２０２５年４月２９日（火）加筆：「Hatena for はてなブログ」（＝２０２５年５月３１日以前に使用していたデザイン・汗）のデザインにおいては、「レスポンシブ対応」設定にはしない方がイイです！　各所の「はてなブログ」のデザイン指南ブログにて、「レスポンシブ対応」にして、「パソコン」と「スマホ」で共通の画面にしておいた方がイイ！　といったものがございまして、それはそれで一般的にはその方がイイのやもしれません。ですから、もちろん恨みなぞもございません（笑）。しかし、当該のデザインにて「レスポンシブ対応」にて設定してしまった場合には、やはり「スマホ」での画面ですと、文字がやや小さくて読む気になれないほどでした～（汗）。
　加えて、「Google Search Console」「グーグル・アナリティクス」などで分析してみると、スマホの画面側においては、「４．」にて追加した「グローバル・メニュー」と、後述する「６．」にて追加した「固定グローバル・メニュー」かつ「ドロップダウン・メニュー」についても、その文字についてはあまりにも小さい！　間隔も狭い！　よって、モバイル・フレンドリー（スマホに親切）ではない！　といった判定がされてしまっておりました～。つまりは、２０１８年あたりからの、被リンク数のみならず、スマホ（モバイル）での読みやすさも上質なネット上のページであるとする新たな判定基準によっても、グーグル検索では上位にはランキングされにくくなってしまう……といったことにもなっておりました～（汗）。よって、当該のブログ・デザインにおいては、「レスポンシブル対応」には設定しない方がイイことにもなります！
（「レスポンシブ対応」設定は、グーグルからのクロール情報取得には便利である！　といったものではあるようですけど、しかし「Hatena for はてなブログ」のデザインについては、世間一般的な「はてなブログ」を上回る「軽さ」「速さ」といったメリットもあるようには思います。各種「はてなブログ」サイトさまの「Page Speed Insights」による各々さまの自ブログでの計測結果記事と比較するかぎりでは……。
　以下の記事は、２０１３年のものですので古いのですけど、「レスポンシブ・ウェブ・デザイン」が、「ＳＥＯ」（「検索（サーチ）・エンジン・最適化」）においても、常に最良の選択でもないようにも見受けられます）――
www.suzukikenichi.com
www.gadgerepo.com

５－１．ＣＳＳ（未設置）

　当該デザイン・テーマの拙ブログでは、家族のスマホの「Ｇｏｏｇｌｅ」ブラウザ（Ｇｏｏｇｌｅの「Ｃｈｒｏｍｅ」ブラウザにあらず）で参照するかぎり、特に字が異常に小さく表示されることなく（？）表示されました。

――字が異常に小さく表示される場合には、「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「ＰＣ（スパナのマーク・カスタマイズ）」⇒「デザインＣＳＳ」欄に、既存のものは残したままで、以下のコメント行のかたちをしたＣＳＳを加筆⇒「変更を保存する」を実施すると、「はてな」社側にてレスポンシブ対応してくれる仕様になっております。しかし、拙ブログでは以下のコメント行が記述されていなくても、特に支障を感じていなかったために、以下のＣＳＳは加筆しませんでした（汗）。しばらく様子見といたします――

/*==============================================
「はてなブログ」用「レスポンシブ対応」宣言
================================================*/
/* Responsive: yes */

――２０１９年３月２８日（木）加筆：上記の『「はてなブログ」用「レスポンシブ対応」宣言』である「/* Responsive: yes */」を「デザインＣＳＳ」欄に加筆して、スマホで参照してみました。
　結果、「サイドバー」の占める面積が増えてしまい、「本文」の方も活字が大きめになってしまって、マヌケな表示となりはてて……（タブレットでの表示は大丈夫でした）。
　てなワケで、拙ブログの「デザイン・テーマ」では、『「はてなブログ」用「レスポンシブ対応」宣言』である「/* Responsive: yes */」なる指定は加筆しない方がイイです！――

６．「固定グローバル・メニュー」かつ「ドロップダウン・メニュー」の追加

（２０１９年２月１６日（土）加筆）

スクロールしても、PC・タブレット・スマホの画面上部に固定される「グローバル・メニュー」。かつ、「サブ・カテゴリー」も一覧表示させる「ドロップダウン・メニュー」に改造

（ただし、画面最上部にではなく、「はてなブログ」規定ヘッダーの直下。スクロール時には、画面上部の本文の上に「メニュー・バー」が浮かび上がる表示・汗）

　コレについても、多数のサイトを参考にさせていただき、照合の果てに、もといパクって試してもウマく動作はしない失敗を重ねた末に（笑）、やはり「ｊＱｕｅｒｙ」だの「Ｊａｖａ」だのの言語を使うと動作が少々重たくなるそうなので、以下の最小限のＨＴＭＬとＣＳＳを作成（もとい、ほぼ流用）してみました。

　主に以下のブログさまを参考にさせていただき、ＣＳＳ言語を９０％程度（汗）は解読ができた上で、流用・改変をさせていただいております。
www.bambi.pro

　本来は、「はてなブログ」初期表示の「ブログ」画面の最上部が表示された状態では、この「固定グローバル・メニュー」は表示されてはおらず、画面を最上部から下部へとスクロールさせることによって、「固定グローバル・メニュー」が画面最上部に貼りついたかたちにて出現、表示されつづける……といった仕様のモノになります。
　しかし、試行錯誤の実験＆ＣＳＳ言語の解読の果てに、画面の最上部の「はてなブログ」規定ヘッダーの方が「固定グローバル・メニュー」よりも画面表示の優先順位が高いことから、初期表示では「固定グローバル・メニュー」が表示されていない――「はてなブログ」規定ヘッダーのウラ側に隠されている――ことを発見！　スクロールして「はてなブログ」規定ヘッダーが画面の最上部から離脱することで、ウラ側に隠れていた「固定グローバル・メニュー」が代わりに表示されるようになっていたのでありやした（多分～汗）。

　けれども、やはり「はてなブログ」初期表示の段階でも、画面の上部のドコかに「固定グローバル・メニュー」を表示させたいなぁ。……と思っていたところに、貧乏神のインスピレーションがヒラメいた！
　「固定グローバル・メニュー」を画面の最上部の「はてなブログ」規定ヘッダーの位置ではなく、その直下の位置にして、拙ブログ・タイトルの直上、その両者の狭いスキマの位置に表示をさせればイイ！（笑）

――最上部には表示させてはいない、もうひとつの理由もここに記述いたします。「タブレット」や「スマホ」でインターネットの画面を上方にスクロールし続けていると、画面を表示している「ｃｈｒｏｍｅ（クロム）」などの「ブラウザ」自体の外ワクの最上位の「タブ」やその直下の「ＵＲＬ」の表示部分などが、「タブレット」や「スマホ」画面の上方の外側にハミ出るようなかたちでの画面表示になっていると思います。実はコレに巻き込まれてしまって「固定グローバル・メニュー」もまた、画面上方の外側にハミ出ているようなイメージでの非表示となってしまうことが往々にしてあったものなので、コレを最上部ではなく、最上部の少々下部に表示させることで回避しようといった目論見もありました。
　ただし、「タブレット」や「スマホ」でブログ「本文」部分を「ピンチ」して（＝ふたつの指で押し広げて）、「サイドバー」は画面のヨコ側にハミ出すかたちで、画面のヨコ幅を「本文」のヨコ幅側に合わせて拡大表示をさせてしまうと、その拡大表示比率に釣られて「固定グローバル・メニュー」がまたも「タブレット」や「スマホ」画面の上方の外側にハミ出てしまって、非表示になってしまうといった問題は残ります。
　よって、この事象を回避するために、「固定グローバル・メニュー」の位置を、「はてなブログ」規定ヘッダーの直下ではなくって、さらに下部である拙ブログ・タイトルの直下に表示させることも検討はしたのですけれども……。ブログ「本文」部分を「ピンチ」しての少々拡大をしての画面表示の場合にはともかくとしても、通常の画面表示の場合ですと、「固定グローバル・メニュー」がまだまだ画面上部に位置して表示されているとはいえ、やや画面中央に垂れ降り過ぎておりまして……。
　それはさすがにウザいし、見苦しいし、読者の気が散ってしまうかとも思えます。しかし、上方へのスクロール時には画面の上方にはハミ出てしまって見えなくなってしまっても、下方へスクロールの向きを変えれば、画面上部の「固定グローバル・メニュー」も再び見えるようにはなります。よって、その存在それ自体を読者に認知させることはできるであろうし、むしろ適度に画面の上方にハミ出てくれることによってウザさも回避できるであろうと、我が身の無策・不作為・怠惰さも自己正当化するかたちで（笑）、拙ブログでは「はてなブログ」規定ヘッダーの直下に「固定グローバル・メニュー」を設置してみた次第です――

　その結果が、以下の通りとなります。
――「パソコン」では大丈夫ですけど、「タブレット」だと拙ブログ・タイトルの活字の上部がビミョーに欠けております（汗）。設定的には「メニューバーの高さ」の箇所に該当し、「1px」分を減らせば大丈夫なのであろうけれども……。もうイイや（笑）。（……後日に、「1px」分を減らすかたちで修正済です！）――

６－０．「４－１」での加筆「ＨＴＭＬ」と、「４－２」での加筆「ＣＳＳ」は削除して、以下を代入加筆

６－１．ＨＴＭＬ

　（「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「ＰＣ（スパナのマーク・カスタマイズ）」⇒「ヘッダ」⇒「タイトル下」欄に、以下のＨＴＭＬを加筆（⇒「変更を保存する」はこのタイミングで押下してもよいが、後続の「６－２．ＣＳＳ」側にて一括して押下するのが無難））

<!-- 固定の「グローバル・ナビゲーション・メニュー」 -->
<ul class="navi-top">
   <li><a href="https://katoku99.hatenablog.com/">最新10記事</a></li>
   <li><a href="https://katoku99.hatenablog.com/archive">全記事一覧</a></li>
   <li><a href="#!">▼ウルトラ</a>
      <ul>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%A6%E3%83%AB%E3%83%88%E3%83%A9">ウルトラ</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%A6%E3%83%AB%E3%83%88%E3%83%A9%E7%B7%8F%E8%AB%96">ウルトラ総論</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%A6%E3%83%AB%E3%83%88%E3%83%A9%E7%B5%82">ウルトラ終</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%A6%E3%83%AB%E3%83%88%E3%83%A9%EF%BC%83%EF%BC%91">ウルトラ＃１</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%A6%E3%83%AB%E3%83%88%E3%83%A9%E6%98%A0%E7%94%BB">ウルトラ映画</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%83%A1%E3%83%93%E3%82%A6%E3%82%B9">メビウス</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%83%9E%E3%83%83%E3%82%AF%E3%82%B9">マックス</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%83%8D%E3%82%AF%E3%82%B5%E3%82%B9">ネクサス</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%83%8D%E3%82%AA%E3%82%B9">ネオス</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E5%A4%A7%E6%80%AA%E7%8D%A3">大怪獣</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E5%B9%B3%E6%88%90%E3%82%A6%E3%83%AB%E3%83%88%E3%83%A9">平成ウルトラ</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%A8%E3%83%BC%E3%82%B9">エース</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%BF%E3%83%AD%E3%82%A6">タロウ</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%83%AC%E3%82%AA">レオ</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%B6%E2%98%86%E3%82%A6%E3%83%AB">ザ☆ウル</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%EF%BC%98%EF%BC%90">８０</a></li>
      </ul>
   </li>
   <li><a href="#!">▼ライダー</a>
      <ul>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%83%A9%E3%82%A4%E3%83%80%E3%83%BC">ライダー</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%83%A9%E3%82%A4%E3%83%80%E3%83%BC%E7%B5%82">ライダー終</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%83%A9%E3%82%A4%E3%83%80%E3%83%BC%E6%98%A0%E7%94%BB">ライダー映画</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E6%98%AD%E5%92%8C%E3%83%A9%E3%82%A4%E3%83%80%E3%83%BC">昭和ライダー</a></li>
      </ul>
   </li>
   <li><a href="#!">▼戦隊ほか</a>
      <ul>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E6%88%A6%E9%9A%8A">戦隊</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E6%88%A6%E9%9A%8A20%E4%B8%96%E7%B4%80">戦隊20世紀</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E6%88%A6%E9%9A%8A%E6%98%A0%E7%94%BB">戦隊映画</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E8%B6%85%E6%98%9F%E7%A5%9E">超星神</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E7%89%B9%E6%92%AE%E4%BB%96">特撮ほか</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E7%89%B9%E6%92%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88">特撮イベント</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E8%A5%BF%E9%81%8A%E8%A8%98">西遊記</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E6%99%82%E4%BB%A3%E5%8A%87">時代劇</a></li>
      </ul>
   </li>
   <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%B4%E3%82%B8%E3%83%A9">ゴジラ</a></li>
   <li><a href="#!">▼特撮洋画</a>
      <ul>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%A2%E3%83%A1%E3%82%B3%E3%83%9F%E6%B4%8B%E7%94%BB">アメコミ洋画</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E7%89%B9%E6%92%AE%E6%B4%8B%E7%94%BB">特撮洋画</a></li>         <li><a href="https://katoku99.hatenablog.com/archive/category/%E7%89%B9%E6%92%AE%E9%82%A6%E7%94%BB">特撮邦画</a></li>
      </ul>
   </li>
   <li><a href="https://katoku99.hatenablog.com/archive/category/%E7%89%B9%E6%92%AE%E6%84%8F%E8%A6%8B">特撮意見</a></li>
   <li><a href="#!">▼アニメ</a>
      <ul>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%A2%E3%83%8B%E3%83%A1">アニメ</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%A2%E3%83%8B%E3%83%A1%E6%98%A0%E7%94%BB">アニメ映画</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%AC%E3%83%B3%E3%83%80%E3%83%A0">ガンダム</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%83%A4%E3%83%9E%E3%83%88">ヤマト</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%83%9E%E3%82%AF%E3%83%AD%E3%82%B9">マクロス</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%83%9E%E3%83%B3%E3%82%AC">マンガ</a></li>
      </ul>
   </li>
   <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%AC%E3%83%B3%E3%83%80%E3%83%A0">ガンダム</a></li>
   <li><a href="#!">▼オタ思想他</a>
      <ul>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%82%AA%E3%82%BF%E3%82%AF">オタク</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E6%80%9D%E6%83%B3">思想</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E8%BF%BD%E6%82%BC">追悼</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E3%83%89%E3%83%A9%E3%83%9E">ドラマ</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E8%8A%B8%E8%83%BD">芸能</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E5%90%8C%E4%BA%BA%E8%AA%8C">同人誌</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E7%9B%AE%E6%AC%A1">年度目次</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/%E8%A6%9A%E3%81%88%E6%9B%B8%E3%81%8D">覚え書き</a></li>
         <li><a href="https://katoku99.hatenablog.com/archive/category/InDesign%E8%A6%9A%E6%9B%B8">InDesign</a></li>
      </ul>
   </li>
</ul>

　「ＵＲＬ」と「カテゴリー名」は、各自のブログのそれに応じて、読み替えてくださいませ（汗）。
――「ＵＲＬ」を「#!」と記述している「親・カテゴリー」の箇所は、クリックやタップをしてもドコにもジャンプさせない、といった意味での規定語です。理由は後述――

６－２．ＣＳＳ

　（「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「ＰＣ（スパナのマーク・カスタマイズ）」⇒「デザインＣＳＳ」欄に、既存のものは残したままで、以下のＣＳＳを加筆⇒「変更を保存する」）
　（ＣＳＳは記述する位置が後半以降だと効力を発揮しない説もあったので、念のために冒頭の「はてなブログ」採用デザインテーマのＣＳＳと、先に入力した「アーカイブ・ページ」用のＣＳＳの中間に、以下のＣＳＳを加筆）

/*==============================================
画面上部に貼りつく「固定グローバル・メニュー」かつ「ドロップダウン・メニュー」
================================================*/
ul.navi-top, ul.navi-top a {
        color:blue;/*メニューバーの文字色*/
        background-color:white;/*メニューバーの背景色*/
}

ul.navi-top a:hover {
        color:white;/*マウスオーバー時の文字色*/
        background-color:grey;/*マウスオーバー時の背景色*/
}

ul.navi-top {
        position:fixed;/*位置固定（left:0やtop:0と合わせての画面上位に固定？）*/
        left:0;
        top:0;
        margin-top: 5.3em;/*枠線外・上余白・メニュー文字の５．３文字分（？）を空けることで、「はてなブログ」規定ヘッダーと当該ブログ・タイトルの隙間（汗）に当該「固定グローバル・メニュー」を表示（※各ブログごとでの改変対象数値）*/
     /* margin: 0;  枠線外・余白（コメント囲いで無効化）*/
        padding:0;/*枠線内・余白*/
        font-size:65%;/*カテゴリ名の文字の大きさを縮小（※各ブログごとでの改変対象数値）*/
     /* font-size:14px;  カテゴリ名の文字の大きさ（コメント囲いで無効化）*/
        width:100%;
        text-align:center;/*左寄せや右寄せではなく均等配置*/
        z-index:50;/*重なり順（※10000などの巨大数を指定すると、「はてなブログ」規定ヘッダーに上塗り優先する形で、当該「グローバル・メニュー」が表示されるが、規約違反なので不可！　画面スクロール時に最優先表示の「はてなブログ」規定ヘッダーから離脱することで、当該「グローバル・メニュー」が本文よりも優先表示される模様）*/
}

/*１階層目*/
ul.navi-top li {
        width: 80px;/*１階層目の幅（※各ブログごとでの改変対象数値。★画面幅の拡縮に応じて変化する「width: calc(100% / メニューのカテゴリ数 )」を指定したら、２層目が表示不可になってしまった。どなたか解決策を教えてくださいませ！・汗）*/
        display: inline-block;/*ヨコ並びのブロック要素だが、幅・高さ・内外余白指定可（※float:leftの代替？　高度版？）*/
        list-style-type: none;/*カテゴリ名の先頭に中点や番号なし*/
        position: relative;/*相対位置*/
}

ul.navi-top a {
        line-height: 18px;/*メニューバーの高さ（※各ブログごとでの改変対象数値）*/
        text-align: center;/*文字位置・中央寄せ*/
     /* padding-left:10px;  枠線内・左余白（コメント囲いで無効化）*/
        text-decoration: none;/*文字装飾・なし*/
        font-weight: normal;/*文字の太さ・普通*/
        display: block;/*タテ並びのブロック要素で、幅・高さ・内外余白指定可*/
}

/*２階層目*/
ul.navi-top ul {
        display: none;/*非表示（？）*/
        margin:0px;/*枠線外余白*/
        padding:0px;/*枠線内余白*/
        position: absolute;/*絶対位置*/
        z-index:51;/*重なり順（※2025年５月31日追加。１階層目は「50」なので、２階層目は「51」にすることで、スマホ画面で１階層目が２行にわたってしまった場合に、１行目の２階層目については、２行目の１階層目の方が優先されてしまって、ウラに隠れて非表示になってしまう不具合を解消*/
}

ul.navi-top ul a{
        width: 100%;/*２階層目の幅（※小さい数値の％だと崩れる）*/
} 

ul.navi-top li:hover ul {
        display: block;/*タテ並びのブロック要素で、幅・高さ・内外余白指定可*/
}

　……流用元のブログさま、あるいは各種の「グローバル・メニュー」を設定しているブログさまでも散見される現象ですけど、「パソコン」では問題ないものの、「タブレット」や「スマホ」ですと、「グローバル・メニュー」の「親・カテゴリー」名を指先でタップして「サブ・カテゴリー」を「ドロップダウン」表示させると、「ドロップダウン・メニュー」それ自体は表示はされるのですけど、そのまま滞空せずに即座に「サブ・カテゴリー」ではなく「親・カテゴリー」自体のリンク先の画面に遷移してしまう傾向があるようでした。ゆっくりとタップすると、「ドロップダウン・メニュー」が表示された画面のままで滞空するようではありますが……。

――ここのみ、２０１９年２月２０日（水）加筆：「タブレット」や「スマホ」でタップして「ドロップダウン・メニュー」を表示させると、「サブ・カテゴリー」を選択する前に「親・カテゴリー」側のリンク先へとジャンプをしてしまう問題を回避するために、「親・カテゴリー」の「ＵＲＬ」にクリックやタップをしても、ドコにもジャンプをさせないための規定語「#!」を指定しました――

　あと、「パソコン」や「タブレット」の場合には、この「固定グローバル・メニュー」は、画面のヨコ幅の縮小に応じて、「カテゴリー」配置があくまでも１行に収まったままでの均等配置では縮まらずに、あまりに画面のヨコ幅を狭くしてしまうと「カテゴリー」の後段（右側）側が２行目としての「メニュー・バー」として表示がされるようになってしまいます（汗）。
　それはまだしもイイとしても（？）、１行目側の任意の「カテゴリー」を選択して、その「サブ・カテゴリー」を「ドロップダウン」表示させると、「サブ・カテゴリー」の１件目が「固定グローバル・メニュー」側の２行目の「カテゴリー」表示のウラ側に隠れてしまって表示がなされない……といった問題もあります。
――仮に当該デザインでも、「スマホ」でも「パソコン」と同じ画面を表示させる設定にしていた場合には、拡大表示は可能であっても、縮小表示は基本的には不可能ですので、直上の問題は生じないとは思います――

　しかし、このへんの問題を解消するスキルも知識もなくって、画面をそこまで極端に狭めて表示させる御仁もそんなにはいないであろうし（？）、トータルでの得失を勘案して見切り発車で当該方策を採用し、物理的・肉体的にヒトが傷ついてしまうような悪事でもないであろうと（笑）、上記のＨＴＭＬとＣＳＳも公表させていただきました次第です～。

――２０２５年５月の後日付記：　「margin-top: 3.3em;/*枠線外・上余白・メニュー文字の３．３文字分（？）を空け」であったものを、いつぞやからの「はてなブログ」それ自体の規定のヘッダー部分の厚みが増してしまったことで、「margin-top: 5.3em;/*枠線外・上余白・メニュー文字の５．３文字分（？）を空け」のように、「３．３文字分空け」から「５．３文字分空け」に変更しております。上記のサンプルもその改訂版になります。
　『１行目側の任意の「カテゴリー」を選択して、その「サブ・カテゴリー」を「ドロップダウン」表示させると、「サブ・カテゴリー」の１件目が「固定グローバル・メニュー」側の２行目の「カテゴリー」表示のウラ側に隠れてしまって表示がなされない……といった問題』についても、『z-index:51;/*重なり順（※2025年５月31日追加。１階層目は「50」なので、２階層目は「51」にすることで、スマホ画面で１階層目が２行にわたってしまった場合に、１行目の２階層目については、２行目の１階層目の方が優先されてしまって、ウラに隠れて非表示になってしまう不具合を解消*/』を付与することで、解決できました――

７．悪ノリして、「グローバル・メニュー」＆「固定グローバル・メニュー」の両方を表示

（２０１９年２月２３日（土）加筆）

「４．」の「グローバル・メニュー」＆「６．」の「固定グローバル・メニュー」を同時に表示

　「カテゴリー」ごとの「記事一覧」などの「リンク」集を表示させている「固定グローバル・メニュー」とはまた別に、新「はてなブログ」のブログ・タイトル直下の部分に表示される当該の「ブログの説明」の文中に、「オススメ記事」へのリンクをいくつか貼れないものかなぁ、とついつい欲張ったことを考え出してしまいました。
――旧「はてなダイアリー」時代においては、「ページのヘッダ」設定画面にＨＴＭＬを加筆することで、ブログ・タイトルの直下に固定文言や「おすすめ記事」への「リンク」も加筆可能であったためです――
　それで、「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「設定」⇒「基本設定」⇒「ブログの説明」欄に、リンクを貼る意味のＨＴＭＬを加筆して「変更する」押下で試してみたところで……、見事に玉砕！　ＨＴＭＬ言語がそのままで表示されてしまったのでした（汗）。

　そこで、またビンボー症の神さまのインスピレーションがハタとヒラメいた（笑）。「４．」の「グローバル・メニュー」＆「６．」の「固定グローバル・メニュー」を、「同時」にいっしょに表示させてしまおうと！

　てなワケで、「デザイン」⇒「ヘッダ」⇒「タイトル下」に、

●まず、「６ー１．」の「固定グローバル・メニュー」のＨＴＭＬを貼付し、
●直後に、直上のＨＴＭＬと直下のＨＴＭＬの境目を識別しやすくさせるための便宜で、数行の空白を空けて、
●最後に、「４ー１」の「グローバル・メニュー」のＨＴＭＬを貼付して、

「はてなブログ」規定ヘッダーの直下には「固定グローバル・メニュー」を、拙ブログ・タイトル直下には通常の「グローバル・メニュー」を設置してみた次第です～。

　ここで追加した通常の「グローバル・メニュー」は、「カテゴリー」名ではなく「オススメ記事」名を表示させているため、「リンク」部分の文字数が多くて、しかも各々の「リンク」の文字数の長短も異なっているため、均等配置だとかえって不格好になるために、文字数に応じて各々の「リンク」の間隔も詰めたかったのですけれども、いろいろと試してみても当方のスキルではうまくいかない……。今後の課題といたします～。

　「ＣＳＳ」は、先の「４－２」における、通常の「グローバル・メニュー」と基本は同一ですけれども、

・「width: calc(100% / 11);/*メニュー幅÷メニューカテゴリ数（※各ブログごとでの改変対象数値）*/」
　　　　　　　　　　　　　↓
・「width: calc(100% / 8);/*メニュー幅÷★メニューおススメ記事数（※各ブログごとでの改変対象数値）*/」

・「font-size: 70%;/*カテゴリ名の文字の大きさを縮小（※各ブログごとでの改変対象数値）*/」
　　　　　　　　　　　　　↓
・「font-size: 65%;/*★記事名の文字の大きさを縮小（※各ブログごとでの改変対象数値）*/」

上記の２箇所のみを、変更しております～。

――２０１９年３月２９日（金）加筆：　上記の「カテゴリー」ごとの「記事一覧」などの「リンク」集を表示させている「固定グローバル・メニュー」については、拙ブログが採用しているブログデザインにおける「パソコン」上において、ＧｏｏｇｌｅのブラウザとＧｏｏｇｌｅの「Ｃｈｒｏｍｅ」ブラウザ、マイクロソフトの新世代ブラウザ「Ｅｄｇｅ（エッジ）」においては、全８カテゴリーの見出しがヨコいっぱいに問題なく表示されていることを確認！　「タブレット」においても、ＧｏｏｇｌｅのブラウザとＧｏｏｇｌｅの「Ｃｈｒｏｍｅ」ブラウザでは、問題なく表示されていることを確認！　「スマホ」においても、Ｇｏｏｇｌｅのブラウザでは問題なく、全８カテゴリーの見出しがヨコいっぱいに表示されていることを確認！
　しかし、「パソコン」上における、マイクロソフト社の旧ブラウザ「インターネット・エクスプローラー」においては、拙ブログを例に取れば、全８カテゴリーの先頭の７カテゴリーの見出しについてはメニューの１行目に表示されたものも、最後の１カテゴリーのみ２行目の方にハミ出てしまって表示されてしまうことが発覚（汗）。
　ただまぁ、大過はナイとは思いますし、マイクロソフト社は「インターネット・エクスプローラー」のバージョンアップは終了して、新ブラウザ「Ｅｄｇｅ」への移行を奨励していることもあったので、「インターネット・エクスプローラー」での「グローバル・メニュー」の表示が少々オマヌケになったとしても、そのまま放置することにする！――

――２０２５年９月１日（月）加筆：　「カテゴリー」ごとの「記事一覧」などの「リンク」集を表示させている「固定グローバル・メニュー」については、「タブレット」にてヨコ長にして表示させた場合には、Ｇｏｏｇｌｅの「Ｃｈｒｏｍｅ」ブラウザにおいては、全８カテゴリーの見出しがヨコいっぱいに表示されていることを確認！　しかし、タテ長にして表示させた場合には、全８カテゴリーの見出しの先頭の５カテゴリーの見出しについてはメニューの１行目に表示されるも、残りの３カテゴリーのみ２行目の方にハミ出てしまって表示されてしまう（汗）。
　「スマホ」にてヨコ長にして表示させた場合には、Ｇｏｏｇｌｅの「Ｃｈｒｏｍｅ」ブラウザにおいては、全８カテゴリーの見出しの先頭の７カテゴリーの見出しについてはメニューの１行目に表示されるも、最後の１カテゴリーの見出しのみ２行目の方にハミ出てしまって表示されてしまう（汗）。タテ長にして表示させた場合には、全８カテゴリーの見出しの先頭の５カテゴリーの見出しについてはメニューの１行目に、次の５カテゴリーの見出しについてはメニューの２行目に、残りの１カテゴリーの見出しについてはメニューの３行目の方に、ハミ出てしまって表示されてしまう（汗）。

　ただまぁ、いずれにしても、「カテゴリー」ごとの「記事一覧」などの「リンク」集を表示させている「固定グローバル・メニュー」側のハミ出てしまった２行目以降の箇所によって、本文や他の箇所が隠れてしまうワケではなく、大過はナイとも思うので、そのまま放置することにする！――

Ｘ．スマホ画面専用の「ボトム・ナビゲーション」追加　（→：当該デザインでは、設置不可能だと判明・汗）

（２０２５年５月２６日（月）加筆）

　「ボトム・ナビゲーション」or「ボトム・メニュー」or「フッター・メニュー」。多数の呼び名があるようです。

　いろいろと試してはみたものの、――２０２５年５月３１日まで採用していたデザイン「Hatena for はてなブログ」では――設置不可能だと判明！

――２０２５年１０月１９日（日）後日付記：　２０２５年５月３１日から採用したデザイン「classic diary（日記向け）」においても、たしか設置不可能であったと記憶（汗）――

　まず、「スマホ」画面側での表示設定を、「レスポンシブ対応」欄は未入力（＝「非対応」）のままで、つまりは「はてなブログ」規定の「スマホ」用画面が表示される設定のままで、各所というか有名どころで発表されている専用の「ＨＴＭＬ」を、「デザイン」⇒「ヘッダ」⇒「タイトル下」欄に記載済の「グローバルメニュー」用のＨＴＭＬの「下」や「上」に転記してみた。しかし、「スマホ」側にて拙ブログを表示してみても、「ボトム・ナビゲーション」は表示されなかった。

　次に、「レスポンシブ対応」欄に「レ」点を入力（＝「対応」）して、つまりは「スマホ」側でも「パソコン」側と同じ画面を表示させる設定にしてみて、専用「ＨＴＭＬ」を「タイトル下」欄の既存の「グローバルメニュー」の設定の「下」や「上」に転記してみた。しかし、それでも正規のあるべき姿としての「ボトム・ナビゲーション」は表示されなかった。
　その代わりに、「ボトム・ナビゲーション」として設定しておいた過去記事への「リンク」などが、「ボトム」（底）の「バー」（棒）としてではなく、最上部の「ブログのタイトル下」に１行ずつのただの青いリンクとして表示されるだけであった（笑）。

　上記に加えて、「ＣＳＳ」欄に、「/* Responsive: yes */」を追加してみた。それでも「ボトム・ナビゲーション」は表示されなかった。

　専用の「ＨＴＭＬ」を、「デザイン」⇒「ヘッダ」⇒「タイトル下」欄ではなく、「デザイン」⇒「フッタ」欄側に転記してみた。しかし、ブログ記事の直下に、１行ずつのただの青いリンクとして表示されるだけであった（笑）。

　よって、そもそもの「レスポンシブデザイン」対応の「デザイン」でなければ、スマホ画面専用の「ボトム・ナビゲーション」追加はできないのであろうと推測。
　と思って、当該「元祖はてなダイアリー」風デザインテーマ「Hatena for はてなブログ」と同じコンセプトのデザインテーマ「classic diary（日記向け）」の方は、「レスポンシブデザイン」対応の「デザイン」ではあったので、そちらの方でも試してみた。……そもそも、どうやっても「ボトム・ナビゲーション」が表示されてこない！（当方個人でなにか設定漏れをやらかしたのであろうか？・汗）

　整理すると、「レスポンシブデザイン」対応の「デザイン」ではあっても、スマホ画面専用の「ボトム・ナビゲーション」が追加できない場合もあるようだ……といったことになるのか！？

Ｘ－１．ＨＴＭＬ　（→：当該デザインでは、設置不可能なので、未設置）

　（「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「ＰＣ（スパナのマーク・カスタマイズ）」⇒「ヘッダ」⇒「タイトル下」欄に、以下のＨＴＭＬを加筆（……もちろん、既存の「ＨＴＭＬ」は削除や上書きはしないで、残したうえで、その続きに加筆すること！）

<!-- bottom navigation -->

<ul class="bottom-menu">
    <li>
	<!--　↓↓項目1. ホーム 　＃の部分にホームのURLを入れる -->
        <a href="https://katoku99.hatenablog.com/">
	<i class="blogicon-home"></i><br><span class="mini-text">ホーム</span></a>
    </li>

    <li class="menu-width-max">
	<!-- ↓↓項目2. おすすめ　すぐ下の"＃"はそのまま -->
        <a href="#"><i class="blogicon-list"></i><br><span class="mini-text">おすすめ</span></a>

		<ul class="menu-second-level">

		<!-- 下の"#"の部分におすすめ"記事URL"とタイトル等を入れる -->
			<li><a href="https://katoku99.hatenablog.com/entry/20250211/p1">機動戦士ガンダム　ジークアクス</a></li>
			<li><a href="https://katoku99.hatenablog.com/entry/20241020/p1">ヤマトよ永遠に　REBEL 3199</a></li>
			<li><a href="https://katoku99.hatenablog.com/entry/20250303/p1">ウルトラマンアーク総括</a></li>
			<li><a href="https://katoku99.hatenablog.com/entry/20220116/p1">仮面ライダーセイバー総括</a></li>
			<li><a href="https://katoku99.hatenablog.com/entry/20230521/p1">機界戦隊ゼンカイジャー総括</a></li>
			<li><a href="https://katoku99.hatenablog.com/entry/20190601/p1">ゴジラ評論６０年史</a></li>
			<li><a href="https://katoku99.hatenablog.com/entry/20250309/p1">シビル・ウォー　アメリカ最後の日</a></li>
        	</ul>
    </li>
    <li>
	<!-- ↓↓項目3.　読者登録 ↓↓の部分の書き換えが必要です -->
        <!--  ~hatena.ne.jp/自分のはてなID/URL(http://の部分は無し)/subscribe　-->
 	<a href="https://blog.hatena.ne.jp/katoku99/katoku99.hatenablog.com/subscribe" target="_blank">
	<i class="blogicon-hatenablog"></i><br><span class="mini-text">読者登録</span></a>
    </li>
    <li>
	<!-- ↓↓項目4.　ツイッター ↓↓の部分の書き換えが必要です-->
	<!-- screen_name=自分のツイッターID" ←＠マーク以降のIDを入れる -->
        <a href="https://twitter.com/intent/follow?screen_name=katoku99">
	<i class="blogicon-twitter"></i><br><span class="mini-text">Follow</span></a>
    </li>
</ul>

Ｘ－２．ＣＳＳ　（→：当該デザインでは、設置不可能なので、未設置）

　（「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「ＰＣ（スパナのマーク・カスタマイズ）」⇒「デザインＣＳＳ」欄に、既存のものは残したままで、以下のＣＳＳを加筆⇒「変更を保存する」）
　（ＣＳＳは記述する位置が後半以降だと効力を発揮しない説もあったので、念のために冒頭の「はてなブログ」採用デザインテーマのＣＳＳと、先に入力した「アーカイブ・ページ」用のＣＳＳの中間に、以下のＣＳＳを加筆）

/*PC表示の際はボトムメニューは表示しない*/
@media(min-width: 768px){
    .bottom-menu{display:none; }
}



/*========================
　smartphone　bottom menu
　========================*/


.mini-text{font-size:10px;}/*文字大きさ*/

ul.bottom-menu {
    position: fixed;
    left:0;
    bottom:0;
    width: 100%;
    height:45px;/*高さ*/
    margin:0;
    padding:0;
    background-color:#f5f5f5;/*背景色*/
    border-top:2px solid #808080;/*バーの上の線*/
    border-bottom:2px solid #808080;/*バーの下の線*/
    z-index:30;}

ul.bottom-menu li {
    float:left;
    width:25%;
    background-color:#f5f5f5;/*背景色*/
    list-style-type:none;
    text-align:center;
    font-size:25px;/*アイコンのサイズ*/}

.bottom-menu li a {
    display: block;
    color:#808080;/*アイコン＆文字の色*/
    padding-top:10px;
    padding-bottom:5px;
    line-height:10px;
    text-decoration:none;}

.bottom-menu li a:hover {
    color:#a9a9a9;/*マウスオーバー時の色*/}

/* === 展開メニュー === */

ul.menu-second-level {
    visibility: hidden;
    opacity: 0;
    z-index:1;}

ul.menu-second-level li a{
    border-top:1px dashed #a9a9a9;/*展開の枠点線*/
        font-size:15px;/*展開メニューの文字サイズ*/
        line-height:30px;/*文字の縦幅*/}

.menu-second-level li a:hover {
    height:100%;
    background: lightgrey;/*マウスオーバーの色*/}

li.menu-width-max ul.menu-second-level {
    position: absolute;
    bottom: 47px;/*高さ*/
    left: 0;
    box-sizing: border-box;
    width: 100%;
    padding:0;}

li.menu-width-max:hover ul.menu-second-level {
    bottom: 47px;/*高さ*/
    visibility: visible;
    opacity: 1;}

li.menu-width-max ul.menu-second-level li {
    float: left;
    width: 100%;
    border: none;}

（ついでに、「スマホ」で当該デザイン――「Hatena for はてなブログ」の方。「classic diary（日記向け）」の方にはあらず――の拙ブログを表示させた場合に、「サイドバー」を非表示にする設定なども「ＣＳＳ」欄の方に入れてみる実験もしてみた。非表示にはできたものの……。「サイドバー」のエリアが「記事本文」で埋まる……といったものではなくて、単に「サイドバー」分の空白エリアが発生するだけであった（爆）。つまり、「スマホ」側でも「パソコン」と同じ画面を表示させる設定だという、ブログ側での「レスポンシブデザイン」項目に「レ」点を入れておいても、いわゆる「レスポンシブデザイン対応」のデザインになっているブログでなければ、「スマホ」側では「サイドバー」が非表示になって「記事本文」だけで埋まったり、「サイドバー」が「記事本文」の下に表示されるというような挙動にはならないようであった。よって、「レスポンシブデザイン対応」のデザインになっていないブログにおいては、「サイドバー」の非表示設定にもあまり用途がないようであった……・汗）

　以下のように、「はてなブログ ボトムナビゲーション レスポンシブデザインでしか表示されないのか」　といった文言でググってみたところ、「ＡＩによる概要」によれば、「レスポンシブデザイン」に対応したブログ・デザインでなければ、「ボトム・ナビゲーション」は設置不可能である模様であった……。そこは残念！

「はてなブログ ボトムナビゲーション レスポンシブデザインでしか表示されないのか」
→　「（中略）ボトムナビゲーションはレスポンシブデザインに対応したブログデザインの場合に、スマートフォンでの表示に特化して追加される機能です。」
www.google.com

　他にも、「ボトム・ナビゲーション」が設置できなかった旨のブログ記事も見つけた……。
nonkinablogs.xyz

――２０２５年１０月１９日（日）後日付記：　上記の「ＡＩによる概要」が変更されていた（汗）。　→「いいえ、ボトムナビゲーションはレスポンシブデザインでなくても表示されますが、表示方法がレスポンシブデザインが有効な場合にスマートフォン表示を最適化するために自動的に調整されるようになります」――

８．「アーカイブ・ページ」をさらにスマート化

（２０１９年２月２３日（土）加筆）

「全記事見出し一覧」や「カテゴリーごとの記事見出し一覧」ページの行間詰め

「記事名タイトル」の行から改行されてからの「左詰め」での該当記事の「カテゴリー」リンクの表示も、改行なしでの「記事名タイトル」行内にて「右詰め」化

（ただし、「記事名タイトル」があまりに長いと、右詰めの「カテゴリー」リンクと「記事名タイトル」の末尾が重複してしまう問題はアリ～汗）

　「はてなブログ」の「アーカイブ・ページ」の行間等々が空きすぎていたり、各記事ごとの「カテゴリー」を示すリンクも、なぜだか「記事名タイトル」を表示する「行」から改行されて、その１行下に「左詰め」（！）にて表示されてしまって、各々の記事がドコの「カテゴリー」に属しているのかが即座には判別しがたい見づらいモノでしたので、ナンとかしたいなぁと、コレもまたネットサーフィンをしていたところで……、ありました！

　以下のブログさまを参考にさせていただき、そのまま流用（汗）させていただきました。
www.detourist.net

８－１．ＣＳＳ（いったん設置したが、６年後に削除・汗）

　（「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「ＰＣ（スパナのマーク・カスタマイズ）」⇒「デザインＣＳＳ」欄に、既存のものは残したままで、先の「２．」と「３．」の「アーカイブ・ページ」のＣＳＳも残したままで、その下に以下のＣＳＳを加筆⇒「変更を保存する」）

/*==============================================
「記事一覧ページ」をさらにスマート化（ただし、記事名が長いと、右詰めの「カテゴリー」のリンクと重複～汗）
================================================*/
.archive-entry-header {
    display: table;
    width: 100%;
    border: none;
    padding: 0;
}
.archive-entry-header .date {
    display: table-cell !important;
    padding: 2px 0 !important;
    margin: 0 !important;
    width: 86px !important;
    text-align: right !important;
}
.archive-entry-header .entry-title {
    display: table-cell !important;
    padding: 2px 0 2px 1em !important;
    margin: 0 !important;
    font-size: 100% !important;
    font-weight: normal !important;
}
.archive-entry {
    position: relative;
    margin-bottom: 0 !important;
}
.archive-entry .categories{
    position: absolute;
    right: 0;
    bottom: 2px;
    margin: 0 !important;
}
.archive-entry .entry-thumb-link, 
.archive-entry .archive-entry-body {
    display: none !important;
}

９．「サイドバー」の固定　（→：当該デザインでは、設置不可能だと判明・汗）

（２０１９年３月１日（金）加筆）

スクロールして下端に達すると画面に固定される、ＣＳＳのみで設定可能な「サイドバー」

　コチラもググると、「ｊＱｕｅｒｙ」や「Ｊａｖａ」等の動作が少々重たくなる言語を使用しないでも可能な「サイドバー」の固定法がありました。以下の３箇所のサイトを参考にさせていただきました。
https://www.okuni.me/entry/only-css-sidebar-fixedwww.okuni.me
www.bambi.pro
www.foxism.jp

９－１．ＣＳＳ（未設置）

/*==============================================
スクロールして下端に達すると、画面に固定される「固定サイドバー」
================================================*/
#box2{/*サイドバー全体の箱*/
	    display: -webkit-flex;
	    display: flex;
}	
.hatena-module:last-of-type{/*サイドバー最後の要素*/
	    position: -webkit-sticky;
	    position: sticky;
	    top: 0;/*上から離す距離（50pxなど）*/
}

　しかし！　当該デザインのブログでは、「サイドバー」がなぜだか固定されない模様（汗）。原因は不明です。

　それとは別に、２０１９年３月１３日（水）、それまでに生じていた以下の別件は解決しておりました。

　「『拙ブログ・デザインでは「サイドバー」が「記事本文エリア」側に少しハミ出て表示される不具合が発生するため、当該ＣＳＳの設置は保留（汗）」

　上記の問題が解消した理由は、当該「はてなブログ」デザイン（＝２０２５年５月３１日以前に使用していたデザイン・汗）の本家本元の造物主さまが、２０１９年３月１０日（日）に「サイドバー」中の「検索窓」が「ブログ」の「本文」側にハミ出てこないようにデザインを改修されたことに起因するのでは？　あるいは、ついでに「サイドバー」それ自体を改修してくださったのでは？　と愚考・推測はしております。
　経緯としては、「検索窓」のハミ出し問題が改修されたので、試しに「サイドバー」固定用の当該ＣＳＳを設置してみたところ、「サイドバー」が「記事本文エリア」側に少しハミ出て表示される不具合は解消されていることは確認ができた次第です。ただし、ハミ出はしないし、むしろ大カンンゲイではありますけど、「サイドバー」は１行あたり１文字ほど増えて表示がされるようになりました～――「サイドバー」中の「最新20記事一覧」（拙ブログでは「最新記事（ここｸﾘｯｸで一覧）」名義）の方は例外でして、ナゼだかコチラは１行あたりの文字数には変更はありませんでしたけど（それによる支障もまったくありませんが・笑）――。




――２０１９年３月２８日（木）加筆：「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「スマホ（スマホのマーク）」⇒「詳細設定」⇒「レスポンシブデザイン」欄に「レ」点を入力した状態で、『「はてなブログ」用「レスポンシブ対応」宣言』である「/* Responsive: yes */」を「デザインＣＳＳ」欄へはあえて加筆しない設定の状態、かつ上記の「サイドバーの固定」のＣＳＳを加筆してある設定の状態で、スマホの方も参照してみました。
　結果、「サイドバー」がサイドに寄らずに、画面の中央に表示される「ミドルバー」状態になってしまうことが発覚！（爆～タブレットの方は大丈夫でした）
　仕方がないので、上記「サイドバーの固定」のＣＳＳを削除したところ、スマホでも「サイドバー」はキチンとミドルならぬサイドへと寄りました。てなワケで、拙ブログの「デザイン・テーマ」こと「Hatena for はてなブログ」（＝２０２５年５月３１日以前に使用していたデザイン・汗）では、「サイドバーの固定」はしない方がイイのかも？（汗）――

――２０１９年４月１４日（土）追記：当該デザインテーマ「Hatena for はてなブログ」（＝２０２５年５月３１日以前に使用していたデザイン・汗）で、「サイドバーの固定」が可能か否かについて、本格的（？）に調査をしてみました。
　当方も利用している「はてなブログ」無料ユーザープランでは、「はてなブログ」を合計３つ開設できるので、以下のサイトを参照して（https://walkingyorimichi.hatenablog.com/entry/hatena-beginner-05）、非公開設定のダミーブログを作って、「サイドバー固定」指定文以外のＣＳＳを省いて確認してみたところ……、やはり「サイドバーの固定」はできない！（笑）　よって、他の用途のＣＳＳが悪さをしているという可能性もゼロになりました。

　試しに、２０１９年２月中下旬に追加されたばかりの旧「はてなダイアリー風」の同系デザインデーマ「classic diary（日記向け）」でも、「サイドバーの固定」が可能か否かをダミーブログの方で確認してみました。
　結果……。コチラもダメでした（爆）。
　いやまぁ、別にイイんですけれどもネ。一応、確認をしてみないと気が済まない、実験してみたかっただけでして。大きな支障があるとはいえないので、天秤にかければ当該デザインテーマそれ自体をとても気に入っていることもあり、このまま使用をしつづけるつもりではあります。あとは、それぞれのデザインテーマの造物主さまが気まぐれで降臨してくださり、改造でもしてくだされば……といったところですかネ（笑）――

Ｙ．「classic diary（日記向け）」におけるデザインの微変更　：　「サイドバーの幅の縮小」「サイドバーのモジュールの文字の縮小」「サイドバーのリンクを青色化」など！

（２０２５年５月３１日（土）加筆）

Ｙ－１．ＣＳＳ　（「ustom-bookmark」は、「注目記事（はてな被ブックマーク）」のサイドバー・モジュール側に設定した「クラス名」。「custom-osusume」は、「最新記事（特定カテゴリー「おすすめ」）」のサイドバー・モジュール側に設定した「クラス名」のこと）

/***サイドバー：スマホでは非表示モジュール分***/
@media screen and (max-width:767px){
.hatena-module-search-box{display:none;}/*検索ボックス*/　←：※左記の「検索ボックス」行は、スマホでも表示させるために、拙ブログでは未設置（汗）
.hatena-module-profile{display:none;}/*プロフィール*/　←：※左記の「プロフィール」行は、スマホでも表示させるために、拙ブログでは未設置（汗）
.hatena-module-recent-entries{display:none;}/*最新記事*/
.hatena-module-links{display:none;}/*リンク*/
.hatena-module-category{display:none;}/*カテゴリー*/
.hatena-module-html{display:none;}/*HTML*/
.hatena-module-custom-bookmark{display:none;}/*カスタム・注目記事（はてな被ブックマーク）*/
.hatena-module-custom-osusume{display:block}/*カスタム・最新記事モジュール用だが、特定カテゴリーのモジュール分のみ、「block」にて例外的に表示*/
}



/* サイドバーの文字の大きさ */
#box2 {
font-size:11px!important;
}



/* サイドバーの幅 */
@media (min-width: 900px){
  #main {
      width: calc(100% - 220px);
  }
  #box2 {
    width: 150px;
  }
}



/* サイドバーの各モジュール自体のタイトルが、リンクになっている部分の文字色 */
.hatena-module-title a { /*「a」（アンカー）タグ＝リンク部分のみに対して設定*/
    color: inherit; /* 親要素の色を継承 */
}



/* サイドバーの各モジュール内の明細行が、リンクになっている部分を青字化 */
.hatena-module-body a { /*「a」（アンカー）タグ＝リンク部分のみに対して設定*/
    color: blue; /*文字色*/
}



/* 記事本文の枠の幅 */
@media (min-width: 769px){
  #container,
  footer#footer{
    margin-left:1%;
    margin-right:1%;
  }
}

　「サイドバーの各モジュール自体のタイトルが、リンクになっている部分の文字色」なる設定については、このように設定しておかないと、「スマホ」でサイドバー部分をサイドバーならぬブログ記事の下側に表示させた場合に、「サイドバーの各モジュール自体のタイトルが、リンクになっている部分の文字色」については、青いバーに「白色の文字リンク」ではなく、青いバーに「青色（爆）の文字リンク」になってしまって、見えにくくなってしまったための処置。

15分で丸わかり！はてなブログで稼ぐ方法: 知識ゼロから始める不労所得作り 15分で丸わかりシリーズ

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　デザイン改造ではなく、旧「はてなダイアリー」時代のＵＲＬの一括置換　＆　リンク切れチェックツールなど

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１０．リダイレクトされない旧「アーカイブ・ページ」のＵＲＬを、新「アーカイブ・ページ」のＵＲＬに一括変換

（２０１９年３月１日（金）加筆）
　旧「はてなダイアリー」の各記事のＵＲＬから新「はてなブログ」の各記事のＵＲＬへの遷移は、「はてな」社側にて自動で「リダイレクト遷移」をしてくれるので、記事中に過去日付の記事の旧ＵＲＬでリンクを貼っていたままで放置しても問題はなし。
　しかし、各記事中に手書きで記した、「アーカイブ・ページ」（全記事見出し一覧）の旧ＵＲＬや、カテゴリーごとの「アーカイブ・ページ」の旧ＵＲＬについては、リダイレクトされないことが発覚（汗）。
――厳密には、前者の　旧「全記事見出し一覧」　⇒　新「ブログ」トップページ　にリダイレクト。後者の　旧「カテゴリーごとの記事見出し一覧」　⇒　新「全記事見出し一覧」　にリダイレクト。いずれにしても、望ましい画面遷移のされ方ではない（汗）――

　こんなものは、新旧ＵＲＬの語句に法則性がある変更なのであるからして、リダイレクト設定しておくのはカンタンだったハズだろ！　「はてな」社側にて「アーカイブ・ページ」も旧ＵＲＬから新ＵＲＬへリダイレクトしてくれよ～。とダメ元でも、「はてな」の「お問い合わせ」フォームから要望してみようと思ったものの……。「待て、待て」。
　新「はてなブログ」登場が８年も前の震災の年の２０１１年。それから８年も経ていれば、ごくごく少数でも上記のような要望はすでになされていたハズ。しかも、対応はカンタンなハズ（？）。それでも実装がなされていないということは……。少なくともこの件についてだけは、「はてな」スタッフ諸氏にもヤル気がなかった……といったことなのか？（爆）

　てなワケで、「はてな」社には頼らずに、好事家の職人有志が、上記の目的を達成するような便利ツールを作成しているのではなかろうか？　とググってみたら……。「あった！　あった！！」（笑）。
　「はてなブログ」の全記事中の特定語句――各記事中に手書きしていた「ＵＲＬ」の記述も含む！――をひとつずつ、いちいち手書きで修正するのではなくって、複数記事にまたがる語句ではあっても、「変更前の語句」と「変更後の語句」を指定してあげれば、一括して変換・置換してくれるツールが！

　少なくとも、以下の３種の「はてなブログ」用の記事中の語句一括変換ツールがありました～。

１０－１．「はてなブログ一括置換ツール」

（紹介記事）
www.notitle-weblog.com
（実サイト）
https://spiderwebs.tokyo/customize-tool/replace-login.phpspiderwebs.tokyo

１０－２．「ReplaceEntryContent（はてなブログ用ツール）」

（紹介記事）
www.zbuffer3dp.com
（実サイト）
smdn.jp

（２０２５年５月後日付記）：
　２０２５年現在では、当該ツールが一番便利で、一括置換速度も圧倒的に早いのでオススメ！

　Ｗｉｎｄｏｗｓ自体が常備している「コマンドプロンプト」画面にて、以下のようなコマンドを実行して、一括置換をする。

ReplaceContentText.exe -id katoku99（自分のブログID） -blogid katoku99.hatenablog.com（自分のブログのドメイン） -apikey XXXXXXXXXX（自分のブログのASPキー。「設定」→「詳細設定」→「ASPキー」で確認可） -from "YYYYYYYYYY" -to "ZZZZZZZZZZ" -v

　上記ツールを使用するにあたっては、上記のサイトにも説明があるとおりで、事前に「ＭｉｃｒｏＳｏｆｔ．ＮＥＴ　８．０　ランチタイム」のおそらく「コンソールアプリ」版のインストールが必要！（……「９．０」にて実行すると、なぜか［８．０」版が見つかりませんといった旨のエラーになってしまうので注意！

　しかし……。「８．０」版にて実行したももの、途中で「ログインに失敗しました。（404 NotFound）」エラーが表示されて、止まってしまった（汗）。その原因は……。

　Ｗｉｎｄｏｗｓの「コマンド・プロンプト」画面にて、一括置換・専用コマンド（命令文）を手入力時に、「-blogid」オプションに、「はてなブログ」の自ブログの「ドメイン」を入力するのだが、そこに記載ミスがあったためであった（汗）。誤記：「https://katoku99.hatenablog.com」　→　正解：「katoku99.hatenablog.com」。つまり、「ＵＲＬ」を当該に転記するワケではなかった。先頭の「https://」を除いた部分を転記するのが正！　加えて、ＵＲＬからコピペした場合に、自動で付与されてしまう末尾の「／」も不要！

　および、一部記事（＝実は当該の記事それ自体！・爆）にて、「エラーにより中断しました」なるエラーメッセージが発生してしまって、一括置換処理がそこで中断になってしまった。長すぎる記事だからであろうか？（その記事については、一括変換もなされていなかった）

　当該の一括置換ツールはブログ記事の「下書き」版も置換対象だという説明ではあったのだが、念のために当該記事のみ「下書き」状態に戻して、再実行！　そうしたところ、今度は全ブログ記事の一括置換に成功した！　その後に当該記事も「公開」状態に戻すことにした……。

（さらなる後日付記：　２度目の一括変換でも、当該記事にてエラーが発生！　しかし、当該記事の一括変換はされてしまっていた。当該記事のみ、一括変換での前後の「例示」をしていたために、一括変換の対象にはしたくなかったので、その意味では変換したくはない記事の全文については、テキストファイルの形式にて全文バックアップを取っておいた方がイイ！）
　ただし、「コマンド・プロンプト」画面にて表示されている「実行ログ（記録）」の記載を参照してみても、どこが修正された箇所であったのかについては分かりにくい。「（変更あり）」の文言が出力されているのだが、それは必ずしも修正箇所そのものではない（汗）。特定の「記事」が終わった箇所と、次の「記事」との、「はざま」に「（変更あり）」とのメッセージが出力されていると、直上までの「記事」には修正箇所が発生していた……といった意味合いであるらしい……）

１０－３．「はてなブログライター」

ima.hatenablog.jp
――２０２５年５月の後日付記：　上記ツールについても、使用にあたっての前提条件が多くて、当方には困難であった（汗）。加えて、一括置換が可能であるのは、最大１００記事までであった（汗）――

　拙ブログ管理人である当方は、（２０１９年２月現在ではそのようにも思えていた）一番操作がカンタンである「１０－１」の「はてなブログ一括置換ツール」を用いて、語句やＵＲＬの一括変換（置換）を実施してみた――ただし、「はてな」側のサーバー負荷を軽減するために、全記事を一括変換できるツールではなくって、最新の記事からさかのぼって１００記事ずつを指定して一括変換するツールであるそうな……（２０２５年５月の後日付記：　「１０－１」と当該「１０－３」のツールは、制作者の方々にはまことに失礼ではありますけれども、個人的にはオススメではなくなりました～。「１０－２」側のツールをオススメいたします！）――。

　しかし、大は小を兼ねないことも往々にしてあるもので、「アーカイブ・ページ」（全記事見出し一覧）のＵＲＬを最初に一括置換にしてしまうと、カテゴリーごとの「アーカイブ・ページ」のＵＲＬの共通先頭部分と識別が付かなくなってしまって、のちのちの一括変換に支障が生じてしまうために、以下の順番にて、語句変換やＵＲＬ変換を実施しています。

（１）．カテゴリーごとのアーカイブ・ページの旧ＵＲＬ　⇒　カテゴリーごとのアーカイブ・ページの新ＵＲＬ
（例：『http://d.hatena.ne.jp/katoku99/archive?word=%2a%5b%a5%a6%a5%eb%a5%c8%a5%e9%5d』　⇒　『https://katoku99.hatenablog.com/archive/category/%E3%82%A6%E3%83%AB%E3%83%88%E3%83%A9』）

　「全カテゴリー」について、「１カテゴリー」ごとに上記の一括変換を実施。「全カテゴリー」について、共通の先頭語句である『http://d.hatena.ne.jp/katoku99/archive?word=』⇒『https://katoku99.hatenablog.com/archive/category/』についての一括変換はしてはイケナイし、しても無意味。
　その理由。旧「はてなダイアリー」と新「はてなブログ」では、「文字コード」が「Ｓ－ＪＩＳ」（エス・ジス）からその上位拡張版（？）でもある「ＵＴＦ－８」（ユーティーエフ・エイト）に変更になったようで（？）、「カテゴリー」名が新旧で同じであっても、ＵＲＬ上でのスペルは異なる英数字や記号になってしまうため……。
（これが理由で、「はてな」社側では「カテゴリー」ごとの「アーカイブ・ページ」をリダイレクトしてくれないのであろうか？　だとしても、「カテゴリー」なしの「全記事見出し一覧」はリダイレクトしてくれてもイイようにも思いはするものの・汗）

（２）．年月ごとのアーカイブ・ページの旧ＵＲＬ　⇒　年月ごとのアーカイブ・ページの新ＵＲＬ
（例１：『http://d.hatena.ne.jp/katoku99/archive/199712』　⇒　『https://katoku99.hatenablog.com/archive/1997/12』）
（例２：『http://d.hatena.ne.jp/katoku99/archive/1997』　⇒　『https://katoku99.hatenablog.com/archive/1997』）

　拙ブログでは、旧「はてなダイアリー」が開設される前の２０世紀～２１世紀初頭の「年月」単位の記事の「アーカイブ・ページ」を、特定の旧作品やシリーズの「全記事見出し一覧」としても使用しています。そして、各記事中でこの「年月」単位の旧「アーカイブ・ページ」のＵＲＬのリンクを貼っているので（まぁ、フツーの方はこんなアクロバティックなリンクの貼り方はしないでしょうけれども・汗）、コレも一括変換の対象とした。ただし、「年月」中の「月」は置換対象にはいちいち含まずに「年」までの語句に留めて、「年」の直後の末尾に「/」（スラッシュ）を付与して一括変換（置換）を実施する方が、１２ヵ月分＝１２回の置換を１回にて済ませることができるので、よりクレバー。
――厳密には、「年月」単位の旧「アーカイブ・ページ」のＵＲＬは、「年月」単位の新「アーカイブ・ページ」のＵＲＬへとリダイレクトされている。しかし、直下の（３）の分と同時に一括変換して、新ＵＲＬ規定の末尾「1997/12」ではなく「年」と「月」の間の「/」（スラッシュ）抜きの末尾「199712」で一括変換してしまうと、新「アーカイブ・ページ」にリダイレクトされても、「Ｎｏｔ　Ｆｏｕｎｄ　　お探しの記事は見つかりませんでした。」となってしまう支障が生じるために、先に当該の「年月」単位の「アーカイブ・ページ」のＵＲＬだけで一括変換（まぁ、工夫をこらせば、（３）のあとに変換してもイイのであろうけれど）。
　ちなみに、「年」単位の旧「アーカイブ・ページ」のＵＲＬは、「年月」単位のそれとは異なり、新「アーカイブ・ページ」のＵＲＬへとリダイレクトしてくれない（新ブログのトップページへ遷移する）。ナンでやねん！？（汗）――

（３）．全記事のアーカイブ・ページの旧ＵＲＬ　⇒　全記事のアーカイブ・ページの新ＵＲＬ
（例：『http://d.hatena.ne.jp/katoku99/archive/』　⇒　『https://katoku99.hatenablog.com/archive』）

　上記（１）（２）の変換後にはじめて、「年月」や「カテゴリー」や「特定の作品」や「特定のシリーズ」に限定されない、真の意味での「全記事見出し一覧」の旧ＵＲＬの記述を新ＵＲＬへと一括置換。

（４）．旧「はてなダイアリー」での検索窓「searchdiary」や、アーカイブ・ページでの検索窓「archive」での語句検索結果ＵＲＬ変換　
（例１：『http://d.hatena.ne.jp/katoku99/searchdiary?word=～』　⇒　新「はてなブログ」では検索結果の全記事「全文」を表示する機能自体がナイ（？）。（検索結果の全記事「一覧」ページはあり））
（例２：『http://d.hatena.ne.jp/katoku99/archive?word=～』　⇒　『https://katoku99.hatenablog.com/search?q=～』）

　前者の検索窓「searchdiary」での検索結果の全記事「全文」は、新ブログ側に該当ページがないために（？）、検索結果の全記事「一覧」のＵＲＬに代替させるのがイイと思われます。
　後者の旧アーカイブ・ページでの検索窓「archive」での検索結果は、「～」が検索語句に該当しますけれども、先にも述べた新旧ブログで「文字コード」が変更されている問題があるために、新ブログ側での該当語句での検索結果の画面のＵＲＬを、変換後のＵＲＬとして指定するのがイイでしょう。
　……コレらのＵＲＬを、記事中にリンクとして貼っていた御仁は極少だとは思われますけど（笑）。

　個人的には、一番操作がカンタンである「１０－１」の「はてなブログ一括置換ツール」をオススメするけど、拙ブログの場合、カテゴリー数が多かったために、単純計算では、

（１）．全３２「カテゴリー」数　×　８回（１００記事ずつの全・約７５０記事なので８回変換）　＝　　２５６回（汗）
（２）．４種の「年月」（「１９９７年１２月」と「２０００年１１月）ほか全４種ほどの「年月」）　×　８回（同上）　＝　３２回
（３）．８回（同上）
（４）．数回

と３００回前後、平日の帰宅後の深夜に数日間を要する変換作業を実施するハメに（汗）。そう考えると、「１０－２」の「ReplaceEntryContent（はてなブログ用ツール）」か「１０－３」の「はてなブログライター」を用いた方がよかったとも後悔……。

――２０２５年５月付記：　「１０－２」のツールの方をオススメいたします！　しかし、いずれのツールを使用するにしても、念のために事前に「はてなブログ」の全記事をバックアップしておくこと！　その方法は、「はてなブログ」側の「設定」⇒「詳細設定」⇒「エクスポート」⇒「記事のバックアップと製本サービス」⇒「〈ブログ名〉をエクスポートする」⇒「ダウンロード」。……各記事が長文で、１０００記事以上が存在するのだけれども、数分でダウンロードができてしまった！　ちなみに、「１０－２」のツールでの一括置換に要した時間は、１時間弱程度であった――

　あと、正しく一括変換されたか否かについては、最後に上記のツール群ではなく、新「はてなブログ」の「記事の管理」画面で、過去記事の「語句」検索機能を用いて、変換漏れ――変換前の語句やＵＲＬ――を探した方が、１００記事単位ではなく全記事単位での検索でもあるのでラクです。変換漏れが発見されれば、「はてなブログ」側なり各種の変換ツール側にて個々に再変換することを忘れずに～。
――原因は不明だけれども、当該ツールで一括変換しても、ごくごくマレに変換されない記事が発生することはアリ。まぁ、大過はナイので、最後に新「はてなブログ」の「記事の管理」画面で、過去記事の「語句」検索機能を用いて、変換されなかった記事については個々に手修正で変換すればよし！――

１０－４．これらのＵＲＬの一括置換ツールは、各記事に対してのみ有効で、サイドバーやヘッダーなどには無効であるので注意！

１１．「リンク切れ」チェック・ツール

（２０１９年３月２０日（木）加筆）
　旧「はてなダイアリー」から新「はてなブログ」への移行ついでに、記事中に貼っていた過去日付記事へのリンクＵＲＬが誤記になっていて、リンク先に実は記事が存在しないところがあれば、やはり今どきのことであるから、奇特な職人の方々が「リンク切れ」チェックツールを作成していて、ネット上にフリー（無料）で置いておいてくださるであろうと推測。
　それで、ググってみたところ……。やっぱり、あった、あった、ありました（笑）。
lonestar.hatenablog.com
hukugyouhoukoku.hatenablog.com
gotubo.hatenablog.jp
https://www.zakkiblog.net/entry/link-checkwww.zakkiblog.net

自動でリンク切れチェックし、Webサイトの品質を保つ便利ツール8選

2010年4月16日 9:00

• UX／CX
• Web担当者／仕事
• 解説／ノウハウ

webtan.impress.co.jp

１１－１．「リンクチェッカー（リンク切れチェックツール）dead-link-checker.com」

　で、操作がカンタンそうですので、上記のブログ群でも多く言及されていた、以下のサイトの「リンクチェッカー」（dead-link-checker）を使って、拙ブログ全記事に対して、過去記事へのＵＲＬの誤記ということにとどまらずに、外部リンクの「リンク切れ」も含めて確認をしてみました。
www.dead-link-checker.com

１１－２．「リンクチェッカー」使用時の注意点＆反省点

　上記のブログ群では数十分～数時間はかかると言及されていました。拙ブログでは、全記事数が約７５０記事で各々が比較的に長文でして、過去の日付記事へのリンクも各記事・各所で膨大に貼ってあったことから、通常以上に長時間を要するであろうと予想はしていたけれども……。
　実行してみると、２４時間かかっても終わらなかったのでありました～（爆）。１回目は１日半。２回目は１日強。そして、注意点や事前の準備が必要なことも判明。

１１－２－１．リンクチェック中に、別サイトを表示中だと、リンクチェック活動も休止

　しかも、インターネットのサイトを表示させるブラウザで、別の「タブ」を開いて、そこで他のサイトを表示させたままにしておくと、その間はリンクチェック活動も休止になってしまうという……――別「タブ」やウラ側でリンクチェックが進行することはない――。「リンクチェッカー」サイトに刻々と表示されつづけていくログ（記録）の時刻で、他サイト閲覧中は休止状態になっていることを判断可能。

１１－２－２．パソコンがスリープ状態になると、リンクチェック活動も休止

　パソコン自体が電電ＯＮでも、５分・１０分・１５分間、操作がないと、自動で電源ＯＦＦではなく、電源は落ちていないけど低電力消費モードであるスリープ状態となって、画面も真っ暗になってしまうが、その間もリンクチェックが休止してしまう。
　２４時間なり就寝中にチェックを実施する場合には、スリープ状態にならないように、設定を変更しておくこと。その方法は以下のサイトなどの通り。
www.tipsfound.com
――ついでに、今どきのパソコンは、「電源に接続時」と「バッテリー駆動時」の２種に分かれたスリープ設定があることも知る。そうか、だから当方宅のＰＣは電源コンセントを抜いて、持ち歩いてバッテリー駆動させていると５分でスリープ状態になってしまっていたのか……（汗）。ちなみに、「画面」（モニター・ディスプレイ）だけ規定時間が過ぎるとＯＦＦになる設定もあるものの、「画面」がブラックアウトするまでの時間の方を短くて、パソコンが「スリープ」状態になるまでの時間を長く設定しておけば、「画面」が先に真っ暗になってもパソコン自体は「スリープ状態」にはならずに活動中（リンクチェック中）にすることも可能――

１１－２－３．「はてなブックマーク」ボタンは、事前に一時的に「非表示」の設定にしておかないと、リンク切れ扱い

　ヨソさまの「はてなブログ」では、当該「リンクチェッカー」を使用したところで、自ブログ記事の「被・ブックマーク・ページ」が「リンク切れ」扱いとなってエラー表示されてしまった……とは聞かないので、拙ブログ特有の現象もしくは一時的な不具合現象やもしれないものの、拙ブログのおそらく個々の記事ごとの全「被・ブックマーク・ページ」が「リンク切れ」扱いとしてエラー表示されてしまったのであった――実際には「被・ブックマーク・ページ」自体は「４０４　Ｎｏｔ　Ｆｏｕｎｄ」にはならずに、実在はしているというのに！（たとえば、http://b.hatena.ne.jp/entry/https:/katoku99.hatenablog.com/entry/20181125/p1）――
　これによって、約「７５０」記事ある拙ブログの「リンク切れ」エラーの数は「８１１」個にも登ってしまった（爆）。

　試しに、「はてなブログ」画面の右上方の「自分のはてなＩＤ」⇒「デザイン」⇒「ＰＣ（スパナのマーク・カスタマイズ）」⇒「記事」で、ブログ記事中に表示させる「ツイートボタン」や「Ｆａｃｅｂｏｏｋ『シェア』ボタン」などの「ソーシャルパーツ」欄から、「はてなブックマークボタン」欄の「レ」点を取り除いて、同ボタンを非表示設定にしてから、「リンクチェッカー」を再実行してみたところで、エラーの数は「４１」個に激減！
　というワケで、当該「リンクチェッカー」を実施する前には、「はてなブログ」の記事中に表示させる「はてなブックマークボタン」は一時的にでも「非表示」に設定しておいた方がイイとも思われる。

１１－２－４．その他

　上記の「被・ブックマーク・ページ」がエラー扱いとなる問題は解消したが、「はてなブックマークボタン」経由ではなく、意図的に表示させている「はてなブックマークページ」（http://b.hatena.ne.jp/entrylist?url=https%3A%2F%2Fkatoku99.hatenablog.com%2F&sort=count）については、実在するのに「リンク切れ」扱いとしてエラーになってしまう！　コレも実際にはエラーではないので無視してもよかった！

　その他、旧「はてなダイアリー」や新「はてなブログ」でデフォルトの、記事中の語句に自動でリンクが貼られた先の「はてなキーワード」や「はてなキーワード」の「アマゾン商品ページ」に対しても、リンクチェックしてくれているのはイイけれども、実在するコレらの「はてなキーワード」ページでもマレに「リンク切れ」扱いとしてエラーになってしまう。
　いずれにせよ、「はてなキーワード」ページで「リンク切れ」エラーとなっていたものも、実際には実在するページであるので、エラー表示は無視してもイイ！

　このへんはナンなのでであろうか？　表示されるまでのアクセス速度がやや遅かったりするので、それを「リンク切れ」扱いと判定してしまって、エラー表示としているのであろうか？
　ただ、特に大きな支障ではなく、そこまでもの万能性を各種ツールに対して求める気もないので、目視にて全記事の「リンク切れ」検査などはできない以上は、当該ツールを開発した職人さんには感謝を捧げたい（笑）。

　なお、拙ブログでは、各記事中に過去記事への膨大なリンクを貼ってはいるものの、手前ミソで恐縮だけれども、誤記による「リンク切れ」はほぼナシ！――厳密には２件ほど誤記が発覚して、それについては手修正を完了。まぁ、「リンク切れ」ならぬ「リンク先・間違い」については、自動・機械ツールではチェックのしようがないので、そのへんについては不明ではあるものの（汗）――。
　ただし、マレに貼ってある外部サイトへのリンクについては、趣味系・オタク系商業サイトであれば閉鎖がされていたり、秋葉原ラジオ会館にあった輸入ＤＶＤ専門店がすでに閉店になっていたり、「ｓｏ－ｎｅｔ」や「ｂｉｇｌｏｂｅ」や「ｎｉｆｔｙ」や弱小電子書籍のサイトがなくなっていたりで、諸行無常の響きあり。ヨソさまの９０年代中盤にて子供時代を送ったとおぼしきブログにリンクした先がプライベートモードで実質、閉鎖になっていたものの、その引っ越し先サイトでは現在、商業ライターとして活躍中！　というモノもあったりして……隔世の感。

　いずれについても、「リンク」ＵＲＬの抹消はせずに、「リンク」の直後に「（２０１９年現在、リンク切れ）」の文言を追加することにて対応。好事家の方はご存じ、インターネットの草創期から、全世界の全サイトを記録・収集している「インターネット・アーカイブ」（http://warp.da.ndl.go.jp/contents/reccommend/world_wa/world_wa02.html）（https://archive.org/）というモノがあって――完璧には収集しきれていないようではありますけど、オプションに「Search archived web sites」を指定すれば検索可――、そこでＵＲＬを指定して、遷移した先の次画面で「年月日」も指定すると、消滅してしまったハズの過去記事が読めることもありますので――拙ブログの旧「はてなダイアリー」時代のＵＲＬ（http://d.hatena.ne.jp/katoku99/）もそこにて参照可（汗）――、万々が一のための歴史記録的な便宜として「リンク切れ」のＵＲＬそれ自体も残してみた次第。ＳＥＯ（サーチ・エンジン・対策）的にイイとか悪いとかは、この場合は二の次です（笑）。

１１－３．「W3C Link Checker」（２０２５年現在、当該がオススメ！）

（２０２５年８月２日（土）後日付記）
　２０２５年現在では、当該がオススメです。リンク切れチェック（404）のみならず、リダイレクトの有無（301・302など）なども、超高速でチェックしてくれます。10～20分程度で拙ブログの全体のチェックが完了。ついでに、「ＨＴＭＬ」や「ＣＳＳ」の文法間違いまで探してくれます！
W3C Link Checker

　以上となりま～す。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」（サーチ・エンジン・最適化）対策

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１２．２０２２年６月２３日（木）後日付記：当該ブログ・デザインの「スマホ」表示画面での「ＳＥＯ」（サーチ・エンジン・最適化）に関わる問題が、「Google サーチコンソール」にて発覚！

（……いやまぁ、当該デザインにおいても、「スマホ」画面の場合には、「グローバルメニューを非表示化」「サイドバーも非表示化」「文字も少々大きめ化」……といった処置は可能なのやもしれませんけど、とりあえず……）

→：２０２２年、「スマホ」だと「グローバルメニュー」の「文字」が小さすぎであったため！　よって、「スマホ」での「パソコン」とも同じ画面での表示はやめた！

→：２０２５年５月３１日（土）現在、「グローバルメニュー」の「文字」が小さすぎでも、グーグル検索の判定においては致命的ではなくなった模様（それよりも表示スピードの方が優先される）。よって、「Hatena for はてなブログ」から「classic diary（日記向け）」へとブログ・デザインを変更したのに伴ない、「スマホ」における「パソコン」とも同じ画面での表示を復活させた！

「貴サイトが 3 件の モバイル ユーザビリティ の問題に影響を受けていることが検出されました」

●テキストが小さすぎて読めません

●クリック可能な要素同士が近すぎます

●ビューポートが設定されていません

（２０２２年における、上記のメッセージ表示の数日後に、「モバイル ユーザビリティ」で「コンテンツの幅が画面の幅を超えています」というメッセージも到着した・汗）

　当該デザイン「Hatena for はてなブログ」（＝２０２５年５月３１日以前に使用していたデザイン・汗）に、２０１９年に変更してから３年後の２０２２年（汗）に、改めて「Google サーチコンソール」というモノで、拙ブログのトップページのＵＲＬをGoogleのインデックスに登録してみたところで――もちろん、Google側にて自動的にすでにインデックスには登録済ではあったものの――、上記のメッセージとともに、

「上記の問題をできる限り解決されることをおすすめします。問題を解決することで、サイトのエクスペリエンスや Google 検索結果での表示を最適化できます」

といった検証結果が表示されてしまうことが発覚！――「Google サーチコンソール」の「URL検査」の「公開URLをテスト」だと、上記の問題はナシだと表示されるのだけれども、数時間～半日後にはメールで「貴サイトが 3 件の モバイル ユーザビリティ の問題に影響を受けていることが検出されました」といった旨のエラーメッセージが送信されてくるので、「公開URLをテスト」の方はアテにはならない模様である（汗）――

　つまり、当該「Hatena for はてなブログ」（＝２０２５年５月３１日以前に使用していたデザイン・汗）を、モバイル（スマホ）媒体においても、ＰＣと同じ画面表示をさせてしまっていた場合においては、

①テキストが小さすぎる　（「本文」の箇所か？　←：スマホ画面での「グローバル・メニュー」の文字（テキスト）のことかも？）
②クリック可能な要素同士が近すぎます　（スマホ画面での「ドロップダウンする画面上部固定グローバル・メニュー」のことか？　←：そのとおり！）
③ビューポートが設定されていません　（「ＣＳＳ」側にて設定する定義のことらしい。←：「ＨＴＭＬ」での設定のことでした～）
④コンテンツの幅が画面の幅を超えています　（「③」の派生事項であろうか？　←：不明。ブログ全体ではなく、特定の記事の画像のヨコ幅に問題があった？）

上記の４点で問題が発生してしまうのであった（汗）。

　ダミーで拙ブログと同じデザインのブログを作成して――記事については当該記事をコピペした１記事のみとし、サイドバーは初期設定で表示されるもののみとする――、それに対して、以下の変更＆テストを実施して、この問題が解消されるか否かについての検証を実施してみる予定である。

①については、『「５－１」ＣＳＳ（未設置）』にて記述した、設置してしまうとＰＣでの画面と同じ表示になるように設定しておいたスマホの画面においては、本文の文字が小さめになるとも感じていた、以下の未設置であったＣＳＳを、そこに設置してみせることで解消されるのか否かを確認。
　設置後に、「①を解消したので再チェック」または「再リクエスト」の旨のボタンをクリックしたところで、「検証には数日かかることがございます。処理が完了し次第お知らせいたします。以下のリンクにアクセスして、テストの進捗状況をご確認いただくこともできます」との文言が表示されるのであった。実際には翌朝には、件名『「モバイル ユーザビリティ」の問題が修正されました』のメールが到着！
　つまり、「①」さえ解決すれば、「②」と「③」の問題が残っていても『「モバイル ユーザビリティ」の問題が修正されました』になってしまうといったことなのであろうか？

（後日付記：　『「モバイル ユーザビリティ」の問題が修正されました』の旨のメールが到着していても、実際にはこの問題は解決していなかった！（汗）……　ナンでやねん！？　当該の原因は、「スマホ」の画面においても「パソコン」とも同様に「グローバル・メニュー」と「固定グローバル・メニュー」における小さな「字」を表示させていたことにあったのであった！　しかし、当該「Hatena for はてなブログ」（＝２０２５年５月３１日以前に使用していたデザイン・汗）を、「はてなブログ」一般における「スマホ」専用画面（＝トップページなどは、「最新７記事」の「見出し」のみが「一覧表示」される形式のもの）で表示させてあげると、「①」と「②」の問題は解決したのであった……）

　一応は、以下の「ＣＳＳ」設置にて解決されることは判明した。ひょっとすると、これによって、同時に「②」と「③」も解決されたのやもしれない。（後日付記：　「①」～「③」まで、実は以下の施策においても、解決されない！）

　しかし、「①」については、やはり拙ブログをスマホ画面にて表示させてあげると――ＰＣ上でも各種のブラウザ、たとえば「Ｃｈｒｏｍｅ」の画面にて右クリックの「検証」⇒白い二重四角型の「スマホ」型のアイコン選択などでも、「スマホ」での表示イメージ画面を表示可能！――、サイドバーの幅が極端に大きくて全幅の半分以上を占めてしまって、本文の幅の方が狭くなってしまうという（汗）、あまりに論外の読みにくいデザインとなって表示されてしまうのであった。……よって、以下の「ＣＳＳ」の設置はやはり却下！
/*==============================================
「はてなブログ」用「レスポンシブ対応」宣言
================================================*/
/* Responsive: yes */

「②」についても、ダミーの同デザインのブログから「ドロップダウンする画面上部固定グローバル・メニュー」を削除してみて、解決されるか否かを確認してみる予定である。

――２０２２年６月の後日付記：　スマホでの表示画面においても、ＰＣでの表示画面とも同様に、「グローバル・メニュー」と「固定グローバル・メニュー」を表示させていた場合には、これらの「グローバル・メニュー」を削除することで、スマホ側での問題は解決することが判明。……しかし！　ＰＣ側ではこれらの「グローバル・メニュー」は残しておいて、スマホ側のみ「はてなブログ」一般用のスマホ専用画面にて表示させる設定に変更してあげるかたちで、この問題を解決させています――

――２０２５年５月の後日付記：　「Hatena for はてなブログ」から「classic diary（日記向け）」へとブログ・デザインを変更したのに伴ない、スマホでの表示画面においても、ＰＣでの表示画面とも同様に、「グローバル・メニュー」と「固定グローバル・メニュー」を表示させる方式に復活させております――

「③」については、各サイトにおける同様トラブルでの対策記事を参考に、「はてなブログ」側の「設定」⇒「詳細設定」⇒「head内タグ」⇒「要素にメタデータを追加」欄に対して、

<meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0">

上記を記述することで解消されるとの記述を発見！　……しかし、この処置を施してみたあとでスマホ画面で表示させてみると、「①」での「レスポンシブ対応宣言」の「ＣＳＳ」設置で生じてしまった現象とも同様の、サイドバーの幅が極端に大きくて全幅の半分以上を占めてしまって、本文の幅の方が狭くなってしまうという（汗）、あまりに論外の読みにくいデザインとして表示されてしまう現象が再発。……よって、「ビューポート」設定もやはり却下！

　結果については、おいおい備忘録的に加筆していきます～（汗）。

――２０２５年５月の後日付記１　：「Hatena for はてなブログ」（＝２０２５年５月３１日以前に使用していたデザイン・汗）においては、スマホ側の画面でも「はてなブログ」用のスマホ専用画面の形式にて表示させる設定をしてあげたうえで（＝「５．」における、「レスポンシブ対応」設定を、「レ」点のオンならぬオフにすること！）、上記の「～"viewport"～」を記述してあげれば、この問題も解決いたしました！――

――２０２５年５月の後日付記２：　２０２５年現在では、上記については、重要指標になってはいないのやもしれない……（そもそも、「Google サーチコントロール」に「モバイル ユーザビリティ」の指標なり、そのチェックそれ自体が今では存在していない？）　２０２５年現在では、グーグルの「Page Speed Insights」での計測における「ユーザー補助」指標（＝実質、視覚障害者のための便宜の指標）における「タップ ターゲットのサイズや間隔は十分な大きさではありません。」項目の成績には該当してはくるものの……。表示スピード関係の「パフォーマンス」指標などに比すれば、重要ではない要素になっているとも推測――

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　「ＣＬＳ」（レイアウト・シフト）の減少

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１３．後日付記：「Google」側にて「被リンク数」だけでなく、「ＣＬＳ」（Cumulative Layout Shift）、つまり「レイアウト・シフト」が少ないことも、良質サイトの基準に求められたことでの対策

（２０２５年５月１５日（木）加筆）

１３－１．「ＣＬＳ」対策１：「ブログ」のサイドバーなどには、その特に最上部には、「ツイッター」の吹き出し（タイムライン）画面などは連動表示をさせない！（表示に時間がかかって、「レイアウト・シフト」も発生して、「CLS」の点数も悪くなるため）

１３－２．「ＣＬＳ」対策の結果：「パソコン」「スマホ」ともどもに、グーグルの「Page Speed Insights」での計測では、レイアウト・シフトが０．１以下である「緑」（90点以上）にできた（……そもそも、もとから０．１以下であったやも）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　「ＬＣＰ」（最大の画像orテキストなどのコンテンツ・描画所要時間）の減少

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１４．後日付記：「Google」側にて「被リンク数」だけでなく、「ＬＣＰ」（Largest Contentful Paint）、つまり「ブログのトップや各記事ごとの、『大きな画像』『テキストブロック』『動画』に対するレンダリング（描画・びょうが）に要する時間」が少ないことも、良質サイトの基準に求められたことでの対策

（２０２５年５月１５日（木）加筆）

１４－１．「ＬＣＰ」対策１：世間一般的には、大きな画像については、サイズを縮小したり、圧縮したり、画質も劣化させて、掲載し直す

　「はてなブログ」でのその方法は、ネットの各所にて有識者が発表済。そちらを参考のこと！　ただし、拙ブログ管理人は、写真の類いはほとんどアップロードはしていなかったものの（汗）。

１４－２．「ＬＣＰ」対策２：アマゾンの商品の写真を、「はてなブログ」の「はてな記法」での「ASIN表記」にて、各ブログ記事の参考画像として表示させている。そして、「Page Speed Insights」の「パソコン」側での「ＬＣＰ」指標の『「最大コンテンツの描画」要素』項目では、このアマゾン商品画像が、描画に時間がかかる対象にはなっていない。「スマホ」側での「ＬＣＰ」指標においても、描画に時間がかかる対象にはなっていない。しかし、「オフスクリーン画像の遅延読み込み」および「適切なサイズの画像」項目の対象にはなっていた！

　ちなみに、「適切なサイズの画像」とは、「ファイルのサイズ」ではなく「縦横の画像のサイズのこと」だそうだ。

　ちなみに、通信販売のアマゾンの商品の写真を最大表示にしても、小さく表示させても、「最大」と「小さく」を双方同時に表示させても、サイズは同じで１件の画像だとも判定されている。とはいえ、アマゾンの商品の最大化された方の写真は、各記事のサムネイル画像やツイッターでの記事告知のピンボケにはならない写真にも自動転用できるものなので、完全廃止にはしたくない。しかし、複数のアマゾン商品画像が存在すると、記事のサイズは大きくなってしまう。よって、アマゾンの商品の写真は、複数ではなく単数もしくは少数にとどめた方がよい？（写真ナシの単なるリンクについては無問題）　……これらアマゾンの商品画像については、後述する「ＦＣＰ」対策側において記載する。

１４－３．「ＬＣＰ」対策３：「パソコン」側においては、「スマホ」側においても、「アマゾン商品の画像」は大丈夫であった（各記事の先頭に表示しているワケではないからか？）。しかし、「スマホ」側では、常にどの記事においても、「テキストブロック」、つまり単なる長めで太字の「記事それ自体のタイトル」や、各記事の最上部などに設置した過去記事などへの青く反転した「リンク」部分の「長めの語句」に対しては、「ＬＣＰ」指標で問題視されている

　『「最大コンテンツの描画」要素』なるチェック項目にて、やたらとレンダリング（描画）に時間を要しているのであった。ただの「記事そのもののタイトル」や「リンク」でしかないのに～（汗）。ちなみに、レンダリングに要する時間は、同一記事ではあっても測定ごとにランダムで、数秒～１０数秒と都度都度で大きくバラつきが発生している

――２０２５年７月１２日（土）後日付記：　『「最大コンテンツの描画」要素』なる指標が、２０２５年６月下旬から急に消えてしまった模様。「Page Speed Insights」に併設された掲示板の類いを見てみても、この指標は評判が悪かったようなので（汗）、廃止されてしまったのでは？　とも憶測……。２０２５年８月３日（日）後日付記：　「LCP breakdown」（＝「LCP の内訳」）名義の指標に変えて残存していたことを確認。しかし、一律に「〇」（エラーなし）にされている。ところが……。Ｇｏｏｇｌｅのブラウザ「Ｃｈｒｏｍｅ」側の「拡張機能」での「Page Speed Insights」と同等の機能でもある「lighthouse」側では、旧来の「最大コンテンツの描画」要素がまだ残存していたものの。２０２５年９月２７日（土）後日付記：　「lighthouse」側でも、旧来の「最大コンテンツの描画」要素がなくなって「LCP breakdown」（＝「LCP の内訳」）名義の指標に変更された模様。どころか、「lighthouse」側を機動させると、「Page Speed Insights」と同一ＵＲＬの画面が表示されるようになった模様――

――２０２５年１０月１８日（土）後日付記：　１０月１７日（金）夜間から、「Page Speed Insights」の計測結果の表示方法がビミョーに変更されている。パソコンで計測して表示させる分には従来どおりである。しかし、タブレットとスマホで計測して表示させる分だと、「パフォーマンス」指標が「インサイト」と「診断」に上下分割されずに混合されていた２０２５年の５～６月以前の表示方法に戻ってしまっている模様である。しかも、タブレットとスマホで計測して表示させている分だと、スマホ側のラボデータ側の「ＬＣＰ」指標内における「最大コンテンツの描画」の意味だとも思われる「Largest Conentful Paint element」が「赤」にて表示されてくる！　どういうこと？　ウ～ム。指標としては廃止、あるいは一時的に停止されたが、復活になった、あるいは復活予定、もしくは間違って復活してしまった、といったことなのか？　とはいえ、拙ブログにおいては、その内訳実態は「テキストブロック」でもあるので、後述する理由で無視をしても支障はないのでもあった。「パフォーマンス」指標の点数にも、特に悪化したなどの変化は見られなかった（ヨソさまのブログも計測してみると、パソコン側でも「インサイト」と「診断」に上下分割されずに混合されている（汗）。１０月２１日付記：　同日夜間から、世間さまのブログやサイトを測定してみても、７月以降の「インサイト」と「診断」に上下分割しての表記に無事に戻っていた――

１４－３－１．「Page Speed Insights」の「ＬＣＰ」の『「最大コンテンツの描画」要素』項目をクリックすると、たしかに「レンダリング遅延」が原因とあった。しかし、「記事それ自体のタイトル」などは修正・対処も不可能！　この問題の解消はムリかと思いきや……。有識者による「レンダリング遅延」の解消方法を一応は発見（汗）

sorokatu.com

――２０２５年７月１３日（日）後日付記：　上記のサイトさまにはご感謝を申し上げつつも、後出しジャンケンで不正確な箇所も一点あるやもしれません。「Ｊａｖａスクリプト」の「遅延読み込み」には、「Ｓｃｒｉｐｔ」の「後読み」（遅延読み込み）（＝ｄｅｆｅｒ）指定が可能。しかし、「デザインＣＳＳ」については、「Ｊａｖａスクリプト」ではないので、「Ｓｃｒｉｐｔ」の「後読み」（遅延読み込み）（＝ｄｅｆｅｒ）指定は無効であるようです（汗）。「デザインＣＳＳ」の「後読み？」（遅延読み込み？）については、「rel="preload" 指定にて、onloadイベントで、 rel="stylesheet" に変更する」といった手法であったようです。「２５．『デザインＣＳＳ』『Ｊａｖａスクリプト』『各種サイト』の遅延or先読み込み」の項目の方の説明を参照のこと！――

　当該デザインテーマにおいては、「はてなブログ」側の「設定」⇒「詳細設定」⇒「head内タグ」⇒「要素にメタデータを追加」欄に対して、

<link rel="preload" href="https://cdn.blog.st-hatena.com/css/blog.css?version=38caf1a85fdfdc17ce7f4fdc07ae02" as="style" onload="this.onload=null;this.rel='stylesheet'">
<link rel="preload" href="https://usercss.blog.st-hatena.com/blog_style/98012380855795339/6733c135bfec664cc1b6e42f9d7aa3f2c27b55a8" as="style" onload="this.onload=null;this.rel='stylesheet'">
<meta name="viewport" content="width=device-width, initial-scale=1.0">

上記を記述することで……、特に有意な差（改善）は見受けられず……（汗）（一番下の「行」の「～"viewport"～」については、先に追加済であった分の記載。こちらは上書きせずに残しておくこと！）。
　「レンダリングを妨げるリソースの除外」として、おそらく当該デザインにて使用されている（？）、あるいは「はてなブログ」一般にて使用されている（？）、上記の２種の「リソース」を、「除外」ならぬ「後読み」（遅延読み込み）実行させるといった意味での方策である。
　「後読み実行」ではなく、また別の記載による「先読み実行」でも実験してはみたものの、そちらだと「スマホ」ならぬ「パソコン」側での表示画面の幅がナゼだか狭くなってしまったので不可！　加えて「スマホ」側でも、「ＬＣＰ」指標に特に改善点なども見受けられなかったような……。

（上記の記述を追加しても削除しても、太字の「記事そのもののタイトル」や、各記事の最上部などに設置した過去記事などへの青く反転した「リンク」部分の語句が、「ＬＣＰ」で２．５秒超過～１０秒前後になって引っかかったり、２．５秒以下になって「緑」（90点以上）になったりと、挙動も一定しない。「スマホ」側での「画像」ならぬ「タイトル見出し」や「リンク」部分についての「ＬＣＰ」については、もうこれ以上の改善はムリかも？・汗）

――２０２５年５月２１日（水）後日付記：　「レンダリングを妨げるリソースの除外」として、上記２種のＵＲＬを指定したものの、後日にあらためて「レンダリングを妨げるリソース」の値を参照してみたところで、ＵＲＬの末尾の方の値が変わってしまっていた！（笑）　これでは、「除外」設定ができないではないか（汗）。フル・パスではない形式での途中までの値での「ＵＲＬ」を指定するようなかたちでの、除外指定などは可能なのであろうか？　→　「ＵＲＬ」の途中までの共通の値よりもあとに、いわゆるワイルドカード「*」を付与して設定してみたが、このかたちでの除外設定も有効にはならなかった（汗）――

――２０２５年７月６日（日）後日付記：　「レンダリングを妨げるリソースの除外」として、現時点での最終的（？）には、「２５．『デザインＣＳＳ』『Ｊａｖａスクリプト』『各種サイト』の遅延or先読み込み」の項目にて記載したように設定しております。そちらの方を参照してくださいませ。　２０２５年８月２７日（水）後日付記：　ただし、「はてなブログ」においては、「レンダリングを妨げる『デザインＣＳＳ』」については、遅延or先読み込みであろうが、あまたの実験の末に解決はできないものと見ております。ここが解決できている「はてなブログ」も世間一般的に存在しない模様です（笑）――

１４－４．「ＬＣＰ」対策４：常にではないが、「パソコン」側にて表示されるブログ画面での「サイドバー」上に、スクロールなしでも表示されてしまう初期画面の上部のモジュールにて、「黒字」ではなく「色付きの文字」の語句で、そのモジュール名なりテキスト語句などを表示させてしまうと、その色塗りの「描画」に時間を要してしまうようであり、「ＬＣＰ」にて引っかかることが、常にではないがマレにはあった。および、各記事のアイキャッチ画像も表示させた「最新記事」モジュールを画面上部に配置していた場合でも、同様の現象は生じたことがあった

　何らかの修正をしてもよいのだが、常に引っかかるワケでもないのであれば（１０回に１回ほども引っかからないのであれば）、放置してもよいと思う！

１４－５．「ＬＣＰ」対策の結果：「パソコン」画面側では、「Page Speed Insights」での計測でも「緑」（90点以上）にできた（……そもそも、もとから「緑」であったやも）。しかし、以上の施策をもってしても、「スマホ」画面の側では、同一記事ではあっても、「画像」ならぬ「テキストブロック」こと「記事それ自体のタイトル」の描画にて、２．５秒超過～１０秒前後になってしまって引っかかったり、２．５秒以下になって「緑」（90点以上）になったりと、挙動が一定しない（汗）

――２０２５年７月１２日（土）後日付記：　先にも言及したが、『「最大コンテンツの描画」要素』なる指標が、２０２５年６月下旬から急に消えてしまった模様。「Page Speed Insights」に併設された掲示板の類いを見てみても、この指標は評判が悪かったようなので（汗）、廃止されてしまったのでは？　とも憶測……。２０２５年８月３日（日）後日付記：　「LCP breakdown」（＝「LCP の内訳」）名義の指標に変えて残存していたことを確認。しかし、一律に「〇」（エラーなし）にされている。ところが……。Ｇｏｏｇｌｅのブラウザ「Ｃｈｒｏｍｅ」側の「拡張機能」での「Page Speed Insights」と同等の機能でもある「lighthouse」側では、旧来の「最大コンテンツの描画」要素がまだ残存していたものの。２０２５年９月２７日（土）後日付記：　「lighthouse」側でも、旧来の「最大コンテンツの描画」要素がなくなって「LCP breakdown」（＝「LCP の内訳」）名義の指標に変更された模様。どころか、「lighthouse」側を機動させると、「Page Speed Insights」と同一ＵＲＬの画面が表示されるようになった模様――

――２０２５年１０月１８日（土）後日付記：　１０月１７日（金）夜間から、「Page Speed Insights」の計測結果の表示方法がビミョーに変更されている。パソコンで計測して表示させる分には従来どおりである。しかし、タブレットとスマホで計測して表示させる分だと、「パフォーマンス」指標が「インサイト」と「診断」に上下分割されずに混合されていた２０２５年の５～６月以前の表示方法に戻ってしまっている模様である。しかも、タブレットとスマホで計測して表示させている分だと、スマホ側のラボデータ側の「ＬＣＰ」指標内における「最大コンテンツの描画」の意味だとも思われる「Largest Conentful Paint element」が「赤」にて表示されてくる！　どういうこと？　ウ～ム。指標としては廃止、あるいは一時的に停止されたが、復活になった、あるいは復活予定、もしくは間違って復活してしまった、といったことなのか？　とはいえ、拙ブログにおいては、その内訳実態は「テキストブロック」でもあるので、後述する理由で無視をしても支障はないのでもあった。「パフォーマンス」指標の点数にも、特に悪化したなどの変化は見られなかった（ヨソさまのブログも計測してみると、パソコン側でも「インサイト」と「診断」に上下分割されずに混合されている（汗）。１０月２１日付記：　同日夜間から、世間さまのブログやサイトを測定してみても、７月以降の「インサイト」と「診断」に上下分割しての表記に無事に戻っていた――

１４－５－１．「Page Speed Insights」の下半分側の「ＬＣＰ」と上半分側の「ＬＣＰ」、および「Google サーチコンソール」の「ＬＣＰ」の３者のあいだでも、「ＬＣＰ」の数値（秒数）が異なっていた！

――Page Speed Insights」の上半分側には各種指標が何も表示されない場合もある（＝「データがありません」と評意された場合）。その理由は、そのサイトやブログはアクセスの絶対数が少ないので、フィールドデータとしての「ＬＣＰ」「ＦＣＰ」「ＣＬＳ」の有意なデータも存在していないから、といった意味になる（汗）――

　「Page Speed Insights」の上半分側と「Google サーチコンソール」の方が秒数は大きい！　ラボデータ側では「緑」（90点以上）なのに、この２者は「オレンジ」（90点未満）になっている！　この２者の「ＬＣＰ」については、28日間平均での「フィールドデータ」であるとのこと（＝実際にユーザーが使用している環境でのデータ。グーグルのブラウザ「Ｃｈｒｏｍｅ」を使用する全ユーザーから集めた値の平均値）。ちなみに、「Page Speed Insights」の下半分側の「ＬＣＰ」については、「ラボデータ」なのだそうで、ラボラトリー（実験室・研究所）の意味のラボであろうから、論理的な計測データ、シミュレーション・データといった意味であろう――そのワリには実行するたびに結果が大きく異なるものの……（笑）。ググってみると、「はてな無料ブログ」側では毎回、重さなどが異なる「広告」を自動挿入してくるので、それが主として「ＴＢＴ」や「ＴＴＦＢ」に影響して、まわりまわって「ＦＣＰ」「ＬＣＰ」などの「パフォーマンス」指標に影響しているのでは？　といった説もあった。および、ラボデータ側については、通信回線が低速かつ貧弱な性能での端末を前提とした、キビしめの数値になるらしい（汗）――。

（以下、２０２５年８月１３日（水）加筆）
　以下の正規の注釈を読むと、フィールドデータ側の「ＬＣＰ」の秒数の方が小さくなるのは、さもありなんではあった。

「フィールドの LCP は、ページへのすべてのユーザー アクセスの 75 パーセンタイルとして計算されるため、そのユーザーの大部分で LCP 要素が非常に速く読み込まれた場合（システム フォントでレンダリングされたテキストの段落など）、一部のユーザーで LCP 要素として読み込みに時間がかかる大きな画像があっても、そのユーザーが 25% 未満であれば、そのページのスコアに影響しない可能性があります」

「ラボでは、ページが完全に読み込まれるまでブラウザが待機し、LCP 要素を特定します。ただし、実際のブラウザでは、ユーザーがページをスクロールまたは操作すると、サイズの大きい要素のモニタリングが停止します。
　これは、ユーザーは通常、ページが読み込まれた「ように見える」まで待ってから操作を開始するため、LCP 指標が検出しようとしているのはまさにそのことです。また、ユーザーの操作後にビューポートに追加された要素を考慮することも意味がありません。これらの要素は、ユーザーの操作が原因で読み込まれただけである可能性があります。
　ただし、ページのフィールド データでは、そのページでのユーザーの行動に応じて、LCP 時間が短く報告される可能性があります」
web.dev

（以下、２０２５年１１月１５日（土）加筆）
　「Page Speed Insights」の下半分側の「ＬＣＰ」と上半分側の「ＬＣＰ」、および「Google サーチコンソール」の「ＬＣＰ」の３者のあいだでも、「ＬＣＰ」の数値（秒数）が異なっていたことの原理についての調査結果や仮説・推測については、後述の「２９．後日付記：２０２５年１０月時点での整理」における「●２０２５年１０月２５日（土）に、サイドバーを３１個から１９個に減少」の項目を参照のこと！

１４－６．「ＬＣＰ」対策その他：ＧｏｏｇｌｅさまがＳＥＯで重視する「Ｃｏｒｅ　Ｗｅｂ　Ｖｉｔａｌ（コア・ウェブ・バイタル）」においては、「Page Speed Insights」の下半分側の「ラボデータ」側ではなく、上半分側の「フィールドデータ」側の「ＬＣＰ」を参照するとのこと

（２０２５年８月７日（木）加筆）

　ということは、「Page Speed Insights」の下半分側の「ラボデータ」側の「ＬＣＰ」については、「最大コンテンツの描画」指標でエラー（「赤」＝50点未満）になっていたとしても、それが「画像」ではなく、「テキスト」のブロック（＝各記事の「見出し」や、ファーストページ（トップページ）中の「一段落」）なのであれば、無視をしてしまってもよいとも思われる。
　理由としては、グーグルの「検索順位」に影響するとされる「Ｃｏｒｅ　Ｗｅｂ　Ｖｉｔａｌ（コア・ウェブ・バイタル）」においては、「Page Speed Insights」の下半分側の「ラボデータ」側ではなく、上半分側の「フィールドデータ」側の「ＬＣＰ」を参照しているためである。しかも、「はてなブログ」一般においては、上半分側の「フィールドデータ」側の「ＬＣＰ」の方の数値（秒数）については少なくて、「緑」（90点以降）にもなっている。下半分側の「ラボデータ」側の「ＬＣＰ」の方の数値については、「ラボ」（研究室）のデータだとはいったものの、同一記事ではあっても他の要素（＝「はてなブログ」側で自動で挿入してくる広告の都度都度での種類の相違による軽重？）に影響されてか、計測の度に大きな変動があって、概して悪い数値（「赤」＝50点未満）になってしまうことが多いためでもある。および、ラボデータ側については、通信回線が低速かつ貧弱な性能での端末を前提としており、概してキビしめの数値になるらしい。

　とにかく、「最大コンテンツの描画」指標のエラーの原因が、「テキスト」のブロック（＝各記事の「見出し」や、ファーストページ（トップページ）中の「一段落」）なのであったのであれば、無視することにする！　これは「Page Speed Insights」の上半分側の「フィールドデータ」側の「ＬＣＰ」には影響していない！　よって、「フィールドデータ」側の「ＬＣＰ」の改善については、別の方法で傾注していくこと！
――「フィールドデータ」側の「ＬＣＰ」については、それに先行するものとしての「ＴＴＦＢ」（Time to First Byte＝リクエストからレスポンスの最初のバイトが到着するまでの時間）の改善が必要でもあるそうな――

　後述する「２３－２－７」、および「２３－７」の一連についても、当該事項について記載したので、参照のこと！

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　「サイドバー」のモジュール減少

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１５．「サイドバー」のモジュール数は減らした方がよい！

（２０２５年５月１５日（木）加筆）

１５－１．「スマホ」側では「サイドバー」を表示させずに、「はてなブログ」独自の「スマホ」専用画面にて表示させていたのにも関わらず、なぜだか「スマホ」側も遅くなっていた

　そもそも、各カテゴリーごとの「最新記事」モジュールをサイドバーに狂ったように膨大に付けていたので（汗）、これを半減させてみたところで、「パソコン」側のみならず「スマホ」側の画面遷移（表示）も早くなったため！（某・商用サイトによれば、スマホ画面側においては非表示ではあっても、ＰＣ用の「ＨＴＭＬ」（つまりサイドバー部も！）をもすべて読込しているのだとのこと）

１５－２．しかし、「サイドバー」の件については、「ＬＣＰ」や後述する「ＦＣＰ」チェックでは引っかかってはいなかった

１５－２－１．「はてな無料ブログ」では、合計３つの無料ブログを作成可能なので、そちらで「サイドバー」をほぼほぼナシ（アクセス・カウンターなどもナシ）にして実験してみたところで、「ＬＣＰ」「ＦＣＰ」や「ＳＩ」（Speed Index）など、すべての指標で有意な差はなかったために、そのようにも判断。……ひょっとすると、「ＩＮＰ」（Interaction to Next Paint＝ページの全体的な応答性）の指標や、「ＦＣＰ」と「ＬＣＰ」に先立つものだという「ＴＴＦＢ」（Time to First Byte＝リクエストからレスポンスの最初のバイトが到着するまでの時間）なる指標については、改善されていたのやも……

　しかし、「Google サーチコンソール」側では、いまだに「ＬＣＰ」で引っかかっている？（「Google サーチコンソール」側の「ＬＣＰ」は、28日間の平均での「フィールドデータ」だとのこと）　いずれにしても、スマホ側での画面遷移は早くなるので、今やほぼ全員でもあろうスマホのユーザーの利便性的にはゼロにせずとも減らした方がイイ！

１５－３．「サイドバー」については、後続の「２６．「サイドバー」と「はてなブログカード」と「内部リンク」」にて、さらに調査したので、そちら側を参照のこと！

（２０２５年８月１２日（火）加筆）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　まずは「ＣＬＳ」と「ＬＣＰ」にて「赤」になった項目を対策すべき！

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１６．後日付記：まずは、重要指標になっている「ＣＬＳ」と「ＬＣＰ」で「赤」になった項目を対策すべき！　しかし、「メインスレッド～」「ＪａｖａＳｃｒｉｐｔ～」「ＣＳＳ～」「サードパーティー」「効率的なキャッシュ保存期間を使用する」「ネットワークの依存関係ツリー」、および「Ａｌｌ」側で「赤」になる「強制リフロー」「過大なネットワーク ペイロードの回避」については、さんざんに調査はしてみたものの、「はてな」にかぎらず「ブログ」一般においては、我々のような一般ユーザーが直接的に改造できる箇所ではないとも思われる（「サードパーティー」のみ、間接的に改善可能？）

　「オレンジ」にて判定されている項目は、「赤」よりも軽微な「警告」の意味ではあるので、我々のような素人にとっては、まずは放置でもよいのでは？　と思われる。まぁ、提示してくる改善策の意味がよくわからないということもある（爆）。最初は、対策しても効果が比較的にウスい隘路（あいろ）には入らずに、費用対効果が高い「赤」判定された項目にチャレンジすることが合理的である。

（２０２５年８月２７日（水）加筆）

１６－１．拙ブログの「ブログデザイン」では、「ＬＣＰ」指標で、マレに「フォント表示 」項目が「赤」や「オレンジ」として判定されてくる

　この「フォント」は「はてなブログ」それ自体のフォント（活字の書体）のことであった。その改善策として「テキストの表示を統一するため、font-display を swap または optional に設定することを検討してください。swap をさらに最適化して、フォント指標のオーバーライドでレイアウト シフトを軽減できます」などが提示されてくるが、その具体的な設定方法が不明ではある。
　しかも、このフォント用のＵＲＬの末尾がひんぱんに変更されてしまう。よって、「後読み込み」などの設定処置なども不可能であると思われる。同一記事でも常に発生するワケではないので放置することにした（汗）。

（２０２５年１０月２４日（金）加筆）
　後述の「２５．「Page Speed Insight」サイトにて引っかかった、先にも設定した２種の「デザインＣＳＳ」、および「Web Page Test」サイトにて、「レンダリングをブロック」してくる旨で引っかかった４種の「はてなブログ」系の「Ｊａｖａスクリプト」を遅延読み込み、または先読み込みにしてみる」項目の側にも、「はてなフォント」のドメインに対する「先読み込み」についての四苦八苦を記載。

（２０２５年５月１５日（木）加筆）

１６－２．拙ブログでは、いわゆる過去記事への画像＆概要説明付きのリンク「はてなブログカード」については、「ＬＣＰ」などの不良要素としては一切、判定されてこない。よって、こちらの軽量化の対策なども不要なのでは？　などとも推測。しかし、回りまわって、後述する「ＴＢＴ」の「第三者コードの影響を抑えてください 」などに影響してたりするのやも？

（２０２５年９月２７日（土）加筆）
　２０２５年７月中下旬に、「はてなブログカード」を一括置換で、過去ブログ記事へのただの「ＵＲＬ」へと変更してみた。しかし、「Page Speed Insights」の「パフォーマンス」指標や「ＴＢＴ」の「第三者コードの影響を抑えてください 」指標などには、有意な差は見受けられなかったような……。
　後述する「２６－２．拙ブログの過去記事への内部リンクである「はてなブログカード」を一括置換で、単なる「ＵＲＬ」だけの内部リンクへの変更処置は影響なし？」の項目においても、その際の実験結果について記載済。

１６－２－１．以下のブログさまの記事によれば、『「はてなブログカード」は、iframe（inline frame）で構成されているので、ブログカードを生成するAPI（JavaScript）を実行。よって、「はてなブログカード」をたくさん埋め込んでいると、何度も何度もJavaScriptを読込むことになり、スピードが低下する』のだとのこと！（だが……）

　加えて、『「はてなブログカード」をスマホで表示すると概要のフォントが12px未満に小さくなり、モバイルフレンドリーでないとGoogleに怒られる』のだとのこと！　その問題を回避できるオリジナルの「はてなブログカード」用の「ＨＴＭＬ」と「ＣＳＳ」も公表されていた！
　ウ～ム。拙ブログの各記事の末尾には、過去記事へのリンクとして膨大に「はてなブログカード」を設置しているので、どうしたものやら……。一括置換で対応する方法も検討中。この程度（？）であれば、「はてな社」側にて一括で改修してほしいところだけれども……。
www.heavy-peat.com

――２０２５年９月２７日（土）後日付記：　しかし、後述するが、「はてなブログカード」をすべて廃止して、単なるＵＲＬだけの内部リンクに変更してみたものの、有意な差は見受けられなかったのであった（汗）。後述する「２６－２．拙ブログの過去記事への内部リンクである「はてなブログカード」を一括置換で、単なる「ＵＲＬ」だけの内部リンクへの変更処置は影響なし？」の項目においても、その際の実験結果について記載――

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　「ＴＢＴ」（トータル・ブロッキング・タイム）の減少

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１７．後日付記：「ＴＢＴ」（Total Blocking Time＝合計ブロック時間。メインスレッドがブロックされて、ユーザーが操作できない時間）については、以下のとおり

１７－１．「ＴＢＴ」対策１：その主要因＆対策は「第三者コードの影響を抑えてください 」とあった

　某サイトさまによれば、「第三者コード」（サード・パーティー）の一覧で表示される「ＵＲＬ」を片っ端から、先の「レンダリングを妨げるリソースの除外」とも同様に、「除外」ならぬ「先読み」or「後読み」実行させればよい……といった意味の記載もあった。しかし、あまりにもその数が膨大であって、予期せぬ挙動が発生する危険性もあるので、しばらくは対策しないことにする……。
yws.tokyo
gara-kuta.blog
（↑　：　「Ｇｏｏｇｌｅタグマネージャー」側での設定変更についての記載あり。自ブログに「Ｇｏｏｇｌｅタグマネージャー」を設定している場合には要・参考。……と思ったが、「はてな」社それ自体が「はてなブログ」全体に対して「Ｇｏｏｇｌｅタグマネージャー」を設定しているのであった……）

paso-jiyu.com
developer.chrome.com
web.dev（↑　：　後述する「preconnect」や「Web Page Test」による改善策についての記載もあり）

　……ス、スイマセン。上記のブログ記事群の内容については、当方は理解がよくできず……。「第三者コード」の一覧にて表示される「ＵＲＬ」を片っ端から、先の「レンダリングを妨げるリソースの除外」とも同様に、「除外」ならぬ「先読み」実行させればよい……と云っていたブログ記事さまのＵＲＬについても失念（汗）。

――２０２５年８月１３日（水）後日付記：　「はてなブログ」にかぎらず、世間一般的なブログの場合、「第三者コード」（サード・パーティー）の「除外」設定は不可能だとも思われる。「preload」による「先読み」も、多用すると効果がなくなるとの説もあった。超・技術マニアはともかくとしても、ここに最初から深入りはしない方がよいような――

――２０２５年９月２０日（土）後日付記：　期せずして、「２５．『デザインＣＳＳ』『Ｊａｖａスクリプト』『各種サイト』の遅延or先読み込み」の項目にて記載した、いくつかのドメインへの「preload」ならぬ「preconnect」対応が効を奏したのかは不明なれども、いつの間にやら、「Page Speed Insights」では「第三者コードの影響を抑えてください」のエラーが出なくなっていた（「ＴＢＴ」指標側ではなく「Ａｌｌ」指標側に、単なる「サードパーティ」名義の項目として、「○」（＝問題なし）が表示されている）――

――２０２５年１０月１８日（土）後日付記：　１０月１７日（金）夜間から、「Page Speed Insights」の計測結果の表示方法がビミョーに変更されている。パソコンで計測して表示させる分には従来どおりである。しかし、タブレットとスマホで計測して表示させる分だと、「パフォーマンス」指標が「インサイト」と「診断」に上下分割されずに混合されていた２０２５年の５～６月以前の表示方法に戻ってしまっている模様である。しかも、タブレットとスマホで計測して表示させている分だと、スマホ側の「ＴＢＴ」指標内における「第三者コードの影響を抑えてください」の意味だとも思われる「Reduce the impact third-party code」が「赤」にて表示されてくる！　ついでに、「過大な DOM サイズの回避」の意味だとも思われる「Avoid an excessive DOM size」も「赤」にて（パソコン側では「オレンジ」にて）表示されてくる！　どういうこと？　ウ～ム。指標としては廃止、あるいは一時的に停止されたが、復活になった、あるいは復活予定、もしくは間違って復活してしまった、といったことなのか？　とはいえ、「パフォーマンス」指標の点数には、特に悪化したなどの変化は見られなかった（ヨソさまのブログも計測してみると、パソコン側でも「インサイト」と「診断」に上下分割されずに混合されている（汗）。１０月２１日付記：　同日夜間から、世間さまのブログやサイトを測定してみても、７月以降の「インサイト」と「診断」に上下分割しての表記に無事に戻っていた――

１７－２．「ＴＢＴ」対策２：その主要因＆対策は「JavaScript の実行にかかる時間の低減」ともあった

　素人にはまったくわからないので、対策しないことにする
https://fastest.jp/blog/total-blocking-time/fastest.jp

――２０２５年８月１３日（水）後日付記：　「はてなブログ」にかぎらず、世間一般的なブログの場合、「JavaScript」の設定変更は不可能だとも思われる。超・技術マニアはともかくとしても、ここに最初から深入りはしない方がよいような――

１７－３．「ＴＢＴ」対策３：「はてなスター」や「はてなブックマークボタン」「フェイスブックボタン」などを外せ！　といった対処もある

　「１９．後日付記：「はてなスター」や「はてなブックマークボタン」「フェイスブックボタン」「ツイッターボタン」、記事本文の語句に自動で付与される旧「はてなキーワードリンク」こと「はてなタグ」のリンクなどは実は重たいので、外しておけ！　といった、巷間にて云われている施策」側にて、実験してみた。しかし、拙ブログにおいては「Page Speed Insights」で測定してみても有意な差（改善）が発生しない～（汗）。

　しかし、以下のサイトさまの記事内の「サードパーティコンテンツを外す」によれば、これによって、いくつものホストが読み込みされなくなるのだそうだ。
takehora.hatenadiary.jp

１７－４．「ＴＢＴ」対策４：その主要因＆対策は「メインスレッド処理の最小化」ともあった

　素人にも可能そうな対策としては、「クリティカルではない CSS を先送りする」という項目での手法が有効そうには思える。「CSS ファイルはレンダリングをブロックするリソース」なのだそうで、「ブログ」の初期画面の表示には無関係な「ＣＳＳ」の実行を「後回し」にできる記述があるようだ。
developer.chrome.com
web.dev

――２０２５年８月１３日（水）後日付記：　「はてなブログ」にかぎらず、世間一般的なブログの場合、「デザインＣＳＳ」の実行「後回し」設定は困難だとも思われる。超・技術マニアはともかくとしても、ここに最初から深入りはしない方がよいような――

――２０２５年９月２０日（土）後日付記：　後述する「２５．『デザインＣＳＳ』『Ｊａｖａスクリプト』『各種サイト』の遅延or先読み込み」の項目側にて、「デザインＣＳＳ」の実行「後回し」設定についての顛末を記載――

１７－４－１．ファーストページ（トップページ）ではなく、アーカイブページ（全記事見出し一覧）のデザイン変更用の「ＣＳＳ」を恒久的に削除。ついで、グローバルメニュー用の「ＣＳＳ」と「ＨＴＭＬ」も実験的に削除

　しかし、特に有意な差は見受けられなかった（汗）。……「はてなブログ」程度の「デザインＣＳＳ」であれば、そもそも軽量だったとか？

１７－４－２．あとは、「はてなブログ」の「設定」⇒「aboutページ編集」（＝「ブログの説明」）欄の側に、初期画面の表示に必要な部分の「デザインＣＳＳ」（＝クリティカルＣＳＳ）だけをインライン化するといった方策があるようだ

　だけど、その方法がよくわからず（汗）。

１７－４－３．以下のサイトさまには、「ＣＳＳ自体の遅延実行」の方法についての記載があった

www.glco.xyz
qiita.com

　「はてなブログ」の「デザインＣＳＳ」設定の先頭に、以下の文言を挿入するのだとのこと。……ただまぁ、「preload」とあるので、実際には「先読み込み」ですよね？（「先読み込み」だけ済ませておいての「遅延実行」？・汗）

<link rel="preload" as="style" href="async_style.css" onload="this.rel='stylesheet'">

　……しかし、拙ブログにおいては、有意な差（改善点）は見受けられず……。
――後日付記：　href="async_style.css"における、「"」で囲まれた箇所は、「Page Speed Insights」での診断結果における「レンダリングをブロックしているリクエスト」にて表示される、「はてなブログ」自体の「デザインＣＳＳ」の「ＵＲＬ」にすべきでした（汗）――

――２０２５年７月６日（日）後日付記：　上記については、現時点での最終的（？）には、「２５．『デザインＣＳＳ』『Ｊａｖａスクリプト』『各種サイト』の遅延or先読み込み」の項目にて記載したように設定しております。そちらの方を参照してくださいませ――

１７－４－４．以下のサイトさまには、「ＣＳＳ自体の非同期ロード」の方法についての記載もあった。

qiita.com

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

　「はてなブログ」の「デザインＣＳＳ」設定の先頭に、以下の上記の文言を挿入してみたものの……。拙ブログにおいては、有意な差（改善点）は見受けられず……。むしろ、「遅延実行」にしろ「非同期ロード」にしろ、悪化してしまったような……（汗）。よって、取り外すことにした。
――後日付記：　こちらも、href="/path/to/my.css"における、「"」で囲まれた箇所は、「Page Speed Insights」での診断結果における「レンダリングをブロックしているリクエスト」にて表示される、「はてなブログ」自体の「デザインＣＳＳ」の「ＵＲＬ」にすべきなのでした（汗）――

――２０２５年７月６日（日）後日付記：　上記については、最終的（？）には、「２５．『デザインＣＳＳ』『Ｊａｖａスクリプト』『各種サイト』の遅延or先読み込み」の項目にて記載したように設定しております。そちらの方を参照してくださいませ――

１７－４－５．「ＣＳＳ」それ自体の「ｍｉｎｉｆｙ」（ミニファイ・最小化　＝　ＣＳＳ内の改行やコメントを削ること）という対策

　この対策については、個人的には抵抗があるので、実施しないことにする（汗）。「コメント」（注釈）などはクドいくらいに付けておいた方が、あとあとにわかりやすいし、備忘録的にも有効だとも思うので……。多少は実験してみたものの、個人的には、このあたりの対策については、「Page Speed Insights」でも計測ができないような世界であって、手間暇をかける必要性はないとも独断！（汗）

１７－５．「ＴＢＴ」対策５：「スマホ」用の画面側の「Page Speed Insights」での測定チェックでは、たまに要因＆対策として「過大な DOM サイズの回避」なるものがサジェスチョン（提案）されてくる

　「パソコン」用の画面側の場合だと、常にサジェスチョンされている（爆）。

１７－５－１．「スマホ」の場合で、非常に長～い記事の場合にのみ、この問題が生じていた

　しかし、長い記事の場合であっても、これらを短い記事としての剪定（せんてい）はしたくない（笑）。具体的にはどのように対処すればよいのか？
digitalidentity.co.jp
digitalidentity.co.jp
tech.travelbook.co.jp
terukosan.com

（↑：上記の商用サイト群によれば、「診断」に「メインスレッド処理の最小化」が発生した場合には、それと同時に、「過大な DOM サイズの回避」も「診断」されている場合が多いとあった。加えて、その原因については「記事が長すぎる」「段落を多用」ともあった（爆）。……それらの対策はさておいたところでの、「過大な DOM サイズの回避」の方法についてが、高度なプログラム言語的な世界になってしまって、わからない～。素人には、あるいは「はてなブログ」では、手が出せない世界でもあるような……）

１７－５－２．以下のサイトによれば、「画面外の DOM 要素を遅延レンダリングする『content-visibility プロパティ』を使用する」ことで、「最初のページのレンダリングでレンダリング作業を大幅に削減できる」とあった！

web.dev
（　↑　：　中盤の「DOM サイズを最小限に抑える」の箇所に、「content-visibility を使用して画面外の要素を遅延レンダリングする」とある。「詳細については、以下をご覧ください。 DOM サイズとインタラクティビティ」を選択すると、直下の画面へ遷移する。そのひとつ下の「こちらをご覧ください。content-visibility: レンダリング パフォーマンスを向上させる新しい CSS プロパティ」を選択すると、２つ下の画面へ遷移する）

web.dev
web.dev

１７－５－３．しかし、「はてなブログ　content-visibility 　使えるか」でググってみると、グーグルの「ＡＩによる概要」によれば、「はてなブログ」ではこの命令文はまだ使用できない模様であった・汗）

「はてなブログ content-visibility 使えるか」
www.google.com

１７－５－４．２０２５年７月あたりから、「パソコン」でも「スマホ」でも「過大な DOM サイズの回避」がサジェスチョンされてこなくなった（「Page Speed Insights」の指標としても廃止された？）

　（２０２５年７月１９日（土）加筆）
　２０２０５年７月あたりから、「パソコン」でも「スマホ」でも「過大な DOM サイズの回避」がサジェスチョンされてこなくなった（「ＴＢＴ」指標側ではなく「Ａｌｌ」指標側に、単なる「DOM サイズを最適化する」名義の項目として、「○」（＝問題なし）が表示されている）。「Page Speed Insights」の指標としては廃止されたのか？　それとも、後段のもろもろの処置が功を奏したのか？　５月末に、「はてなブログ」のデザインを「Hatena for はてなブログ」から「classic diary（日記向け）」に変更したからなのか？　不明である（汗）。

――２０２５年１０月１８日（土）後日付記：　１０月１７日（金）夜間から、「Page Speed Insights」の計測結果の表示方法がビミョーに変更されている。パソコンで計測して表示させる分には従来どおりである。しかし、タブレットとスマホで計測して表示させる分だと、「パフォーマンス」指標が「インサイト」と「診断」に上下分割されずに混合されていた２０２５年の５～６月以前の表示方法に戻ってしまっている模様である。しかも、タブレットとスマホで計測して表示させている分だと、スマホ側の「ＴＢＴ」指標内における「第三者コードの影響を抑えてください」の意味だとも思われる「Reduce the impact third-party code」が「赤」にて表示されてくる！　ついでに、「過大な DOM サイズの回避」の意味だとも思われる「Avoid an excessive DOM size」も「赤」にて（パソコン側では「オレンジ」にて）表示されてくる！　どういうこと？　ウ～ム。指標としては廃止、あるいは一時的に停止されたが、復活になった、あるいは復活予定、もしくは間違って復活してしまった、といったことなのか？　とはいえ、「パフォーマンス」指標の点数には、特に悪化したなどの変化は見られなかった（ヨソさまのブログも計測してみると、パソコン側でも「インサイト」と「診断」に上下分割されずに混合されている（汗）。１０月２１日付記：　同日夜間から、世間さまのブログやサイトを測定してみても、７月以降の「インサイト」と「診断」に上下分割しての表記に無事に戻っていた――

１７－６．「ＴＢＴ」対策の結果：以上の施策をもってしても、「パソコン」「スマホ」ともどもに、効果がなかった

　スマホの場合の指標である２５０ミリ秒以下の「緑」（90点以上）にはどうしてもならずに、どころか時折り、スマホの場合であれば６００ミリ秒超過の「赤」（50点未満）にさえなってしまう（ＰＣでもまったくの同様）。つまり、同一記事であっても、挙動が一定しない（汗）。

――２０２５年９月２０日（土）後日付記：　期せずして、「２５．『デザインＣＳＳ』『Ｊａｖａスクリプト』『各種サイト』の遅延or先読み込み」の項目にて記載した対応が、効を奏したのかは不明なれども、「ＴＢＴ」の改善が見られたような？？？――

１７－７．「ＴＢＴ」対策その他：「はてなブログＰＲＯ」だと、「ＴＢＴ」の数値が低かった！

（２０２５年８月７日（木）加筆）

　「Page Speed Insights」で、あまたの「はてなブログ」を計測してみた。すると、「はてなブログＰＲＯ」の場合に、「ＴＢＴ」の数値が低かった！　ということは、「はてな無料ブログ」の場合には、「はてな」社側にて自動的に挿入してくる「広告」で、「ＴＢＴ」の数値が増えているのだとも思われる。とはいえ、「はてなブログＰＲＯ」でも、個人で「Ｇｏｏｇｌｅアドセンス」での広告を追加している方々ではあっても、「ＴＢＴ」の数値が低かった。どういうこと？　ウ～ム。
　いわゆる、ＧｏｏｇｌｅさまがＳＥＯで重視する「Ｃｏｒｅ　Ｗｅｂ　Ｖｉｔａｌ（コア・ウェブ・バイタル）」においては、「ＴＢＴ」は含まれてはいないことにはなっているので、とりあえずアキラめるしかない？

　しかし、「Total Blocking Timeは、Google検索に影響があるか」の語句でググって、「ＡＩによる概要」を参照してみると、以下のように「Ｃｏｒｅ　Ｗｅｂ　Ｖｉｔａｌ」にも「ＴＢＴ」は含まれているとの回答が表示されてくる（汗）。

「Total Blocking Timeは、Google検索に影響があるか」
→　「「PageSpeed Insights」のコアウェブバイタルにTBTが含まれており、Webページのユーザー体験やSEO（検索エンジン最適化）に大きく関わります。TBTが長いとユーザー操作への応答が遅れ、検索順位に悪影響を及ぼす可能性があります」
www.google.com

　けれども、以下の正規の注釈を読むと、フィールドデータ側の「ＩＮＰ」が合格さえしていれば、ラボデータ側の「ＴＢＴ」はあまり気にしなくてもよいようにも思える。

「この遅延は、ユーザーが経験する実際の入力レイテンシに影響するため、ページの INP にカウントされます。ただし、この遅延は技術的には長いタスクではないため、ページの TBT には影響しません。つまり、TBT スコアが非常に高いにもかかわらず、ページの INP が低い場合があります」
web.dev

　とにかく、有料の「はてなブログＰＲＯ」にしてまで、改善しようとは思わない（汗）。「はてな無料ブログ」のままで極限まで極めてみたいのだ（笑）。

１７－８．「ＴＢＴ」対策その他：「Ｇｏｏｇｌｅタグマネージャー」を「先読み込み」にしてみる！（自ブログに「Ｇｏｏｇｌｅタグマネージャー」を設定している場合にのみ？）

（２０２５年８月２８日（木）加筆）

　「はてなブログ」に「Ｇｏｏｇｌｅタグマネージャー」を設定している方オンリーの設定にはなるものの（……と思ったが、「はてな」社それ自体が「はてなブログ」全体に対して「Ｇｏｏｇｌｅタグマネージャー」を設定している……）、「２５．『デザインＣＳＳ』『Ｊａｖａスクリプト』『各種サイト』の遅延or先読み込み」の項目にて記載した設定を実施してみた。そちらの方を参照してくださいませ。

１７－９．「ＴＢＴ」対策まとめ：「ＴＢＴ」指標については、「Ｃｏｒｅ　Ｗｅｂ　Ｖｉｔａｌ」指標となるフィールドデータ側の「ＩＮＰ」指標の基となるものである。よって、「ＩＮＰ」指標が合格しているのであれば、対策に傾注するのは誤りやも？（汗）　「ＩＮＰ」指標が不合格であれば、傾注すべき！？

（２０２５年１１月２９日（土）加筆）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　「ＦＣＰ」（描画開始時間）の減少

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１８．後日付記：「ＦＣＰ」（First Contentful Paint＝ユーザーがページに初めて移動してから、ページのコンテンツ（テキストor画像）のいずれかの部分が画面上にレンダリングされるまでの時間）について

（２０２５年５月１５日（木）加筆）

１８－１．「ＦＣＰ」のエラーの主要因＆対策については、「オフスクリーン画像の遅延読み込み」および「適切なサイズの画像」とあった

――ちなみに、「適切なサイズの画像」とは、「ファイルのサイズ」ではなく「縦横の画像のサイズのこと」だそうだ――

１８－１－１．これらについては、いずれも拙ブログの場合には「アマゾンの商品の画像」が原因となっていた！　先にもふれたとおりで「レンダリングを妨げるリソースの除外」は実装済である（その効果には疑問符が付き、除外先のＵＲＬの末尾についても変更されていくので、意味はないものの……）。そのうえで、「アマゾンの商品の画像」のみの「遅延読み込み」といったことは可能なのであろうか？

　画像の「遅延読み込み」とは、初期画面には表示されてこない、画面の下方の外にある画像（＝オフスクリーン画像。下方へとスクロール時に読込される画像といった意味）については、ごくマレに１００キロバイトに近い「アマゾンの商品の画像」を用いている記事が発覚した場合には、「スマホ」側での「ＦＣＰ」の時間が非常に悪くなるとは判明した。よって、それに気付いた各記事の場合には、商品画像はナシでのリンクのみに変更したり、別の商品の画像に差替することにしようと思ったのだが……。後述の方法にて対処！――「はてなフォトライフ」経由での新規の「画像」貼り付け分については、すでに「はてな」社側にて2021年６月から「遅延読み込み」での設定に変更されたとのこと――

１８－１－２．ググると、グーグルの「ＡＩによる概要」で、「はてなブログ」記事の「記事編集」の「ＨＴＭＬ」画面にて、「AmazonのアフィリエイトリンクのHTMLコードを探し（中略）「imgタグ」に`loading="lazy"`を追加する。Amazonの商品紹介画像に使われている「imgタグ」に loading="lazy" 属性を追加します。例えば、以下のようなコードになります」……といった処方箋が提示されてくる

「はてなブログ amazon商品紹介画像 遅延読み込みするには」
www.google.com

<img src="画像のURL" alt="代替テキスト" width="画像幅" height="画像高さ" loading="lazy">

　↑　：　「画像のＵＲＬ」とは、「アマゾンの商品の画像」オンリーのサイトのこと。「ＦＣＰ」の「診断」の「オフスクリーン画像の遅延読み込み」の「ＵＲＬ」欄をクリックすると、「アマゾンの商品の画像」のみが表示されている。他にも、「はてなブログ」で表示される「新しい記事」（次の記事）と「過去の記事」（前の記事）各々の小さな画像なども一覧表示されている場合もある。しかし、サイズは各々が４キロバイトほどなので、こちらは無視での対処不要でよくて（対処の方法もないので・笑）、「アマゾンの商品の画像」側の問題が解消できれば、それで解決するとも推測。

――２０２５年５月２４日（土）後日付記：　上記のグーグル検索での「ＡＩによる概要」を再表示させると、以下のように「width="画像幅" height="画像高さ"」抜きでのコマンドが表示されていた……。どっちが正解やねん！？（汗）　たぶん、「width="画像幅" height="画像高さ"」がある方が正解ではある。とりあえず、「width="画像幅" height="画像高さ"」付きにて、ＰＣ側のトップページで表示される拙ブログの最新５記事分に対してのみ、「アマゾン商品画像」の遅延読み込みを設定してみて、実験してみることにする。画像幅と高さについては、「ＦＣＰ」の「オフスクリーン画像の遅延読み込み」項目に表示される「ＵＲＬ」欄をクリックして、アマゾン商品画像を表示させておき、グーグルのブラウザ「Ｃｈｒｏｍｅ」であれば、右クリック⇒「診断」にて表示される「ＨＴＭＬ」に、「width」（幅）と「heght」（高さ）の数値が表示されているので、そちらを転記すればよし！（最後には、「ＨＴＭＬ」が表示された画面の右上スミの「×」を押下で、「ＨＴＭＬ」が表示された画面は閉じておくこと！――

<img src="画像のURL" alt="代替テキスト" loading="lazy">

　上記の「loading="lazy"」による遅延読み込みについては、該当記事にて「はてな記法」であれば、「ASIN記法」で設定している箇所を、この「ＨＴＭＬ記法」にて置換してあげればよいだけであった。

１８－１－３．しかし、これとは別に、（「野生の」なる形容が付いた）「lazyload」なる手法もあるそうだ

　こちらについては２ヵ所、つまりは各記事の写真部分のみならず、「はてなブログ」の「フッタ」または「ヘッダ」設定欄または「設定」⇒「詳細設定」⇒「head要素にメタデータを追加」欄のいずれかに、大前提としての規定の長めの専用「ＨＴＭＬ」を記載してあげる必要があるようだ！

　けれども、メンドウそうなので、先の「loading="lazy"」による遅延読み込みとしておいた……。

１８－１－４．上記の「loading="lazy"」による遅延読み込みによって、「ＦＣＰ指標」における「診断」＝「オフスクリーン画像の遅延読み込み」については「赤」（50点未満）ではなく「オレンジ」（50点以上～90点未満）にはなったのだが……

　「スマホ」側の「ＦＣＰ」のスピード秒数に変化は見られず、１．８秒以下の「緑」（90点以上）にはならなかった。つまり、「パフォーマンス」指標的には有意な差（改善）が見受けられない。
――そのことはともかくとしても、せっかく「img src="画像のURL" alt="代替テキスト" width="画像幅" height="画像高さ" loading="lazy"」に代替したのに、既存分の「ASIN記法」での記述を、文字のみの「title」属性ではなくブログカード形式での「detail」属性などにて残してしまうと、その分については「遅延読み込み」の対象にはならないので、「オフスクリーン画像の遅延読み込み」の「診断」についても「赤」（50点未満）のままで引っかかってしまう。よって、「ASIN記法」を「detail」属性にて残さないように注意！――

１８－１－５．「ＦＣＰ」指標側に自動表示される「アマゾン商品画像」の各画像のサイズは、数１０キロバイト程度でしかなった（ごくまれには１００キロバイト近いものもあるにはあったけど……）。よって、世間一般の写真画像に比すれば重たくないと思われる。しかし……

　世の「はてなブログ」高速表示化サイトを参照すると、アマゾン画像はともかくとしても、写真画像の類を１０キロバイト程度（！）に圧縮せんとしているサイトさまなどもあった。それでは、アマゾン商品画像を個人のパソコンにダウンロードしてきて、それに対して圧縮をかけたものを、「はてなフォトライフ」経由にてアップロードすべきなのか？

　しかし、それらは著作権法的にはグレーである。しかも、やや手間がかかる。加えて、スマホ画面の一番下に自動表示される「前の記事」「次の記事」の類に表示されている、各記事のアマゾン商品画像を基にした小さなアイキャッチ画像の類も、「ＦＣＰ」指標の方に自動表示されてくる分を参照すると、４～５キロバイトのサイズである。よって、正規の画像を１０キロバイト程度に圧縮するなど、とても不可能だと推測！――可能であっても、画質がピンボケになることだろう――。よって、アマゾン商品画像の圧縮作業は労多くして報いは少ない作業かもしれない。コスト・パフォーマンス（費用対効果）を考えて、これらの圧縮作業はしないことにしておこう。そもそも、著作権法的にも……（汗）。

１８－１－６．「パソコン」側の「ＦＣＰ」指標の「オフスクリーン画像の遅延読み込み」項目に、マレにサイドバーに設置してある「読書になるボタン」のボタン画像と思われる部分が引っかかる場合がある

（２０２５年８月３１日（日）後日付記）

　各種の「ボタン」の画像もビミョーに重たいようだ。しかし、２．３キロバイトでしかなかった。これを改造する指南も世にはある。けれども、先のアマゾンの商品画像の１／１０以下でしかない。単独では「赤」判定にもならない。よって、致命的な悪影響を与えるものではないので、しばらく放置することにした。

１８－１－７．「スマホ」「パソコン」双方の「ＦＣＰ」指標の「オフスクリーン画像の遅延読み込み」項目に、「はてなスター」の「アイコン」画像が引っかかる場合がある

（２０２５年９月２４日（水）後日付記）

　「はてなスター」を付けてくれた、「はてなユーザー」による「アイコン」画像は、７．５キロバイトであった。けれども、先のアマゾンの商品画像の数十キロ～１００キロバイト弱に比すれば、まだまだ小さい。単独では「赤」判定にもならない。よって、致命的な悪影響を与えるものではないので、放置することにした。というか、「はてなスター」を非表示にしないかぎり、対応ができないし、せっかく付けてくれた「はてなスター」を非表示にするのも忍びないし、心苦しい（笑）。

１８－１－８．２０２５年１０月２０日ごろから、「アマゾン商品画像」が「オフスクリーン画像の遅延読み込み」項目にてエラーにならなくなった？

（２０２５年１０月２２日（水）後日付記）

　２０２５年１０月２０日ごろから、「ＦＣＰ」指標および「ＬＣＰ」指標の「オフスクリーン画像の遅延読み込み」項目においては、「はてな記法」の「ASIN:B234567890:image:large」や「ISBN:1234567890:image:large」指定にて各ブログ記事に表示させている大きめの「アマゾン商品画像」が、「赤」（50点未満のエラー）として引っかからなくなった模様である。どういうことなのか？　「アマゾン」側または「はてな」社側にて、ブログ記事に「アマゾン商品画像」を表示させる際には、自動的に初期設定として「遅延読み込み」させるように設定を変更してくれたのであろうか？
　ただし、「画像配信を改善する」項目においては、「オレンジ」（50点以上～90点未満の警告）にて引っかかってしまうようにはなったようだ。いや、以前から「オレンジ」にて引っかかってはいて、放置にしていたナ……（汗）。その「画像配信を改善する」項目の詳細を表示させてみると……。

●パソコン側では、各ブログ記事の「アマゾン商品画像」それ自体は引っかかってはいなかった。「サイドバー」側に表示されている「アマゾン商品画像」を基にしている６～７キロバイト程度の軽～いアイキャッチ画像に対して――width（画像幅）とheight（画像高さ）が、サイドバー側に自身が設定した値そのものであった点でも、それだとわかった――、「最新の画像形式（WebP、AVIF）を使用するか、画像の圧縮率を高くすると、この画像のダウンロード サイズが改善する可能性があります」といったメッセージが表示されていた。これは画像の種類を、世界的にも主流で万国共通の「jpeg（ジェイ・ペグ）」形式ではなくって、近年に誕生した（WebP、AVIF）形式に変えると、ダウンロードの速度が、ひいては画面表示の速度が速くなる、といった意味である。でも、「アマゾン商品画像」それ自体が「jpeg」形式なのであって、変更不可能でもあるものなので放置するしかない（汗）。
――これは、ファーストページ（トップページ。ページの上部にして拙ブログの初期画面）側に、該当アイキャッチ画像を表示させている「サイドバー」が存在しているからではなかった。ファーストページよりも下方の映らない箇所（オフスクリーン）側の「サイドバー」のアイキャッチ画像ではあっても、引っかかるものであるようだ。よって、サイドバーにアイキャッチ画像を表示させているかぎり、解消はできない（汗）――
●スマホ側では、「サイドバー」のアイキャッチ画像に対してではなくって、「ASIN:B234567890:image:large」や「ISBN:1234567890:image:large」などの「はてな記法」にて表示させている各ブログ記事の「アマゾン商品画像」それ自体に対して、「この画像ファイルは、表示サイズ（370x278）に必要なサイズ（500x375）より大きくなっています。画像のダウンロード サイズを小さくするには、レスポンシブ画像を使用します」などといったメッセージが表示されていた。でも、「アマゾン商品画像」それ自体を表示させているだけなのであって、画像それ自体にスマホ用にサイズを自動調整させるような「レスポンシブ」設定を付与することなどはできないのでは？　と思われる。

　「ＣＬＳ」こと「レイアウト・シフト」指標側でも、パソコン・スマホともどもに、「画像要素で width と height が明示的に指定されていない」項目においては、「ASIN:B234567890:image:large」や「ISBN:1234567890:image:large」などの「はてな記法」にて表示させている大きめの「アマゾン商品画像」が、「オレンジ」（50点以上～90点未満の警告）にて引っかかってしまっていた。そうなると、やはり「アマゾン商品」の画像専用サイトへの直接リンクにして、それに対しての「img src="画像のURL" alt="代替テキスト" width="画像幅" height="画像高さ" loading="lazy"」設定を実施するしかないような……。
　とはいえ、あくまでも「オレンジ」なのであって、世間一般に対してはそこまでの改善処置をオススメはしない。しかも、「Page Speed Insights」の上方に表示される「直近28日間の平均値」としてのフィールドデータ側の「ＣＬＳ」指標については、拙ブログではスマホ側は「０」、パソコン側は「０．０１」であって、余裕で「０．１」以上での「緑」（90点以上）を達成してもいるので……。
　２０２５年５月下旬から、拙ブログにおいては週に４～６記事ほど、「はてな記法」での「ASIN:B234567890:image:large」や「ASIN:B234567890:detail」を、「アマゾン商品」の画像専用サイトへの直接リンクにして、それに対しての「img src="画像のURL" alt="代替テキスト" width="画像幅" height="画像高さ" loading="lazy"」設定への書き換えを実施してきたが、地味にメンドウで時間も取られてきた。よって、拙ブログにおいては、今後はこの修正は費用対効果を考慮して放置にすることにした。

　ただし、「ASIN:B234567890:image:large」ではなく「ASIN:B234567890:detail」指定での小さめな「アマゾン商品画像」だけを各ブログ記事に表示させている場合には、パソコン・スマホともどもに、「ＦＣＰ」指標および「ＬＣＰ」指標の「オフスクリーン画像の遅延読み込み」項目はもちろん、「ＣＬＳ」指標の「画像要素で width と height が明示的に指定されていない」項目においても、引っかかってはいなかった。「detail」表示の場合には固定の大きさでのワク表示であるので、width と height がウラ側で設定されているからでもあろう。スマホ側では、「ＦＣＰ」指標および「ＬＣＰ」指標の「画像配信を改善する」項目についても、引っかかってはいなかった。
　そして、スマホ側では「画像配信を改善する」項目が引っかかってはいない！　「detail」表示の場合には、小さめの画像を表示させているからだと思われる。パソコン側でのみ、「画像配信を改善する」項目が引っかかってはいる。しかし、その詳細を表示させてみると、各ブログ記事の「アマゾン商品画像」それ自体が引っかかっていたワケではなかった。やはり、「サイドバー」の６～７キロバイト程度の軽～いアイキャッチ画像に対して、「最新の画像形式（WebP、AVIF）を使用するか、画像の圧縮率を高くすると、この画像のダウンロード サイズが改善する可能性があります」といったメッセージが表示されていた。変更不可能でもあるので放置するしかない（汗）。
――これも、ファーストページ（トップページ。ページの上部にして拙ブログの初期画面）側に、該当アイキャッチ画像を表示させている「サイドバー」が存在しているからではなかった。ファーストページよりも下方の映らない箇所（オフスクリーン）側の「サイドバー」のアイキャッチ画像ではあっても、引っかかるものであるようだ。よって、サイドバーにアイキャッチ画像を表示させているかぎり、解消はできない（汗）――

　けれども、「ASIN:B234567890:detail」表示においては、ツイッターでブログ記事を宣伝する際には記事のアイキャッチ画質がピンボケになってしまうのではあった。よって、その場合には、「アマゾン」の「商品画像」専用ＵＲＬに直接にリンクして、大きめのサイズで表示させた方がよいことにはなる。あるいは、「オフスクリーン画像の遅延読み込み」項目にて引っかからなくなったようであるので、「ASIN:B234567890:image:large」指定に変更してあげればよいだけにはなる。

　つまり、２０２５年１０月２０日ごろから、「アマゾン商品画像」については、「img src="画像のURL" alt="代替テキスト" width="画像幅" height="画像高さ" loading="lazy"」による「遅延読み込み」設定を実施はしなくてもよくなったと思われる。「はてな記法」での大きめ表示用の「ASIN:B234567890:image:large」だけを設定すればよいだけになった模様である。

　とはいえ、すでに「img src="画像のURL" alt="代替テキスト" width="画像幅" height="画像高さ" loading="lazy"」による「遅延読み込み」設定を実施してしまったブログのページについては、「ASIN:B234567890:detail」表示設定とも同様に、パソコン・スマホともどもに、「オフスクリーン画像の遅延読み込み」項目についても、「画像要素で width と height が明示的に指定されていない」項目についても、ダブルで引っかからないのではあった。
　そして、スマホ側では「画像配信を改善する」項目が引っかかってはいない！　「アマゾン」の「商品画像」専用ＵＲＬに直接にリンクして表示させているから、ダウンロードの時間が早くなることで、合格になっているのであろうか？　それとも、「商品画像」専用ＵＲＬで表示させるナマ画像については、「ASIN:B234567890:image:large」指定にて表示させる大きめの画像よりかは小さめなので、合格になっているのであろうか？
　パソコン側でのみ、「画像配信を改善する」項目が引っかかってはいる。しかし、その詳細を表示させてみると、各ブログ記事の「アマゾン商品画像」それ自体が引っかかっていたワケではなかった。やはり、「サイドバー」の６～７キロバイト程度の軽～いアイキャッチ画像に対して、「最新の画像形式（WebP、AVIF）を使用するか、画像の圧縮率を高くすると、この画像のダウンロード サイズが改善する可能性があります」といったメッセージが表示されていた。変更不可能でもあるので放置するしかない（笑）。
――これも、ファーストページ（トップページ。ページの上部にして拙ブログの初期画面）側に、該当アイキャッチ画像を表示させている「サイドバー」が存在しているからではなかった。ファーストページよりも下方の映らない箇所（オフスクリーン）側の「サイドバー」のアイキャッチ画像ではあっても、引っかかるものであるようだ。よって、サイドバーにアイキャッチ画像を表示させているかぎり、解消はできない（汗）――

　「アマゾン商品画像」ではなく「はてなフォトライフ」の画像を表示させている場合には、これらの問題は発生しない。パソコン側でのみ、「画像配信を改善する」項目が、やはり「サイドバー」の６～７キロバイト程度の軽～いアイキャッチ画像に対して、「最新の画像形式（WebP、AVIF）を使用するか、画像の圧縮率を高くすると、この画像のダウンロード サイズが改善する可能性があります」といったメッセージで引っかかっているだけである。サイドバーのアイキャッチ画像を非表示にする気はないので、放置するしかないものの（笑）。

１８－２．（ラボデータ側の）「ＦＣＰ」の結果：「パソコン」側では常に、０．９秒以下の「緑」（90点以上）になっている。しかし、「スマホ」側については、トップページ（＝「はてなブログ」独自の「スマホ」専用画面にしておいて、最新７記事の見出し一覧ページしか表示させない場合に限定）については、あともう少しではあっても、達成ができない（……「ＬＣＰ」とも同様に、フィールドデータ側の「ＦＣＰ」の秒数の方が大きくて、「パソコン」「スマホ」双方ともに「オレンジ」（90点未満）のままであった・汗）。

（２０２５年８月１３日（水）後日付記）

　その後、２０２５年５月３１日に拙ブログの採用デザインそれ自体を「Hatena for はてなブログ」から「classic diary（日記向け）」へと変更して、なおかつ「レスポンシブデザイン」対応にして、「スマホ」側のトップページではあっても最新７記事の見出し一覧のみではなく、「パソコン」側と同様の最新５記事を全表示にするように変更したためでもあろうか？
　いつの間にやら、フィールドデータ側の「ＬＣＰ」と「ＦＣＰ」の秒数の方が、ラボデータ側の「ＬＣＰ」と「ＦＣＰ」の秒数よりも小さくなるようにはなっていた――表示速度の改善処置を実施する直前のフィールドデータ側の「ＬＣＰ」と「ＦＣＰ」の秒数は、パソコン・スマホともどもに４．０秒前後と非常に悪かったので（汗）――。「Ｃｏｒｅ　Ｗｅｂ　Ｖｉｔａｌ」指標においては、フィールドデータ側を基準としており、それであっても「緑」（90点以上）にはなっているので、とりあえずは問題なしである。

（２０２５年１０月２５日（土）後日付記）
　直上のこの時点での、フィールドデータ側の「ＦＣＰ」や「ＬＣＰ」指標の改善理由についてが、「『「Hatena for はてなブログ」から「classic diary（日記向け）」へと変更して、なおかつ「レスポンシブデザイン」対応にして、「スマホ」側のトップページではあっても最新７記事の見出し一覧のみではなく、「パソコン」側と同様の最新５記事を全表示にするように変更したためであろうか？』といった憶測については、誤認であった。
　「ブログのデザイン変更」や「「スマホ」側のトップページではあっても最新７記事の見出し一覧のみではなく、「パソコン」側と同様の最新５記事を全表示にするように変更」といったことが、フィールドデータ側の「ＦＣＰ」や「ＬＣＰ」指標の改善理由ではなかった。

●２０２５年５月のゴールデンウィーク明けあたりで、膨大なるモジュールを設定していた「サイドバー」を半減させたこと。
●２０２５年５月２１日に、膨大にあった過去記事へのリンクである旧「はてなダイアリー」時代のＵＲＬを、新「はてなブログ」でのＵＲＬへと一括置換にしたこと。

　上記の２点が、フィールドデータ側の「ＦＣＰ」や「ＬＣＰ」指標の改善理由であった。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　各種ＳＮＳボタンの取り外しに効果はない!?

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

１９．後日付記：「はてなスター」や「はてなブックマークボタン」「フェイスブックボタン」「ツイッターボタン」、記事本文の語句に自動で付与される旧「はてなキーワードリンク」こと「はてなタグ」のリンクなどは実は重たいので、外しておけ！　といった、巷間にて云われている施策

（２０２５年５月１７日（土）加筆）

１９－１．拙ブログにて試してみた範疇では、「パソコン」「スマホ」双方ともに、「Page Speed Insights」の「ＣＬＳ」「ＬＣＰ」「ＴＢＴ」「ＦＣＰ」のいずれの指標においても、有意な差（改善）が見受けられない

１９－１－１．どういうことなのか？　すでに「はてな」社側にて対策済だとか？　各種「ボタン」についても、ブログ「記事」の「上」ではなく「下」側に表示させているので、「Page Speed Insights」では計測できない部分だとか？

１９－２．そうは云っても、「はてなブックマークボタン」「フェイスブックボタン」「ツイッターボタン」は、各所で推薦されている以下のサイトさまで公開されているボタンを採用することにした

note.com

　記事本文の語句に自動で付与される旧「はてなキーワードリンク」こと「はてなタグ」のリンクなども、とりあえず外しておいた――ただし、本来の旧「はてなダイアリー」時代の「はてな」の醍醐味は、「キーワード・リンク」だったとも思うので、大差がないのであれば、復活させたい（笑）――。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　「おすすめの方法」・「ユーザー補助」・「ＳＥＯ」

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

２０．後日付記：「Page Speed Insights」の「ＣＬＳ」「ＬＣＰ」「ＴＢＴ」「ＦＣＰ」などを含んでいる「パフォーマンス」以外の指標については、とりあえず説明文においても後方に配置・記載されているので、後回しにするか、もしくは無視・軽視してもよいのでは？　と勝手に憶測（汗）

（２０２５年５月１７日（土）加筆）

２０－１．「おすすめの方法」と「ＳＥＯ」の指標における「診断」は、「はてなブログ」ではイジりようがない箇所だとも思われる

２０－１－１．しかし、「設定」⇒「詳細設定」⇒「フォーマット（記事ＵＲＬ）」項目を、「ダイアリー」（/entry/20111107/1320650325）ではなく「標準」（例: /entry/2011/11/07/161845）として設定してあった、実験用の「Hatena for はてなブログ」デザイン（＝２０２５年５月３１日以前に使用していたデザイン・汗）のブログ側の、トップページではなく各記事の側においては、「パソコン」「スマホ」ともどもに、「画像要素に [alt] 属性が指定されていません」エラーが発生しないことによって、「ＳＥＯ」指標の点数は「85点」（オレンジ色）から「92点」（緑色）にまで上がっていた

　……とはいえ、使用途中のブログで、ここの設定を途中から変更してしまっても、大丈夫であるのか否かについては不明である（汗）。

２０－１－２．上記の「フォーマット（記事ＵＲＬ）」は、いわゆる「ドメイン」とは異なるものである。「ドメインパワー」といった概念もあるそうだ

　その概念によって、「はてなブログ」の標準的な「hatenablog.com」のドメインの方が、「hatenadiary.com」のドメインなどよりも、「ＳＥＯ」的には強いのだそうだ。
　しかし、「はてなブログＰＲＯ」だと設定可能な独自ドメインの方が「ＳＥＯ」的には有利であるとか、グーグル検索でも１種のドメインにつき、１種のブログしか上位に表示されないので、同一ドメイン内での競合的にも不利である……といった記載もどこかで読んだような……。とはいえ、そのためだけに、有料版の「はてなブログＰＲＯ」にしようとまでは思わないものの（汗）。
www.monoist.work

２０－２．「ユーザー補助」（＝実質、視覚障害の方々のための補助）の指標における「診断」については、以下のとおり

２０－２－１．「背景色と前景色には十分なコントラスト比がありません」

　「はてなブログ」の右上隅に自動的に挿入されてくる「読者になる」ボタンや、各記事ごとの「年月日」に、各種ＳＮＳへのボタンの「色」や、サイドバー内の「赤」や「緑」色の文字に、「はてな」の過去記事へのリンクこと「はてなブログカード」内の「青いリンク」のことであったので、変更不可能！
　（「はてなブログ」全般で、同じ現象が生じている）

２０－２－２．「リンクは色に依存して識別可能です」

　各記事の本文内に張った、青いＵＲＬのリンクことであったので、変更不可能！　そもそも、世界標準だともいえる青いＵＲＬのリンクに対して、（視覚障碍者）にとっては「低コントラストのテキスト」だと指摘してくるというあたりについても、腑に落ちないものの……。

２０－２－３．「frame または iframe の要素にタイトルが指定されていません」

　「はてなブログ」それ自体の規定の最上位部分のヘッダーと、「はてなスター」の押下ボタンのことであったので、変更不可能！
　（「はてなブログ」全般で、同じ現象が生じている。ただし、有料版の「はてなブログＰＲＯ」で、「はてなブログ」それ自体の規定の最上位部分のヘッダーを非表示にしている場合には、当該項目でのエラーにはなっていない）

２０－２－４．「画像要素に、重複する内容の[alt] 属性が含まれています」

　拙ブログの場合には、「はてなブログ」それ自体のアイコン画像のことであったので、変更不可能！　……いや、各個人ごとにアイコン画像を設定することが可能であるので、その画像に「ａｌｔ」属性に任意のテキストを付与しておけば解消されるのやも？（未実験。たぶんダメそうな気がする）
　（「はてなブログ」で、当該項目がエラーにはなっていない方もいらっしゃったが……）

２０－２－５．「タップ ターゲットのサイズや間隔は十分な大きさではありません」

　「パソコン」側については、サイドバーの「リンクモジュール」で表示させている「文字」の大きさが小さいと判定されている。サイドバーの他のモジュールの「文字」の大きさについては問題視されていないのにナゼ？　「リンクモジュール」の「文字」だけを大きくしてしまってはマヌケになってしまうので、変更対応はしないことにする！
　（「はてなブログ」全般で、同じ現象が生じている）

　「スマホ」側については、「固定グローバル・メニュー」かつ「ドロップダウン・メニュー」の「文字」の大きさが小さいと判定されている。こちらの「文字」も大きくはしたくないし、そもそものこの「ユーザー補助」指標それ自体が、過去には存在していたＧｏｏｇｌｅの「モバイルフレンドリーテスト」や「Ｇｏｏｇｌｅサーチコンソール」の「モバイルユーザビリティレポート」が２０２３年１２月１日に廃止されたために、今ではグーグル検索の「Page Speed Insights」などの要素ではあっても、「Ｃｏｒｅ　Ｗｅｂ　Ｖｉｔａｌ」の重要要素ではない（？）のであろうと勝手に見て、変更対応はしないことにする！

　「パソコン」側については、「サイドバー」に表示される「関連記事」の「文字」＆「カテゴリーモジュール」で表示されているカテゴリー名のリンクも引っかかった。
　それらの「行間」を「ＨＴＭＬ」によって広げる……といった方策なども、各種サイトにはあったものの、その設定は「サイドバー」ではなく「記事本文」に対する設定であるようにも思われたので、未実験……。
　「カテゴリーモジュール」それ自体は、Ｇｏｏｇｌｅがクロール（検索結果に反映させるための自動巡回）に利用しやすいといった話もあるので、ここでは望ましくはないと「診断」されたとしても、ＳＥＯ的には削除はしない方がイイとも思われる。サイドバーがあってもなくても、「ユーザー補助」指標的には76点のままで変化がなく、特に低い点数でも決してなかったものなので……。

（後日付記：　サイドバーに「カテゴリーモジュール」は残しておいた方が、Ｇｏｏｇｌｅからのクロール的にはよい、といった話はあったものの、サイドバーのモジュールが多いことのデメリット（表示速度の遅延。「ＴＴＦＢ」指標の遅延）も発覚したことと、拙ブログにおいては「カテゴリー」については「固定グローバル・メニュー」かつ「ドロップダウン・メニュー」側にもリンクを設置しているので、サイドバーの「カテゴリーモジュール」は削除することにした・汗）

２０－２－６．「見出し要素は降順になっていません」

　「はてなブログ」全般で、「記事タイトル」それ自体が「ＨＴＭＬ」では「ｈ１」記述である。「大見出し」は飛んで「ｈ３」。「中見出し」は「ｈ４」。「小見出し」は「ｈ５」に初期設定されている。つまり、「ｈ２」の見出しが「はてなブログ」では元から存在していないため！

　ブログ各記事中に手書きの「ＨＴＭＬ」にて、「ｈ２」の見出しも入れてみると、このエラーは消える。しかし、「ユーザー補助」指標それ自体の点数は上がらなかった（汗）。どころか、ブログ記事の「ｈ２」と「ｈ３」の間における「ｈ３」見出しの直前に、「はてな」側にて「広告画像」を自動で挿入してきて、レイアウト・シフトも発生してしまう！――ナンでやねん！？　おそらく広告画像の分だけ「ＴＢＴ」や「ＴＴＦＢ」などが重たくなるとも思うので、比較考量して対応不要と推測――

２０－２－７．「ドキュメントにメインのランドマークが設定されていません」

（２０２５年１０月２２日（水）後日付記）

　２０２５年１０月２０日ごろから、「ユーザー補助」に新たな指標「ドキュメントにメインのランドマークが設定されていません」が追加されたようだ。ただし、これによって、「ユーザー補助」指標の点数が悪化したなどの事実はなかった。

　しかし、以下の「ＡＩによる概要」によれば、「はてなブログ」」にかぎらず、世間一般的なブログでは、解消できなさそうな……（汗）。

「ドキュメントにメインのランドマークが設定されていません。」→「「ドキュメントにメインのランドマークが設定されていません」というメッセージは、ウェブアクセシビリティの観点から、ウェブページの主要なコンテンツ部分が明確にマークアップされていないことを意味します」「これは、主に目の不自由なユーザーがスクリーンリーダー（画面読み上げ機能）を利用してウェブサイトを閲覧する際に問題となります」「解決方法：この問題を解決するには、HTML5の

要素、またはWAI-ARIAのrole="main"属性を使用して、ページの主要なコンテンツ部分を明示的に指定する必要があります」
www.google.com

２０－３．「おすすめの方法」の指標における「診断」については、以下のとおり

２０－３－１．「HTTPS が使用されていません 」「サポートを終了した API が使用されています」「サードパーティ Cookie が使用されています」「ブラウザのエラーがコンソールに記録されました」「問題が Chrome デベロッパー ツールの [Issues] パネルに記録されました」

　「はてなブログ」ではイジりようがない箇所だとも思われるので、放置する！（「はてなブログ」全般で、同じ現象が生じている。……と云いたいところだが、当該デザインと同じ「はてなブログ」の「ＰＲＯ」版の一部では、「サポートを終了した API が使用されています 」のみが、あるいは左記と「ブラウザのエラーがコンソールに記録されました」のみが「赤」として出現しているものもあった。なにゆえに！？）

　「HTTPS が使用されていません 」エラーについては、同一記事での計測ではあっても、このエラーがマレに出現したりしなかったりもする。出現すると、「おすすめの方法」の指標が、39点（赤点）などに急落してしまう。「はてな無料ブログ」の場合、都度都度で自動挿入してくる広告が異なっているので、その広告の種類によって、「HTTPS」ではなく「S」ヌキでの旧来の「HTTP」が使用されていることもあって、それが原因で発生するのでは？　と推測している。

２０－４．「ＳＥＯ」の指標における「診断」については、以下のとおり

２０－４－１．「リンクはクロールできません」

　「はてなブログ」それ自体の規定の「コメント欄」や「ツイートボタン」のことであったので、変更不可能！（「はてなブログ」全般で、同じ現象が生じている）

２０－４－２．「画像要素に [alt] 属性が指定されていません」

　ブログのトップページや個別記事についての「Page Speed Insights」の「ＳＥＯ」指標で、上記が発生した場合には、該当の画像に「ａｌｔ」属性（＝画像の非表示の説明・注釈テキスト）を付加するかたちで再アップロードすれば解消できる。「ａｌｔ」属性（＝画像の非表示の説明・注釈テキスト）は、視覚障碍者用のソフトであれば、音声で読み込みされるかたちで利用されるものである。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　旧「はてなダイアリー」ＵＲＬを、改めて新ＵＲＬに一括置換

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

２１．後日付記：旧「はてなダイアリー」から新「はてなブログ」へ移行した際の「ＵＲＬ」の変更については、いわゆる「３０１リダイレクト」なのだそうで、「ＳＥＯ」対策におけるいわゆる「３０２リダイレクト」問題は発生しない

　よって、「ＳＥＯ」対策においては、旧「はてなダイアリー」時代の「ＵＲＬ」をリンクとして貼っておいても、そのままでＯＫ!?

（２０２５年５月２４日（土）加筆）

２１－１．試しに、いくつかの記事で、旧「ＵＲＬ」での多数のリンクを、新「ＵＲＬ」に修正してみて、「Page Speed Insights」にて計測してみたが……、やはりすべての指標で有意な差（改善）は見受けられなかった

２１－２．しかし、旧「はてなダイアリー」のＵＲＬのことではなく、単にＵＲＬの「大文字」と「小文字」や末尾の「／」のアリ・ナシの相違については、「３０１」ではなく「３０２」側の望ましくはないリダイレクトだとして、「Page Speed Insights」側ではなく「Google サーチコンソール」側にて判定されてしまうので、修正した方がイイ！

２１－３．といったソバから、「パフォーマンス」の指標以外の「ＴＴＦＢ」（Time to First Byte＝リクエストからレスポンスの最初のバイトが到着するまでの時間）なる指標についての、以下のサイトの説明やその「TTFB を改善する方法」を参照してみると、「３０１」側のリダイレクトについてもよろしくはない……といった意味の記載があった！（爆）

……ということは、Ｗｅｂページ内の外部リンクや内部リンクも、たとえ画面遷移はせずとも、事前に「リンク切れ」や「リダイレクト」の有無については、リンク先どころかそのリンクを貼ったページを表示する前の段階にて確認しているということなのか？

２１－４．この「ＴＴＦＢ」とは、「ＦＣＰ」や「ＬＣＰ」にも先行する、その意味ではラボデータならぬフィールドデータ側の「ＦＣＰ」と「ＬＣＰ」の内訳としても含まれている稼働時間のことであるらしい！　スマホでの画面遷移がやや重たいのはこれが原因なのやも!?

最初のバイトまでの時間（TTFB）  |  Articles  |  web.dev
web.dev

２１－５．当該「Hatena for はてなブログ」のブログ・デザイン（＝２０２５年５月３１日以前に使用していたデザイン・汗）を使用しているヨソさまのブログや、それ以外のデザインのブログに、「はてなブログ」以外のブログなどのトップページならぬ各記事のＵＲＬを、「Page Speed Insights」にて計測してみた

　すると、たしかに概して「ＴＴＦＢ」指標が、８００ミリ秒（０．８秒）以下（スマホの場合の基準）の「緑」（90点以上）にはなっていた。ちなみに、拙ブログの場合については、１８００ミリ秒（１．８秒）超過（スマホの場合の基準）の「赤」（50点未満）になっている（爆）。……加えて、過去記事へのリンクを貼りまくっていることが影響して、「ＴＴＦＢ」指標が悪化している可能性についても憶測――後日付記：　結果的には過去記事へのリンクが原因ではない模様。真犯人については後述――。

　……しかし、同じデザインの先のブログ記事においては、ラボデータ側の「ＬＣＰ」は「オレンジ」（50点以上～90点未満）であったのに、フィールドデータ側の「ＬＣＰ」は「緑」（90点以上）になっていた（個別記事ではなく全記事の平均値だとはいえ……）。その他の記事についても、画像の有無などの大差はなかったハズなのに、これはどういうことなのか!?）

２１－５－１．よって、旧「はてないダイアリー」時代の過去記事へのリンクのＵＲＬを、先の「１０－２」のツールを使用して一括置換してみた

　ただし、「ＴＴＦＢ」項目については、「Page Speed Insights」の「パフォーマンス」項目の内訳ではない。「Page Speed Insights」の上方に表示されている、「直近28日間の平均値」としてのフィールドデータ側の項目である。よって、28日後に再確認をして、その結果を当該項目に加筆することにしよう！

　ちなみに、この一括置換によっても、「パフォーマンス」指標の内訳としての「ＦＣＰ」「ＬＣＰ」「ＴＢＴ」「ＳＩ」などの項目には、有意な差（改善）は見受けられなかった。「スマホ」側からの画面遷移においても、少しは早くなったような気がするが（錯覚？　願望？）、大差はないような……。

　拙ブログにおいては、「３０１リダイレクト」になるのだから問題ナシであろうと放置していた、旧「はてなダイアリー」時代の過去記事ＵＲＬへのリンクを、万が一、他にも悪影響を及ぼさないようにと、以下の２種のルールで一括置換した。

（１）．旧「はてなダイアリー」時代の過去記事ＵＲＬ　⇒　新「はてなブログ」時代の過去記事ＵＲＬ
（例１：『http://d.hatena.ne.jp/katoku99/1』　⇒　『https://katoku99.hatenablog.com/entry/1』）・・・末尾の１は、1900年代の日付に設定したＵＲＬの変換用
（例２：『http://d.hatena.ne.jp/katoku99/2』　⇒　『https://katoku99.hatenablog.com/entry/2』）・・・末尾の２は、2000年代の日付に設定したＵＲＬの変換用
（例３：『http://d.hatena.ne.jp/katoku99/』　⇒　『https://katoku99.hatenablog.com』）・・・上記２種を一括変換後、最後にトップページの旧ＵＲＬの変換用

　ただし、「サイドバー」に設置した、過去記事への旧ＵＲＬを手書きにした「リンク」モジュールや、「ヘッダ」設定欄などのグローバルメニューに「ＨＴＭＬ」にて記述した過去記事への旧ＵＲＬについては、一括置換されないとも思われる（多分）。それらについては、手書きにて修正すること！

（２０２５年１０月１２日（日）加筆）
　以下の企業系サイトさまの記事に、「サーバー応答速度はTTFBという指標で表すことができます」「リダイレクトは別ページへの転送を意味します。つまり、HTMLデータを生成すべき最終的なURLを決めるまでに時間がかかるため、データ生成が始まるまでの時間を遅らせてしまいます」「内部リンクにリダイレクトされるような古いURLを記載している場合は、リダイレクトが不要な最終的な正規URLにリンク先を変更する」といった記載もあった。
　この記載に依拠するのであれば、旧ＵＲＬでの記載を残したことによるリダイレクト用のＨＴＭＬデータの生成によって、「ＴＴＦＢ」が遅延しているといった解釈もできるであろう。
（なお、この企業系サイトさまの記事は、２０１９年の記事である。同記事中にもあるとおり、２０２１年５月からのグーグル検索における「Core Web Vital」指標が採用される直前の記事である。「Core Web Vital」指標は最優先ではないとの記述は、２０１９年当時のものなので、誤解のなきように……）
www.sakurasaku-marketing.co.jp

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　「Page Speed Insights」と「lighthouse」での計測結果に相違はない!?

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

２２．後日付記：「Page Speed Insights」とは別に、２０２３年１２月１日に廃止になったというＧｏｏｇｌｅの「モバイルフレンドリーテスト」という検証サイトの代替として、「lighthouse（ライトハウス＝灯台）」という検証サイト（というのか、Ｇｏｏｇｌｅのブラウザ「Ｃｈｒｏｍｅ」の「拡張機能」）も存在する

（２０２５年５月２４日（土）加筆）

２２－１．しかし、「Page Speed Insights」とも共通の結果画面が表示されるものであった。その数値にも大差がないような……

　何の意味があるのであろうか？（汗）　「Page Speed Insights」だけで足りるし、「Page Speed Insights」の下半分の「ラボデータ」結果の部分が、「lighthouse」による計測結果だとの記載も見つけた。加えて、「Page Speed Insights」の方が、検証結果も早く画面表示されているような……。

――２０２５年９月２７日（土）後日付記：　Ｇｏｏｇｌｅのブラウザ「Ｃｈｒｏｍｅ」の「拡張機能」としての「lighthouse」側を機動させると、「Page Speed Insights」と同一の画面が表示されるようになった模様――

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　拙ブログの２０２５年５月時点の問題点

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

２３．後日付記：２０２５年５月時点での問題点。「スマホ」側については問題アリ。当該ブログのデザイン側ではなく、拙ブログ固有の問題点でもなく、「はてなブログ」一般の問題点でもあったらしい、あるいは「はてなブログ」に関係なく、あらゆるサイトで問題になっているらしい、「画像」ならぬ「テキストブロック」こと「記事それ自体のタイトル」の描画に時間を要して、「ラボデータ」側の「ＬＣＰ」指標こと「表示速度」が悪化してしまう……といった整理ができる

（２０２５年５月２４日（土）加筆）

　まさかと思うが、超・長～い記事ゆえにではなくって、「記事タイトル」それ自体が超・長いゆえであったからだとか？　→　短くしてみたが、有意な差（改善）は発生しなかった……。

――２０２５年７月１２日（土）後日付記：　先にも言及したが、『「最大コンテンツの描画」要素』なる指標が、２０２５年６月下旬から急に消えてしまった模様。「Page Speed Insights」に併設された掲示板の類いを見てみても、この指標は評判が悪かったようなので（汗）、廃止されてしまったのでは？　とも憶測……。２０２５年８月３日（日）後日付記：　「LCP breakdown」（＝「LCP の内訳」）名義の指標に変えて残存していたことを確認。しかし、一律に「〇」（エラーなし）にされている。ところが……。Ｇｏｏｇｌｅのブラウザ「Ｃｈｒｏｍｅ」側の「拡張機能」での「Page Speed Insights」と同等の機能でもある「lighthouse」側では、旧来の「最大コンテンツの描画」要素がまだ残存していたものの。２０２５年９月２７日（土）後日付記：　「lighthouse」側でも、旧来の「最大コンテンツの描画」要素がなくなって「LCP breakdown」（＝「LCP の内訳」）名義の指標に変更された模様。どころか、「lighthouse」側を機動させると、「Page Speed Insights」と同一ＵＲＬの画面が表示されるようになった模様――

――２０２５年１０月１８日（土）後日付記：　１０月１７日（金）夜間から、「Page Speed Insights」の計測結果の表示方法がビミョーに変更されている。パソコンで計測して表示させる分には従来どおりである。しかし、タブレットとスマホで計測して表示させる分だと、「パフォーマンス」指標が「インサイト」と「診断」に上下分割されずに混合されていた２０２５年の５～６月以前の表示方法に戻ってしまっている模様である。しかも、タブレットとスマホで計測して表示させている分だと、スマホ側のラボデータ側の「ＬＣＰ」指標内における「最大コンテンツの描画」の意味だとも思われる「Largest Conentful Paint element」が「赤」にて表示されてくる！　どういうこと？　ウ～ム。指標としては廃止、あるいは一時的に停止されたが、復活になった、あるいは復活予定、もしくは間違って復活してしまった、といったことなのか？　とはいえ、拙ブログにおいては、その内訳実態は「テキストブロック」でもあるので、後述する理由で無視をしても支障はないのでもあった。「パフォーマンス」指標の点数にも、特に悪化したなどの変化は見られなかった（ヨソさまのブログも計測してみると、パソコン側でも「インサイト」と「診断」に上下分割されずに混合されている（汗）。１０月２１日付記：　同日夜間から、世間さまのブログやサイトを測定してみても、７月以降の「インサイト」と「診断」に上下分割しての表記に無事に戻っていた――

２３－１．昨今では、この「スマホ」側での表示の速さが、グーグル側での検索ランキングにおいては重視されているので、「ラボデータ」側の「ＬＣＰ」が基準だとすれば、その点についてはキビしい――後日付記：　正解は「ラボデータ」側ではなく「フィールドデータ」側が指標であった！――

２３－２．「スマホ」画面側の「パフォーマンス」指標に占める「ＬＣＰ」指標については、試しに当該デザインテーマ「Hatena for はてなブログ」（＝２０２５年５月３１日以前に使用していたデザイン・汗）を使用しているヨソさまのテキスト・文章主体のブログの各記事と、はてな社の本家「はてなブログ開発ブログ」（！）の各記事なども計測してみた

　やはり、「記事それ自体のタイトル」や、ファーストページに表示されている長めの「段落」こと「テキストブロック」が、『「最大コンテンツの描画」要素』となって、常に「レンダリング遅延」が発生しており、「赤」（50点未満）にもなっていた！（爆）

　よって、前述してきた「レンダリングを妨げるリソースの除外」なども効果があったようには見えなかったので、現時点ではもう処置の施しようがないことにもなってしまう……。

２３－２－１．とはいえ、先の「２１－４」においても言及したこととも同様で、「Page Speed Insights」の上半分に表示される直近28日平均の「フィールドデータ」側の「ＬＣＰ」指標については、前述のヨソさまのブログ記事や「はてなブログ開発ブログ」においても、「ラボデータ」側の「ＬＣＰ」が「赤」になっていたこととは真逆で、はるかに高スコアで「緑」（90点以上）になっていたりもする……

　個別記事ではなく全記事の平均値だとはいえ、各記事ごとの画像の有無や多寡などには大差はないようにも見えるのに……。ナンでやねん？

２３－２－２．「Page Speed Insights」の上半分に表示される直近28日平均の「フィールドデータ」側の「ＬＣＰ」指標と、下半分に表示される「ラボデータ」側の「ＬＣＰ」指標については、下記のグーグルさまのサイトでの説明によれば、その基準が違うようだ（爆）

web.dev

「ラボテスト（ラボデータ）では、比較的小さなビューポートを備え、ページの「ヒーロー画像」が最初は「画面外にレンダリング」される Moto G4 スマートフォンをエミュレート（模倣）しているため、「テキスト ブロック」が「LCP 要素」として識別される場合があります」
→　「ラボデータ」側では、ファーストページ（トップページ）にて画面上で見えている「テキストブロック」が、「ＬＣＰ」として判定されがちではある。

「ただし、フィールドデータには、画面が大きい Google Pixel XL（スマホ）のユーザーがほとんど含まれている場合があり、そうしたユーザーにとっては、読み込みに時間がかかる「ヘッダー画像」が「LCP 要素」です」
→　「フィールドデータ」側では、一番重たい「画像」が、「ＬＣＰ」として、一応は判定されるものでもある（例外は後述）。

「ラボ（ラボデータ）では、「ページが完全に読み込まれるまでブラウザが待機」し、「LCP 要素を特定」します」
→　「ラボデータ」側では、ファーストページ（トップページ）にて画面上で見えている「テキストブロック」を「ＬＣＰ」として判定されがちである、といった説明とは矛盾しているようには思えるものの、「画像」も含めた（？）ページのダウンロードが完了するのを待って、「ＬＣＰ」が何であったのか？　を特定している。

「ただし、実際のブラウザ（＝フィールドデータ）では、ユーザーが「ページをスクロールまたは操作」すると、「サイズの大きい要素のモニタリングが停止」します」
「これは、ユーザーは通常、ページが読み込まれた「ように見える」まで待ってから操作を開始するため、「LCP 指標が検出しようとしているのはまさにそのこと」です」
「また、ユーザーの操作後にビューポート（＝画面の表示領域）に追加された要素を考慮することも意味がありません。これらの要素は、ユーザーの操作が原因で読み込まれただけである可能性があります」
「ただし、ページの「フィールド データ」では、そのページでの「ユーザーの行動に応じて、LCP 時間が短く報告される」可能性があります」
→　文章がこなれておらず、接続詞や逆説の接続詞もおかしい気はするものの、「フィールドデータ」側では、「画像」も含めたページのダウンロードが完了してはいなくても、ユーザーがスクロールやクリックなどを開始してしまうと、そこでもう、一番重たい「ＬＣＰ」要素とは何か？　といった判定は中断・終了されてしまって、それまでの一番重たい要素が「ＬＣＰ」として判定されてくることで、「ＬＣＰ」の数値（秒数）については短く判定されてくる……。

　勝手に要約・超訳させてもらうと、

●後者の「Page Speed Insights」の上半分側に表示される直近28日平均の「フィールドデータ」側の「ＬＣＰ」についても、ブログ各記事の「ページ全体」を対象として、ページ途中や下方の画像も含んでのものである。しかし、ユーザーがスクロールやクリックを開始した瞬間に、「ＬＣＰ」判定は終了するので、「ＬＣＰ」の「最大の要素」もその瞬間の数値になってしまうことで、概して短い数値になる。
●前者の「Page Speed Insights」の上半分側に表示される「ラボデータ」側の「ＬＣＰ」については、ページ全体ではなくスクロールなしで表示されるファーストページ部分が優先されて、「ＬＣＰ」の「最大の要素」はファーストページ（トップページ）の「テキストブロック」にはなりがちである。しかし、「ＬＣＰ」の「最大の要素」ではないものの、たとえページの下方に表示されている部分ではあっても、拙ブログのようにアマゾンの商品画像などを表示させていれば、それも「ＬＣＰ」の「一要素」にはなっている。

　といったようにも、読めるのでもあった。その意味では、たとえページの下方に表示されている部分ではあっても、拙ブログのようにアマゾンの商品画像などについても、遅延読み込みの設定を施していった方がよいようにも思えるのであった。

２３－２－３．仮に拙ブログ主の解読が正しいのであれば、拙ブログの場合には、「フィールドデータ」側の「ＬＣＰ」指標については、各記事ごとのページの最後の方に設置してある「アマゾン商品画像」のレンダリング（描画）に時間を要してしまっていることも一因になってしまうのやも？

　そうなると、これに対しての対策は、先の「１８－１」においても言及したとおりで、全記事に対して「アマゾン商品画像」をゼロにはせずとも、複数ある分については１つに減らすか、すべてを残すにしても、各々に対しての「遅延読み込み」設定をひたすらに施すしかなくなってしまう～（汗）。

――２０２５年１０月１１日（土）後日付記：　「フィールドデータ」側の「ＬＣＰ」指標については、拙ブログにおいては、「ラボデータ」側の「ＬＣＰ」指標よりもはるかに小さい数値であった。前者の「フィールドデータ」側の「ＬＣＰ」指標の方が、グーグル検索における「Core Web Vital」の指標となるので、「ラボデータ」側の「ＬＣＰ」指標については最重要視はしなくてもよいとも思われる。「フィールドデータ」側の「ＬＣＰ」指標については、「アマゾン商品画像」よりも、それに先立つ「ＴＴＦＢ」指標の影響の方が大きいそうだ。
　ただし、「アマゾン商品画像」については、ゼロにはせずとも複数ある分については１つに減らすか、すべてを残すにしても、各々に対しての「遅延読み込み」設定をひたすらに施すことについては、２０２５年５月の下旬から、週に４～６記事程度に対して実施中ではある――

――２０２５年１０月２２日（水）後日付記：　「アマゾン商品画像」については、　「ラボデータ」および「フィールドデータ」側の「ＬＣＰ」指標および「ＦＣＰ」指標についても、あまり問題ではなくなったのかもしれない。前述した「１８－１－８．２０２５年１０月２０日ごろから、「アマゾン商品画像」が「オフスクリーン画像の遅延読み込み」項目にてエラーにならなくなった？」の項目を参照のこと――

２３－２－４．あと、過去記事へのリンクとして、各記事の末尾に「はてなブログカード」を大量に設置していることについても、なんらかの遅延の問題が発生していそうではある

　これを回避するためには、「１６－１－１」にて言及したオリジナルの「はてなブログカード」や、単なる「ＵＲＬ」によるリンクへの一括置換が必要であるのやも……。

――２０２５年１０月１１日（土）後日付記：　「はてなブログカード」については、後述する「２６．「サイドバー」と「はてなブログカード」と「内部リンク」」の項目側を参照のこと！――

２３－２－５．しかも、グーグルさま自身の最新研究（！）においては、「フィールドデータ」側の「ＬＣＰ」指標が遅延・悪化する原因については、画像などのサイズやそのレンダリング遅延だけに起因するのではなく、それに先だっての「ＴＴＦＢ」の方が大きいのだとのこと！

　加えて、「ラボデータ」側の「ＬＣＰ」指標については、「ＴＴＦＢ」をその内訳には含んではいなかった……といった説明を発見！
web.dev

２３－２－６．そうなると、先の「２１－３」でもふれた、「ＴＴＦＢ」指標が悪化する要因のひとつとしての「３０１＆３０２リダイレクト」問題こと、拙ブログにおける過去記事への膨大な数のリンクについては、旧「はてなダイアリー」時代の旧「ＵＲＬ」は「３０１リダイレクト」されるから……といった理由で放置してきてしまった根本問題もあらためて浮上してくるのだ……

２３－２－７．つまり、「Page Speed Insights」の下半分に表示される「ラボデータ」側の「ＬＣＰ」指標の原因が、画像ではなくテキストブロック（長めの記事タイトルや本文の段落）であった場合で、上半分に表示される直近28日平均の「フィールドデータ」側の「ＬＣＰ」指標の数値は小さかった場合には（たいていはそうなっているハズ！）、後者がグーグル検索における「Core Web Vital」の指標となっているので、前者のテキストブロック（長めの記事タイトルや本文の段落）の件は無視してもよいことになる！

２３－３．同じく「パフォーマンス」指標に占める比重としては小さめ（１０％）なれども、「スマホ」側での「ＦＣＰ」指標なる、これまた表示速度の基準の内訳においては、各記事ごとのアイキャッチ画像に使用している「アマゾン商品」の各々が数十キロバイト程度の画像についても、やや重たいとも判定されている

　しかし、オリジナルの軽い画像なんぞは用意はできない。先にも言及した「アマゾン画像」の「遅延読み込み」の「診断」項目については「赤」から「オレンジ」にはなったものの、「ＦＣＰ」指標としては点数向上などの改善はあまりなされてはいなかった（爆）。かといって、画像を皆無にしてしまう記事もまた味気がない――いや、いっそ、アマゾンの商品の画像はナシ。アイキャッチとしてのアマゾン画像もナシの記事にしてしまうか？（汗）――。

２３－４．旧「はてなダイアリー」時代の過去記事ＵＲＬを一括変換したので、その処置の単独としての成果を見るために、その28日後に「ＴＴＦＢ」指標に変化が生じたか否かを確認してみよう！　その後に、「サイドバー」を大幅に削ってみて、その28日後に「ＴＴＦＢ」指標に変化が生じたか否かを確認してみよう！

　しかし、仮に前者の処置にて「ＴＴＦＢ」指標に大きな変化（改善）が生じるのであれば、「サイドバー」はそのままにするか？　けれども、実験用の「サイドバー」がほとんどないサブ・ブログ側では、「スマホ」の場合での画面遷移が明らかにカルいのだから、やはり「サイドバー」はもう少し削るべきなのか？（ただし、ゼロにする気もない。そこはバランスである・笑）

２３－４－１．「ＴＴＦＢ」指標の「フィールドデータ」ならぬ「ラボデータ」側の方についても、以下のグーグルさまの「ＴＴＦＢ」の説明における「TTFB を測定する方法」の「ラボツール」の項目によれば、実は参照可能ではあった。しかも、いくつかの方法があるようだ

　しかし、その実際の操作方法・参照方法についてはイマイチわからず……（汗）。
web.dev

　とりあえず、以下の「Web Page Test」サイトでの計測でよいようだ。その計測結果でもある「Page Performance Metrics」の１行目（１回目）と２行目（２回目）のおのおのの先頭（一番左）に、「Time to First Byte」（＝日本語に自動翻訳された場合には、「最初のバイトまでの時間」）名義で、「ＴＴＦＢ」指標が表示されるのであった。（１ヵ月に３００回の使用が可能。上限に達したとしても、翌日には少数回の使用が可能）

「Web Page Test」サイト
https://www.webpagetest.org/

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　拙ブログの２０２５年５月時点で効果があった施策

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

２４．後日付記：２０２５年５月時点での効果があった施策。結局は、「Page Speed Insights」の下半分に表示される「ラボデータ」側の「ＣＬＳ」「ＬＣＰ」「ＴＢＴ」「ＦＣＰ」などを内訳に含んだ「パフォーマンス」指標については、実は拙ブログにおいては何ひとつとして効果的な施策が存在しなかった！（爆）　……しかし！

（２０２５年５月２５日（日）加筆）

２４－１．「ツイッター」のタイムライン表示を、ブログのサイドバーへ埋め込みする件については、数年前に廃止済であるので未検証（ただし、使用当時は明らかに盛大に「レイアウト・シフト」が発生していた……）

２４－２．あとは、旧「はてなダイアリー」時代の旧ＵＲＬを新「はてなブログ」の新ＵＲＬへと一括変換して、「３０１リダイレクト」が発生しないようにした施策の効果と、もともと大量にあった「サイドバー」のモジュールの大幅減少による施策の効果が、「Page Speed Insights」の上半分に表示される直近28日平均である「フィールドデータ」側の「ＴＴＦＢ」指標などに発生するか否かを様子見することにしよう

――「Page Speed Insights」の上半分の「フィールドデータ」側については、各種指標が何も表示されていないブログやサイトも存在している（＝「データがありません」と表示される）。その理由は、そのサイトやブログはそもそものアクセスの絶対数が少ないので（汗）、フィールドデータとしての「ＬＣＰ」「ＦＣＰ」「ＣＬＳ」の有意なデータも存在していないから、といった意味になる――

２４－３．そして！　「ラボデータ」側ならぬ、「Page Speed Insights」の上半分に表示される直近28日間平均の「フィールドデータ」側の「ＣＬＳ」「ＬＣＰ」「ＦＣＰ」、および「ＴＴＦＢ」「ＩＮＰ」指標においては、２０２５年５月８日時点と５月２５日時点とでの１７日間をおいての両者を比較してみると、それらすべてで数値が向上してはいたのであった！

　以後も日々、各々の指標で毎日、改善されていった。そして、「パソコン」側については、翌月６月８日に「ＬＣＰ」が２．５秒以下の「緑」（90点以上）を達成できたことで、「Page Speed Insights」上では「合格」表記になった！

　６月１５日現在でも２．２秒とまだじょじょに早くなっている（「ＴＴＦＢ」の秒数もじょじょに改善されてはいっているものの、こちらはまだ「赤」（50点未満）であった（汗）。６月下旬には「ＬＣＰ」は１．９秒。「ＴＴＦＢ」は１．６秒で「オレンジ」（50点以上～90点未満）を達成）。
　「スマホ」側の「ＬＣＰ」も、同じく６月８日には２．６秒に達した。その後も、２．５秒以下の「緑」（90点以上）にはあともう少しの２．５秒超は達している。しかし、この２．５秒以下がなかなか達成できなかった。けれども、６月１７日になって、ようやく２．５秒以下を達成して、「Page Speed Insights」上でも「合格」表記になったのであった――試しに「Google サーチコンソール」側を参照してみると、その前日の６月１６日には達成したことになっていた……。なにゆえに？――

２４－３－１．「フィールドデータ」と「ラボデータ」とでは基準が異なるとはいえ、「ラボデータ」側の「ＣＬＳ」「ＬＣＰ」「ＦＣＰ」の数値については、まったく改善が見られなかったというのに……

２４－３－２．ということは、「フィールドデータ」側の「ＣＬＳ」「ＬＣＰ」「ＦＣＰ」の数値については、「フィールドデータ」側の「ＴＴＦＢ」指標の方が影響していると考えるべきであろう。具体的には何が奏功したのであろうか？

　「レイアウト・シフト」の対策は実施していない。「画像」の圧縮対策なども実施していない。「アマゾン画像」の遅延読み込みについては、直近の２０２５年５月２５日計測の前日である５月２４日に最新５記事に対してのみ実施しただけであって、直近28日間の平均値への影響はほぼナシになるハズだ。そうなると、心当たりは、

①：前月４月２７日に、拙ブログの「スマホ」画面での表示方法を、「パソコン」側とも同一の画面を表示させる設定から「はてなブログ」規定の「スマホ」版を表示させる方式へと変更したことで、「スマホ」で表示される文字が少々大きくなって、トップページ自体は「最新７記事の見出し一覧」へと変更したことで、なおかつおそらくその表示スピードも増したこと（……しかし、５月３１日に「はてなブログ」のデザインそれ自体を変更し、レスポンシブデザイン対応で、トップページ自体も「最新５記事の全記事」に再び変更したことで、その後の再度の悪化要素にはなったやも？・汗）

②：５月のゴールデンウィーク明けあたりで、膨大なるモジュールを設定していた「サイドバー」を半減させたこと（……スマホでの画面遷移は体感的にも早くなった。しかし、世間一般の「はてなブログ」のそれらと比すれば遅いものの・汗）

③：５月２１日に、膨大にあった過去記事へのリンクである旧「はてなダイアリー」時代のＵＲＬを、新「はてなブログ」でのＵＲＬへと一括置換にしたこと

……仮説にはなるものの、これらの施策によって、諸指標に先行している「ＴＴＦＢ」の数値がじょじょに改善していったことで、釣られて「フィールドデータ」側の「ＣＬＳ」「ＬＣＰ」「ＦＣＰ」の数値も向上していったのでは？　と推測している……（まぁ、「ＣＬＳ」（レイアウト・シフト）の減少については、表示速度の向上とは無関係ではあるので、腑には落ちないものの……）

（２０２５年１０月２５日（土）　後日付記）
　「Page Speed Insights」側の上半分のフィールドデータ側のリンク「過去28日間（履歴）」から遷移ができる、実際には毎週の金曜日基準での過去28日間の平均値（月曜の１１～１４時ごろに算出されて表示）の画面側では、過去１０ヵ月分の毎週金曜日のフィールドデータが「折れ線グラフ」形式にて参照できる。
　施策を開始する直前である２０２５年４月２５日（金）からその28日後である５月２３日（金）までと（＝サイドバーの半減の効果が出たであろう期間にほぼ相当）、膨大にあった過去記事へのリンクである旧「はてなダイアリー」時代のＵＲＬを新「はてなブログ」でのＵＲＬへと一括置換にした５月２１日からほぼその28日後であって、各種指標の数値の改善が停滞してしまった直後であった６月２０日（金）までの４週間。合わせて、８週間（56日間）の数値の変化は、以下のとおりであった。

●パソコン側：
・［ＬＣＰ」　：３．９秒（爆・オレンジ）　→　３．１秒（オレンジ）　→　１．９秒（緑）
・「ＦＣＰ」　：３．８秒（爆・赤）　　　　→　３．０秒（オレンジ）　→　１．９秒（オレンジ）
・「ＴＴＦＢ」：３．５秒（爆・赤）　　　　→　２．５秒（赤）　　　　→　１．６秒（オレンジ）

●スマホ側：
・［ＬＣＰ」　：４．３秒（爆・赤）　　　　→　３．３秒（オレンジ）　→　２．５秒（緑）
・「ＦＣＰ」　：４．４秒（爆・赤）　　　　→　３．２秒（赤）　　　　→　２．５秒（オレンジ）
・「ＴＴＦＢ」：３．８秒（爆・赤）　　　　→　３．０秒（赤）　　　　→　１．９秒（赤）

２４－４．しかし、６月１７日以降は、「スマホ」「パソコン」側ともに「フィールドデータ」側の「ＣＬＳ」「ＬＣＰ」「ＦＣＰ」「ＴＴＦＢ」各指標の改善は停滞してしまったのであった。６月２７日には恐れていた「スマホ」側の「ＬＣＰ」が２．５秒超になってしまって、再度の「不合格」になってしまったのであった（爆）

（２０２５年６月２８日（土）加筆）

２４－４－１．原因は不明である。２０２５年５月３１日（土）に拙ブログのデザインそれ自体を変更して、「スマホ」側のトップページを「最新７記事の見出し一覧」ではなく「最新５記事の全表示」へと変更してはいるものの、それからでももう１ヵ月弱も経ってからでもあった。境界線上の数値ではあったので、ちょっとした変動で２．５秒の「以下」から「超過」へと変化してしまったものであろうか？

（２０２５年１０月２５日（土）後日付記）
　あらためて原因が判明。主に「サイドバーの半減」と、過去記事へのリンクである旧「はてなダイアリー」時代のＵＲＬを新「はてなブログ」でのＵＲＬへと一括置換にしたことでの「不要なリダイレクト接続の消失」であった。後者は遅れて５月２１日に実施している。それから２８日が経過したことで、６月１７日あたりでフィールドデータ側での改善数値が一定に達したからである。

２４－４－２．「ＬＣＰ」改善の一般は、画像の「軽量化」や「遅延読み込み」なのであって、後者については記事中の「アマゾンの商品画像」に対する「遅延読み込み」処置を、引き続き対応していくつもりではある

２４－４－３．しかし、繰り返しにはなるが、拙ブログについては、「Page Speed Insights」の上半分に表示される直近28日間平均の「フィールドデータ」側の「ＬＣＰ」に先立つ要素でもあるという「ＴＴＦＢ」指標の改善の方が問題だったのでは？　とも推測している。この「ＴＴＦＢ」指標の秒数が増えてしまう一因でもある、過去記事への「３０１リダイレクト」の問題については、過去記事ＵＲＬを一括置換することで解消していた。その効果によるものとも思われる「ＴＴＦＢ」の秒数も、「スマホ」の場合には３．８秒（爆）から１．９秒へと２秒近くもの大幅な削減（半減）もできていた（それでもまだ「オレンジ」だけれども・汗）。そのうえで、具体的には拙ブログにおいては、画像付きの「はてなブログカード」による過去記事へのリンクの多さが尋常ではないので（笑）、こちらが「ＴＴＦＢ」に悪さをしている可能性も考慮して、そちらも減らしていこうとも考えてはいる

　ただし、「はてなブログカード」それ自体は、「はてなブログ」の「サイドバー」とも同様に、「画像遅延読み込み」は初期装備はされている。それは拙ブログの画面を下方へと急速スクロールをしていくと、そこで画像が初めて描画されていくことが、目に見えてわかる事象でもある。近年になってからの改良された仕様なのやもしれないけれども……。

　それとも、半減はさせたものの、世間一般的にはなお膨大であろう「サイドバー」のモジュールの多さが問題なのであって、それが「スマホ」画面であればサイドバーならぬ記事の最下部に表示されてしまうことがネックになっているのであろうか？
　そもそも、過去記事への画像リンクならぬ、単なるテキスト・リンクそれ自体の膨大さもまたネックになってしまっているのであろうか？（汗）――「スマホ」画面の場合に、サイドバー（実質、アンダーバー？）を非表示にすることが可能であれば、そうした処置もしてみるか？――

（２０２５年１０月１２日（日）加筆）
　後述する「２６．「サイドバー」と「はてなブログカード」と「内部リンク」の項目側においても、その実験結果について記載。

２４－４－４．加えて、「PageSpeed Insights」にて表示されている「Ｊａｖａスクリプトの実行にかかる時間の低減」の対策としての、「Ｊａｖａスクリプト」の「非同期読み込み・先読み込み・ 遅延読み込み」にも着手しようと検討中である……

２４－５．２０２５年７月２４日に、「スマホ」側の「ＬＣＰ」がふたたび２．５秒以下の「緑」になって、再度の「合格」！

（２０２５年７月２５日（金）加筆。８月３日（日）再加筆）

　毎度、「Ｇｏｏｇｌｅサーチコンソール」の「エクスペリエンス」側では、７月２４日ではなく前日の２３日に「ＬＣＰ」が２．５秒以下（緑）を達成できたことになっている……。しかし……。７月２６日に再び２．５秒超過（オレンジ）へと転落！（汗）

　直下の項目「２５．『デザインＣＳＳ』『Ｊａｖａスクリプト』『各種サイト』の遅延or先読み込み」にて記載した施策と（＝実質、レンダリングをブロックしてくる「はてなブログ」系の「Ｊａｖａスクリプト」の遅延or先読み込み）、外部リンクではなく内部リンク（＝拙ブログの過去記事へのリンク）用の「はてなブログカード」を一括置換ですべて廃止して、ただの青いリンク文字であるＵＲＬに変更している。
　ただし、後者の「はてなブログカード」廃止については、「Page Speed Insights」の下半分のラボデータ側の各指標に毎度、変化は見られなかったものの……。「Page Speed Insights」の上半分のフィールドデータ側の各指標に先だってのものであるらしい「ＴＴＦＢ」指標の方こそを改善したいのだけれども、こちらも今のところは改善が見られず……。

　そうなると、「サイドバー」をもっと減らすべきなのであろうか？　「レスポンシブデザイン」をやめて、「スマホ」側は「はてなブログ」側で用意している「最新７記事の見出し」のみを一覧表示させる形式に変更してしまった方が、軽量化されるのでよいのであろうか？（それは、一番最後の手段にしたいが・汗）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　「デザインＣＳＳ」「Ｊａｖａスクリプト」「各種サイト」の遅延or先読み込み

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

２５．「Page Speed Insight」サイトにて引っかかった、先にも設定した２種の「デザインＣＳＳ」、および「Web Page Test」サイトにて、「レンダリングをブロック」してくる旨で引っかかった４種の「はてなブログ」系の「Ｊａｖａスクリプト」を遅延読み込み、または先読み込みにしてみる

（２０２５年７月６日（日）加筆。７月１６日（水）加筆改訂。その後も順次、加筆改訂）
「Web Page Test」サイト
https://www.webpagetest.org/

２５－１．「はてなブログ」側の「設定」⇒「詳細設定」⇒「head内タグ」⇒「＜head＞要素にメタデータを追加」欄に対して、以下の状態に設定した。

<link rel="preload" href="https://cdn.blog.st-hatena.com/css/blog.css?version=38caf1a85fdfdc17ce7f4fdc07ae02" as="style" onload="this.onload=null;this.rel='stylesheet'">
<link rel="preload" href="https://usercss.blog.st-hatena.com/blog_style/98012380855795339/6733c135bfec664cc1b6e42f9d7aa3f2c27b55a8" as="style" onload="this.onload=null;this.rel='stylesheet'">
（当該行は絶対に設置不要！）<link rel="preload" href="https://usercss.blog.st-hatena.com/-/theme/17680117126981573769.css?version=5c19a9c5d66b0ea153fd63cd43e9bc17b48a05d6" as="style" onload="this.onload=null;this.rel='stylesheet'">（当該行は絶対に設置不要！）
<link rel="preload" href="https://cdn.blog.st-hatena.com/js/external/jquery.min.js?v=1.12.4&version=38caf1a85fdfdc17ce7f4fdc07ae02" as="script">
<link rel="preload" href="https://cdn.blog.st-hatena.com/js/texts-ja.js?version=38caf1a85fdfdc17ce7f4fdc07ae02" as="script">
<link rel="preload" href="https://cdn.blog.st-hatena.com/js/vendors.js?version=38caf1a85fdfdc17ce7f4fdc07ae02" as="script">
<link rel="preload" href="https://cdn.blog.st-hatena.com/js/hatenablog.js?version=38caf1a85fdfdc17ce7f4fdc07ae02" as="script">
<link rel="preconnect dns-prefetch" href="https://www.googletagmanager.com">
<link rel="preconnect dns-prefetch" href="https://www.google-analytics.com">
<link rel="preconnect dns-prefetch" href="https://pagead2.googlesyndication.com">
<link rel="preconnect" href="https://cdn.blog.st-hatena.com">
<link rel="preconnect" href="https://usercss.blog.st-hatena.com">
<link rel="preconnect" href="https://cdn.pool.st-hatena.com">
<link rel="preconnect" href="https://s.hatena.ne.jp">
<link rel="preconnect" href="https://m.media-amazon.com">
<link rel="preload" href="https://fonts.gstatic.com/s/roboto/v48/KFO7CnqEu92Fr1ME7kSn66aGLdTylUAMa3yUBA.woff2" as="font" type="font/woff2" crossorigin>
<meta name="viewport" content="width=device-width, initial-scale=1.0">

・１行目：「https://cdn.blog.st-hatena.com/css/blog.css?version=6c66e5ebdf355ec310245c74edecea」は、「Page Speed Insights」の「レンダリングをブロックしているリクエスト」で表示されたＵＲＬ。「はてなブログ」全体（？）の「デザインＣＳＳ」その１（？）で、「preload」で先読み込み。（※：やや使用しているので、先読み。しかし、「Page Speed Insight」でも「Web Page Test」でも効果なしだと判定。しかも、URLの末尾はひんぱんに変更されていくので、変更された時点で、効果はなくなる（汗）。よって、それに追随して、URLの末尾も変更していくのはメンドウに過ぎるので、当該の設定はナシに決定！）

・２行目：「https://usercss.blog.st-hatena.com/blog_style/98012380855795339/98fd9194e3dba2f7a0e4d43759c444218fd56e89」は、「Page Speed Insights」の「レンダリングをブロックしているリクエスト」で表示されたＵＲＬ。拙ブログが採用したブログデザインの「ＣＳＳ」、および個人で追加した「ＣＳＳ」カスタマイズそれ自体を基に作成された、「はてなブログ」全体（？）の「デザインＣＳＳ」その２（？）で、「preload」で先読み込み。（※：やや使用しているので、先読み。しかし、「Page Speed Insight」でも「Web Page Test」でも効果なしだと判定。しかも、URLの末尾はひんぱんに変更されていくので、変更された時点で、効果はなくなる（汗）。よって、それに追随して、URLの末尾も変更していくのはメンドウに過ぎるので、当該の設定はナシに決定！）

・３行目：「https://usercss.blog.st-hatena.com/-/theme/17680117126981573769.css?version=5c19a9c5d66b0ea153fd63cd43e9bc17b48a05d6」は、「はてなブログ」全体ではなく拙ブログが採用しているデザインそれ自体の「ＣＳＳ」。つまり、個人で追加した「ＣＳＳ」カスタマイズは含まれていない。「デザインＣＳＳ」欄の先頭の方に初期記載されていた「ＵＲＬ」それ自体を転記。「preload」で先読み込み。（※：当該処置については有効に機能した！　しかし！　当然ながら、個人で追加した「ＣＳＳ」カスタマイズは無視されてしまった（初期設定としての表示になってしまった）。どころか、「ＣＬＳ」（レイアウト・シフト）も発生して、０．１超過になってしまったので、当該行の設定それ自体が不要・廃止・削除！）

・４行目：「https://cdn.blog.st-hatena.com/js/external/jquery.min.js?v=1.12.4&version=6c66e5ebdf355ec310245c74edecea」は、「はてなブログ」の「Ｊａｖａスクリプト１（external）」で、「preload」で先読み込み。（※：「Page Speed Insight」では検知されないが、「Web Page Test」では「レンダリングをブロックしている」と判定されるため。「defer」による遅延読み込みでは解消されず。当該の「preload」だと「パソコン」側では有効（「スマホ」側では無効・汗）。しかし、URLの末尾はひんぱんに変更されていくので、変更された時点で、効果はなくなる（汗）。よって、それに追随して、URLの末尾も変更していくのはメンドウに過ぎるので、当該の設定はナシに決定！）

・５行目：「https://cdn.blog.st-hatena.com/js/texts-ja.js?version=6c66e5ebdf355ec310245c74edecea」は、「はてなブログ」の「Ｊａｖａスクリプト２（texts-ja.js）」で、「preload」で先読み込み。（※：「Page Speed Insight」では検知されないが、「Web Page Test」では「レンダリングをブロックしている」と判定されるため。「defer」による遅延読み込みでは解消されず。当該の「preload」だと「パソコン」側では有効（「スマホ」側では無効・汗）。しかし、URLの末尾はひんぱんに変更されていくので、変更された時点で、効果はなくなる（汗）。よって、それに追随して、URLの末尾も変更していくのはメンドウに過ぎるので、当該の設定はナシに決定！）

・６行目：「https://cdn.blog.st-hatena.com/js/vendors.js?version=6c66e5ebdf355ec310245c74edecea」は、「はてなブログ」の「Ｊａｖａスクリプト３（vendors.js）」で、「preload」で先読み込み。（※：「Page Speed Insight」では検知されないが、「Web Page Test」では「レンダリングをブロックしている」と判定されるため。「defer」による遅延読み込みでは解消されず。当該の「preload」だと「パソコン」側では有効（「スマホ」側では無効・汗）。しかし、URLの末尾はひんぱんに変更されていくので、変更された時点で、効果はなくなるものの……（汗）。「Web Page Test」での診断によれば、「～事前にロードされていますが、ページのロード中には使用されません」とのメッセージも表示されるが、当該行での先読み込みがないと、「～サードパーティのリクエストがページのレンダリングをブロックしています」側のチェックで引っかかるので、必要！　しかし、URLの末尾はひんぱんに変更されていくので、変更された時点で、効果はなくなる（汗）。よって、それに追随して、URLの末尾も変更していくのはメンドウに過ぎるので、当該の設定はナシに決定！）

・７行目：「https://cdn.blog.st-hatena.com/js/hatenablog.js?version=6c66e5ebdf355ec310245c74edecea」は、「はてなブログ」の「Ｊａｖａスクリプト４（hatenablog.js）」で、「preload」で先読み込み。（※：「Page Speed Insight」では検知されないが、「Web Page Test」では「レンダリングをブロックしている」と判定されるため。「defer」による遅延読み込みでは解消されず（どころか、サイドバーの「注目記事」などは二重で一覧表示される副作用まで発生！）。当該の「preload」だと「パソコン」側では有効（「スマホ」側では無効・汗）。しかし、URLの末尾はひんぱんに変更されていくので、変更された時点で、効果はなくなるものの……（汗）。「Web Page Test」での診断によれば、「～事前にロードされていますが、ページのロード中には使用されません」とのメッセージも表示されるが、当該行での先読み込みがないと、「～サードパーティのリクエストがページのレンダリングをブロックしています」側のチェックで引っかかるので、必要！　しかし、URLの末尾をひんぱんに変更していくのはメンドウに過ぎるので、当該の設定はナシに決定！）

・８行目：「https://www.googletagmanager.com」は、ブログに「Ｇｏｏｇｌｅタグマネージャー」を自分で設定している場合にのみの処理（……と思ったが、「はてな」社それ自体が「はてなブログ」全体に対して「Ｇｏｏｇｌｅタグマネージャー」を設定しているのであった……）。「Ｇｏｏｇｌｅタグマネージャー」の「外部スクリプト」で、「preconnect」と「dns-prefetch」で、外部スクリプトを事前に接続して読み込ませる。（※：「ＴＢＴ」指標に大きな効果あり！　釣られて、「パソコン」側のラボデータの「ＬＣＰ」ひいては「パフォーマンス」も改善？　しかし、「スマホ」側のラボデータの「ＬＣＰ」と「パフォーマンス」には改善がなかった。けれど！　当該行を先頭行（１行目）に移植すると、「スマホ」側のラボデータの「ＬＣＰ」と「パフォーマンス」もじゃっかん良くなるような！？）

・９行目：「https://www.google-analytics.com」は、ブログに「Ｇｏｏｇｌｅアナリティクス」を自分で設定している場合にのみ、「Ｇｏｏｇｌｅアナリティクス」の「外部スクリプト」で、「preconnect」と「dns-prefetch」で、外部スクリプトを事前に接続して読み込ませる。（※：効果はないようだ・汗）

・10行目：「https://pagead2.googlesyndication.com」は、「Ｇｏｏｇｌｅ関係（汗）」の「外部スクリプト」で、「preconnect」と「dns-prefetch」で、外部スクリプトを事前に接続して読み込ませる。（※：効果はないようだ・汗）

・11～14行目：「https://cdn.blog.st-hatena.com」他の「はてなブログ」系統のドメインは、「Page Speed Insights」では検知されないが、「Web Page Test」側の「ページパフォーマンス」指標のグラフ（図表）を参照すると、「レンダリング開始」前に稼働すべきものであって（？）、それらの稼働所要時間に比して稼働開始時刻が少々遅いので、「preconnect」にしてみた。「Page Speed Insights」側では有意な差は見られない。しかし、「Web Page Test」側ではこれらの稼働開始が早まったことで「レンダリング開始」または「ＦＣＰ」（First Contentful Paint）（描画開始時間）も少々早くなっているようには思える。

・15行目：「https://m.media-amazon.com」の「アマゾン商品画像」のドメインは、「１８－１－２」でも説明したとおり、拙ブログにおいては「アマゾン商品画像」のみのＵＲＬそれ自体を直に読みに行くといったイレギュラーなことを常用しているための処置。「Page Speed Insights」では検知されないが、「Web Page Test」側の「ページパフォーマンス」指標のグラフ（図表）を参照すると、「レンダリング開始」前に稼働すべきものでもあって（？）、それらの稼働所要時間に比して稼働開始時刻が少々遅いので、「preconnect」にしてみた。「Page Speed Insights」側では有意な差は見られない。しかし、「Web Page Test」側ではこれらの稼働開始が早まったことで「レンダリング開始」または「ＦＣＰ」（First Contentful Paint）（描画開始時間）も少々早くなっているようには思える。

・16行目：「https://fonts.gstatic.com/s/roboto/v48/KFO7CnqEu92Fr1ME7kSn66aGLdTylUAMa3yUBA.woff2」は、「はてなブログ」の「フォント（活字）」で、「Page Speed Insight」では検知されないが、「Web Page Test」の「スマホ」側では引っかかったので、「preload」で先読み込み。（※：効果はないのやも・汗）

・最終行：「viewport" content="width=device-width, initial-scale=1.0」は、先に説明したもので、必須設定！

・注釈：実は、上記の１～７行目の「はてなブログ」系の「デザインＣＳＳ」と「Ｊａｖａスクリプト」のＵＲＬの末尾の部分について、その値がひんぱんにランダムに変更されていく。中途の「．ｊｓ」＝（.js）までのところなど、途中までは一致させたＵＲＬでカバーができないかと実験もしてみたが、ダメであった（汗）。とりあえず、「Page Speed Insights」の下半分の「ラボデータ」の計測値については毎度のことながら変化が見られなかったものの、パソコン・スマホともどもに、ブログ画面の遷移は早くなったようには思える（錯覚？　願望？）。よって、「Page Speed Insights」の上半分の「フィールドデータ」側の「ＬＣＰ」および「ＴＴＦＢ」の数値こと直近２８日間の平均値を、これから２８日かけて観測してみることにする。
――２０２５年８月２日後日付記：　１～７行目の「はてなブログ」系の「デザインＣＳＳ」と「Ｊａｖａスクリプト」に対する施策による、「フィールドデータ」側の「ＬＣＰ」および「ＴＴＦＢ」の数値については、有意な変化は見られなかった（汗）――

　１～２行目の、「はてなブログ」共通の「デザインＣＳＳ」や、拙ブログが採用しているデザインそれ自体の「デザインＣＳＳ」での、「preload」での先読み込みの方法については、以下のサイトのコマンドが独特ではあって有用そうでもあったので、こちらを参考・採用した。
misc.laboradian.com

numb86-tech.hatenablog.com

www.webdesignleaves.com
（上記の「media」属性を「print」指定にする方法も気になる。以下のサイトでの説明だと、「media」属性を「print」指定にする方法が良いようにも思える）

qiita.com

　その場合、１～２行目は、以下の４行分になると思われる。しかし、「Page Speed Insight」でも「Web Page Test」でも、「レンダリングをブロックしているリクエスト」については効果なしだと判定（汗）。

<link media="print" onload="this.media='all'" rel="stylesheet" href="https://cdn.blog.st-hatena.com/css/blog.css?version=47e98161b1a3575f5517f7ce16bdce" type="text/css" />
<noscript><link rel="stylesheet" href="https://cdn.blog.st-hatena.com/css/blog.css?version=47e98161b1a3575f5517f7ce16bdce" type="text/css" /></noscript>
<link media="print" onload="this.media='all'" rel="stylesheet" href="https://cdn.blog.st-hatena.com/css/blog.css?version=47e98161b1a3575f5517f7ce16bdce" type="text/css" />
<noscript><link rel="stylesheet" href="https://cdn.blog.st-hatena.com/css/blog.css?version=47e98161b1a3575f5517f7ce16bdce" type="text/css" /></noscript>

　以下の４行分になる記載もあった。しかし、「Page Speed Insight」でも「Web Page Test」でも、「レンダリングをブロックしているリクエスト」については効果なしだと判定（汗）。

<link rel="preload" href="https://usercss.blog.st-hatena.com/blog_style/98012380855795339/a4f74cfbed445736f8fea5bd6006c1cc2bef0316" as="style">
<link rel="stylesheet" href="https://usercss.blog.st-hatena.com/blog_style/98012380855795339/a4f74cfbed445736f8fea5bd6006c1cc2bef0316" media="print" onload="this.media='all'">
<link rel="preload" href="https://cdn.blog.st-hatena.com/css/blog.css?version=a11a0e0f57b771831b00fa2d305c51" as="style">
<link rel="stylesheet" href="https://cdn.blog.st-hatena.com/css/blog.css?version=a11a0e0f57b771831b00fa2d305c51" media="print" onload="this.media='all'">

　実は、先の１行目と２行目の「デザインＣＳＳ」に対する先読み込みや非同期・遅延読み込みの処置が、2025年５～６月には有効に機能していたと思うのだけれども（？）、７月以降、「Page Speed Insights」でのチェックでは、ＵＲＬがその末尾まで完全合致しているのにも関わらず、相変わらずに「レンダリングをブロックしているリクエスト」として引っかかったままになってしまうのであった……。なぜだ？　ウ～ム。当方が別のＪａｖａスクリプトに対して指定した「ｐｒｅｌｏａｄ」などが回りまわって影響しているのだとか？（汗）

　つまり、さんざんに議題にしてきた、先の１行目と２行目の「はてなブログ」それ自体の「デザインＣＳＳ」に対する先読み込みや非同期・遅延読み込みの処置については、「Page Speed Insights」でも「Web Page Test」でもまったく効果がなかったのであった（爆）。あまたの世間一般の「はてなブログ」や同「ＰＲＯ」についても、「Page Speed Insights」と「Web Page Test」にて結果を参照させてもらったが、「レンダリングをブロックしているリクエスト」としての「はてなブログ」それ自体の「デザインＣＳＳ」が解消されているものはひとつとして存在しなかった。よって、放置してもよいと思われる！

　４～７行目の「はてなブログ」の「Ｊａｖａスクリプト１」～同「４」については、「Page Speed Insight」では検知されないが、「Web Page Test」では「レンダリングをブロックしている」と判定される。しかし、それらのＵＲＬの末尾の値については週に１～２回、ひんぱんに変更されていく。それに追随して設定を変更していくのはメンドウに過ぎるし、「Page Speed Insight」側の各種指標でも有意な差が見られないので、当該の設定はナシに決定！

　８行目と９行目の「https://www.googletagmanager.com」と「https://www.google-analytics.com」の「preconnect」と「dns-prefetch」は、「はてなブログ」に「Ｇｏｏｇｌｅタグマネージャー」や「Ｇｏｏｇｌｅアナリティクス」を設定している方オンリーの設定になるやもしれませんけれども（……と思ったが、「はてな」社それ自体が「はてなブログ」全体に対して「Ｇｏｏｇｌｅタグマネージャー」を設定しているのであった……）、以下のサイトを参考にした。
dg-style.net

zenn.dev
（　↑　：　「ＧＴＭ」とは、「Ｇｏｏｇｌｅタグマネージャー」のこと）

qiita.com

zenn.dev
（直上サイトでは、「ｓａｆａｒｉ（サファリ）」というブラウザで参照する場合に「preconnect」と「dns-prefetch」の同時使用ができないともあったが、「ｓａｆａｒｉ」で参照する御仁は少なかろうとも思うので、拙ブログでは同時使用で設定している）

　……などど記してきたが、「Page Speed Insights」の「パフォーマンス」指標における「ネットワークの依存関係ツリー」の最下部には「Preconnect candidates」――「Preconnect」の「候補」――が表示されては来るのだ。しかし、当該で上がってくる「候補」がまた毎度、異なっているのでアテにはならない。

　それらをいろいろと「preconnect」してみたが、「Ｇｏｏｇｌｅタグマネージャー」と「はてな」系と「アマゾン商品画像」のサイト（ドメイン）指定を除いて、特に改善も見られない！（汗）　「Web Page Test」側の「ページパフォーマンス」指標のグラフ（図表）を参照してみても、これらの「preconnect」候補のサイトがレンダリングを遅延させているとは思えない。
　さらに加えて、「Add preconnect hints to your most important origins, but try to use no more than 4.」（最も重要なオリジンに事前接続ヒントを追加しますが、使用するヒントは 4 つ以下にしてください）といったメッセージが表示されている。以下のサイトさまによると、「preconnect」を３つ以上指定すると、「Page Speed Insights」で警告を受けるともあった（爆）。
　しかし、ブッチ切って、効果が出たように見えた「Ｇｏｏｇｌｅタグマネージャー」と「はてな」系と「アマゾン商品画像」の合計６サイト（ドメイン）へ「preconnect」を指定することにした。
igawa.co

　結論。８行目のＧｏｏｇｌｅタグマネージャーの「https://www.googletagmanager.com」への「preconnect」＆「dns-prefetch」と、11～14行目：「https://cdn.blog.st-hatena.com」他の全４種の「はてなブログ」系統のドメインへの「preconnect」と、15行目：「https://m.media-amazon.com」の「アマゾン商品画像」系のドメインへの「preconnect」だけが効果があったような――もちろん、最終行に記載した「meta name="viewport" content="width=device-width, initial-scale=1.0"」は必須指定！――。よって、拙ブログにおいては、それらの行のみを設定（記載）して、他の行の設定は廃止（削除）にしてみた。

　ただし、個人で「Ｇｏｏｇｌｅタグマネージャー」を設定し、なおかつ「アマゾン商品画像」オンリーのＵＲＬを参照するようなブログは極小だとも思われる。よって、世間一般的には参考にはならないであろう（笑）。

　加えて、８行目のＧｏｏｇｌｅタグマネージャーの「https://www.googletagmanager.com」への「preconnect」＆「dns-prefetch」で、たしかに「ＴＢＴ」指標は改善していた。しかし、「ＴＢＴ」指標それ自体は、ＧｏｏｇｌｅさまがＳＥＯで重視する「Ｃｏｒｅ　Ｗｅｂ　Ｖｉｔａｌ（コア・ウェブ・バイタル）」のひとつではない。あくまでも、「Ｃｏｒｅ　Ｗｅｂ　Ｖｉｔａｌ」の「ＩＮＰ」指標の基に過ぎない。けれども、そもそも「ＩＮＰ」指標には問題はなく、「緑」（90点以上）を達成してもいた。そう考えると、「はてなブログ」における「Ｃｏｒｅ　Ｗｅｂ　Ｖｉｔａｌ」の改善においては、８行目のＧｏｏｇｌｅタグマネージャーの「https://www.googletagmanager.com」への「preconnect」＆「dns-prefetch」の処置についても、あまり有意義ではなかったのやもしれない（汗）。

　なお、「preconnect」においては、たとえば「https://cdn.pool.st-hatena.com」などの名義で指定すること！　「https://」などの「スキーマ（プロトコル）」は省略した「cdn.pool.st-hatena.com」などの「ドメイン名」だけの指定は、以下のＧｏｏｇｌｅ検索での「ＡＩによる概要」では、可能ではあっても推薦されないのだとのこと！――「Web Page Test」での処方箋などでは、「https://」ヌキでの「preconnect」の用例を提示してくるというのに（汗）――

「preconnectのドメインはフルパスか HTTPSは省略してもよいか」→「preconnectのドメイン指定には、プロトコル（https://など）を含んだ、フルパスではないドメイン名を指定する必要があります。パスやファイル名を含める必要はありません」。「HTTPSは省略できるか？」→「HTTPSは省略すべきではありません。常にプロトコル（https://）を含めて指定するのが推奨されます」「省略してhref="//example.com"のように記述する（プロトコル相対URL）方法もありますが、以下の理由から推奨されません」
――上記の「フルパスではないドメイン名」とは、「.com」などの「ドメイン名」以降にも続いていく「パス」のこと――
www.google.com

　加えて、「preconnect」においては、たとえば「https://cdn.pool.st-hatena.com/」など、「.com」などの「ドメイン名」の末尾には「/」（スラッシュ）も付与すること！（後日付記：そのようにも思ったのだが、「/」は不要であったやもしれない。理由は後述）

「preconnectのドメインの末尾にスラッシュは必要か」→「rel="preconnect" の指定においてドメインの末尾にスラッシュの有無は必須ではなく、どちらでも機能しますが、スラッシュを付けた方がより安全です」
www.google.com

――２０２５年１１月７日（金）後日付記：　上記の「ＡＩによる概要」が変更されていたのであった（汗）。　→　「一般的な慣例として、preconnectでは通常、以下のようにスラッシュを含めない形式がよく使用されます」（……「以下」の例文については、省略）。つまり、末尾の「/」は不要だとのことだろう――

（２０２５年１０月６日（月）加筆）
　ただし、「Ｇｏｏｇｌｅタグマネージャー」のドメインへの「preconnect」については、末尾に「/」（スラッシュ）を付与してはいない。それは先人の用例が軒並み、そうなっていたからだ（笑）。ただし、近いうちに末尾に「/」（スラッシュ）を付与しての、実験はしてみたい。

……と思ったが、ググってみると、「Ｇｏｏｇｌｅタグマネージャー」の場合には、末尾に「/」（スラッシュ）を付与しない方がよいのだとの、「ＡＩによる概要」と「ＡＩモードでさらに詳しく」での結果でもあった。ムムムム。ホントウなのだろうか？　いずれ、実験はしてみよう――ただし、「Ｇｏｏｇｌｅタグマネージャー」それ自体を全然使用はしていないし（汗）、使用の方法についてもいまだによくわかっていないので、拙ブログからは外してしまった方がよいのやも？――。

「Ｇｏｏｇｌｅタグマネージャーのドメインにpreconnectする際、ドメインの末尾にスラッシュはあった方がよいか」→「どちらでも問題ありません」「スラッシュなしで統一:サーバーがリダイレクトを発生させる手間を省き、またURL表現もスッキリするため、ドメインの末尾にスラッシュを付けずに統一するのが無難とされています」
www.google.com

「ＡＩモードでさらに詳しく」：「スラッシュが不要な理由」～「リダイレクトの回避: 末尾にスラッシュを付けると、一部のサーバーではスラッシュなしのURLからスラッシュ付きのURLへリダイレクトが発生することがあります。preconnectの目的は接続時間を短縮することなので、余分なリダイレクトは避けるべきです」
Google Search

　これらの処置が効を奏したのかは不明なれども、おそらく８行目のＧｏｏｇｌｅタグマネージャーの「https://www.googletagmanager.com」への「preconnect」＆「dns-prefetch」が効を奏したのだろうと推測するけれども、いつの間にやら、「Page Speed Insights」では「ＴＢＴ」指標内における「第三者コードの影響を抑えてください」とのエラーが出なくなっていた……（「ＴＢＴ」指標側ではなく「Ａｌｌ」指標側に、単なる「サードパーティ」名義の項目として、「○」（＝問題なし）が表示されている）。
――２０２５年１０月１８日（土）後日付記：　１０月１７日（金）夜間から、「Page Speed Insights」の計測結果の表示方法がビミョーに変更されている。パソコンで計測して表示させる分には従来どおりである。しかし、タブレットとスマホで計測して表示させる分だと、「パフォーマンス」指標が「インサイト」と「診断」に上下分割されずに混合されていた２０２５年の５～６月以前の表示方法に戻ってしまっている模様である。しかも、タブレットとスマホで計測して表示させている分だと、スマホ側の「ＴＢＴ」指標内における「第三者コードの影響を抑えてください」の意味だとも思われる「Reduce the impact third-party code」が「赤」にて表示されてくる！　ついでに、「過大な DOM サイズの回避」の意味だとも思われる「Avoid an excessive DOM size」も「赤」にて（パソコン側では「オレンジ」にて）表示されてくる！　どういうこと？　ウ～ム。指標としては廃止、あるいは一時的に停止されたが、復活になった、あるいは復活予定、もしくは間違って復活してしまった、といったことなのか？　とはいえ、「パフォーマンス」指標の点数には、特に悪化したなどの変化は見られなかった（ヨソさまのブログも計測してみると、パソコン側でも「インサイト」と「診断」に上下分割されずに混合されている（汗）。１０月２１日付記：　同日夜間から、世間さまのブログやサイトを測定してみても、７月以降の「インサイト」と「診断」に上下分割しての表記に無事に戻っていた――

　および、断言はできないものの、２０２５年９月中旬～下旬に集中的に追加設定した、「アマゾン商品画像」系のドメインへの「preconnect」と、すでに設定済であった全４種の「はてなブログ」系統のドメインへの「preconnect」における末尾への「/」（スラッシュ）の付与と、同じく全４種中の２種の「はてなブログ」系統のドメイン指定に省略していたプロトコル（https://など）を付与したことで、急速に改善が見られたような……。（後日付記：同時期に実施した、アイキャッチ画像付きのサイドバー・モジュールの大量削除による効果であったようだ・汗）

　とはいえ、「Page Speed Insights」の「パフォーマンス」指標における「ネットワークの依存関係ツリー」の最下部の「Preconnect candidates」――「Preconnect」の「候補」――には、11～14行目の「https://cdn.blog.st-hatena.com」他の「はてなブログ」系統のドメインが、時折りには表示されてくる。すでに「Preconnect」設定を指定済の分であるというのに……（汗）。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　「サイドバー」と「はてなブログカード」と「内部リンク」

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

２６．「サイドバー」と「はてなブログカード」と「内部リンク」

（２０２５年８月２日（土）加筆）

２６－１．「サイドバー」のさらなる減少

　「はてなブログ サイドバー モジュールを減らすとTTFBは改善されるか」の語句にて、グーグル検索してみると、「はい、サイドバーのモジュールを減らすと、サーバーが応答するまでの時間（TTFB）が改善される可能性があります。サイドバーに表示されるモジュールが多いほど、ページを生成するために必要な処理が増え、その結果TTFBが長くなることがあります」だとの「ＡＩによる概要」が表示される。

　「Web Page Test」側の「ページパフォーマンス指標」のグラフ（図表）の一番上の行に表示される自ブログ「https://katoku99.hatenablog.com/」行の、「ＨＴＭＬ」稼働（読み込み？）時間も半減していた――「Page Speed Insights」では計測されない数値である――。「Web Page Test」側の「ＴＴＦＢ」数値も減少している。「Page Speed Insights」側の「ＴＴＦＢ」数値も、今後の２８日間をかけて減少するのではなかろうか？

（後日付記：　その結果については、後続の「２６－４．「サイドバー」側の「旧・ＵＲＬ」や「リダイレクトのＵＲＬ」の一部が、一括置換の対象外となっていたために残存していたので修正」の項目側に、「後日加筆」のかたちにて記載）

２６－２．拙ブログの過去記事への内部リンクである「はてなブログカード」を一括置換で、単なる「ＵＲＬ」だけの内部リンクへと変更してしまう処置は影響なし？

　「はてなブログカード」もビミョーに重たいと主張しているブログはあるものの、その画像自体は当初はともかく、ある時点からは「はてなブログ」社側にて遅延読み込み（遅延表示）に改良されているようだし、「Page Speed Insights」でも「Web Page Test」でも、特に有意な差は見当たらないような……。

　２０２５年７月の中下旬あたりに、「はてなブログカード」を一括置換で、単なる「ＵＲＬ」だけの内部リンクへ変更したことで、「はてなブログカード」を全廃したものの、各種指標に特にこれによる変化は見られなかった。よって、拙ブログでは、その３ヶ月後の２０２５年１０月から、以前ほどには大量には設置しないものの、要所要所で「はてなブログカード」を復活させることにした……。

　しかし、「はてなブログ はてなブログカードを減らすとTTFBは改善されるか」の語句にて、グーグル検索してみると、「はい、はてなブログカードの数を減らすことは、TTFB（Time To First Byte、最初の1バイトが届くまでの時間）の改善につながる可能性があります。はてなブログカードは他のブログへのリンクを生成するため、多くのカードは、そのカードが読み込まれるための追加のリクエストを発生させます。これによってサーバーへの負荷が増加し、応答時間が長くなることがあります」だとの「ＡＩによる概要」が表示されてしまうことは念のため……。
www.google.com

２６－３．内部リンクの多寡も、「ＴＴＦＢ」には影響なし？

　ググってみると、以下のＧｏｏｇｌｅの「ＡＩによる概要」によれば、影響はなさそうである。しかし、「内部リンク」の乱用は、Ｇｏｏｇｌｅの検索ランキング指標には悪影響があるのだとも……。

「内部リンクを減らすとＴＴＦＢは減るか」→「内部リンクを過度に減らすことは、TTFB（Time To First Byte：最初の1バイトがユーザーに届くまでの時間）に直接的な影響を与えることはほとんどありません」
www.google.com

「内部リンクが多いと表示も遅くなるのか」→「内部リンクが多いこと自体が直接表示を遅くするわけではありませんが、不適切な設定や過剰なリンクは、サイトパフォーマンスの低下につながる可能性があります」
www.google.com

――２０２５年１０月１９日（日）後日付記：　上記の「ＡＩによる概要」が変更されていた（汗）。　→「はい、内部リンクが多すぎると表示速度が遅くなる可能性があります。これは、多くのリンクがページの読み込み時間を増加させ、Googleのクローラーが重要なページを特定しにくくするためです。また、ユーザーにとっても情報が混乱し、回遊しづらくなるという悪影響があります」。ムムムム……。拙ブログでは狂ったように膨大に過去記事へのリンクを貼っているので、それでは減らすことも検討してみよう（汗）。
　１０月２２日（水）後日付記：　上記の「ＡＩによる概要」がまたまた変更されていた（汗）。　→「内部リンクの数を減らしても、直接的にTTFB（Time to First Byte）が短縮されるわけではありません。TTFBは、主にサーバーサイドの処理速度やネットワーク環境に左右されるためです」――

２６－４．「サイドバー」や「グローバル・ヘッダー・メニュー」側の「旧・ＵＲＬ」や「リダイレクトのＵＲＬ」の一部が、一括置換の対象外となっていたために残存していたので修正

　こちらも削除したり修正してみた。先にも言及したとおりで、「ＦＣＰ」と「ＬＣＰ」に先立つものでもある「Page Speed Insights」側の「ＴＴＦＢ」数値は、「リダイレクトＵＲＬ」が残存していることで相応に悪化していたハズではあるので、今後の２８日間をかけて減少していくのか、要・確認！

　ただし、「サイドバー」のモジュールのさらなる減少とも同時に処置を実施したので、「Page Speed Insights」側の「ＬＣＰ」「ＦＣＰ」「ＴＴＦＢ」数値に対する、個々の処置ごとの厳密なる効果の測定・検証は不可能ではある（汗）――各種数値は減ってはいるものの――。

２６－４－１．「Page Speed Insights」側の上半分の直近28日平均の値でもあるフィールドデータ側の「ＬＣＰ」「ＦＣＰ」「ＴＴＦＢ」の日々の改善記録！

●「スマホ」用の「Page Speed Insights」側の上半分の直近28日平均の値でもあるフィールドデータ側の「ＬＣＰ」については、２．５秒超過（オレンジ＝50点以上～90点未満）であったものが、２０２５年７月３０日に三度目の２．５秒以下（緑＝90点以上）を再達成！　８月２日には２．４秒も記録！　８月９日には２．３秒も達成！　８月１５日には２．２秒も達成！（その後は限界に達したのか、停滞・汗）――それでも、世間一般的には１秒台前半のようですので、遅いのですけど――
（後日付記：　９月４日には２．３秒へと悪化。おそらく８月最終週にサイドバーのモジュールをまた増やしてみた影響である（汗）。９月１０日には２．２秒へと減少（改善）したが、こちらは８月３１日～９月１日にかけて、サイドバーをさらに減少させた効果であろう。９月１５日には「ＦＣＰ」側についても２．２秒へと減少（改善）。９月２０日には「ＬＣＰ」のみ２．１秒へと改善。９月２１日には「ＦＣＰ」も２．１秒へと改善。９月２６日には「ＬＣＰ」と「ＦＣＰ」が２．０秒へと改善。９月２９日には「ＬＣＰ」のみ１．９秒へと改善。９月３０日には「ＦＣＰ」も１．９秒へと改善。１０月１日には「ＬＣＰ」のみ１．８秒へと改善。１０月２日には「ＦＣＰ」も１．８秒へと改善（ただし、「ＦＣＰ」の「緑」と「オレンジ」の分水嶺でもある１．８秒ではあっても、１．８秒超過ではあるので、まだ「オレンジ」）。１０月４日には「ＬＣＰ」のみ１．７秒へと改善。１０月５日には「ＦＣＰ」については、同じく１．８秒名義ではあっても、１．８秒以下を意味する「緑」（90点以上）へと改善。１０月７日には「ＦＣＰ」も１．７秒へと改善！
　……その後は停滞していたが、飛んで１０月２０日に「ＬＣＰ」のみ１．６秒へと改善！――当該にかぎらず、「Page Speed Insights」側の上半分のフィールドデータ側のリンク「過去28日間（履歴）」から遷移ができる、実際には毎週の金曜日基準での過去28日間の平均値（月曜の１１～１４時ごろに算出されて表示）を参照してみると、１０月２０日ではなく１０月１７日（金）に四捨五入での１．６秒を達成していた。その値が月曜の１１～１４時くらいに反映されるといったところであろう――。しかし、１０月２５日に１．７秒へと悪化・汗）

　最初の処置の直後には、「Page Speed Insights」側の「ＴＴＦＢ」指標に変化が見られなかったというのに、「Page Speed Insights」側の上半分のフィールドデータ側の「ＬＣＰ」と「ＦＣＰ」側の方が先行して改善されていたのはナゼ？――８月４日にようやくスマホ側の「ＴＴＦＢ」についても改善。ただし、もともとが１．９秒であったものが１．８秒になっただけ。まだ「赤」（50点以下）ではある（爆）。８月１１日には１．８秒以下になって、「オレンジ」（50点以上）を達成。８月１５日には１．７秒も達成。８月２４日には１．６秒も達成！（それでも、世間一般的な「はてな無料ブログ」で、「ＴＴＦＢ」が０．５秒前後であることを思えば・汗）　その後は限界に達したのか、停滞。
（後日付記：　９月２日には１．７秒へと悪化。おそらく８月最終週にサイドバーのモジュールをまた増やしてみた影響である（汗）。９月５日には１．６秒へと減少（改善）したが、こちらは８月３１日～９月１日にかけて、サイドバーをさらに減少させた効果であろう。９月２０日には１．５秒へと改善。９月２６日には１．４秒へと改善。９月２９日には１．３秒へと改善。１０月３日には１．２秒へと改善。１０月７日には１．１秒へと改善！）

●「パソコン」側の「Page Speed Insights」側の上半分のフィールドデータ側の「ＬＣＰ」と「ＦＣＰ」についても、８月４日に２．０秒から１．９秒へと減少。８月１８日に「ＦＣＰ」のみ１．８秒へと減少した……と思ったら、８月２０日にまた１．９秒へと戻ってしまった……と思ったら、８月２１日に「ＬＣＰ」と「ＦＣＰ」ともどもに１．８秒へと減少した。８月２４日には後者の「ＦＣＰ」が同じく１．８秒ではあっても、１．８秒以下を意味する「緑」（90点以上）を達成！（その後は限界に達したのか、停滞・汗）
（後日付記：　９月１１日に「ＦＣＰ」のみ１．７秒へと減少（９月７日前後に、サイドバーをさらに減少させた効果であろうか？）。９月１５日には「ＬＣＰ」側も１．７秒へと減少（改善）。９月１９日には「ＦＣＰ」のみ１．６秒へと減少。９月２２日には「ＬＣＰ」側も１．６秒へと減少。９月２８日には「ＦＣＰ」のみ１．５秒へと減少。９月２９日には「ＬＣＰ」も１．５秒へと減少。１０月１日には「ＦＣＰ」のみ１．４秒へと減少。１０月４日には「ＬＣＰ」も１．４秒へと減少。１０月７日には「ＦＣＰ」のみ１．３秒へと減少（改善）！　その後は限界に達したのか、停滞。１０月１９日には「ＦＣＰ」のみ１．４秒へと増大（悪化・汗））

　やはり最初の処置の直後には、「パソコン」側の「Page Speed Insights」側の「ＴＴＦＢ」には変化が見られなかったものの、やはり８月１１日に１．６秒から１．５秒へと減少。８月１７日に１．４秒へと減少。８月２５日に１．３秒へと減少。１週間で約０．１秒ほど減少しているとすれば、28日間がイコール４週間でもあるので、トータルでは実験当初の値からは約０．４秒ほどは減少するのでは？　と推測している――それでも、世間一般的な「はてな無料ブログ」で、「ＴＴＦＢ」が０．５秒前後であることを思えば（汗）――。その後は限界に達したのか、停滞（汗）。
（後日付記：　９月１日には１．４秒へと増大（悪化）してしまった。９月４日には１．３秒へと減少（改善）したが、こちらは８月３１日～９月１日にかけて、サイドバーをさらに減少させた効果であろう……と思った同日には、また１．４秒へと増大（悪化）。その後、９月１１日には１．３秒へと減少（改善）。９月２１日には１．２秒へと減少。９月２８日には１．１秒へと減少。９月３０日には１．０秒へと減少。１０月６日には０．９秒へと減少（改善）！）

　施策を開始する直前である２０２５年７月２５日（金）から、改善が停滞する直前であった８月２２日（金）までの４週間（28日間）の数値の変化は、以下のとおりであった。さらに加えて、８月最終週以降の施策の改善が停滞してしまった直後であった１０月１０日（金）も併せて記入すると、以下のとおり。

●パソコン側：
・［ＬＣＰ」　：２．０秒（緑）　　　　　　→　１．８秒（緑）　　　　　→　１．４秒（緑）
・「ＦＣＰ」　：２．０秒（オレンジ）　　　→　１．８秒（緑）　　　　　→　１．３秒（緑）
・「ＴＴＦＢ」：１．６秒（オレンジ）　　　→　１．３秒（オレンジ）　　→　０．９秒（オレンジ）

●スマホ側：
・［ＬＣＰ」　：２．５秒（オレンジ）　　　→　２．２秒（緑）　　　　　→　１．７秒（緑）
・「ＦＣＰ」　：２．５秒（オレンジ）　　　→　２．２秒（オレンジ）　　→　１．７秒（緑）
・「ＴＴＦＢ」：１．９秒（爆・赤）　　　　→　１．６秒（オレンジ）　　→　１．１秒（オレンジ）

　つまり、最終的には、「Page Speed Insights」側の下半分のラボデータ側ではなく、上半分のフィールドデータ側の「ＬＣＰ」「ＦＣＰ」「ＴＴＦＢ」などが「Core Web Vital」の指標となるので、そちら側が改善していっているか否かを確認していくことになる。

なお、上記については、２０２５年９月の中下旬から１０月の初旬にかけて、各指標に急速な改善が見られる。９月上旬から下旬にかけては、以下の施策を実施したための、その結果だとも思われる。あるいは、それらのうちのいずれかが、効果を発揮したのだとも思われる

●８月最終週：「サイドバー」の一部モジュールについて、各記事のアイキャッチ画像を「非表示化」に設定。

●８月３１日～９月１日：さらなる「サイドバー」の減少。

●９月７日前後：①：さらにさらなる「サイドバー」の減少と、②：「サイドバー」の一部モジュールについて各記事のアイキャッチ画像を「非表示化」に設定。

●９月中旬：サイドバーならぬ各記事の下に、「はてな」側にて自動で表示してくれる「関連記事（＝同じカテゴリーとはかぎらない、５種の記事見出し）」を完全に非表示化。

●９月中旬：サイドバーは「スマホ」での表示の場合には、サイドではなくブログ記事の下に自動表示される。これを「Ｙ．「classic diary（日記向け）」におけるデザインの微変更　：　「サイドバーの幅の縮小」「サイドバーのモジュールの文字の縮小」「サイドバーのリンクを青色化」など！」の項目に記載した方法にて、「パソコン」で表示される場合よりもモジュールを大幅に減らしてみた（一部のモジュールを非表示設定にしてみた）。

●９月下旬：『２５．「Page Speed Insight」サイトにて引っかかった、先にも設定した２種の「デザインＣＳＳ」、および「Web Page Test」サイトにて、「レンダリングをブロック」してくる旨で引っかかった４種の「はてなブログ」系の「Ｊａｖａスクリプト」を遅延読み込み、または先読み込みにしてみる』の項目にて例示した、15行目：「https://m.media-amazon.com」の「アマゾン商品画像」のドメインを「preconnect」接続する設定それ自体の追加。（※：ただし、これは拙ブログの各記事で、「アマゾン商品画像」のみのサイトへ直接にリンクを貼っているためで、世間一般的には不要である処置）

●９月下旬：『２５．「Page Speed Insight」サイトにて引っかかった、先にも設定した２種の「デザインＣＳＳ」、および「Web Page Test」サイトにて、「レンダリングをブロック」してくる旨で引っかかった４種の「はてなブログ」系の「Ｊａｖａスクリプト」を遅延読み込み、または先読み込みにしてみる』の項目にて例示した、11～12行目：「https://cdn.blog.st-hatena.com」と「https://usercss.blog.st-hatena.com」の２種の「はてな」系のドメイン指定については、「https://」ナシの指定であったものを「https://」アリへと修正。

●９月下旬：『２５．「Page Speed Insight」サイトにて引っかかった、先にも設定した２種の「デザインＣＳＳ」、および「Web Page Test」サイトにて、「レンダリングをブロック」してくる旨で引っかかった４種の「はてなブログ」系の「Ｊａｖａスクリプト」を遅延読み込み、または先読み込みにしてみる』の項目にて例示した、11～14行目：「https://cdn.blog.st-hatena.com」と「https://usercss.blog.st-hatena.com」などの全４種の「はてな」系のドメインと、15行目：「https://m.media-amazon.com」の「アマゾン商品画像」のドメインについては、末尾が「.com」で終わるのではなく、その末尾に「/」（スラッシュ）の１文字を追加。

　ただし、「preconnect」でのＵＲＬの先頭に「https://」を付与したり、末尾に「/」を付与したくらいで、そんなに改善されるのか！？　といった疑問はもちろんある（汗）。別の事象が改善に影響している可能性もある――はてな社の「はてな開発ブログ」を参照するかぎりでは、この時期になんらかの改善を実施したとの報告は上がってはいなかったものの……。Ｇｏｏｇｌｅの「Page Speed Insights」側にて計測方法に変更があったのであろうか？　しかし、ヒトさまのあまたの「はてなブログ」を「Page Speed Insights」にて計測してみても、総じて数値が拙ブログと同様な改善傾向などは見せていない――。

　それに、拙ブログの表示速度が遅すぎるがゆえに効果が生じたのであって、すでに良好な表示速度を達成できている「はてなブログ」一般においては、収穫逓減（しゅうかく・ていげん）の法則がはたらいて、これらの処置は大した効果をもたらさない気がしないでもないのでもあった（汗）。
　加えて、「１８－１－２」にて記載したとおりで、週に４～６記事ほどに対して、各記事のアイキャッチ画像にもなる通販の「アマゾン商品画像」を、アマゾンの画像専用サイトのＵＲＬへの直接リンクでの遅延読み込みに手修正していってもいる。しかし、それは２０２５年５月下旬から継続的・定型的に実施してきたことでもある。よって、９月の中下旬から１０月の初旬にかけての急速なる改善の理由にはならないであろう。

（２０２５年１０月１７日（金）加筆）
　「Page Speed Insights」側の上半分の直近28日平均の値でもあるフィールドデータ側の「ＬＣＰ」「ＦＣＰ」「ＴＴＦＢ」が、２０２５年１０月７日を最後に停滞してしまって、１０日も過ぎてしまった……（汗　～パソコン側の「ＬＣＰ」については、１０月１９日に０．１秒の悪化が発生。スマホ側の「ＬＣＰ」のみ、１０月２０日に０．１秒の改善）。

　フィールドデータは直近28日平均の値でもあるので、やはり直近28日間に実施した施策が効果があったことにはなる。してみると、２０２５年９月下旬に実施した、「https://」付与だの、末尾に「/」（スラッシュ）付与だのの施策は効果がなかった？　９月７日前後に実施した「①：さらにさらなる「サイドバー」の減少」と、「②：「サイドバー」の一部モジュールについて各記事のアイキャッチ画像を「非表示化」に設定」の施策の方が、効を奏していただけなのでもあろうか？

　「パソコン」側でも「スマホ」側でも、「Page Speed Insights」の上半分のフィールドデータ側の各種指標は、「ＴＴＦＢ」を除いて「緑」（90点以上）を達成できた。スマホ側にて拙ブログの内部リンクをクリックして別ページに遷移させるときの「ややモッサリ感」も解消されていた。よって、このあたりで手を打ってもよいのだが……。欲が出てきて、「ＴＴＦＢ」も含めての「緑」（90点以上）を達成したくもなるのだ（笑）。

　しかし、これ以上は、「サイドバー」を減らしたくはない。別の施策を考えることにしよう。

２６－５．Google検索の「Core Web Vital」の３大指標ではないものの、それに次ぐ「Page Speed Insights」側の上半分のフィールドデータ側の「ＦＣＰ」の改善はいかにすべきか思案中（サイドバーの一部モジュールの各記事のアイキャッチ画像を非表示化。各記事の下に自動表示される「関連記事」の非表示化）

（２０２５年８月９日（土）加筆）

　よそさまの「はてなブログ」と比すると、「Page Speed Insights」側の上半分の直近28日平均の値でもあるフィールドデータ側の「ＦＣＰ」の秒数が、常に「ＬＣＰ」の秒数ともほぼ一致している。ナゼ？　どころか、「ＦＣＰ」が先に来て、「ＬＣＰ」がそのあとの秒数になるのでは？　と思いきや、「スマホ」側では０．１秒ほど前後逆転していることもある（誤差？）。
　サイドバー（スマホの場合、各記事の下の部分）の「最新記事」「注目記事」「関連記事（＝同じカテゴリーの最新記事）」の見出し一覧すべてに、各記事ごとのアイキャッチ画像を表示させてしまっているからであろうか？　よそさまの「はてなブログ」では、サイドバーにアイキャッチ画像を表示させていないケースも多かった（汗）。しかし、このアイキャッチ画像がないと、各記事への誘導が弱くなってしまうであろうし（汗）。

　でも、それゆえにＧｏｏｇｌｅ検索にて上位にランキングされていないのであれば、サイドバー側のアイキャッチ画像をすべて非表示にしてしまうか、サイドバーならぬ各記事の下に「はてな」側にて自動で表示してくれる「関連記事（＝同じカテゴリーとはかぎらない、５種の記事見出し）」あたりを完全に非表示にしてしまうか、悩みどころではある。

　サイドバーの各記事のアイキャッチ画像を非表示にすると、フィールドデータ側の「ＦＣＰ」のみならず「ＬＣＰ」や「ＴＴＦＢ」、ラボデータ側の「ＴＢＴ」なども改善されるのであろうか？　各記事の下に「はてな」側にて自動で表示してくれる「関連記事（＝同じカテゴリーとはかぎらない、５種の記事見出し）」それ自体を完全に非表示にしてしまうと、フィールドデータ側の「ＦＣＰ」のみならず「ＬＣＰ」や「ＴＴＦＢ」、ラボデータ側の「ＴＢＴ」なども改善されるのであろうか？
　近いうちに実験してみたいが、フィールドデータ側は直近28日間の平均値であるので、約１ヵ月間もサイドバー側の各記事のアイキャッチ画像を非表示にすることには抵抗感がある……（笑）。
　先の「２６－１．「サイドバー」のさらなる減少」と「２６－４．「サイドバー」側の「旧・ＵＲＬ」や「リダイレクトのＵＲＬ」の修正」の施策後の28日後以降に、実験してみることにしよう……。

　「ＦＣＰ」ならぬ「ＴＴＦＢ」として、「はてなブログ サイドバー モジュールのアイキャッチ画像を非表示に変えるとTTFBは改善されるか」の語句にて、グーグル検索してみると、「はい、改善される可能性があります。はてなブログのサイドバーにあるアイキャッチ画像を非表示にすると、モジュールの読み込み処理が軽減され、TTFB（Time To First Byte）が短縮される可能性があります。特にサイドバーのモジュールを多数設定している場合、アイキャッチ画像のような重いコンテンツの読み込みが減ることで、サーバーからの初回バイト受信までの時間が改善されることが期待できます」だとの「ＡＩによる概要」が表示される。
www.google.com

　先にもふれたとおりで、最終的には、「Page Speed Insights」側の下半分のラボデータ側ではなく、上半分のフィールドデータ側の「ＬＣＰ」「ＦＣＰ」「ＴＴＦＢ」などが「Core Web Vital」の指標となるので、そちら側が改善していっているか否かを確認していくことになる。

（２０２５年９月１６日（火）加筆）
　「サイドバーの各記事のアイキャッチ画像を非表示にする設定」については、サイドバーの一部（２～３種ほど）のモジュールについてのみ、２０２５年の８月最終週より実施した。その結果は、直上の「２６－４．「サイドバー」側の「旧・ＵＲＬ」や「リダイレクトのＵＲＬ」の一部が、一括置換の対象外となっていたために残存していたので修正」の項目側に、「後日加筆」のかたちにて記載。一部のモジュールについてのみであったせいか、顕著な変動は見られなかった。９月の第１週から実施した「さらにさらなるサイドバーの減少」の方が、効果があったようには思える。

　……もちろん、最初からサイドバーの各記事のアイキャッチ画像を非表示にしてしまったり、「サイドバー」をがっしり削って最小限にしてしまって、各記事の下に「はてな」側にて自動で表示してくれる「関連記事（＝同じカテゴリーとはかぎらない、５種の記事見出し）」なども、一挙に廃止にしてしまえばよいのだけれども……、それはしたくはないのだ（笑）。それらをどのくらい残存させられるかを試してみたいのだ。
　とはいえ、それでも競合ブログさまのグーグル検索の順位を凌駕はできずとも、拮抗すらできないようであれば――筆者の正体がアクセス乞食な俗物そのものでもあることがバレてしまいますけど（汗）――、これらの一挙廃止も射程に登ってくるのだ。
　「表示速度の改善」だけで考えれば、巷間ではスマホでの表示用は「レスポンシブデザイン」がよいとは云われてはいるものの、それはやめてしまって、「はてなブログ」一般における「スマホ」専用画面（＝トップページなどは、「最新７記事」の「見出し」のみが「一覧表示」される形式のもの）に変更してしまった方がよいのやもしれない（しかし、スマホでは非表示ではあっても、ＨＴＭＬ読み込みとしての影響はあるので、サイドバー側のモジュールの削減は必要）。でも、その場合には、独自に設定した「グローバル・ナビゲーション」or「ヘッダー・メニュー」or「グローバル・ナビゲーション・メニュー」or「グローバル・メニュー」or「グローバル・ヘッダー」or「グローバル・ヘッダー・メニュー」などが、「スマホ」専用画面側では非表示になってしまうのがイタいので、それは避けたいのだ……。

２６－６．Google検索の「Core Web Vital」の３大指標ではないものの、それに次ぐ「Page Speed Insights」側の上半分のフィールドデータ側の「ＴＴＦＢ」の改善はいかにすべきか思案中

（２０２５年９月１６日（火）加筆）

　「Web Page Test」側での「ＴＴＦＢ」の計測では、サイドバーのさらなる減少の処置などで、パソコンでもスマホでも０．３秒程度を達成できた。しかし、「Page Speed Insights」側の上半分の直近28日平均の値でもあるフィールドデータ側の「ＴＴＦＢ」では、１．５秒前後になっている。ナゼ？　おそらく「Page Speed Insights」側の「ＴＴＦＢ」の方が、Google検索の「Core Web Vital」の３大指標ではなくても、「ＦＣＰ」ともどもに５大指標（笑）にはなっていそうな気がするので、さらなる改善が必要そうではある。

　「ＴＴＦＢ」の改善結果についても、直上の「２６－４．「サイドバー」側の「旧・ＵＲＬ」や「リダイレクトのＵＲＬ」の一部が、一括置換の対象外となっていたために残存していたので修正」の項目側に、「後日加筆」のかたちにて記載。

２６－６－１．「グローバル・ヘッダー・メニュー」を追加したことでの「ＴＴＦＢ」への影響はなさそう？

　５年以上も前の２０１９年２月に、「グローバル・ナビゲーション」or「ヘッダー・メニュー」or「グローバル・ナビゲーション・メニュー」or「グローバル・メニュー」or「グローバル・ヘッダー」or「グローバル・ヘッダー・メニュー」を追加したことでの「ＴＴＦＢ」への大きな影響はなさそうではある。前述した「１７－４－１．」でも、一時的な削除などの実験はして確認もしている……（汗）。

　厳密には、その３年後の２０２２年６月２３日に、スマホでもＰＣと同じブログ画面を表示させると「字」が小さすぎると、「Google Search Console」で警告が出たために、そこでいったん「グローバル・メニュー」を廃止にしていた。そして、さらに３年後の本年２０２５年５月３１日から「グローバル・メニュー」を復活させている。復活させたからといって、「ＴＴＦＢ」が悪化したといった事実もなかった。

　「はてなブログ グローバルヘッダーを追加するとTTFBは遅くなるか」→「はてなブログにグローバルヘッダーを追加すること自体が直接的にTTFBを遅くするわけではありませんが、追加するヘッダー画像やレイアウトに大量のデータが含まれていたり、処理が重くなるデザインだったりすると、サイトの読み込み速度が遅くなる可能性があります」
www.google.com

　「グローバルヘッダー」用の画像などは微塵も使用していないので……。

――２０２５年１０月１９日（日）後日付記：　上記の「ＡＩによる概要」が変更されていた（汗）。　→「はい、グローバルヘッダーを追加するとTTFB（Time To First Byte）が遅くなる可能性があります。これは、追加されたヘッダー画像や要素を読み込むためのサーバー処理時間が増えるためです」――

――２０２５年１０月２５日（日）後日付記：　「グローバル・ヘッダー」ではなく「グローバル・メニュー」の文言に変えてググってみた。　→「はてなブログでグローバルメニューを追加すること自体が、TTFB（Time to First Byte）を大幅に遅くする直接的な原因になる可能性は低いです。ただし、実装方法によっては間接的に影響を与える可能性があります」「グローバルメニューがTTFBに与える影響の考え方：　はてなブログは、サーバー側でページのHTMLを生成してブラウザに返す仕組み（サーバーサイドレンダリング）が基本となっています。このため、グローバルメニューをブログに反映させる過程で、どのような処理が行われるかが重要になります」「TTFBに影響しないケース（通常）：　デザインCSSの追加によるメニュー: スタイルシート（CSS）でメニューの見た目を調整する場合、CSSファイル自体のサイズはわずかであり、サーバー側の処理にはほとんど影響しません。HTMLの静的な追加: 管理画面の「カスタマイズ」からHTMLを直接追加する場合、ページのHTMLが生成される際にその内容が含まれるだけなので、サーバーへの負荷はごくわずかです」「TTFBに影響する可能性があるケース：　動的なメニューの生成: グローバルメニューに表示する内容を、JavaScriptなどで動的に取得・生成する場合、サーバー側の処理（API通信やデータベースクエリなど）が発生する可能性があります。この処理に時間がかかるとTTFBが遅くなる原因となります」「結論として、単純なグローバルメニューの追加でTTFBが遅くなることはほとんどありません」――

２６－６－２．「サイドバー」の「リンクモジュール」を「ＨＴＭＬモジュール」に変更することでの「ＴＴＦＢ」への影響はありそう？

　「はてなブログ サイドバー リンクモジュールをHTMLモジュールに変えるとTTFBは改善されるか」→「リンクモジュールをHTMLモジュールに置き換えることで、TTFBが直接的に大幅に改善されるとは限りません」「もし「リンクモジュールを静的なHTML（テキストとリンクタグのみ）に置き換える」のであれば、サーバーサイドの処理が減るため、TTFBが改善される可能性があります」
www.google.com

　そのうちに、実験してみることにしよう。大差はなさそうな気がするものの……。ただし、同様の趣向で、サイドバーの「プロフィール・モジュール」を「ＨＴＭＬモジュール」にて手打ちで組み直すことで軽くする……といった方策も、各所に上がってはいる。

２６－７．Google検索の「Core Web Vital」の３大指標でもある、「Page Speed Insights」側の上半分のフィールドデータ側の「ＩＮＰ」（Ｉｎｔｅｒａｃｔｉｏｎ　ｔｏ　Ｎｅｘｔ　Ｐｏｉｎｔ）の挙動の変動

（２０２５年９月１８日（木）加筆）

　「Page Speed Insights」側の上半分の直近28日平均の値でもあるフィールドデータ側の「ＩＮＰ」の指標が、２０２５年９月に入ってから悪化してきた。おそらく、８月の最終週にサイドバーを少々追加したからだと推測。それで、サイドバーをまたたま少々減らしてみせた成果か否かは判然とはしないものの、スマホ側の「ＩＮＰ」が「緑」（90点以上）ではあっても１５７ミリ秒にまで悪化していたものが、２０２５年９月１８日に１日だけで１４９ミリ秒まで改善した！　と思ったら、翌日９月１９日には１５７ミリ秒に戻ってしまった（汗）。その翌日９月２０日には１５４ミリ秒、同日の夕方には１５１ミリ秒へと少々改善。その翌日９月２０日には１５４ミリ秒へとまた少々悪化。飛んで、９月２４日には１５９ミリ秒へともっと悪化（汗）。
　飛んで、９月２６日には１３８ミリ秒へと、先日よりも２０ミリ秒以上も改善！（理由がわからず。「ＩＮＰ」指標に関連が深い「ＴＴＦＰ」指標には変化がないのにもかかわらず。「はてなブログ」それ自体側で改善処置があったのか？　Ｇｏｏｇｌｅの「Page Speed Insights」側にて計測方法に変更があったのか？）　ただし、この１３８ミリ秒は、２０２５年９月に入ってから悪化する直前の８月下旬の数値とも同等である。９月２９日にも１３２ミリ秒へと微改善。９月３０日にも１３１ミリ秒へと微改善。１０月１日にも１３０ミリ秒へと微改善。１０月２日にも１２５ミリ秒へと改善。１０月３日には１３０ミリ秒へと悪化。１０月４日には１２３ミリ秒へと改善！（～２００ミリ秒以下であれば、「緑」（90点以上）ではあるので、ヤキモキしなくてもいいか（笑）。よって、以降の「ＩＮＰ」の備忘録的な記録・加筆は中止にする）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　拙ブログの２０２５年１０月時点での課題：自ブログに設定していた「Ｇｏｏｇｌｅタグマネージャー」を廃止

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

２７．拙ブログの２０２５年１０月時点での課題：自ブログに設定していた「Ｇｏｏｇｌｅタグマネージャー」を廃止

（２０２５年１０月１８日（土）加筆）

　拙ブログに対して、個人的に数年前から設定していた「Ｇｏｏｇｌｅタグマネージャー」。実際にはまったく使用していなかったので（使用方法それ自体もよくわからず・汗）、廃止にする方向にて、施策をすることにする。
　ググってみると、「Ｇｏｏｇｌｅタグマネージャー」を導入してしまうと、そのサイトは重たくなるともあったので……。しかし、いきなり廃止にするのでは面白くはない。先にも掲示した、「Ｇｏｏｇｌｅタグマネージャー」の「タグ」の「配信トリガー」を、「Ａｌｌ　Ｐａｇｅｓ」から「ＤＯＭ　Ｒｅａｄｙ」に変更すると、早くなる……といった方策を試してみたい。
gara-kuta.blog
（↑　：　「Ｇｏｏｇｌｅタグマネージャー」側での設定変更についての記載あり。自ブログに「Ｇｏｏｇｌｅタグマネージャー」を設定している場合には要・参考。……と思ったが、「はてな」社それ自体が「はてなブログ」全体に対して「Ｇｏｏｇｌｅタグマネージャー」を設定しているのであった……）

　試してみたかったのだが……。なぜだか、「ＤＯＭ　Ｒｅａｄｙ」に変更できない。そもそも、「ＤＯＭ　Ｒｅａｄｙ」が選択肢として一覧表示されてこない（汗）。単なる当方個人のオペレーションミスなのであろうが、メンドウなので、断念することにした。

　よって、２０２５年１０月１７日（金）に、「はてなブログ」の「詳細設定」画面にて設定できる、「Ｇｏｏｇｌｅタグマネージャー」の「個人ＩＤ」を削除（消去）にしてみた――「はてなブログ」側の設定を削除しただけであって、「Ｇｏｏｇｌｅタグマネージャー」の自分の「個人ＩＤ」それ自体を削除したワケではないことは、念のため――。

　そして、「Page Speed Insights」の下半分に表示されるラボデータ側の「JavaScript の実行にかかる時間の低減」指標の内訳に表示される箇所を参照してみた。「Ｇｏｏｇｌｅタグマネージャー」に起因する「JavaScript」が６種から４種に減っている。
　減っていたのは、自身が設定していた「Ｇｏｏｇｌｅタグマネージャー」の「個人ＩＤ」分であった。残りの正体不明の「Ｇｏｏｇｌｅタグマネージャー」の「ＩＤ」＝「GTM-P4CXTW」分については、拙ブログにかぎらず、よそさまの「はてな無料ブログ」でも「はてなブログＰＲＯ（有料版）」でも、「JavaScript の実行にかかる時間の低減」指標には、必ず表示されている分でもあった。ということは、「はてな社」にて設定している「Ｇｏｏｇｌｅタグマネージャー」の「ＩＤ」でもあるからして、これは解消できないものであるとの判断ができる。

　「Ｇｏｏｇｌｅタグマネージャー」の「個人ＩＤ」を、拙ブログから削除（消去）したことによって、「Page Speed Insights」の上半分のフィールドデータ側の各種指標が、今後の２８日間をかけて減少していくのか否かを、要・確認！（後日付記：後述の「３０．自ブログに設定していた「Ｇｏｏｇｌｅタグマネージャー」を廃止」側にて、その結果を記載）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　ＵＲＬの大文字・小文字違いの誤記起因での自動リダイレクトの有無の調査方法　＆　一括変換方法

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

２８．旧「はてなダイアリー」ではなく、新「はてなブログ」での過去記事への内部リンク。大文字・小文字違いの誤記起因での自動リダイレクトの有無の調査方法　＆　一括変換方法

（２０２５年１０月１８日（土）加筆）

２８－１．ＵＲＬの大文字・小文字の誤記起因での自動リダイレクトの調査方法

　「Ｇｏｏｇｌｅサーチコンソール」の「インデックス作成」の「ページ」の「ページにリダイレクトがあります」画面にて、「はてなブログ」の過去記事のＵＲＬへの内部リンクに、大文字・小文字違いの誤記起因にて、自動リダイレクトが発生していることが発覚する場合がある。
　Ｇｏｏｇｌｅさまの判定においては、そのリンクをクリックして遷移したワケでもないのに、先回りしてリダイレクトをして正規のＵＲＬを取得してから、画面表示用のＨＴＭＬデータを作成しているのだそうな。よって、そのリダイレクトによって、表示速度が遅いと判定されてしまって、「ＴＴＦＢ」指標（Time to First Byte＝リクエストからレスポンスの最初のバイトが到着するまでの時間）が悪化してしまうのだとのこと。

　「はてなブログ」の編集画面こと「記事の管理」画面での全記事一覧画面の「記事を検索」窓からの検索では、ＵＲＬなどの大文字と小文字の区別はナシで検索されてしまって、一覧表示されてしまう。
　編集画面ではなく、「はてなブログ」の対外的な正規の画面のサイドバーに、「検索」窓が設置してあれば、そこから検索してあげると、やはり大文字と小文字の区別はナシで検索されてはしまう。しかし、アーカイブ・ページ（全記事見出し一覧ページ）での要約表示のように、黄色く反転させた該当語句を中心に表示させるかたちで、一覧表示もしてくれる。ただし、大文字・小文字の不一致分も、黄色く反転させた該当語句にて、その先頭の１つ目分だけが表示されてしまうので、そこは注意！

――余談：　「Ｇｏｏｇｌｅサーチコンソール」の「インデックス作成」の「ページ」の「重複しています。Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」画面にて、自ブログの過去記事のＵＲＬが大文字・小文字違いなどの誤記起因にて一覧表示されてしまった場合には、もう対処のしようがないとも思われる（笑）。
　自ブログの記事ではなく、自ブログの記事にリンクを貼ってくれた方の誤記であるためだ。または、自ブログ側にて間違って大文字・小文字違いの誤記版のＵＲＬでいったんアップした記事に対してＵＲＬに修正を施したものの、修正前の誤記版のＵＲＬにてリンクを貼ってくれた方がいた場合であるためだ。あるいは、修正前の誤記版のＵＲＬであった時期に、自分でツイッターなどで修正前の誤記版のＵＲＬ版にてツイートしてしまった場合であるためだ（誤記版ＵＲＬのツイートを削除してしまえばよいのかもしれないが・笑）。
　ただまぁ、自ブログ内での過去記事へのＵＲＬに大文字・小文字違い起因でのリダイレクトが発生していれば、たしかに表示速度には悪影響がある。しかし、外部のサイトやＳＮＳなどからの自ブログへのリンクに大文字・小文字違い起因でのリダイレクトが発生していたとしても、その外部のサイトそれ自身やＳＮＳそれ自身には表示速度に悪影響があるものの、自ブログ内での表示速度にはまったくの無関係ではあるので、気にしなくてもよいとは思われる――

２８－２．ＵＲＬの大文字・小文字の誤記分に対する、一括置換方法

　前述した「１０－２．「ReplaceEntryContent（はてなブログ用ツール）」項目にて記載した、ツールにて一括置換するのが便利である。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　拙ブログの２０２５年１０月時点での整理

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

２９．後日付記：２０２５年１０月時点での整理

（２０２５年１０月１９日（日）加筆）

●２０２５年４月２７日に、拙ブログの「スマホ」画面での表示方法を、「パソコン」側とも同一の画面を表示させる設定から「はてなブログ」規定の「スマホ」版を表示させる方式へと変更したことで、「スマホ」で表示される文字が少々大きくなって、トップページ自体は「最新７記事の見出し一覧」へと変更された。

●２０２５年５月のゴールデンウィーク明けあたりで、膨大なるモジュールを設定していた「サイドバー」を半減させた。

→　２０２５年５月８日～５月２５日時点にかけての１７日間にかけて、「ラボデータ」側ならぬ、「Page Speed Insights」の上半分に表示される直近28日間平均の「フィールドデータ」側の「ＣＬＳ」「ＬＣＰ」「ＦＣＰ」、および「ＴＴＦＢ」「ＩＮＰ」指標については、それらすべてで数値が急上昇！　各々の指標で約０．８～１．２秒ずつ改善。

　施策を開始した直前である２０２５年４月２５日（金）から、５月２３日（金）までの４週間（28日間）の数値の変化は、以下のとおりであった。

●パソコン側：
・［ＬＣＰ」　：３．９秒（爆・オレンジ）　→　３．１秒（オレンジ）
・「ＦＣＰ」　：３．８秒（爆・赤）　　　　→　３．０秒（オレンジ）
・「ＴＴＦＢ」：３．５秒（爆・赤）　　　　→　２．５秒（赤）

●スマホ側：
・［ＬＣＰ」　：４．３秒（爆・赤）　　　　→　３．３秒（オレンジ）
・「ＦＣＰ」　：４．４秒（爆・赤）　　　　→　３．２秒（赤）
・「ＴＴＦＢ」：３．８秒（爆・赤）　　　　→　３．０秒（赤）

→→　２０２５年５月のゴールデンウィーク明けあたりでの、「サイドバー」の減少が主要因であったろうと思われる。

●２０２５年５月２１日に、膨大にあった過去記事へのリンクである旧「はてなダイアリー」時代のＵＲＬを、新「はてなブログ」でのＵＲＬへと一括置換にした。

→　２０２５年５月２１日～６月１７日の約２８日間にかけて毎日、改善されて、各々の指標で約０．７～１．２秒ずつ改善。

　そして、「パソコン」側については、翌月６月８日に「ＬＣＰ」が２．５秒以下の「緑」（90点以上）を達成できたことで、「Page Speed Insights」上では「合格」表記になった。６月１５日には２．２秒を達成――「ＴＴＦＢ」の秒数もじょじょに改善されてはいっているものの、こちらはまだ「赤」（50点未満）であった（汗）。６月下旬には「ＬＣＰ」は１．９秒。「ＴＴＦＢ」は１．６秒で「オレンジ」（50点以上～90点未満）を達成――。

　「スマホ」側の「ＬＣＰ」も、同じく６月８日には２．６秒に達した。その後も、２．５秒以下の「緑」（90点以上）にはあともう少しの２．５秒超は達している。しかし、この２．５秒以下がなかなか達成できなかった。けれども、６月１７日になって、ようやく２．５秒以下を達成して、「Page Speed Insights」上でも「合格」表記になった。

　施策を開始した直後である２０２５年５月２３日（金）から、改善が停滞した直後であった６月２０日（金）までの４週間（28日間）の数値の変化は、以下のとおりであった。

●パソコン側：
・［ＬＣＰ」　：３．１秒（オレンジ）　→　１．９秒（緑）
・「ＦＣＰ」　：３．０秒（オレンジ）　→　１．９秒（オレンジ）
・「ＴＴＦＢ」：２．５秒（赤）　　　　→　１．６秒（オレンジ）

●スマホ側：
・［ＬＣＰ」　：３．３秒（オレンジ）　→　２．５秒（緑）
・「ＦＣＰ」　：３．２秒（赤）　　　　→　２．５秒（オレンジ）
・「ＴＴＦＢ」：３．０秒（赤）　　　　→　１．９秒（赤）

→→　２０２５年５月２１日に、膨大にあった過去記事へのリンクである旧「はてなダイアリー」時代のＵＲＬを、新「はてなブログ」でのＵＲＬへと一括置換したことで、リダイレクトが発生しなくなったことが要因であったろうと思われる。

→　２０２５年６月１７日以降は、「スマホ」「パソコン」側ともに「フィールドデータ」側の「ＣＬＳ」「ＬＣＰ」「ＦＣＰ」「ＴＴＦＢ」各指標の改善は停滞。６月２７日には恐れていた「スマホ」側の「ＬＣＰ」が２．５秒超になってしまって、再度の「不合格」

●２０２５年５月３１日に、ブログのデザインを、「Hatena for はてなブログ」から「classic diary（日記向け）」へ変更した。なおかつ、スマホ側は「レスポンシブデザイン」ことパソコン側と同じ画面を表示させるように設定を変更した。ついでに、廃止にしていた「グローバル・ヘッダー・メニュー」も復活させた。

→　２０２５年５月２１日の「ＵＲＬ一括変更」とも同時期の変更なので、効果の判定については困難である。

●２０２５年７月上旬に、２種の「デザインＣＳＳ」、および「Web Page Test」サイトにて、「レンダリングをブロック」してくる旨で引っかかった４種の「はてなブログ」系の「Ｊａｖａスクリプト」を遅延読み込み、または先読み込みに設定した。

→　特に効果はなかった。パソコン・スマホともども、各々の指標で、４週間（＝28日間）で、約０．０５秒ずつ微改善されていった程度であった。

●２０２５年７月の中下旬あたりに、「はてなブログカード」を一括置換で、単なる「ＵＲＬ」だけの内部リンクへ変更した。

→　特に効果はなかった？　と思われる。

→　２０２５年７月２４日に、「スマホ」側の「ＬＣＰ」がふたたび２．５秒以下の「緑」になって、再度の「合格」。

→　２０２５年７月２６日に、再び２．５秒超過（オレンジ）へと転落して「不合格」！（汗）

●２０２５年７月最終週あたりに、「サイドバー」をさらに減少させた。

●２０２５年７月最終週あたりに、「サイドバー」や「グローバル・ヘッダー・メニュー」側の一部に、旧ＵＲＬが残存していたので修正した。

→　２０２５年７月３０日～８月２５日の約２８日間にかけて、各々の指標で約０．４秒ずつ改善。

　スマホ側については、７月３０日に「ＬＣＰ」が２．５秒以下（緑＝90点以上）を再達成。８月１１日に「ＴＴＦＢ」が１．８秒以下（オレンジ＝50点以上）を達成。
　パソコン側についても、８月２４日に「ＦＣＰ」が１．８秒以下（緑＝90点以上）を達成。

　施策を開始する直前である２０２５年７月２５日（金）から、改善が停滞した直後であった８月２２日（金）までの４週間（28日間）の数値の変化は、以下のとおりであった。

●パソコン側：
・［ＬＣＰ」　：２．０秒（緑）　　　　　　→　１．８秒（緑）
・「ＦＣＰ」　：２．０秒（オレンジ）　　　→　１．８秒（緑）
・「ＴＴＦＢ」：１．６秒（オレンジ）　　　→　１．３秒（オレンジ）

●スマホ側：
・［ＬＣＰ」　：２．５秒（オレンジ）　　　→　２．２秒（緑）
・「ＦＣＰ」　：２．５秒（オレンジ）　　　→　２．２秒（オレンジ）
・「ＴＴＦＢ」：１．９秒（爆・赤）　　　　→　１．６秒（オレンジ）

→→　「サイドバー」の減少と、残存していた旧「はてなダイアリー」時代のＵＲＬを新「はてなブログ」でのＵＲＬへと置換したことでリダイレクトが発生しなくなったことが、要因であったろうと思われる。

●２０２５年８月最終週あたりに、「サイドバー」をじゃっかん増加させた。

→　２０２５年９月５日前後にかけて、各々の指標で約０．１秒ずつ悪化（汗）。

→→　「サイドバー」の増加が、要因であったろうと思われる。

●２０２５年８月３１日～９月１日に、「サイドバー」をさらに減少させた。「サイドバー」の一部モジュールについて、各記事のアイキャッチ画像を「非表示」に設定した。

●２０２５年９月７日前後に、「サイドバー」をさらに減少させた。「サイドバー」の一部モジュールについて、各記事のアイキャッチ画像を「非表示」に設定した。

→　２０２５年９月５日ごろ～１０月７日にかけて、各々の指標で約０．４～０．６秒ずつ改善。

　スマホ側については、１０月５日に「ＦＣＰ」が１．８秒以下（緑＝90点以上）を達成。
　これによって、パソコン・スマホともどもに、「ＴＴＦＢ」のみが「オレンジ」（＝50点以上・90点未満）になって、他は「緑」（＝90点以上）を達成！

　施策を開始する直前である８月２９日（金）から、改善が停滞した直後であった１０月１０日（金）までの６週間（42日間）の数値の変化は、以下のとおりであった。

●パソコン側：
・［ＬＣＰ」　：１．９秒（緑）　　　　　→　１．４秒（緑）
・「ＦＣＰ」　：１．８秒（緑）　　　　　→　１．３秒（緑）
・「ＴＴＦＢ」：１．４秒（オレンジ）　　→　０．９秒（オレンジ）

●スマホ側：
・［ＬＣＰ」　：２．２秒（緑）　　　　　→　１．７秒（緑）
・「ＦＣＰ」　：２．２秒（オレンジ）　　→　１．７秒（緑）
・「ＴＴＦＢ」：１．６秒（オレンジ）　　→　１．１秒（オレンジ）

→→　２０２５年８月３１日～９月１日と９月７日前後にかけての、「サイドバー」の減少が主要因であったろうと思われる。

●２０２５年９月中旬に、スマホ側だけ「サイトバー」の多くのモジュールを非表示に設定した。

●２０２５年９月中旬～下旬にかけて、各種ドメインに「preconnect」（事前接続）を設定した。

→　特に効果はなかった？　と思われる。

●２０２５年１０月の上旬から、一部記事に対して、「はてなブログカード」を少々復活させはじめた。

→　比率で云えば。かつては１００あったうちの５個ほど（？）を復活させてみた程度である。これによる、目に見えての悪影響などはないと思われる。しかし、１０月１９日にパソコン側のフィールドデータ側の「ＦＣＰ」が１．３秒から１．４秒へと悪化したことについては懸念事項である。

……こう整理してみると、「サイドバー」の減少と、旧ＵＲＬを新ＵＲＬへと置換したことだけが、効果があったのであろうか？――「Ｇｏｏｇｌｅタグマネージャー」のドメインへの「preconnect」設定については、２０２５年の７月のことであったか？　８月のことであったか？　失念してしまった（汗）――

今後の方策としては、やはり「サイドバー」をもっと減らしたり、「サイドバー」のアイキャッチ画像を非表示にすべきなのであろうか？

他には、「サイドバー」の「リンクモジュール」や「プロフィールモジュール」を「ＨＴＭＬモジュール」に変更して、ＨＴＭＬ言語での手打ち入力にする方策などもある。しかし、微々たる効果しかもたらさないような気がする。

拙ブログでは、各記事内に過去記事への「内部リンク」（＝「はてなブログカード」にあらず）を膨大多数で大量に貼っている。これらが「ＴＴＦＢ」の数値を悪化させている可能性もある。これを大幅に減らすという方策もある。

前述した「２６－３．内部リンクの多寡も、「ＴＴＦＢ」には影響なし？」では、内部リンクを減少させても、「ＴＴＦＢ」には大きな影響がないようには思えたものの……。膨大にあった過去記事への「はてなブログカード」を、一括置換にてただのＵＲＬだけの「内部リンク」へと変更してみせても、フィールドデータ側の数値には有意な改善が見られなかったことも思えば、「内部リンク」の大幅減少といったこの施策にも大きな効果はなさそうな気もするなぁ（汗）。やはり、まずはサイドバーをさらに減らした方がよいのであろうか？

●やはり、「サイドバー」をさらにもっと減らすことにした（汗）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　自ブログに設定していた「Ｇｏｏｇｌｅタグマネージャー」を廃止

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

３０．自ブログに設定していた「Ｇｏｏｇｌｅタグマネージャー」を廃止

●２０２５年１０月１７日（金）に、自ブログに設定していた「Ｇｏｏｇｌｅタグマネージャー」を廃止

（２０２５年１０月２５日（土）後日付記。以降、順次加筆）

→　２０２５年１０月１７日（金）～１０月２４日（金）にかけて、各々の指標でほぼ変化はなし（汗）

　『自ブログに設定していた「Ｇｏｏｇｌｅタグマネージャー」を廃止』の対策の効果の有無測定については、１０月１７日（金）夜間に廃止を実施してみた。
　「Page Speed Insights」側の上半分のフィールドデータ側のリンク「過去28日間（履歴）」から遷移ができる、実際には毎週の金曜日基準での過去28日間の平均値（＝月曜の１１～１４時ごろに算出される、金曜日分の数値が表示＝月曜の１１～１４時あたりから表示される「フィールドデータ」側の各種数値とも一致）の画面側にて、１０月１７日（金）～１０月２４日（金）の１週間分の変化についてだけは確認ができるので、そこで不充分ではあっても。その結果を見定めてみる。

●パソコン側：
・［ＬＣＰ」　：１．４（１．４２９）秒（緑）　　　　→　１．５（１．４５６）秒（緑）
・「ＦＣＰ」　：１．４（１．３７２）秒（緑）　　　　→　１．４（１．３７２）秒（緑）　
・「ＴＴＦＢ」：０．９（０．９３３）秒（オレンジ）　→　０．９（０．９２３）秒（オレンジ）
→　指標によって、増加したり減少したり。

●スマホ側：
・［ＬＣＰ」　：１．６（１．６４４）秒（緑）　　　　→　１．６（１．６２３）秒（緑）
・「ＦＣＰ」　：１．７（１．６７３）秒（緑）　　　　→　１．７（１．６５０）秒（緑）
・「ＴＴＦＢ」：１．１（１．１１３）秒（オレンジ）　→　１．１（１．０９２）秒（オレンジ）
→　約０．０２秒の改善。誤差の範疇だとすれば、『「Ｇｏｏｇｌｅタグマネージャー」を廃止』の効果は実質的にはなかった？

――２０２５年１１月１０日（月）後日付記：　「Ｇｏｏｇｌｅタグマネージャー」を廃止にしたあと、「Ｇｏｏｇｌｅアナリティクス」が無効になってしまっていたことに気付いた（汗）。原因は凡ミスであった。拙ブログそれ自体には、「Ｇｏｏｇｌｅタグマネージャー」のＩＤだけを設定しており、「Ｇｏｏｇｌｅアナリティクス」のＩＤは設定していなかったからだ。逆に云うと、「Ｇｏｏｇｌｅタグマネージャー」のＩＤだけを設定していれば、「Ｇｏｏｇｌｅアナリティクス」も有効になっていたともいえる――

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　「サイドバー」をさらにもっと減らすことにした（汗）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

３１．「サイドバー」をさらにもっと減らすことにした（汗）

　２０２５年１０月現在、「サイドバー」のモジュールを数えてみると、まだ３１個もある（爆）。うち、１５個は「ＨＴＭＬモジュール」で、「改行」（＝１行空白）を意味する「br」命令文によって、単にモジュール間の「１行空白」を設定しているだけであるので、負荷は軽いと思われる。削れるモジュールとしては、

●トップページではなく各記事のみの表示の場合にのみ、「サイドバー」のトップに表示させている「関連記事モジュール」（＝拙ブログでは「同じカテゴリーの記事」名義に変更して使用）である。１０記事分をアイキャッチ画像付きで表示させているので、負荷は重たいとは思われる。各記事内の下部にも、手書きで同様の内部リンクや「はてなブログカード」を設置しており、そちらとも重複している内容ではあるので、残念だけれども削除候補にしてしまおう。
●「ＨＴＭＬモジュール」で、「同人誌即売会・出店情報」として、近々に参加予定の「同人誌即売会名」と各々の「ブース№」の情報を記載している分がある。負荷は軽いと思われるものの、これもその直上のモジュールに「出店詳細・同人誌詳細」名義にて「同人誌即売会の出店情報の詳細」を記した拙ブログ記事へと遷移すれば、参照可能な情報ではあったので、削除候補にしてしまおう（そもそも、スマホ側では非表示にしているモジュールなのだし……）。
●その直下の「リンクモジュール」での「コミケＷｅｂカタログ」へのリンクも、負荷は軽いと思われるものの、これも先の「出店詳細・同人誌詳細」名義で「同人誌即売会の出店情報の詳細」を記した拙ブログ記事へと遷移すれば、そちらへのリンクも貼ってあるので、こちらも削除候補にしてしまおう（そもそも、スマホ側では非表示にしているモジュールなのだし……）。
●「サイドバー」の一番下から２つ目の「リンクモジュール」で、「年度別の見出し一覧」名義にして、「66年特撮：（初代）ウルトラマン」「67年特撮：（ウルトラ）セブン」～「09年特撮：（侍戦隊）シンケンジャー～」などと一連にしたリンク集それ自体も、サイドバーに記載するのではなく、拙ブログの専用１記事内でのリンク集にしてしまって、その１記事のみへのリンクに変更してしまおう。もしくは、この「リンクモジュール」それ自体を削除候補にしてしまおう（そもそも、スマホ側では非表示にしているモジュールなのだし……）。

　スマホ側では非表示にしているこれらのモジュールではあっても、ウラ側にてそのＨＴＭＬ言語を読み込みしている以上は、画面表示に時間を費やしてしまうそうであるので、特にスマホ向けの速度対策として、サイドバーは減らしておく必要がある。上記のモジュールを削除するのと連動して、「改行」（＝１行空白）を設定している３個の「ＨＴＭＬモジュール」も削除ができる。合計７個のモジュールの削除で、３１個から２４個に減らせることになる。……まだ２４個もある、といった意味では、世間一般的には尋常ではない多さだけれども（汗）。

　ただし、２０２５年１０月１７日から、前述した『２７．自ブログに設定していた「Ｇｏｏｇｌｅタグマネージャー」を廃止』の対策についても実施しているので、その効果の有無を２週間ほど見極めて、１１月に入ってから実施することにしよう。

●２０２５年１０月２５日（土）に、サイドバーを３１個から１９個に減少（ただし、「アイキャッチ画像付きのサイドバーのモジュール」の削除は１本のみ）

→　２０２５年１０月２４日（金）～１０月３１日（金）にかけて、各々の指標でほぼ変化はなし（汗）

　短気を起こして（笑）、２０２５年１０月２５日に、上記のとおりにサイドバーを３１個から２４個ならぬ１９個に減らしてみた（ただし、「アイキャッチ画像付きのサイドバーのモジュール」の削除は１本のみ）。２４個と１９個との差とは、「改行」（＝１行空白）を設定している５個の「ＨＴＭＬモジュール」の削除でもあるので、その５個分については大きな影響はないとは思われるものの……。

　今後の２８日間をかけて、フィールドデータ側の各種数値がどこまで減少していくのか、要・確認！

　以下については、ＧｏｏｇｌｅさまがＳＥＯで重視する「Ｃｏｒｅ　Ｗｅｂ　Ｖｉｔａｌ」にて参考にしている、「Page Speed Insights」側の上半分の直近28日平均の値でもあるフィールドデータ側の各指標の数値である。

●「スマホ」側の「ＬＣＰ」については、１．７秒であったものが、サイドバーを減らした翌日である１０月２６日に１．６秒へと改善！

●「パソコン」側の「ＬＣＰ」ならぬ「ＦＣＰ」についてのみ、１．４秒であったものが、サイドバーを減らした翌日である１０月２６日に１．５秒へと悪化！（汗）

　……とは云ったものの、「Page Speed Insights」側の上半分の直近28日平均の値でもあるフィールドデータ側の各指標の数値については、前述したとおりで、２日前ほどの時点から見た直近28日平均の値ではないのか？　とも推測している。そうなると、サイドバーを減らした前日である１０月２４日（金）時点での数値になってしまう。
　つまり、「サイドバーを減らした効果」ではなくって、『自ブログに設定していた「Ｇｏｏｇｌｅタグマネージャー」を廃止した効果』であった可能性もあるのではあった（汗）。
　あと、２０２５年１０月２０日ごろから、「アマゾン商品画像」が「オフスクリーン画像の遅延読み込み」項目にてエラーにならなくなっている可能性もあって、つまりは自動で「遅延読み込み」されるように改善されている可能性もあって……。

　と云ったソバから、「Ｇｏｏｇｌｅサーチコンソール」の「エクスペリエンス」の「ウェブに関する主な指標」側の「ＰＣ（＝パソコン）」・「モバイル（＝スマホ）」双方の「レポートを開く」の「良好なＵＲＬのデータを表示」の「ＵＲＬグループ」画面にて表示される、自ブログのＵＲＬをクリックすると表示されてくる「ＬＣＰ」指標を参照してみる。すると、まだ一昨日の１０月２４日（金）時点での「ＬＣＰ」が最新数値として表示されていた。つまり、そちらでは昨日１０月２５日（土）までのフィールドデータ側の「ＬＣＰ」の数値と同じ値が表示されていた。
　１０月２６日（日）深夜に、「Ｇｏｏｇｌｅサーチコンソール」側の「ＬＣＰ」指標を参照してみると、昨日の１０月２５日（土）時点での「ＬＣＰ」が最新数値として表示されるようになった。そちらでは、本日１０月２６日（日）の昼前（午前）から表示されるようになったフィールドデータ側の「ＬＣＰ」の数値と同じ値が表示されていた。
　ということは、「フィールドデータ」側の［ＬＣＰ」数値は、「Ｇｏｏｇｌｅサーチコンソール」側の「ＬＣＰ」数値の１日遅れということだ。

　つまり、少なくとも拙ブログにおいては、以下のように、１日ずつズレるかたちで、フィールドデータとしての「ＬＣＰ」の数値が一致していたのであった。

●１．１０月２４日（金）時点分の「Page Speed Insights」側の上半分のフィールドデータ側のリンク「過去28日間（履歴）」から遷移ができる、実際には毎週の金曜日基準での過去28日間の平均値側の「ＬＣＰ」。

●２．１０月２５日（土）時点分の「Ｇｏｏｇｌｅサーチコンソール」側の「ＬＣＰ」。

●３．１０月２６日（日）時点分の「Page Speed Insights」側の上半分のフィールドデータ側の「ＬＣＰ」。

　そうなると、１０月２４日（金）時点分の「ＬＣＰ」は、「Ｇｏｏｇｌｅサーチコンソール」側においては「１日遅れの日付分」の「ＬＣＰ」として、「Page Speed Insights」の上半分の「フィールドデータ」側においては「２日遅れの日付分」の「ＬＣＰ」として、表示されているのではなかろうか？

　この仮説が正しいのであれば、１０月２５日（土）の午前に実施したサイドバーの減少は、「Page Speed Insights」の上半分の「フィールドデータ」側においては、２日遅れの１０月２７日（月）の午前になって、反映されるのではなかろうか？（１０月２７日（月）の午前には、数値の変動は見られなかったものの……）

●「スマホ」側の「ＬＣＰ」ならぬ「ＦＣＰ」については、１．７秒であったものが、サイドバーを減らした３日後である１０月２８日に１．６秒へと改善！　と思ったら、１０月３０日に１．７秒へと悪化（汗）。

●「パソコン」側の「ＬＣＰ」については、１．５秒であったものが、サイドバーを減らした３日後である１０月２８日に１．４秒へと改善！　と思ったら、１０月３０日に１．５秒へと悪化（汗）。　と思ったら、同日に１．４秒へと回復。

　「フィールドデータ」側の１０月２４日（金）～１０月３１日（金）の１週間分の変化については、以下のとおり。

●パソコン側：
・［ＬＣＰ」　：１．５（１．４５６）秒（緑）　　　　→　１．４（１．４０９）秒（緑）
・「ＦＣＰ」　：１．４（１．３７２）秒（緑）　　　　→　１．４（１．３６２）秒（緑）　
・「ＴＴＦＢ」：０．９（０．９２３）秒（オレンジ）　→　０．９（０．８９０）秒（オレンジ）
→　「ＬＣＰ」のみ０．０５秒ほど減少。他は０．０１～０．０３秒ほどの微減。

●スマホ側：
・［ＬＣＰ」　：１．６（１．６２３）秒（緑）　　　　→　１．６（１．６３０）秒（緑）
・「ＦＣＰ」　：１．７（１．６５０）秒（緑）　　　　→　１．７（１．６５０）秒（緑）
・「ＴＴＦＢ」：１．１（１．０９２）秒（オレンジ）　→　１．１（１．０８５）秒（オレンジ）
→　ほぼ変化なし。サイドバーを減らしたのに…。ウ～ム。たしかに「アイキャッチ画像付きのサイドバーのモジュール」の削除は１本のみではあったものの。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　さらに「アイキャッチ画像付きのサイドバーのモジュール」２本を削除

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

３２．さらに「アイキャッチ画像付きのサイドバーのモジュール」２本を削除

●２０２５年１１月１日（土）に、さらに「アイキャッチ画像付きのサイドバーのモジュール」２本を削除

→　２０２５年１０月３１日（金）～１１月７日（金）にかけて、パソコン側では各々の指標で約０．０３５秒、スマホ側では約０．０７０秒ずつ改善。

　２０２５年１１月１日（土）に、さらに「アイキャッチ画像付きのサイドバーのモジュール」２本を削除してみた。以下は、「Page Speed Insights」側の上半分の直近28日平均の値でもあるフィールドデータ側の各指標の数値である。

●「スマホ」側の「ＬＣＰ」については、１．７秒であったものが、サイドバーを減らした３日後である１１月４日に１．６秒へと改善。
　「ＴＴＦＢ」については、１．１秒であったものが、１１月７日に１．０秒へと改善。

●「パソコン」側については「ＦＣＰ」のみ、１．４秒であったものが、１１月６日に１．３秒へと改善。

　「フィールドデータ」側の１０月３１日（金）～１１月７日（金）の１週間分の変化については、以下のとおり。

●パソコン側：
・［ＬＣＰ」　：１．４（１．４０９）秒（緑）　　　　→　１．４（１．３７２）秒（緑）
・「ＦＣＰ」　：１．４（１．３６２）秒（緑）　　　　→　１．３（１．３２９）秒（緑）　
・「ＴＴＦＢ」：０．９（０．８９０）秒（オレンジ）　→　０．９（０．８５２）秒（オレンジ）
→　いずれも、０．０３５秒ほど減少。つまり、４週間（２８日）分に換算すると、４倍になるので０．１４０秒ほど減少して、「ＴＴＦＢ」が０．７５０秒くらい（０．８秒（以下）＝緑＝90点以上）には達するハズ？　「ＬＣＰ」は１．２６９秒？　「ＦＣＰ」は１．２２２秒？
→　４週間（２８日）後の１１月２８日（金）には、「ＴＴＦＢ」が０．６４６秒を達成！　「ＬＣＰ」は１．０９４秒！　「ＦＣＰ」は１．０８５秒を達成！　しかし、後述する１週間遅れで実施した「拙ブログのトップページへの内部リンクで、ＵＲＬの末尾に「／」（スラッシュ）を付与していなかった分についてを、「／」付きのＵＲＬに一括置換」した分の施策の効果も複合された結果ではある。
（「アイキャッチ画像付きのサイドバーのモジュール」２本分なので、１本あたりで０．０７０秒ほどを費やしている？　残りの「アイキャッチ画像付きのサイドバーのモジュール」は５本なので、この５本で０．３５０秒ほどを費やしている？　これらの２＋５＝７本の合計が０．４９０秒となる。仮に「アイキャッチ画像付きのサイドバーのモジュール」を全廃すると、１０月３１日時点での「ＴＴＦＢ」数値である０．８９０秒から０．４９０秒を減算してみせれば０．４００秒にはなるので、「はてなブログ」一般でのパソコン側の「ＴＴＦＢ」の数値でもある平均０．４秒とも一致する！）

●スマホ側：
・［ＬＣＰ」　：１．６（１．６３０）秒（緑）　　　　→　１．６（１．５６２）秒（緑）
・「ＦＣＰ」　：１．７（１．６５０）秒（緑）　　　　→　１．６（１．５７９）秒（緑）
・「ＴＴＦＢ」：１．１（１．０８５）秒（オレンジ）　→　１．０（１．０１３）秒（オレンジ）
→　いずれも、０．０７０秒ほど減少。つまり、４週間（２８日）分に換算すると、４倍になるので０．２８０秒ほど減少して、「ＴＴＦＢ」が０．８０５秒くらい（０．８秒（超過）＝オレンジ＝90点未満）には達するハズ？　「ＬＣＰ」は１．３５０秒？　「ＦＣＰ」は１．３７０秒？
→　４週間（２８日）後の１１月２８日（金）には、「ＴＴＦＢ」が０．８１２秒を達成。「ＬＣＰ」は１．３８４秒。「ＦＣＰ」は１．４０７秒を達成。後述する１週間遅れで実施した「拙ブログのトップページへの内部リンクで、ＵＲＬの末尾に「／」（スラッシュ）を付与していなかった分についてを、「／」付きのＵＲＬに一括置換」した分の施策の効果も複合された結果ではあったものの、パソコン側と比較すると、「アイキャッチ画像付きのサイドバーのモジュール２本を削除」単独の施策としての減少予想値にすらも到達はしなかった（汗）。
（「アイキャッチ画像付きのサイドバーのモジュール」２本分なので、１本あたりで０．１４０秒ほどを費やしている？　残りの「アイキャッチ画像付きのサイドバーのモジュール」は５本なので、この５本で０．７００秒ほどを費やしている？　これらの２＋５＝７本の合計が０．９８０秒となる。仮に「アイキャッチ画像付きのサイドバーのモジュール」を全廃すると、１０月３１日時点での「ＴＴＦＢ」数値である１．０８５秒から０．９８０秒を減算してみせれば０．１０５秒になるので、「はてなブログ」一般でのスマホ側の「ＴＴＦＢ」の数値でもある平均０．５秒よりも小さな数値にはなってしまう。実際には収穫逓減の法則がはたらくので、アリエない仮想値ではあるものの……）

　よって、やはり「アイキャッチ画像付きのサイドバーのモジュール」の存在と、「ＴＴＦＢ」の数値には、ほぼ正比例の相関関係があったと推測するのだ。逆に云うのならば、パソコン・スマホ双方の「ＴＴＦＢ」の分水嶺でもある０．８秒以下（緑）を維持するには、「アイキャッチ画像付きのサイドバーのモジュール」の上限は４～５本といったところではなかろうか？　と推測するのであった――「アイキャッチ画像付きのサイドバーのモジュール」を極力、多く残すためだけに、ここまで遠回りな努力をしてきたのだけれども（笑）――。

　とはいえ、「アイキャッチ画像付きのサイドバーのモジュール」多数を設置しているのに、「ＴＴＦＢ」の数値で０．４～０．５秒をラクラクと達成している「はてなブログ」を発見してしまった場合には――「はてなブログＰＲＯ」は除いての――、「アイキャッチ画像付きのサイドバーのモジュール」以外にも、なにか別の問題点・改善点が潜んでいることにはなってしまうのだけれども……。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　拙ブログの２０２５年１１月時点の課題：「各種ボタン」「はてなリンク」「関連記事」の復活　＆　「内部リンク」の減少

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

３３．拙ブログの２０２５年１１月時点の課題：「はてな」規定の「はてなブックマークボタン」「フェイスブックボタン」「ツイッターボタン」や、旧「はてなキーワードリンク」こと「はてなタグ」のリンクに、サイドバーならぬ各記事の下に「はてな」側にて自動で表示してくれる「関連記事（＝同じカテゴリーとはかぎらない、５種の記事見出し）」の復活　＆　「内部リンク」の減少

　「アイキャッチ画像付きのサイドバーのモジュール」の減少で、「ＴＴＦＢ」の分水嶺でもある０．８秒以下（緑）を達成させる「ひと区切り」がつけば、以下の施策を試してみたい。
　廃止にしてしまった、「はてな」規定の「はてなブックマークボタン」「フェイスブックボタン」「ツイッターボタン」や、自動で付与される旧「はてなキーワードリンク」こと「はてなタグ」のリンクに、サイドバーならぬ各記事の下に「はてな」側にて自動で表示してくれる「関連記事（＝同じカテゴリーとはかぎらない、５種の記事見出し）」。それらを個々に順次、復活させてみるのだ。これらの廃止当時には、各種数値に改善効果は見られなかったものであった。復活させることで、各種数値が悪化しないのであれば、復活させたままにしようとも思うからなのだ。
　加えて、２０２５年１０月２５日（土）にサイドバーを３１個から１９個に減少させた際の、「アイキャッチ画像付きのサイドバーのモジュール」の削除は１本のみではあったのだが、これについても各種数値に改善効果は見られなかった。この削除した「アイキャッチ画像付きのサイドバーのモジュール」とは、拙ブログのトップページにではなく、各記事にのみ表示させていた「関連記事（＝同じカテゴリーの最新記事）」のことであった。これも復活させて実験してみたい。

　先にもふれた、グーグル検索での「ＡＩによる概要」での「内部リンクの数を減らしても、直接的にTTFB（Time to First Byte）が短縮されるわけではありません。TTFBは、主にサーバーサイドの処理速度やネットワーク環境に左右されるためです」。

　しかし、これに対して「はてなブログ」の語句を加えて検索し直してみると……。ウ～ム。拙ブログの場合には、やっぱり内部リンクは減らすべきなのであろうか？（汗）
「はてなブログ 内部リンクが多い場合、TTFBは増大するか」→「はい、内部リンクが非常に多い場合、Time to First Byte (TTFB) が増大する（遅くなる）可能性はあります。ただし、これはリンクの「数」そのものよりも、その数が原因で発生するサーバー側の処理負荷やページのデータ転送量に起因する影響です」「HTMLサイズの増大: リンクが増えることで、ページのHTMLファイルのサイズが単純に大きくなります。これにより、サーバーからブラウザへの最初のバイトの転送に時間がかかる可能性があります」「しかし、通常、適切な範囲の内部リンク数であれば、TTFBに大きな悪影響を及ぼすことは稀です。Googleは「いくつまでなら大丈夫」といった具体的な数値制限を設けていません」
www.google.com

　けれども、そもそも、以下の理由が原因なのやもしれない……（汗）。
「はてなブログ 各記事の文章が長い場合、TTFBは増大するか」→「はい、記事の文章が長くなると、Time to First Byte (TTFB) は増大する可能性が高いです」「データ転送量の増加: 文章が長くなれば、当然ながら生成されるHTMLのデータ量も増加します。サーバーからブラウザーへの最初のデータ送信（最初のバイト）までの時間にも影響が出る要因となります」
www.google.com

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　拙ブログのトップページへの内部リンクで、ＵＲＬの末尾に「／」（スラッシュ）を付与していなかった分についてを、「／」付きのＵＲＬに一括置換

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

３４．拙ブログのトップページへの内部リンクで、ＵＲＬの末尾に「／」（スラッシュ）を付与していなかった分についてを、「／」付きのＵＲＬに一括置換

●２０２５年１１月９日（日）に、各記事の先頭と末尾にある拙ブログのトップページへの内部リンクで、ＵＲＬの末尾に「／」（スラッシュ）を付与していなかった分についてを、「／」付きのＵＲＬに一括置換

→　２０２５年１１月７日（金）～１１月２８日（金）にかけて、パソコン側では各々の指標で約０．２０６～０．２７８秒、スマホ側では約０．１７２～０．２０１秒ずつ改善（しかし、当該の施策の１週間前の２０２５年１１月１日（土）に実施した、「アイキャッチ画像付きのサイドバーのモジュール２本を削除」の効果も複合された結果）

　２０２５年１１月９日（日）に、以下についての施策も実施してみた。
　こちらも世間一般的な処置ではないのだが、拙ブログにおいては、各記事の先頭と末尾に、拙ブログのトップページへの内部リンクを貼っている。こちらのトップページのＵＲＬの末尾には、約１０００記事中の約１６０記事ほどで、トップページのＵＲＬの末尾に「／」（スラッシュ）を付与していない表記になっている。付与されていなくても、問題なく遷移はできる。
　しかし、「／」付きが正規であるのならば、ウラ側にて画面表示用のＨＴＭＬ言語を作成している際に、リダイレクト読み込みが発生しており、それで画面表示速度が遅延している可能性はある。各種のリンク漏れチェックツールなどでは、この「／」なしのＵＲＬにてリダイレクトが発生しているといった判定メッセージは出力されてはいない。しかし、ほとんど「縁起かつぎ」として（汗）、「／」付きのＵＲＬに一括置換することにしてみた。

<a href="https://katoku99.hatenablog.com">拙ブログ・トップページ（最新５記事）</a>

　　　　　↓

<a href="https://katoku99.hatenablog.com/">拙ブログ・トップページ（最新５記事）</a>

　「１０－２．「ReplaceEntryContent（はてなブログ用ツール）」にて例示したツールを使用して、以下の一連のＨＴＭＬ言語の語句に限定して、ＵＲＬの末尾に「／」（＝実際には半角の「/」）を付与する一括置換を実施。ただし、置換前と置換後の語句を「”」（ダブルクォーテーション）で囲む取り決めなのに、その語句のなかにも「”」（ダブルクォーテーション）が含まれいてる。そのような場合には、その語句のなかにも「”」（ダブルクォーテーション）の直前に、「¥」マークを付与する必要がある。この「¥」マークは「例外」を意味させている。「エスケープ文字」ともいう。
（Ｗｉｎｄｏｗｓ常備の「コマンドプロンプト」画面にコピー＆ペーストすると、「¥」マークの部分が「/」（バック・スラッシュ）の文字に変化するが、それで問題なし！）

ReplaceContentText.exe -id katoku99（自分のブログID） -blogid katoku99.hatenablog.com（自分のブログのドメイン） -apikey XXXXXXXXXX（自分のブログのASPキー。「設定」→「詳細設定」→「ASPキー」で確認可） -regex -from "<a href=\"https://katoku99.hatenablog.com\">拙ブログ・トップページ（最新５記事）</a>" -to "<a href=\"https://katoku99.hatenablog.com/\">拙ブログ・トップページ（最新５記事）</a>" -v

ReplaceContentText.exe -id katoku99（自分のブログID） -blogid katoku99.hatenablog.com（自分のブログのドメイン） -apikey XXXXXXXXXX（自分のブログのASPキー。「設定」→「詳細設定」→「ASPキー」で確認可） -from "<a href=\"https://katoku99.hatenablog.com\">拙ブログ・トップページ（最新５記事）</a>" -to "<a href=\"https://katoku99.hatenablog.com/\">拙ブログ・トップページ（最新５記事）</a>" -v

　上記の２種のコマンド（命令文）のいずれでもよいとは思われる。長い方のコマンドには「-regex」が付与されているが、これは「正規表現」の意味である。不要であったのだが、間違って付与して実行してしまった（爆）。しかし、問題なく一括置換できていたので、結果オーライではあった（汗）。そのことも含めて、ここに記録として残しておく。

　以下は、「Page Speed Insights」側の上半分の直近28日平均の値でもあるフィールドデータ側の各指標の数値である。しかし、当該の施策の１週間前の２０２５年１１月１日（土）に実施した、「アイキャッチ画像付きのサイドバーのモジュール２本を削除」の効果も複合したものになる。

●「スマホ」側の「ＬＣＰ」については、１．６秒であったものが、各記事ごとのトップページのＵＲＬの末尾に「／」を付与した２日後である１１月１１日に１．５秒へと改善。「ＦＣＰ」についても、１．６秒であったものが、１１月１３日に１．５秒へと改善。１１月１７日には「ＬＣＰ」のみ１．４秒へと改善。１１月２５日には「ＦＣＰ」も１．４秒へと改善！――ただし、１１月２５日に改善した分は、後述する理由で、実際にはその２日前の１１月２３日には改善していた分であるとも推測――
　「ＴＴＦＢ」については、１．０秒であったものが、１１月１６日に０．９秒へと改善。１１月２７日には０．８秒へと改善！（ただし、「ＴＴＦＢ」の「緑」と「オレンジ」の分水嶺でもある０．８秒ではあっても、０．８秒超過ではあるので、まだ「オレンジ」）

●「パソコン」側の「ＬＣＰ」については、１．４秒であったものが、各記事ごとのトップページのＵＲＬの末尾に「／」を付与した４日後である１１月１３日に１．３秒へと改善。「ＦＣＰ」についても、１．３秒であったものが、１１月１７日に１．２秒へと改善。１１月２５日には「ＬＣＰ」も１．２秒へと改善。同日には「ＦＣＰ」のみ１．１秒へと改善――ただし、１１月２５日に改善した分は、後述する理由で、実際にはその２日前の１１月２３日には改善していた分であるとも推測――。１１月２９日には「ＬＣＰ」も１．１秒へと改善！
　「ＴＴＦＢ」については、０．９秒であったものが、各記事ごとのトップページのＵＲＬの末尾に「／」を付与した２日後である１１月１１日に０．８秒へと改善（ただし、「ＴＴＦＢ」の「緑」と「オレンジ」の分水嶺でもある０．８秒ではあっても、０．８秒超過ではあるので、まだ「オレンジ」）。１１月１７日には、同じく０．８秒名義ではあっても、０．８秒以下を意味する「緑」（90点以上）へと改善。１１月２５日には０．７秒へと改善――ただし、１１月２５日に改善した分は、後述する理由で、実際にはその２日前の１１月２３日には改善していた分であるとも推測――。１２月３日には０．６秒へと改善！（実際には１１月２８日（金）には０．６秒へと改善していたものと推測）

　「Page Speed Insights」の上半分のフィールドデータ側の値である「直近28日分の平均値」の「直近28日分」の具体的な『期間』については、フィールドデータの値のすぐ下に表示されている『過去28日間（？）　（履歴）』欄の『（？）』の語句の部分にカーソルをかざすと、「開始年月日～終了年月日」のかたちで表示されてくる。
　通常は、早い時間帯であると「終了年月日」が３日前の日付。早い時間帯であると「終了年月日」が２日前の日付が表示される。
　しかし、なぜか２０２５年１１月１８日～２５日の１週間分については、「直近28日分」の具体的な『期間』が停滞してしまって変化がほぼなくなってしまっていた。「終了年月日」については、以下のとおりで、「Ｃｏｒｅ　Ｗｅｂ　Ｖｉｔａｌ」側にて何か異常があったとおぼしきで、通常は２日前の日付になるはずが、最大で６日前の日付になってしまっていたのだ。つまり、１１／２５の日中にフィールドデータ側の「ＬＣＰ」などに数値が変更があった分については、「終了年月日」が４日前の１１／２１になっていた分であって。本来はその２日後の１１／２３に、「Page Speed Insights」の上半分のフィールドデータ側の値として表示されていた分であったことになると推測している。

・１１／０９　　　　　　　　：１０／１１～１１／０７の28日間
・１１／１０　　　　　　　　：１０／１２～１１／０８の28日間
・１１／１１、２０：２９　　：１０／１３～１１／０９の28日間
・１１／１２、２０：４０　　：１０／１３～１１／０９の28日間（同上なので、おかしい）
・１１／１３　　　　　　　　：１０／１５～１１／１１の28日間
・１１／１４、１３：４３　　：１０／１５～１１／１１の28日間（同上なので、おかしい）
・１１／１５　　　　　　　　：１０／１６～１１／１２の28日間
・１１／１６、００：００　　：１０／１６～１１／１２の28日間（同上なので、おかしい。「終了年月日」も、当日の４日前の日付）
・１１／１６、０８：３５　　：１０／１７～１１／１３の28日間
・１１／１７、０６：３２　　：１０／１８～１１／１４の28日間
・１１／１７、１１：５６　　：１０／１９～１１／１５の28日間
・１１／１８、１６：３８　　：１０／１９～１１／１５の28日間（同上なので、おかしい）
・１１／１９　　　　　　　　：１０／１９～１１／１５の28日間（同上なので、おかしい。「終了年月日」も、当日の４日前の日付）
・１１／２０　　　　　　　　：１０／１９～１１／１５の28日間（同上なので、おかしい。「終了年月日」も、当日の５日前の日付）
・１１／２１、１５：４６　　：１０／１９～１１／１５の28日間（同上なので、おかしい。「終了年月日」も、当日の６日前の日付）
・１１／２１、１８：５２　　：１０／２１～１１／１７の28日間（「終了年月日」が、当日の４日前の日付なので、おかしい）
・１１／２２　　　　　　　　：１０／２１～１１／１７の28日間（同上なので、おかしい。「終了年月日」も、当日の５日前の日付）
・１１／２３　　　　　　　　：１０／２１～１１／１７の28日間（同上なので、おかしい。「終了年月日」も、当日の６日前の日付）
・１１／２４　　　　　　　　：１０／２２～１１／１８の28日間（「終了年月日」が、当日の６日前の日付なので、おかしい）
・１１／２５、１５：３８　　：１０／２５～１１／２１の28日間（「終了年月日」が、当日の４日前の日付なので、おかしい）
・１１／２５、２０：４８　　：１０／２７～１１／２３の28日間
・１１／２６　　　　　　　　：１０／２７～１１／２３の28日間（同上なので、おかしい）
・１１／２７、１０：０７　　：１０／２７～１１／２３の28日間（同上なので、おかしい。「終了年月日」も、当日の４日前の日付）
・１１／２７、１３：３３　　：１０／２８～１１／２４の28日間
・１１／２７、１９：２５　　：１０／２９～１１／２５の28日間
・１１／２８　　　　　　　　：１０／２９～１１／２５の28日間（同上なので、おかしい）
・１１／２９、０８：４１　　：１０／２９～１１／２５の28日間（同上なので、おかしい。「終了年月日」も、当日の４日前の日付）
・１１／２９、０９：５６　　：１０／３０～１１／２６の28日間
・１１／２９、１９：５５　　：１０／３１～１１／２７の28日間

　ついでに、「Page Speed Insights」側の上半分のフィールドデータ側のリンク「過去28日間（履歴）」から遷移ができる、実際には毎週の金曜日基準での過去28日間の平均値（通常は月曜の１１～１４時ごろに算出されて表示）の画面側では、過去１０ヵ月分の毎週金曜日のフィールドデータが「折れ線グラフ」形式にて参照できる画面それ自体についても、異常が発生していたようだ。１１月２４日（月）になっても、どころか１１月２６日（水）になっても、直近の金曜である１１月２１日（金）基準での最新情報が表示されてこなかったのだ――１１月２７日（木）になってから、ようやく表示されるようになった――。
　その翌週分についても、１２月１日（月）中には表示されずに、１２月３日（水）１２時過ぎになってから、ようやく表示されるようになった（汗）。

　「フィールドデータ」側の１１月７日（金）～１１月１４日（金）～１１月２１日（金）～１１月２８日（金）の３週間分の変化については、以下のとおり。

●パソコン側：
・［ＬＣＰ」　：１．４（１．３７２）秒（緑）→１．３（１．２８４）秒（緑）→１．２（１．１９３）秒→１．１（１．０９４）秒（緑）
・「ＦＣＰ」　：１．３（１．３２９）秒（緑）→１．２（１．２４５）秒（緑）→１．２（１．１５０）秒→１．１（１．０８５）秒（緑）
・「ＴＴＦＢ」：０．９（０．８５２）秒（オ）→０．８（０．７９４）秒（緑）→０．７（０．６８１）秒→０．６（０．６４６）秒（緑）
※：ただし、「ＴＴＦＢ」については、１２月３日（水）の午前７時４６分の時点で１１月２８日（金）までの２８日平均とされていた「Page Speed Insights」の「フィールドデータ」側では、０．７秒のままであった。「Page Speed Insights」側でのナニかがオカシい？　同日の１２時３１分には、１１月３０日（日）までの２８日平均に変更されていた「Page Speed Insights」の「フィールドデータ」側では、しかるべき０．６秒の表示に変更はされたものの……。加えて、このタイミングで、過去１０ヵ月分の毎週金曜日のフィールドデータの「折れ線グラフ」形式の直近の金曜日分がようやく表示されるようになった。そうなると、１１月３０日（日）までの２８日平均というお題目・名義ではあっても、実際には１１月２８日（金）までの２８日平均としての値が、このタイミングで「フィールドデータ」側には表示されるようになったのではなかろうか？
→　１１月７日（金）～１１月１４日（金）の１週間で、「ＬＣＰ」と「ＦＣＰ」は０．０８６秒ほど減少。「ＴＴＦＢ」は０．０５８秒の減少。その１週間前の１０月３１日（金）～１１月７日（金）の変化（＝「アイキャッチ画像付きのサイドバーのモジュール」２本の削除）については、いずれも０．０３５秒ほどの減少だったことを考えると、「ＴＴＦＢ」に限定すれば、その差額の０．０２３秒ほどが「各記事ごとのトップページのＵＲＬの末尾に「／」を付与」した効果なのではなかろうか？
　つまり、４週間（２８日）分に換算すると、４倍になるので「ＴＴＦＢ」は０．０９２０秒ほど減少？　「アイキャッチ画像付きのサイドバーのモジュール」２本の削除によって、「ＴＴＦＢ」が最終的には０．７５０秒くらいに達すると推測していたので、そこから減算すると、０．６５８秒くらい（０．７秒）にまで達するハズ？（結果的に、１２月３日に０．６秒にまで到達した。実際には、１１月２８日（金）には０．６秒へと改善していたものと推測）

）

●スマホ側：
・［ＬＣＰ」　：１．６（１．５６２）秒（緑）→１．４（１．４４７）秒→１．４（１．４１４）秒→１．４（１．３８４）秒（緑）
・「ＦＣＰ」　：１．６（１．５７９）秒（緑）→１．５（１．４９１）秒→１．４（１．４３６）秒→１．４（１．４０７）秒（緑）
・「ＴＴＦＢ」：１．０（１．０１３）秒（オ）→０．９（０．８９９）秒→０．８（０．８４８）秒→０．８（０．８１２）秒（オレンジ）
※：ただし、「ＴＴＦＢ」については、１１月２７日（木）の午前１０時０７分の時点で、１１月２１日（金）ならぬ２３日（日）までの２８日平均とされていた「Page Speed Insights」の「フィールドデータ」側では、０．９秒のままであった。「Page Speed Insights」側でのナニかがオカシい？　同日の１３時３３分には、しかるべき０．８秒の表示にはなったものの……。加えて、このタイミングで、過去１０ヵ月分の毎週金曜日のフィールドデータの「折れ線グラフ」形式の直近の金曜日分がようやく表示されるようになった。そうなると、実際には１１月２１日（金）までの２８日平均としての値が、このタイミングで「フィールドデータ」側には表示されるようになったのではなかろうか？
→　１１月７日（金）～１１月１４日（金）の１週間で、「ＬＣＰ」は０．１１５秒も減少。「ＦＣＰ」は０．０８８秒の減少。「ＴＴＦＢ」は０．１１４秒も減少。その１週間前の１０月３１日（金）～１１月７日（金）の変化（＝「アイキャッチ画像付きのサイドバーのモジュール」２本の削除）については、いずれも０．０７０秒ほどの減少だったことを考えると、「ＴＴＦＢ」に限定すれば、その差額の０．０４４秒ほどが「各記事ごとのトップページのＵＲＬの末尾に「／」を付与」した効果なのではなかろうか？
　つまり、４週間（２８日）分に換算すると、４倍になるので「ＴＴＦＢ」は０．１７６秒ほど減少？　「アイキャッチ画像付きのサイドバーのモジュール」２本の削除によって、「ＴＴＦＢ」が最終的には０．８０５秒くらいに達すると推測していたので、そこから減算すると、０．６２９秒くらい（０．６秒）にまで達するハズ？

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　各記事内の過去記事への膨大多数の「内部リンク」の大幅減少

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

３５．各記事内の過去記事への膨大多数の「内部リンク」（＝「はてなブログカード」にあらず）の大幅減少

拙ブログでは、各記事内に過去記事への「内部リンク」（＝「はてなブログカード」にあらず）を大量に貼っている。これらが「ＴＴＦＢ」の数値を悪化させている可能性もある。これを大幅に減らすという方策もある

　２０２５年１２月６日（土）現在、拙ブログの全１０８８記事中の約７２０記事ほどの先頭と末尾には、拙ブログの「トップページ」と「アーカイブ・ページ」（＝全記事・見出し一覧ページ）への「（自ブログへの内部）リンク」を貼っている。
　拙ブログの「トップページ」と「アーカイブ・ページ」（全記事見出し一覧ページ）へのリンクは、「サイドバー」と「グローバル・ヘッダー・メニュー」上にもリンクを貼っている。よって、各記事側については、存在していなくても支障はないともいえる。
　なので、各記事側の「トップページ」と「アーカイブ・ページ」（全記事見出し一覧ページ）への「内部リンク」については、一括置換で一挙に削除してしまうことも検討中である。これによって、約７２０×４＝２８８０個ほどの「内部リンク」を一挙に削除してみて、「ＴＴＦＢ」の数値に改善が見られるか否かを観測してみるのだ。しかし、「全体」に対する「部分」、「分母」に対する「分子」の比率の問題になるのであって、「内部リンク」の総数こと「母数」の正確なところがわからない（笑）。とりあえず、大雑把に「分子」の１０倍を「分母」として仮定しておくか？

　ググってみると、「内部リンク」をカウントする方法はいくつかあったものの、「Ｇｏｏｇｌｅサーチコンソール」の「リンク」の「内部リンク」項目で、その総数が一応はわかる。４６，４０４件とあった――Ｇｏｏｇｌｅが検索準備用に事前クロール（巡回）してカウントした分だとのこと――。しかし、各記事だけでなく、サイドバー側に表示されている「内部リンク」もカウントしているようなので、それらは重複カウントされていることになる。加えて、「トップページ」と「アーカイブ・ページ」は各々が約７２０×２で１４４０個ほどになるハズだが、前者は１４１個、後者は３１５個になっているので、あきらかにオカシい（汗）。
　しかし、とりあえず他にカウント方法がないので「当たらじといえども遠からず」で、便宜的に「内部リンク」の総数は４６，４０４件だと仮定すると、約７２０×４＝２８８０個ほどの削除候補の「内部リンク」は、全体に対する６．２％ほどになる。全体に対する６％！　６／１００！　微々たるものではある（汗）。その意味では、たとえ効果があったとしても、測定できるほどの結果にはならないような……。
　憶測にて換算すれば、１０／１００で、「内部リンク」の全体数に対する１０％ほどは占めているとは思われるものの……。

　ただし、「トップページ」と「アーカイブ・ページ」へのリンクを一括置換にて削除をする際には、直後の改行コードも削除（消去）をしないと、ムダに意味不明な空白行だけが残存してしまうことにもなる。いわゆる「正規表現」で「改行コード」も含めての削除は可能なのであろうか？（汗）
　前述した『１０－２．「ReplaceEntryContent（はてなブログ用ツール）」』の項目にて紹介した、一括置換ツールの本家のサイトをあらためて確認してみたところ、可能そうではあった！
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
ReplaceContentText.exe -id hatena -blog-id hatena.hatenablog.jp -api-key ****** -from "削除したい文字列"
ReplaceContentText.exe -id hatena -blog-id hatena.hatenablog.jp -api-key ****** -regex -from "置換したい文字列の正規表現" -to "置換後の正規表現"

• regex

オプション。　-fromおよび-toに指定された文字列を正規表現として解釈します。　正規表現を使った置換を行いたい場合はこのオプションを使用してください。

• regexオプションを指定した場合は、-toオプションで$1などの正規表現を指定することにより-fromでキャプチャした文字列に置換することができます。　-fromオプションは複数行モードの正規表現として処理されます。　-regexオプションで使用できる正規表現は.NET Frameworkで使用できる正規表現を参照してください。

（引用元の一括置換ツールの本家サイトでの説明文では、「-from」などが「--from」、つまり「-」が２文字連続の「--」になっているが、実際には１文字のみの「-」表記が正解なので、注意！）

.NET Frameworkで使用できる正規表現

エスケープ文字

・「\n」：LF, ラインフィード
・「\r」：CR, キャリッジリターン

　上記の２種で、特に前者側にて、「改行コード」のことであるのだと、判定ができればよいのだが……（汗）。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

　しかし、「トップページ」と「アーカイブ・ページ」へのリンクを貼ってある、「グローバル・ヘッダー・メニュー」それ自体を削除しないといけない日が来ないともかぎらない。各記事側の「トップページ」と「アーカイブ・ページ」へのリンクを削除してしまうことを、軽々に決定してしまってもいけないのではあった。

　ただし、各記事側の「トップページ」と「アーカイブ・ページ」へのリンクを完全削除にしてしまって復活できないという手法ではなく、既存の語句とは重複していない、加えて視覚的にもあまり邪魔にはならない、例えば「☆☆☆☆☆」や「＃＃＃＃＃」に「％％％％％」などの無意味な語句の羅列に、一時的（半永久的）に一括置換をしておいて、「ＴＴＦＢ」の数値が改善されるか否かを検証してみる。その結果については、後日に随時加筆。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＝　後日付記：Ｇｏｏｇｌｅ用「ＳＥＯ」対策　：　改善前の「Page Speed Insights」での計測結果は、要・ブックマーク！

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

９９．後日付記：改善前の「Page Speed Insights」での計測結果は、ブックマークしておくこと！　後日にこのブックマークを再表示させると、最新版ではなく、そのブックマーク時点での「Page Speed Insights」での計測結果が再表示されるため！　特に「Page Speed Insights」の上半分の直近28日分の平均値としての「フィールドデータ」側の指標を、最新版のそれと比較する際には重宝するため！（しかし、28日間だけの有効であって、それよりも過去になってしまうと、当時の記録は再表示されないのであった……）

（２０２５年５月２５日（日）加筆）

[覚え書き][関連記事]
画面の回転（画面の向き）が不可の場合の対処　〜2010年度NECノートPC･LaVie･Windows7･グラフィックドライバーがintel(R) Graphics Media Accelerator HDの場合
　　https://katoku99.hatenablog.com/entry/20131111/p1
同人誌即売会オンライン申込用のサークルカット作成方法（一例）
　　https://katoku99.hatenablog.com/entry/20121210/p1
テキストエディターで行数（非改行）が表示されるのはTeraPad
　　https://katoku99.hatenablog.com/entry/20120801/p1
テキストエディターでの禁則処理・句読点のぶら下がり設定（私家版）
　　https://katoku99.hatenablog.com/entry/20120802/p1
強制改行で保存されたＭＳ−ＤＯＳ（テキスト）文書の、強制改行の外し方
　　https://katoku99.hatenablog.com/entry/20120803/p1
InDesignで日本語の原稿用紙マス目イメージ・文字組み・禁則処理と同一にしたい場合
　　https://katoku99.hatenablog.com/entry/20050102/p1

はてなブログ Perfect GuideBook 改訂第2版
はてなブログカスタマイズガイド: HTML & CSSで「はてなブログ」を次のステップへ!
初心者向けブログで役立つ本！【はてなブログ偏】 (ムースブックス)
はてなダイアリーガイドブック: ウェブログでつながる新しいコミュニティ
はてなダイアリー実践デザインカスタマイズガイド

[覚え書き]　〜全記事見出し一覧
拙ブログ・トップページ（最新５記事）
拙ブログ・全記事見出し一覧