PCサイトをレスポンシブウェブデザイン（RWD）化した時のメモ

2016年にGoogleはモバイルファーストインデックス（MFI）を正式に発表しました。MFIをざっくり説明するとGoogle検索結果に表示する順番を決定する評価の対象をモバイル端末にすると言うことです。

つまり現在評価の対象であるPC向けページの評価はされなくなるわけです。

当サイトもPCサイトでありモバイル対応といえばメタタグに viewportを記述しているだけです。これではモバイルフレンドリーと呼べる代物ではありません。

そこで今回当サイトもちゃんとモバイル対応（SEO）してみることにしました。モバイル化の実装方法は Googleが推奨するレスポンシブウェブデザインにしました。その理由は既存の HTMLコードと CSSコードを追加、変更することで実現できそうだったからです。

以下はその時のメモです（2017/02）

参考｜ようこそ！｜Mobile Frendly Websites｜Google Developers

対象のモバイル端末と表示切換えのブレークポイント

Googleの言うモバイル端末とは、スマートフォンでありタブレットはモバイル端末に含まない別カテゴリーです。なのでブレークポイントは 480pxの1種類にしました。

したがって CSSで使用したのは次のメディアクエリのみです。

/*480px以下*/
@media screen and (max-width: 480px) {
  セレクタ {
    プロパティ: 値;
  }
}

2019年12月追記

タブレット端末に対応しました。ブレークポイントは 1024pxです。下の画像はデスクトップとこちらのサイトでタブレットとスマートフォンをエミュレートしたスクリーンショットです。

デスクトップ

タブレット

スマートフォン

この機会に <iframe> は廃止しました。これと HTML、CSS の見直しによりページの表示速度は 50%以上速くなりました。

Googleのテストツールである Lighthouse の平均点は 93.75、Test My Site のテスト結果は 4Gネットワークでサイト全体の速度 2.3秒（判定：平均）でした。

▲ 目次へ

ボトルネックだった HTMLタグ - pre , img , video ,table , iframe

既存の HTML , CSSにコード変更や追加を施すという手法を取ったので対処療法的（行きあたりばったり）になりました。故にこれが正しい方法かどうかは分かりません。なお W3C認証チェックはクリアしています。

<pre> ~ </pre>

<pre>タグが PC向けのコードのままですと 480px以下では画面からはみ出てしまい、Googleのモバイルフレンドリーテストをクリアできません。そこで次のように対処しました。

既存のPCサイトのコードは下記のように overflow プロパティで疑似インラインフレームにしているので

CSS
/* 545pxより長いとき水平方向にスクロールする*/
.prebox {
  overflow: auto;
  overflow-y: hidden;
  width: 545px;
}

次の2パターンを設定し場合によって使い分ける事にしました。

CSS
/*480px以下,水平方向にスクロール*/
@media screen and (max-width: 480px) {
  .prebox1 {
    width: 90%; /*画面サイズに合わせる*/
  }
}

CSS
/*480px以下,コードを折り返す*/
@media screen and (max-width: 480px) {
  .prebox2 {
    white-space: pre-wrap; /*英単語を折り返す*/
    width: 90%; /*画面サイズに合わせる*/
  }
}

<pre>タグはレスポンシブウェブデザインにおいては使わないのがベストだと思います。しかし、当サイトでは既に Linux OSのコマンドやコードの記述に多用しており、それは出来ませんでした。

▲ HTML タグへ

<img>

<img>タグで画像を表示させている場合次のように

/*480px以下*/
@media screen and (max-width: 480px) {
  img {
    max-width: 100%;
  }
}

するとよいと聞いたのでやってみると確かにサイト内の全ての画像がレスポンシブルになりました。しかし結果的にこれは使えませんでした。

その理由は、当サイト内の画像の9割に画像を拡大表示させる LightBox Plusを使っているのですが、これが正常に動作しなくなったためです。具体的には画像をクリックすると半透明の画像が画面全体を覆ってしまう状態になります。

試行錯誤の末、次のように対処しましたがこれはおそらく当サイトだけに通用するものと思います。

HTML
<div class="imagebox">
 <p class="caption">飛行機</p>
 <p class="image"><a href="airplain.jpg" class="lightbox[pc01]">
 <img src="airplain.jpg" width="240" alt="飛行機の画像"></a></p>
</div>

に対して（既存のHTMLには手を加えていない）

CSS
/*480px以下*/
@media screen and (max-width: 480px) {
  .imagebox {
    margin: 0;
  }
}

とすると LightBox Plusは正常に動作するようになりました。というわけで画像サイズはレスポンシブルにはならず固定サイズのままその配置の並びが変動するのみです。

もともと PCサイトのページ上に表示させている画像サイズは最大でも 240pxなので画面からはみ出ることはありません。

▲ HTML タグへ

<video> ~ </video>

動画の埋め込みに iframeは使わず<video>タグだけで実装しています。既存の HTMLから width="映像の幅" を削除して次のように対処しました。

HTML
 <video controls poster="video-splash.jpg">
  <source src="sample.mp4" type='video/mp4; codecs="avc1, mp4a"'>
  <source src="sample.webm" type='video/webm; codecs="vp8, vorbis"'>
 </video>

CSS
video {
  width: 97%;
  }

ここではメディアクエリは必要ありませんでした。widthの値が100%でないのは PC表示の体裁のためです。

▲ HTML タグへ

<table> ~ </table>

<table>タグは次のサイトの「項目を分離させる」セクションを参考にして横に並んでいるセルを縦に並び変え、さらに<table> ~ </table>を<div> ~ </div>で囲い、画面右端と表の間にスキマを入れました。

（スキマを入れなくても画面からはみ出すことはありません）

参考サイト｜CSSだけでレスポンシブテーブルをつくろう

HTML
<div class="table-m">
 <table class="sousyoku">
  <tr>
   <th colspan="4">パソコン組立てに必要なパーツ</th>
  </tr>
  <tr>
   <td>PCケース</td>
   <td>電源ユニット</td>
   <td>マザーボード</td>
   <td>CPU</td>
  </tr>
     ⋮
   <td>キーボード、マウス</td>
  </tr>
 </table>
</div>

CSS
/*480px以下*/
@media screen and (max-width: 480px) {
  .table-m {
    width: 96%;
  }
}

上述の結果が下の画像です。この画像の表より複雑な構成になると何を表しているのか分かりずらくなります。

なので<table>タグも<pre>タグと同じくレスポンシブウェブデザインにおいては使わないのがベストだと思います。

▲ HTML タグへ

<iframe> ~ </iframe>

HTML
 <div id="sidemenu">
  <iframe src="sidemenu.html"></iframe>
 </div>
 <div id="sidebutton">
  <iframe src="sidebutton.html"></iframe>
 </div>

CSS
/*480px以下*/
@media screen and (max-width: 480px) {
  iframe {
    height: 1460px; /*値をautoにするとスクロールバーが入る*/
  }
}

/*900px以下*/
@media screen and (max-width: 900px) {
  .sidebutton iframe {
    display: none; /*ボタンを表示しない*/
  }
}

のようにしました。サイドメニュー自体を表示する場所は flotを解除してページのいちばん下、フッター直前にしました。

さらに<iframe>内に読み込んでいる sidemenu.htmlに対してボタンの高さ 20pxをメディアクエリで 40pxにし、さらにフォントサイズも大きくしようと思いサイドメニュー用の CSSに次のように記述しました。

CSS
/*480px以下*/
@media screen and (max-width: 480px) {
  #menu ul li a {
    display: -webkit-flex; /*Safari*/
    display: flex;
    align-items: center;
    justify-content: center;
    font-size: 1em;
    height: 40px;
  }
}

しかしこれは単に PC用 CSSを上書きしただけの、つまり PCの表示も大きくなってしまいメディアクエリは効きませんでした。（sidemenu.html単独でウェブブラウザを開くとメディアクエリは正常に動作します）

そこで何か解決策はないものかとインターネットを検索してみると、次のような jQueryを使って CSSを適用する方法が紹介されていたので Firefoxで試してみました。

まず sidemenu.htmlの head内の CSS読込みコードを削除して oyapage.htmlに次のように記述しました。

HTML
 <div id="sidemenu">
  <iframe id="aaa" src="sidemenu.html"></iframe>
 </div>

 <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js"></script>
 <script>
 $(function(){
  $('#aaa').on('load', function(){
   $('#aaa').contents().find('head').append('<link rel="stylesheet" href="sidemenu.css" type="text/css" />');
   });
 });
</script>

確かに CSSは適用されましたが、肝心のメディアクエリが適用されませんでした。なお IE11と vivaldi1.6では CSS自体が適用されませんでした。

そういう訳でメディアクエリでボタンサイズとフォントサイズを変化させることを諦めました。結局 PCサイトもスマートフォン用のボタンサイズとフォントサイズにしました。

▲ HTML タグへ

▲ 目次へ

モバイルフレンドリーテストの結果

レスポンシブウェブデザインへ変更が完了したところで、Fetch as Googleの「モバイル：スマートフォン（レンダリングリクエスト）」と Googleが提供しているモバイルフレンドリーテストを試してみました。

次の画像はその結果のスクリーンショットです。

Fetch as Google

モバイルフレンドリーテスト

このようにクリアすることができました。ここで Fetch as Googleまたはモバイルフレンドリーテストの [GOOGLEに送信] ボタンをクリックするとスマートフォン用 Googlebotによるクロールをリクエストできます。

急ぎの時は利用するとよいと思います。ただし 100%リクエストに応えてくれる訳ではないようです。当サイトはもう少し細かいところを詰めたいのでこのリクエストはしていません。そのうち勝手にクロールしてくれると思うので。

モバイルフレンドリーテストをクリアしても最適化されているとは限らない

モバイルフレンドリーテストをクリアしたことで確かに Googleの定義するモバイル端末、即ちスマートフォン画面上の体裁は整いました。しかしそれは文字どおり表面上の事だけであり本当の意味で最適化されたわけではありません。

これは Googleが提供しているウェブページの読込み時間を短縮するのための支援ツールである PageSpeed Insights で当サイトのページを解析したことでよく分かりました。

この支援ツールはスマートフォン用とPC用があり、解析結果はそれぞれ表示されます。当サイトのページでは概ね次の内容が指摘されました。

画像	ファイルの圧縮
CSS	ファイルの圧縮 , ファイルの遅延読込み
JavaScript	ファイルの圧縮 , ファイルの遅延読込み , ファイルの削除

下の画像はそのスクリーンショットです。

しかし、これらを全てクリアしようとするとそれはもうレスポシブウェブデザインサイトを 1から作り直すのと同義なので外部 CSSの読込みに使用している @import.cssを廃止するに留め、これより先の事に対応するのはやめました。

▲ 目次へ

雑感

レスポンシブウェブデザイン化をやって思う事

レスポンシブウェブデザイン化を終えたところで数年前、当サイトを HTML5 + CSS3で作りなおした時のことを思い出しました。それまで使っていた HTML4.1の有料テンプレートが昔のテーブルレイアウトだったからでした。

当時は HTMLや CSSの知識などまったく持っていなかったのでかなり苦労したことを今でも覚えています。しかし、その事がここにきて報われたような気分になり、あの時作り直しておいて本当に良かったなと思いました。

管理人にとってそう思えたことが今回のレスポンシブウェブデザイン化の最大のメリットでしたね。こういうのを本来の意味の因果応報と言うんでしたっけ？

レスポンシブウェブデザイン化のデメリット

管理人が思うデメリットで 1つ目は、HTMLおよび CSSファイルのサイズがそれぞれ 50kb , 13kbほど増えた事。

2つ目は、サイト自体が当初からPC向けに作成しておりスマートフォンをまったく意識していないのでレスポンシブウェブデザイン化の際、その装飾にはある程度の妥協が必要だった事。

最後に、これはデメリットと言ってよいのか分かりませんが、Windows 7上の Internet Explorer 11で起こっている現象です。

当サイト任意のページから別のページに遷移するとトップメニューのリンクボタンが一瞬スマートフォン用（480px）のメディアクエリでレンダリングされ、その後 PC用のリンクボタンがレンダリングされる現象が発生しました。

もちろんブラウザの表示を 480px以下に縮めた状態では起こりません。

下の画像がその瞬間を捉えたスクリーンショットです。矢印の部分が PCサイトで表示されるはずのないスマートフォン用のリンクボタンです。これを撮るのに少々手こずりました。

しかし Windows 7上の Firefox , Vivaldi そして Ubuntu 14.04 LTS上の Firefox , Vivaldi , Chromium の各ブラウザにおいてはこのような現象は起こっていません（いずれも実機）

つまり Internet Explorer 11だけで起こる現象だと思われます。なぜメディアクエリが先にレンダリングされてしまうのか皆目見当がつきません。なのでこれはこのまま放置することにしました。

2017年5月追記｜Windows 10 Insider Preview ver.1703 64-bit の Edge で上記の現象は起こっていません

モバイルファーストインデックス（MFI）導入はいつ？

2017年2月現在 MFIの導入時期について少し調べてみました。Googleは導入前に発表するようなことを言っているようですし、その他一般の記事では今秋あたりに導入とか、いやもう既に導入されているなど要するにいつ導入されるのか分からないと言うことですね。

ただウェブマスター素人の管理人が言うのも何ですがモバイル対応（SEO）しておいて損はないと思います。

最後に、本文中のモバイルフレンドリーテストの結果のセクションで「そのうち勝手にクロールしてくれると思う」と書いていますがこのページをサーバーにアップロードする前に Search Consoleを覗いてみました。

下の画像は Search Consoleモバイルユーザビリティのスクリーンショットです。レスポンシブウェブデザイン（RWD）全ページをアップロードしてから約2週間くらい経っています。

御覧のように Fetch as Googleでクロールリクエストしていないにもかかわらずクロールしてくれていますね。残り7件になっています。

モバイルユーザビリティの問題をクリアしました

2017年3月追記

下の画像はレスポンシブ化したページをアップロードしてからおよそ 1ヶ月経過した Search Consoleモバイルユーザビリティのスクリーンショットです。

当サイト全ページのモバイルユーザビリティの問題をクリアする事ができました。

▲ 目次へ

モバイルファーストインデックス（MFI）開始

モバイルファーストインデックスが開始されましたね。最も気になるであろうランキング評価は、2018年3月27日付け Googleウェブマスター向け公式ブログによれば次のようなものだと管理人は理解しました。

MFIにランキングの優位性はない
ページの読み込み速度をモバイル検索のランキング要素に使用する
ユーザー検索ワードに強い関連性があればモバイルファーストでなくても検索結果に表示する
MFIに移行しているサイトは Search Console で通知する

この中で1つ気になる事があります。先述のブログ冒頭には 1.が記載されているのですが MFIのベストプラクティスを覗いてみると以下の記述があります。

“Mobile-first indexing means Google will predominantly use the mobile version of the content for indexing and ranking. Historically, the index primarily used ... ”

これを Google翻訳すると

「モバイル初のインデックス作成は、Googleが主にコンテンツのモバイル版をインデックスとランキングに使用する ことを意味します。従来、このインデックスは... 」

となります。どっちでもいいんですけど、どっちなのでしょうかね？

▲ 目次へ

Lazy-loading をマークアップした｜2020年 2月追記

Chromium 79（Google Chrome 79）で loading属性、値 lazy がネイティブサポートされたので早速、当サイト全ページの画像に対してコーディングしました。

HTML
<img src="photo/slim_ubuntu18_desktop_92.png" loading="lazy" width="268" alt="デスクトップの画像">

その結果 Lighthouse の平均点は 96.25、Test My Site は 4Gネットワークでサイト全体の速度 2.0秒（fig 1）と、いずれのスコアもアップしました。

なお、loading属性は現時点で W3Cに認証されていないので validation checkにかけると、下の画像（fig 2）のように全てエラーとなります。

fig1. Test my site の判定

fig2. W3C Validation check の結果

その他のブラウザでは Firefoxの開発版である Firefox Nightly最新バージョンに追加されました。下の画像はその次の段階のベータ版のスクリーンショットです。

Firefox 74.0b6

about:config を開いて lazy で検索すると lazy-loading が false（無効）の状態で追加されています。

Firefox 74.0b6 about:config
 dom.image-lazy-loadeing.enabled		false
 privacy.testrict3rdpartystorage.console.lazy	true
 toolkit.lazyHiddenWindow			true

これを true にすれば有効になります。安定板では Firefox 75 でサポートされる模様です。

▲ 目次へ