フロントエンドの「想定外」に対応する考え方とTipsいくつか

とても個人的な話ですが、ここ最近で自分自身のプライバシー意識の高まりを感じて、ブラウザの設定を見直す機会がありました。見直したのはCookieの設定で、許可したドメインにしかCookieを記憶しないようにしました。設定変更によるある程度の不便は覚悟していました。とはいえ、ま〜せいぜい、初回アクセスの時のモーダルが何度も出るようになるとか、ログインできなくなるとか、そのくらいかなと思っていました。

しかし実際は、悪い意味で期待を裏切られることになりました。

Cookieが無効なだけで、“全く”動かなくなってしまうウェブサイトやウェブアプリが、本当にたくさんあることに気づいたのです。

全く動かなくなってしまう原因は単純(後述)だったのですが、ちょっとした対処で簡単に直せることなのに、サイト全体が一切使い物にならなくなってて、もったいない!! と思いました。

フロントエンドの想定外

ウェブサイトはもともと想定外が起きやすいメディアです。ひとつのウェブページを表示するのに数十ののリソースをダウンロードしなければいけないし、そのウェブページを構成するデータは、遠いところからいくつものネットワーク機器を経由してやってきています。そのうちどこか一つでつまずきがあっても、まったく不思議ではないですね。

データを正常に読み込めたとしても、ユーザー環境や設定がウェブページの表示や動作に影響を与える可能性は大いにあります。次に挙げる項目はフロントエンド領域の「想定外」ですが、普段どれくらい意識して実装しているでしょうか。

  • 古いブラウザを使っている
  • ブラウザのデフォルトフォントサイズを変更している
  • ブラウザのデフォルトフォントを変更している
  • 広告ブロッカーを使っている
  • 閲覧中のページに改変を加える拡張機能を使っている
  • JavaScriptを無効にしている
  • Cookieを無効にしている
  • プライベートブラウジングを使っている
  • スクリーンリーダーを使っている

これらすべてを想定しながらウェブサイトを作るのは困難でしょう。これらをいっさい考慮しない、という選択も案件によってはあると思います。しかし少し調べてみると、前述の想定外に当たるユーザーは予想以上に多くいるようです。

「想定外」は案外、いろんな人の元で起きている

JavaScriptが使えない…3%〜4%

2016年のWikipediaの調査によると、全世界的にみたときのJavaScriptが使えない割合は7%くらいです。

日本からはアクセスが少ないようで調査結果に載っていませんが、アメリカと同じくらいと考えると、3〜4%くらいでしょうか。EU諸国はプライバシー意識が高いのか、7〜10%のアクセスはJSが使えないようです。

JSが使えない理由は、意図的に無効にしているユーザー以外にも、ブラウザ拡張機能とコンフリクトを起こしているケースや、ウィルス対策ソフトが勝手にブロックしてしまうケースなど、意図しないものも含まれています。

File:Browsers, Geography, and JavaScript Support on Wikipedia Portal.pdf

フォントサイズをデフォルトから変更している…3.08%

Internet Archiveの調査によると、ブラウザのデフォルトフォントサイズを変更している人は3.08パーセント。予想よりずいぶん多いと思いませんか。

Internet Explorerユーザー…10%以上

みんなが嫌いなブラウザ、IE。ブラウザ要件から外される案件もずいぶん増えてきました。Windowsにバンドルされているより新しいEdgeブラウザがあるにも関わらず、日本国内のIEのシェアはいまだに10%を超えています。本当に無視していいんでしょうか?

「想定外」に対する基本的な考え方

「要件にないので考慮しません」と言い切ってしまうのは簡単なことです。コストとの兼ね合いもあるでしょうし、例外を検討するのは面倒なこともあるでしょう。

忘れてはいけないのは、これらの想定外はユーザーが意図せず起こってしまうケースも含まれるということです。そして、デフォルトフォントサイズの変更やCookieの設定は、使いやすさやプライバシーを高めるためのユーザーの権利と言い換えることもできます。「権利を行使した結果は自己責任」などと一蹴せず、できるだけ寛容になれるように努力するのは制作者のつとめだと考えます。

あらゆるエッジケースに対応する必要はありません。費用対効果をみつつ、制作者の矜持とも照らし合わせながら、やるやらないを判断していけばいいと思います。そのために、「想定外」のパターンを知り、対応方法を学び、自分の取りうる手段として持っておくことが大事ではないでしょうか。

想像力を働かせることも肝要です。「IEユーザーはこのサービスの対象層ではない」と決めつけることもできますが、「会社で仕方なくIEを使わされてるけど家ではふつうにChrome。どっちでもウェブサイトは利用したい」というひとは山ほどいるはずです。都合よく解釈していないかどうか、よく考えてみましょう。

少ない工数で「想定外」からユーザーを救う方法

もし、ほんの少しの工数で「想定外」からユーザーを救う方法があるとしたら、それをやらないのはもったいないことです。

いくつか手持ちのTipsを紹介したいと思います。特に誰かに相談することなく、エンジニア判断で導入できるものも多いと思います。

フォントサイズはpx単位ではなくrem単位にする

CSSで文字サイズを指定するとき、px単位を使ってしまうと、ユーザーが設定したフォントサイズは無視され、CSSで指定した文字サイズが適用されてしまいます。かわりにrem単位などの相対単位を使うようにしましょう。

h1 {
  font-size: 1.5rem;
}

pxをremに変換するのは、ひとつSass関数を作るだけなので、手間はありません。 html { font-size: 10px } とすることで、rem単位の計算を楽にする手法もしばしば見られます。

@function rem($px) {
  @return ($px / 16px) * 1rem;
}

h1 {
  font-size: rem(24px); // -> 1.5rem
}

ついでに、line-heightをpx単位で指定するのもやめましょう。単位をつけず倍数を指定しましょう。

/* NG */
line-height: 20px;
/* OK */
line-height: 1.6;

Web Storageを使うときは必ず trycatch で囲む

わたしのようにCookieを許可制にしている環境や、プライベートモードの環境で、localStorageやsessionStorage(まとめてWeb Storage)が例外を投げるブラウザがあります。Chromeもその一つです。localStorageやsessionStorage読み書きするときは、trycatch で囲んで例外が起きても処理が止まらないようにしましょう。

try {
  localStorage.setItem(key, value);
} catch (e) {
  // storageが使えない場合のフォールバック処理
}

冒頭で触れた、Cookieが無効なだけで「全く」動かなくなってしまうウェブサイトのほとんどは、Web Storageを読み書きするときに起きる例外が原因でした。シングルページアプリケーションなのに画面が真っ白のままだったり、Cookieとは全く関係のなさそうなJavaScriptの処理がとまっていたりと、非常にもったいないです。

Autoprefixerの対象ブラウザ設定を広げる

AutoprefixerはCSSに自動的にベンダープレフィクスを追加してくれる仕組みです。対象のブラウザを設定することができます。どうせなら広めにとってあげましょう。ファイルサイズを切り詰めたい気持ちもわかりますが、大してファイルサイズは増えません。

# そんなケチケチせずさ〜
> 1% in JP

# こんくらいやっちゃおうよ!
> 0.1% in JP

この1行の変更で救われる環境があるなら儲けもんですよね。

window.onloadよりDOMContentLoadedを使う

ネットワークの不調などで、ページ内のひとつの画像がなかなか表示されない……というようなケースもあるでしょう。こんなときにJSのトリガーにwindowのonloadイベントを使っていると、いつまでもJSが実行されません。DOMContentLoadedを使いましょう。

// OK
document.addEventListener('DOMContentLoaded', function () { ... })

// OK
$(function () { ... });

背景画像を設定するときは、背景色も同時に指定する

背景画像の手前に文字を置く場合だけでいいですが、背景画像と一緒に背景色も設定しましょう。文字色がしっかり見える背景色がいいでしょう。

background-image: url('bg.jpg');
background-color: #000;
color: #fff;

もし画像の読み込みに失敗した時でも、背景色が設定されていればちゃんと読めるようになります。

JavaScriptが使えない人のためのスタイルを指定する

JSで作られている機能を、JSが動かない環境にどのようにフォールバックするかどうかは機能によって大きく違いそうですが、CSSでフォールバックする下地は作っておいた方がいいでしょう。

<html class="no-js">
<head>
<script>document.documentElement.classList.remove('no-js')</script>

このようにしておくと、JSが有効の環境では、html要素のno-jsクラスが即座に外されます。あとはCSSでスタイルを調整すればOKです。

JSの機能をCSSで無理やり再現するのはあまり筋がよくないので、あくまで「情報が著しく欠損しないレベルにまでフォールバックする」のがいいと思います。例えばアコーディオンUIを全部展開しておくとか、カルーセルを全部出しておくとか。

画像の遅延読み込み(Lazy Loading)は noscript タグでフォールバックする

画像の遅延読み込みは、ふつうの実装をすると、JSが無効な環境で画像がいっさい表示されなくなってしまいます。JSが無効でも表示されるようにするには noscript タグを使います。

<img class="lazy" data-src="cool-image.jpg" alt="">
<noscript><img src="cool-image.jpg" alt=""></noscript>

参考サイト