本サイトのレスポンシブ化の記録

私は、定年を過ぎてから、ホームページ（HP）を作り始めたのだが、最初はホームページの作り方についての知識はほとんどなかった。当時、すでにホームページ作成のテキストなどは、モバイル対応デザインの必要性を強調していたが、私には必ずしもそうは思えなかったのである。

そう考えた最大の理由は、私自身のＷＥＢサイトに関する知識と技術力の不足だった。今にして思えば、技術力不足でサイトのモバイル対応が困難だったため、無理にそう考えようとしたことは否めない。

また、私のサイトは、労働衛生というビジネス向けなので、パソコンで閲覧されることがほとんどだろうと安易に考えてしまったこともある。

とはいえ、私の技術力不足のため、当初のサイトのコンテンツ（記事）はすべてＰＤＦファイルで作成していた。html ファイルで作成していたのは、各コンテンツへの目次的なページだけであった。そのため、モバイル対応デザインとする意味があまりなかったことも事実である。

しかし、その後、私の技術力も向上し、html ファイルをある程度自由に作成できるようになってきた。そのためＰＤＦファイルのデメリットもあり、新しい記事は html ファイルで作るようになっていったのである^（※）。

※　ＰＤＦファイルは、Ｗｏｒｄで執筆した文書をＰＤＦ化すればできるので作成するのは容易なのだが、デザイン的な自由度が少なくメンテナンス（修正）に時間がかかるのである。さらに、詳細なアクセス分析も困難であった。

そのため、当サイトで最も人気の高い労働安全衛生コンサルタント試験の過去問の解説は、かなり前から作成していたことからＰＤＦファイルで公開していたが、衛生管理者試験の過去問^（※）の解説は 後になって作成を始めたので html ファイルで作成するという状況となった。

※　当時、当サイトでは労働安全衛生コンサルタント試験の解説のページの閲覧数（ＰＶ数）の値は、他のページを圧倒していた。しかし、その後、衛生管理者試験の解説のページの人気が増加し、現在では当サイトの人気を二分している。

ただ、そうなると、html ファイルの利便性が私にも分かってくる。このため、人気の高い記事である労働安全衛生コンサルタント試験の過去問解説も、2020 年にすべて html に変換したのである^（※）。html 化したことによって、モバイル対応の必要性が増したのである。

※　コンテンツの html への変更は概ね閲覧者の方から歓迎されたが、印刷しにくいことからＰＤＦの方がよいという意見もあった。しかし、モバイルで閲覧するので、html の方がよいという意見が大勢を占めた。

さらに、すでにＰＤＦファイルで作成していた他の記事も、2021 年に、原則としてすべて html 化した。その結果、ＰＤＦファイルではできない各ページごとの閲覧状況の分析が、html ファイルではできるので、サイト全体の閲覧状況の分析ができるようになったのである。

そして、サイト内の各ページの閲覧状況の分析ができるようになるにつれ、モバイルで閲覧される方の割合がかなり多いことが判明し、ほぼ４割に達することが分かったのである^（※）。モバイル化しないと、使いづらいということが分かってきたのである。

※　総務省の「令和３年版情報通信白書」によれば、2020 年のインターネット利用端末は68.3％がスマホとされている。純粋なビジネス向けのサイトでもスマホによる閲覧数が急増している。当サイトは、国家試験の受験支援という個人向けのコンテンツが増えているのだから、なおさらである。

図のクリックで拡大します

図は、Googleアナリティクスで調べた、私のサイトのデバイスの種類別にみた一箇月当たりのユーザー数^（※）である。デスクトップ（パソコン）が最も多いものの、モバイル（スマホ）を使用されている方の割合もかなりあることが分かる。

※　Googleアナリティクスの概念であるが、実際にサイトを利用した「人」の数。一人の「人」が数回訪問してもユーザー数は１となる。ただし、実際にはCookieで判断しているので、１人の「人」がパソコンとスマホでそれぞれ訪問すると２になる。

さらにそのような中、Google は、モバイル対応していないサイトは、検索結果から順位を下げると宣言する。そして、個々のサイトの中から試験的に選んだものに、モバイルファーストインデックス（MFI）を適用するようになったのである。

図のクリックで拡大します

MFI が適用されると、Googleサーチコンソルの設定画面で、インデックスクローラが「パソコン用Googlebot」から「スマートフォン用Googlebot」に変更され^（※）る。私のサイトはこれまでは適用されていないので「パソコン用Googlebot」のままになっている。

※　また、適用された日付も記載されるが、必ずしもそのサイトに適用された日というわけではないようだ。なお、カバレッジに表示されるメインクローラーも「PC」から「スマートフォン」に変更される。

モバイル対応が必要であると私にも強く感じられるようになってきた。しかも、そのような中でモバイル対応をしていない身近なサイトで MFI が適用され、検索によるヒット数が激減するという例が実際に起きたのである^（※）。

※　Googleサーチコンソールの画面に、MFI が適用されたとのポップアップ表示があり、その後、検索パフォーマンスの「クリック数」と「表示回数」がともに激減した。しかも激減した後は、「表示」又は「クリック」されたのはすべてPDFファイルなどで、htmlファイルは表示されなくなってしまったのである。

そして、モバイルユーザビリティの項目で、「エラー」のあるページ、「有効」なページの双方ともにゼロになってしまった。そればかりか外部リンク数がゼロと評価されるようになってしまった。もちろん、実際にはいくつかの被リンクが存在しているにもかかわらずである。Googlebotがそのサイトのhtmlファイルを認識しなくなってしまったようなのである。

なお、実際に Google で検索してみると、これまでとあまり変わらない順位で表示されているので、これは Google サーチコンソールの統計上だけの問題なのかもしれない。

とはいえ、ＰＣでの閲覧を前提として作成したページ（html ファイル）の数は 2,000 を優に超えており、モバイル化のためにはこれらのファイルすべてに修正を加える^（※）必要があった。

※　実際には、各ファイルで共通な部分の修正は、専用ソフトを用いて一括変換することが可能なケースがほとんどである。しかし、修正する必要がある部分に、各ファイルで共通ではない記述があると、その部分は個別に手作業でファイルを修正しなければならない。そのような場合でも、WordPressなどで作成したサイトであれば一括変換できることもあるのだが、当サイトはhtmlファイルとcssファイルを記述して作成しているので、そのようなことはできないのである。

また、サイト内の国家試験の過去問の解説には、大きな図表を数多く用いている。これを幅の狭い画面に表示するのはかなり困難であり、これをどうするかという問題もある。

さらに、各ページのヘッダ（ページ上部）に設置してあるプルダウンナビをどうするかという問題も存在していた。常識的には、モバイルで閲覧するときには小型アイコン（ハンバーガーメニュー）^（※）にして、クリックすると展開するようにすればよいわけだが、子メニュー、孫メニューなどの数が多すぎて、そのまま展開すると画面いっぱいに広がって利便性を損なうという事情があった。

※　アイコン中に横線を３本縦に並べたデザインにする習慣があり、ハンバーガーに似ているので、ハンバーガーメニューと呼ばれる。

このため、モバイル対応は、当サイトの大きな課題であり、なんとかしたいという思いは高まりつつも簡単には実現できない「far-off dream（見果てぬ夢）」でもあったのである^（※）。

※　映画「ラマンチャの男」では、「impossible dream」を「見果てぬ夢」と訳しているが、この場合は impossible とまではいえないので「far-off dream」としている。

このような中で、あるきっかけによって、モバイル対応も意外に不可能ではないのではないかと思えるようになった。そのきっかけはささいなことである。

当サイトの労働安全衛生コンサルタント試験受験支援のページでは、過去問の解説をタブ形式で表現しており、問題と解説をタブで切り替えるようにしてある。このページで「解説を読んでいるときに問題文を見直そうとすると、タブのある位置までスクロールしなければならない。面倒なので簡単に表示できるようにして欲しい」という要望があったのである。

そこで、問題文をポップアップ形式で読むことができるようにしたのだが、これもすべてのページを一部手作業で修正する必要があった。また、偶然ではあるが、結果的に、ポップアップするウインドウの大きさは閲覧している画面の幅にフィットするようにしたのである^（※）。

※　ただし、この時点では、画面の小さなデバイスで閲覧すると図表が乱れてしまい、スマホ対応といえるようなものではなかった。

※　イメージ図（©photoAC）

しかし、このとき修正したコンサルタント試験の過去問の html ファイルは、当サイトの半数近いのである。だったら、スマホ対応のためにすべての html ファイルを修正することも不可能ではない。

また、プルダウンメニューを展開すると数が多くなりすぎてユーザビリティが悪くなるという問題は、モバイル機器では子メニュー以下を表示しないという方法をとればよい。それでもモバイル化しないよりはよいと思えてきた。

図表をどう表現するかの問題はあるが、他の多くのサイトを参照してみると、大きな表はスクロールできるようにし、図はピンチアウトで拡大することで対処している例が多いようである。これも対応ができないわけではないのだ。

モバイル対応には、大きく分けて２つの方法がある。ひとつは、ＰＣ用とモバイル用の２つのサイトを作成する方法である。ただ、２つのサイトを作成するには工数がかかりすぎるため、かなり大組織のサイトでない限り採用することはほとんどない。

そして、もうひとつがレスポンシブデザインである。これは、閲覧するデバイスの画面の幅に合わせて、ページレイアウトを変化させるデザインのことである。すべてのデバイスの幅に合わせなければならないため、やや、デザインがやりにくく、またデバイスによっては無駄な読み込みが増えて読み込み速度が悪くなりがちというデメリットもある。

しかし、個人や中小規模の企業のサイトであればレスポンシブデザインがもっとも現実的である^（※）。当サイトも、レスポンシブデザインを採用することとした。

※　Google もレスポンシブデザインの方を推奨している。

この場合、スマホは最も小さなものでも横幅が 320 ピクセルなので^（※）、それより小さな端末には対応しないこととした。モバイル端末でこれより小さなものは存在していないためである。事実、Googleアナリティクスによる分析でも、これより小さな端末での閲覧はないことが確認されている。

※　Galaxy Fold では 280 ピクセル表示があり得るが、実際にはそのような使い方はしないだろう。現時点では、375 ピクセルのものが最も多い。

モバイル端末は、WEB サイトを表示するとき、サイトの幅を表示画面に収まるように大きさを調節して表示する機能がある。このとき、一部の文字のみを大きく表示するようになっている。

全体像を把握するには良い機能で、人がピンチアウト操作をすればよいという発想であろう。しかし、これではレスポンシブルデザインの場合、どのような表示になるか分からない。

そこで、レスポンシブデザインにするのであれば、この機能を働かないようにする必要があるのだ。そのため、まず html ファイルの head の部分に次の一文を入れる。

<head>
<meta name="viewport" content="width=device-width,initial-scale=1">
</head>

これは、モバイル等の端末でサイトを表示したときに、画面の拡大縮小はしないようにするが、ピンチ操作による拡大縮小は許すという意味である。通常は、このまま head 内に記述すればよい。

※　イメージ図（©photoAC）

グローバルナビとは、各ページの上部にある横長のサイト内メニューのことである。当サイトでは、マウスホバー^（※）でプルダウン表示するようになっている。画面幅の狭いデバイスでは、ＰＣでの表示と同じように表示することはできないので、なんらかの対応をする必要がある。

※　マウスカーソルを重ねること。

通常は、モバイル端末ではメニュー全体を前述したハンバーガーメニューにしてしまい、クリックしたときに展開するようにする。

当サイトのグローバルナビも、html ファイルの記述は一般的なものなので、css ファイルを書き換えることで簡単にハンバーガーメニューにできると思っていたのだが、実際にやってみると、これがかなり難しいのである。

そこで、今回は次回以降の課題として残すことにし、幅の狭いデバイスではメニューを多段階にすることにした。とりあえずレスポンシブル化し、今後、改良してゆけばよいという方針を採ったのである。

そして１段のときは、画面をスクロールしても画面上部に常にグローバルナビが表示されるようにしていたのだが、多段階にするとさすがに邪魔なので、この機能はなくした。また、モバイル端末では、子メニューは表示するが孫メニュー以下は表示されないようにした。

当サイトは、各ページの表題をかなり大きなフォントにして、背景画像に重ねて表示するようにしている。これはこのままのフォントでは、画面の小さなデバイスではあまりにも大きすぎる。

そこで、画面の大きさに合わせてフォントを小さくするようにするが、ある程度以下の大きさにはならないようにし、背景の画像の大きさもそれに合わせて変化するようにした。

問題は Internet Explorer で、このフォントの大きさを調整する機能が使えないのである。Internet Explorer で閲覧する場合は見捨てるという判断もないわけではない^（※）。しかし、当サイトの訪問者でInternet Explorer を使用しておられる方の割合は、減りつつはあるが現在でも８％程度おられる。さすがに Internet Explorer のサポート終了までは、その閲覧を無視することは現実的ではない。

※　Internet Explorer は 2022 年６月 16 日（日本時間）で、Microsoft 社のサポートが終了し、その後は IE を起動しようとすると自動的に Edge が起動するようになる。また、それ以前からTwitter や Google、サントリーなど、Internet Explorer での閲覧は保証しないという方針を採る企業も多い。

そこで、Internet Explorer を使用する場合は、ＰＣでの閲覧に限られるということを前提^（※）に、やや大きめの固定された大きさのフォントを表示することで対応することにした。ただし、トップページだけは、やや手間のかかる方法で Internet Explorer にも対処できるようにした。

※　かつて、スマホ（Android）で Internet Explorer を使用できたという話が存在しているが、たぶん都市伝説だろう。仮に事実だとしても現時点でそんなことができるわけがないし、できたとしても誰もやらないだろう。

また、トップページのキービジュアル^（※）のスライドショーを、それまで個人の方が公開していたシステムから、一般的な SLIC という方式に切り替えた。これによって、最初の画像が表示されるまでの時間が大幅に改善されている。

※　トップページ上部の画像のこと。メインビジュアルとも呼ばれる。WEBサイトを訪れる方は、メインビジュアルから３秒でそのサイトを閲覧するかどうかを決めるといわれる。

パンくずリストという用語は、まだ一般には知られていないかもしれない。多くのサイトの各ページの上部に、トップページから閲覧しているページまでの各階層を表示するリンク付きのリスト^（※）のことである。

※　チルチルとミチルが、家に戻るための目印として、道にパンくずを落としておいたことが名称の由来となっている。ＷＥＢサイトの製作者にとっては普通の用語である。ただ、いくつかの種類があり、必ずしも各階層を表すものだけではない。

トップページからの階層が離れたページでは、パンくずリストは長くなる。画面の狭いモバイル端末にあえてパンくずリストを表示することが妥当かどうかについては議論がある。しかし、最近ではあったほうが良いという意見の方が優勢になっているようである。

問題は、どのように表示するかである。かつては、画面からはみ出す場合には、折り返して複数行で表示するのが普通だったように思う。また、それぞれの表現の文字数を極力減らすという方法も併せてとられる。しかし、このような方法を採用すると、当サイトの場合はグローバルナビと合わせてあまりにも大きな面積がナビだけで占められることになる。

最近では、１行で表示し、スクロールして全体を見ることができるようにするサイトも増えている。そこで、当サイトでも、この方法を採用した。こればかりは、何が正解というわけではなく、現時点では感覚的に選ぶしかないだろう。

表は、ある程度の小さな画面であれば各セルの幅を狭めることで対応は可能である。しかし、モバイル端末のように横幅の狭いデバイスではそうはいかない。

そこで、大きな表は横方向にスクロールして表示するようにした。この場合、表題的な行や列は固定して常に画面に表示するという手法もあるが、今回は採用しなかった。

ただし、各セルの最小時の幅は iPhone の典型的な画面の幅である375ピクセルを超えないようにした。また、表全体の幅はＰＣで1,024ピクセル以上で表示したときは、原則としてスクロールしなくても全体が表示されるようにするという方針を採った。

また、図は、たんなるイメージイラストであれば、デバイスの画面幅に合わせてそのまま小さくすることもできるが、説明用の図ではそうもいかない。

さらに、元のレスポンシブ化する前の表示で、クリックすると拡大するようにしてある図をどうするかという問題もある。というのは、拡大しても画面いっぱいに広がるだけなので、画面幅が小さいと、ほとんど拡大しないのである。

そこで、説明用の拡大しない図はスクロールするようにすることで対処した。また、拡大する図は元の図は画面幅に合わせて小さくすることにし、拡大させた図をピンチアウト操作によって大きくできるようにすることで対処することとした。

記事中の数式をどうするかは意外に難しい問題を有していた。

当サイト内の数式の表示は３通りの方法によっている。１つは通常の行と同じ書き方によるもの。２つ目は分数式で２行の表を用いているもので、よく Word 文書などでもみられるものである。そして、３つ目は MathJack という数式を表す本来の手法を用いているものである。

そのままの形だと、通常の行を用いているものは折り返して表示され、２行の表を利用しているものは形が崩れ、３つ目は画面からはみ出して表示される。

そこで、通常の行を用いているものは<div>タグで囲んで長さを数式に合わせ、横方向にスクロールするようにした。２つ目は通常の表と同じようにスクロールさせ、３つ目は１つ目と同じようにした。

また、レスポンシブル化を行った後で、スマホでの閲覧速度の改善のために、いくつかの修正も行った^（※）。

※　なお、当サイトは、2013年７月に「さくらのレンタルサーバー」のサーバ更新（さらに速く、快適に New さくらのレンタルサーバ）を行って速度改善を試みた。

残念ながら、新サーバーで不具合が出たため、エックスサーバーに移転した。エクスサーバーはさくらのレンタルサーバーより高速なので、さらに速度改善が図られることとなった。

ＰＣで閲覧している方は、今回のレスポンシブ化ではＳＮＳボタンの位置だけが変更されただけで、デザインの変化には気付かれない^（※）と思うが、閲覧速度は改善されているはずである。

※　閲覧しているWindowの横幅を1,024ピクセルより小さくすると、横幅に応じて全体のデザインが変化する。しかし、1,024ピクセルより大きなWindowでは、ＳＮＳボタンの位置の変化以外には、ほとんどデザインの修正はない。

当サイトにはいくつかの SNS の公式ボタンが設置してある。そのひとつは、Facebookの公式「いいね」ボタンとシェアボタンであるが、この読み込みにかなりの時間がかかるのである。そこで、Facebookのボタンは、ページの他の部分がすべて読み込まれた後に表示される設定とした。具体的には、Facebookのスクリプトコードに次の「js.async = true;」の行をいれるだけである。

<!-- facebook like -->
<div id="fb-root"></div>
<script>(function(d, s, id) {
　var js, fjs = d.getElementsByTagName(s)[0];
　if (d.getElementById(id)) return;
　js = d.createElement(s); js.id = id;
　js.async = true;
　js.src = 'https://connect.facebook.net/ja_JP/sdk.js#xfbml=1&version=v3.2';
　fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</>

なお、Facebookを始めとして各種のＳＮＳの公式ボタンをすべてページの最下部に移動させた。これはＷＥＢサイトの一般的なデザインに合わせるという意味もあるが、最初に閲覧者から見える画面の範囲から外すことで、表示が遅くなるという問題を解消したのである。

また、当サイトを開設した当初に Google＋ へのシェアボタンを設置したのだが、その後、Google＋ がサービスを廃止してしまった。画面上はシェアボタンは表示されなくなったが、html の記述が残っており、閲覧速度を遅らせる一因となっていた。これもこの機会にすべて削除した。

本サイトでは、画面上は小さく表示されるイラスト等に、オリジナルの大きな画像を用いていたケースがあり、表示速度を遅らせる原因となっていた。これは、使用条件としてオリジナルを用いる必要がないことが確認できたものは、すべてイラストを小さくして差し替えた。

後は、画像を jpg や png から、次世代画像形式の WebP や AVIF に変更すれば、読み込み速度が速くなることは分かっているのだが、これらの新しい形式は Internet Explorer では表示できない。さすがに、そこまですると Internet Explorer での閲覧が困難になるので、Internet Explorer のサポート終了後の６月 16 日以降に対応することとした。

※　なお、Internet Explorer で当サイトを閲覧すると、先述したように表題文字の大きさが Window 幅に応じて変化しない他、表題文字の黒い縁取りが表示されなかったり、Twitter の公式ボタンが表示されなかったり、画面からはみ出す枠が正常に表示されなかったりするなどの状態になるが、そこはデザインだけの問題なので割り切っている。

図のクリックで拡大します

この結果、Google Search Console の「モバイルユーザビリティ」の評価は、図に示すように大きく向上した。

このことは SEO^（※） の上からも良い影響がある。結果的に、私のサイトが一般の方の目に触れる機会を増やす効果があるはずである。

※　検索結果のページで、対象となるサイトを上位に上げるための対策のこと。

１つのページで改善されていないという評価だが、これはGoogleのボットのクロールが行い切れていないためである。激減した直後は４だったが、時間が経過するにつれて徐々に減少して現時点では１になっている。

図のクリックで拡大します

また、劇的に改善されたのが、モバイルの読み込み速度であった。それまでも不良とされているページはなかったものの、ほとんどのページが改善が必要（LCP^※ 2.5秒超モバイル又はFID 100秒超モバイル）とされていたのである。これが、ほぼ解決してしまったのだ。

※　LCP（Largest Contentful Paint ＝最大コンテンツの読み込み速度）とは、表示されている領域において、そのページの読み込みを開始してから最も容量の大きなコンテンツが表示されるまでの時間のこと。FID（First Input Delay ＝ページの反応速度、読み込みの応答性）とは、ユーザーが最初にリンクのクリックなどの操作したときから反応するまでの時間を指す。

この直接の原因が何かは分からないが、Facebook の公式ボタンの改善か、Google＋シェアボタンの削除か、画像の縮小の効果のどれかであろう。

図のクリックで拡大します

さらに、その後、数週間を経てからモバイルのページ エクスペリエンス^（※）が急速に改善された。グラフは５月９日までのものであるが、良好URLの比率はさらに改善されそうな勢いである。

※　ページ エクスペリエンスとは、Googleの評価によるユーザーの「使いやすさ」の指標である。Google は 2021 年６月からこの指標を検索順位に反映させると宣言している。

なお、表示回数が４月 29 日から低下しているが、これは同日からゴールデンウイークに入っているからである。

図のクリックで拡大します

右図はパソコンのページ エクスペリエンスであるが、こちらも表示回数が４月 29 日から表示回数が低下しているが、休日による周期的なものである。

なお、パソコンはモバイル対応とは無関係に、ほぼ100 ％の比率で良好とされている。通常、モバイルよりパソコンの方が読み込み速度等が早くなるので、ページ エクスペリエンスはパソコンの方が良い数字となる。

閲覧数についても、Googleアナリティクスの分析によると、レスポンシブ化を図った後のモバイルを用いた閲覧数が増加しており、全体の閲覧数に占めるモバイル利用の割合も高まりつつある。

図のクリックで拡大します

また、これは必ずしも因果関係は明確ではないが、モバイル対応の実施と同時期に衛生管理者試験支援のページの閲覧数（ＰＶ数）が急増した。それ以前から増加の兆しはあったのでその傾向が続いただけかもしれないが、衛生管理者試験支援のページだけで月に１０万ＰＶ弱から１７万ＰＶを超えるまでに上昇したのである。

図は、上が当サイトのＰＶ数、下が衛生管理者試験支援のページに限ったＰＶ数である。当サイトのＰＶ数は労働安全衛生コンサルタント試験の筆記試験が実施される 10 月に急増する傾向があるのだが、2022年は衛生管理者試験のページのモバイル対応を図った３月、４月にも増加傾向がみられる。

３月以降の増加の原因は衛生管理者試験のページのＰＶ数の伸びが原因である。かつては５万ＰＶ程度だったが、４月には４倍程度まで増加している。これもモバイル対応が一因だった可能性はある。

図のクリックで拡大します

また、スマホの平均セッション時間^（※）が伸びてきている。当サイトは労働安全衛生コンサルタントの筆記試験が行われる１０月にセッション時間が長くなる傾向はあるが、スマホのセッション時間はパソコンのセッション時間より常に短かった。これはスマホは電車の中など隙間時間で用いられるためかと思っていた。ところがモバイル対応後にその差が縮まったのである。

※　Googleアナリティクスの用語で、「平均セッション時間」とは、ユーザーが当サイトに訪問してから退出するまでの時間の平均値である。ただし、最後に閲覧したページの滞在時間はゼロと計数されるので、実際の滞在時間より短くなる傾向がある。

※　イメージ図（©photoAC）

やはりスマホでの当サイトの閲覧がしやすくなったことの反映だと解釈できるだろう。事実、個別の情報ではあるが、通勤電車の中でスマホでコンサルタント試験の勉強をするときに見やすくなったという感想もいただいている。

今後、さらにスマホでのユーザビリティを向上させてゆきたいと思う。