Chrome+HTML5 Conferenceに参加してきました 4
スマートフォン向けのモバイルサイトを作る際に注意しなければ
いけない点や、こうするとアクセス速度を改善できる、などの
改善施策についてのお話でした。
スマートフォン向けモバイルサイト開発 (14:00-14:45)
例えばフィーチャーフォンと比べた場合に、スマートフォンのブラウザでは
以下のような利点がある。
JavaScriptで動的なWebページを作成可能に CSS3を利用したきれいなデザイン Ajaxを利用したウェブアプリなどが開発可能に ネットワークが無い場所でも使えるオフライン機能
PCと比べた場合には、例えばネットワークが遅いなどの欠点はあるが
レガシーとなるブラウザが無いことは大きな利点。
スマートフォンでは、縦向きのデザイン(Portrait)と
横向きのデザイン(Landscape)も考える必要がある。
指で押しやすく、動かしやすいタッチフレンドリーなサイトが良い。
Viewport
デフォルトでは、ブラウザはページの横幅がとても広いと勝手に想定しているためViewportを利用してページの横幅を少し小さめに指定してやると良い。
例えば、以下のような書き方になる。
<html> <head> <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, target-densityDpi=medium-dpi"/> </head> <body style="min-height:3000px;background:#ccc;"> Hello world </body> </html>
リンクは指で押すので、近くにリンクが複数あると、間違えやすい
押しやすい大きなリンクやボタンを表示する。
参考になるのは、Youtubeのスマートフォンページなど。
通常のテキストリンクの場合では、リンクにパディングなどを
設定することで「ヒットエリアを見た目より大きくする」ことで改善可能。
PortraitとLandscape
スマートフォンでは持ち方などによって、縦長の画面での表示と横長の画面での表示がある。
MediaQueryを使うことで、画面の状態に応じて異なるCSSを適当可能
@media screen and (orientation:portrait) { ...(CSSの記述)... } @media screen and (orientation:landscape) { ...(CSSの記述)... }
Orientation(画面の向き)の変更イベントはiPhoneとAndroidで異なる
・iPhoneはorientationchange 向きはwindow.orientation ・Androidはresize 向きはwindowの高さと幅で求める
また、iPhone/Androidではホーム画面にブックマークを登録時した際に
表示するアイコンを指定可能。以下のように記述する。
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />
複数端末のサポート
スマートフォンはほとんどwebkitベースFirefoxやOperaなどもあり、IE9も今後普及する可能性はある。
(Windows Phoneなど)
CSSの互換性
ブラウザごとに書き、フォールバックも記述する
一部CSS3の機能は互換が無い。
→ box modelはWebkitとFFでは互換だが、IE9やOperaではそのまま使えない
アニメーションサポート
- アニメGIF
古いAndroidでサポートなし
サイズに制限あり(最初の数フレームしか表示されなかったりも)
- CSS Transition
古い端末でサポートなし
結構昔の端末でも利用可能
異なるDPIの画像
スクリーンの実サイズはそれほど変わらないが、
解像度は320x480から640x960まで大きく違いがある
DPIに応じて、高解像度用の画像と、低解像度用の画像を容易する
※高DPIのデバイスに対しては、高解像度の画像を低解像度のものと
同じサイズに縮めて表示するとよりきれいになる
DPI検出
iPhoneはiPhone4が高解像度。 ただし、UserAgentでは検出不能
Androidはデバイスごとにばらばらだが、古い端末はたいてい低解像度
JSでwindow.devicePixelRatioでDPI検出可能 CSS media queryの場合-webkit-device-pixel-rasio
高速化
なぜ高速化すべきか?スマートフォンではネットワークの遅延が大きいため モバイルネットワークは大抵が低スループットで高RTT リクエストが増える度に遅延が増える → TCP handshake, HTTPリクエストのオーバーヘッドがどんどん増える
外部リソースを削減
遅いネットワークではリクエスト数を減らすことで高速化出来ることも
JavaScript, CSSをインラインで記述
画像などをdata scheme uriで記述など。(data:image/png;base64,...")
HTTP Expire
・HTTPでは、コンテンツに期限を設定可能 ・期限内では、コンテンツにキャッシュがあれば、それを利用する ・そのかわり、既存のファイルを更新した場合、URLが同じだとブラウザが 更新しない可能性があるため、毎度別のURLにアップロードする必要がある
外部リソースの削減 vs HTTP Expire
HTTP Expireは、キャッシュがあるときのみ効果を発揮するキャッシュのヒット率はどのくらいか? から考える
ユーザのうち、再訪問した割合はどのくらい? → 1%くらいしか再訪問しない、などなら外部リソースを削減したほうがいい。 → 再訪問が多いなら、HTTP Expire 外部リソースはどのくらいの頻度で更新される? → 内容が頻繁に更新されるならば、Expireは無意味
HTML, CSS, JavaScript圧縮
小さければ小さいほど転送に掛かるコストは小さい → gzipしていればそれほど大きくは改善しないが、それほど大変ではないので やらないよりはやったほうが良い。 minify、minifierなどで検索してお気に入りのツールを探すと良い。 → だいたい冗長な記述の単純化や、いらない空白の削除を行ってくれる。 JavaScriptに関してはGoogle Closure Compilerがおすすめ。 → 変数名の圧縮などまでやってくれる
画像の圧縮
JPGは画質を落としても大丈夫か試しながらサイズを減らすGIF,PNGなどはソフトで調整しつつ。画素数を減らしたり。
CSSスプライト
CSSを利用して画像を切り抜いて表示することで、
多数の画像へのリクエストを1つのリクエストにまとめる
( OpenGLなどで言う、テクスチャアトラス )
質疑応答
アプリケーションキャッシュでもいいのか?(HTTP Expire)→ Android が Froyoあたりから、iPhoneが 3あたりからしかサポートされていない
データスキームURIで画像をエンコードしたものを埋め込む方法だと、
エンコードに時間がかかって逆に遅くなったことがあるがどうなのか]
→ デコードの処理速度については試したことが無い。 基本的にはあんまり遅くなければいいんじゃないか。
HTTP Expireを強制的に追い出すことは出来ないのか
→ 多分出来ないと思う。
Youtubeサイトなど、全端末検証は大変だったか
→ たまにデバイスごとの違いはあったが、webkitベースになったので フィーチャーフォンよりは全然マシ。 videoタグの挙動が一番違った。
Google用のjQueryMobileなどのライブラリはあるのか
→ Google クロージャライブラリなどはあったが
Youtubeアプリもあると思うが、Web側と同じなのか?
→ ネイティブで開発している。 iPhone側はAppleが、Android側はGoogleで開発している。
結構当たり前のことが多いといえば多いですが、
確かに快適なサイトを構築していく上では注意することが必要なことも多いので
だいたいの内容はまとめて記載しておきました。