モバイル対応化

今年になってサイトのページを色々改定した.最初文字コードをそれまで主にShift_JISであったものをUTF-8に書き換えた.それまでもGoogle maps APIでは必要だったので該当ページはUTF-8にしていたが,ややこしいので全面的に書き換えた.

それが3月上旬Googleウエブマスターで,『モバイルユーザビリティ上の問題が検出されました』とのお知らせを受ける.詳しく見るとそれは『重大な問題』であるようだ.ということでこの問題に一応何とか対応したので整理しておきたい.

UTF-8化

モバイル対応化とは直接関係ないが,Google maps APIを使う場合文字コードはUTF-8使用が望ましいとされていた.そこでGoogle mapsが挿入されるページではUTF-8を,他ページではShift_JISとしてあった.ただUTF-8とShift_JISのファイルを混在するのはややこしいし,間違えたりする可能性もあるので全ファイルUTF-8に書き換えることにした.

2バイトコードのShift_JISに対して,UTF-8コードは,文字に依っては3バイト,4バイトとなるそうだ.つまりファイルサイズがその分大きくなるようである.ただ当サイトの各ページは圧倒的にファイルサイズの大きな写真が大半を占めているので,クライアントへのダウンロードや表示時間を悪化させる程度は微々たるものと思う.

UTF-8コードにするには,先ず<head>タグ内の文字エンコーディングの指定を<meta charset="utf-8">(HTML5)と書き換えた.

全ファイル書き換えるのは結構大変だし,ミスも起こしやすい.そこでファイル中の特定文字列を別の文字列に書き換えてくれるソフトを使わせてもらった.そのソフトはGimite市川氏作成のDevas(ディーヴァス)Ver3.4というありがたいフリーソフトで,指定ディレクトリ内の,指定属性全ファイルの文字列(複数行可)検索し,新しい文字列に置換してくれる.フアイルオープン/クローズを行う必要もなく自動で,極めて強力だ.もちろん文字コード書き換えは一例で,他でもDevasを多用させてもらった.とにかくすばらしいソフトだ.

文中に文字エンコーディングの指定を行っただけでは,ファイルが実際UTF-8コードで書き換えられ訳ではない.そこでこの変換は,サクラエディタでまだShift_JISである各ファイルをオープンし,『名前を付けて保存』で文字コードセットにUTF-8を選んで保存することで行った.全ファイルやるのでそれなりに手間がかかった.まあ一度換えてしまえばそれで終わりであるから大したことないか.

Devasの一括テキスト書き換えのように,一括文字コード変換をやってくれるソフトがあるのかも知れないが....私には不明だった.

UTF-8化に伴うデバグの問題

HTMLファイルをUTF-8化したら困ったことが起こった.ソースファイルのデバグでお世話になっているHTMLクイックチェッカver.0.13が文字化けするようになった.UTF-8未対応のためで,タグそのもののエラー箇所は判るのだが,やはりタグ内文章が読めないとちょっと使いづらい.

そこでまた例によって代替できるソフトがないかググってみた.そしてFirefoxブラウザのアドオンでMarc Gueury氏作Html Validator 0.8.5.8というフリーソフト(寄付歓迎)を知ることとなった.早速ダウンロードし,チェックレベルなど指定し直ぐに使うことができた.

HTMLクイックチェッカのようにディレクトリ内の全ファイルまとめてのチェックはできず,ページ単位となるが,ローカルファイルも可能で,表示されたページの『ソースを見る』でエラー一覧と,それぞれの対応ソース位置を知ることができる.ソースの中のファイルクリックで,当該ページ(ソース)にジャンプし,同時にエラーチェックを行うこともできるし,とても使い勝手がいい.またHTML4も5もそれぞれの仕様に合わせてチェックするようだ.

赤でエラーを,黄で警告を発してくれる.エラーのスレッショルドはW3c Online Validationの基準通りなのであろうか,HTMLクイックチェッカより少しシビアなようだ.例えばimgタグでaltがない場合や,listのネスティング,&文字が&amp;となっていない.....などは警告ではなく赤のエラーとなる.これらはちょっと量が多く大変だったがお告げに従いサクラエディタとDevasとで修正した.

UTF-8化は旧サクラエディタ(ver.1.6.3.0)でも若干問題があった.htmlファイルでは問題ないのだが,cssファイルの場合,すこし不具合があった.UTF-8コードで保存したCSSファイルを再び開くとなぜかShift_JISで開かれてしまうのだ.

CSSファイルは幾らの数でもないのであまり問題ないのだが,無いに越したことはなく,最新のver.2.1.1.4をダウンロードさせてもらった.その結果,無条件にShift_JISで開くことはなくなったが『....UTF-8で開くか?』と,いちいち訊いてくる(中には訊かないCSSファイルもある)使い方が悪いのかな....?

なお最新サクラエディタでは選べるフォント種類が増えるなど,自分にとって一層使いやすくなった.(最初選んだ@付きフォントで文字が横向きになって焦った.横向き文字ってどんな原稿のエディティングに使うのかな....?)

100%のページに重大なモバイルユーザビリティ上の問題あり

3月11日,Googleウエブマスターツールより『貴サイトの1,080ページをテストし,そのうちの100%に重大なモバイルユーザビリティ上の問題を検出しました......』との指摘を受ける.それまでモバイルユーザビリティなどという言葉を聞いたこともなかった.あったとしても頓着無かったのだ.それがいきなり『100%のページに重大な問題あり』と指摘され,慌てて自分のこととして対処することにした.

指摘された問題は

  1. タップ要素同士が近すぎます
  2. フォントサイズが小です
  3. ビューポートが設定されておりません....←最初に対応
  4. Flashが使用されてます

で,1~3項までは全部のページ,4項は十数ページだがyouTubeのあるページは全部,という大変な指摘だ.

とりあえずビューポートを設定

指摘された事項に関する説明や解決方法はGoogleの関連ヘルプページに述べられている.それらを読んでみたがちょっとやそっとでは解決できそうにない.ただ第3項のビューポート設定だけは<head>タグ内に以下のGoogle推奨値
<meta name="viewport" content="width=device-width, initial-scale=1.0">
と書き加えればいいようなので,全ページに書き込むことにした.この書き加えは上述のDevas Ver3.4を使ったお陰で,あっと言う間に完了し,直ぐにWebサーパーにアップロードできた.

なおここでcontent="width=device-width,はデバイス非依存ピクセルサイズに合わせるようにページに指示し,initial-scale=1.0で,そのスケールが指定されることになるようだ.

アップロード後ウェブマスターツールで推移を見ていくと,以下のようになっていった.新たに第5項の問題が加わり,日増しに増加していった.これは元のページ全てがCSSで固定幅となっているためだった.

  1. タップ要素同士が近すぎます....→徐々に減少(上記viewport指定の効果)
  2. フォントサイズが小です....→徐々に減少(〃)
  3. ビューポートが設定されておりません....→徐々に減少(〃)
  4. Flashが使用されてます....変わらず
  5. コンテンツのサイズがビューポートに対応していません....→0から徐々に増加

まあ,スマホでもPCと同じサイズの文字で表示するようになったので,フォントサイズやタップ要素距離は解決したが,コンテンツ幅はPCと同じなので横スクロールが必要になったという次第だ.

コンテンツサイズをビューポートに対応させる

こりゃやはりコンテンツサイズをビューポートに対応させる必要があるな~と思い,泥縄式にGoogle Developersの解説ページなどを読んだり,いろいろなサイトを参照させてもらった.そしていろいろなことが判り,下図のようにデザインを変更しソースを書き換えることにした.

マルチデバイス対応説明図

マルチデバイス対応説明図

箇条書きにすると次のようになる

  1. ビューポート設定で『タップ要素近すぎ』『フォントサイズ小』は大丈夫のようだ
  2. コンテンツ幅をビューポートに合わす,つまりページ幅をスクリーン幅と同じにすること
  3. スクリーン幅は320pxのスマホから...604pxのNexus 7など...PC,と多様
  4. 文字サイズは指定しない(小スクリーンでも同サイズ)
  5. 殆どのページは記事とナビの2段組とし,PCサイズ以下ではナビ部分を落下させる
  6. 記事内の写真は可変幅とし,小スクリーンでは小さくする
  7. 以上のリキッドレイアウトのためCSS3のMedia Queries機能を使った
  8. 必須のCSS3に対し,HTML5は必ずしも要らないが,ついでにHTML4から変更
  9. ナビ部分の落下はfloat:left;の解除で行った(CSS2でも可)
  10. 記事コラム,ヘッダー,フッターは連続的に可変幅とする
  11. その記事コラムなどの幅はwidthの%指定で行った(〃)
  12. 写真や図の幅はwidthの%指定で行った(〃)
  13. youTubeから新しい埋め込みコードを得て,自サイトを書き換え,Flash不要にした
  14. 記事とナビのコラムは,PC~タブレット~スマホへの連続性から左右逆配置にした
  15. CSSはホームページ用,一般ページ(殆ど)用+α,スライド用の3種に簡略化した
  16. スマホで見出しが大きすぎないよう少し簡略化,英表記は縮小した
  17. スマホでヘッダーパンくずリストが大き過ぎないよう少し簡略化
  18. 一方ヘッダーパンくずリストの一部に次ページリンクを追加
  19. どうしても幅が縮められない表(テーブル)が残った.今後検討要
  20. Google adSenseはMedia Queriesで一部スマホで非表示,一部レスポンシブサイズにした
  21. 表示はChromeデベロッパーツールのデバイスエミュレーションでテストした

アップロード結果

上記対策を済ませ,2015/4/17サーバーにアップロードした.サーバーにあればGoogleのモバイルフレンドリーテストにURLを入れて,フレンドリーか否かの判定ができる.表示がスマホの絵なので,iPhone5か6一機種だけの適合度を見ているのであろうか?それにしては結構長い時間がかかる.

モバイルフレンドリーのときはグリーンの文字で,フレンドリーでないときは赤字で,そして併せてその理由が表示される.理由はウエブマスターツールの場合と同じで,タップ要素同士が近すぎます,フォントサイズが小です,ビューポートが設定されておりません,Flashが使用されてます,などのようだ.

幾つかのページを試してみて,おおまかには大丈夫そうなのでひと安心した.このテストがディレクトリ内の全ファイルまとめてできるとか,またローカルファイルでもできるとかだとさらにいいのだが不可能なようだった.まあ後者については前述のChromeデベロッパーツールで大体判るのでいいか.

また久しく音沙汰のなかったウエブマスターツールのモバイルユーザビリティの解析結果も今日2週間ぶりくらいに記されていた.まだ当初の1/10程度のエラーページありとのチャートだが,多くはまだ未解析のためで,エラーページはもっと少ない筈では...と楽観している.

(2015/5/4記)


スポンサーリンク

スポンサーリンク