タグ: モバイルサイト

本機能の日本での提供予定は未定ですが、日本のウェブマスターのみなさまから高い関心が寄せられましたので、その概要をご紹介したいと思います。


スマートフォンで検索をしていると、スムーズな利用を妨げるような場面に遭遇することがあります。たとえば、ウェブページからアプリへの切り替え、あるいは逆にアプリからウェブページへの切り替えが必要になることがありますが、その際にリダイレクトやポップアップ ダイアログが出現して、余計なスワイプやタップが要求されることが多々あります。もし、ウェブサイト上のコンテンツであろうと、アプリ内のコンテンツであろうと、あなたが提供するコンテンツについて、 ウェブサイト上で閲覧するか、アプリ上で閲覧するかユーザーが検索結果上で直接選べるようになったら良いと思いませんか？

Google は先日、Google 検索の新機能「App Indexing」を発表しました。この機能は、ウェブマスターからの技術的なインプットを活用して、ウェブサイトとモバイル アプリケーションをシームレスに横断するユーザー エクスペリエンスを実現します。

今回、これまでウェブサイトをクロールしてインデックスに登録してきたのと同じように、Android アプリ内のコンテンツも Googlebot がインデックスに登録することが可能となりました。ウェブマスターは、どのアプリ コンテンツを Google のインデックスに登録させたいかを、現在ウェブページで行っているように、既存のサイトマップ ファイルやウェブマスター ツールを通じて指定できます。ウェブページ コンテンツとアプリ コンテンツ両方がインデックスに登録されると、検索クエリと関連性があると思われ、ユーザーが対象アプリをインストールしている場合、アプリ コンテンツに直接つながるディープ リンクが Google 検索の検索結果上に表示されるようになります。ユーザーがディープ リンクをタップすると、アプリが起動し、対象のコンテンツに直接移動します。たとえば、カリフォルニア州マウンテンビューの不動産物件（home listings）を検索した場合、次のようになります。



Google では現在、デベロッパー グループと App Indexing のテストを行っています。今後数週間のうちに、米国で Android 搭載端末を使用するログイン ユーザーを対象として、アプリ コンテンツのディープ リンクが Google 検索の検索結果に表示される予定です。提供している Android 向けアプリをインデックスに登録するための手順は簡単です。

1. まずは興味があることを Google にお知らせください（英語）。
   Google では、この新機能を数多くのウェブサイトとアプリに普及させようと取り組んでいます。ぜひご協力ください。
2. 提供しているアプリで、ディープ リンクを有効にしてください（英語）。
3. サイトマップ ファイルか、サイト ページのリンク要素を利用して、代替アプリ URI に関する情報をご提供ください。

実装や登録の詳細については、Google デベロッパー サイト（英語） をご覧ください。

Posted by Lawrence Chang, Product Manager
Original version: Indexing apps just like websites

多くのユーザーがその手軽さや利便性から、スマートフォンからの検索を行っていますが（英語）、携帯端末向けのページではその読み込みに 平均して 7 秒以上かかっていることがわかっています（英語）。この読み込み時間が 1 秒以下になることはユーザーにとってもウェブマスターにとっても理想でしょう。そこで今回、ウェブマスターの方々へ、携帯端末向けページのレンダリングを高速化するための ガイドライン（英語、日本語も準備中です）を公開しました。また、このガイドラインにもとづき、PageSpeed インサイト ツール も更新しました。

”above the fold” コンテンツを優先的に扱う
たとえば こちらのレポート（英語）によると、ページの読み込みに 1 秒以上かかった場合、ユーザーの集中が途切れてしまう傾向にあるようです。サイトの訪問者により良いブラウジング体験を提供してサイトを利用してもらうため、今回策定したガイドラインではいわゆる ”above the fold” と呼ばれる、ユーザーが最初に目にする、スクロールしなくても表示されるエリアのコンテンツを少しでも早く提供する（その他のコンテンツはバックグラウンドで読み込みを進める）ことを重視しました。また “above-the-fold” エリアをレンダリングするのに必要な HTML や CSS, JavaScript は非常に重要なレンダリング パス（critical rendering path（英語））として知られています。

携帯端末上でのユーザーに最初に見えるコンテンツの読み込み時間を 1 秒未満にするためのベストプラクティスをここでご紹介します。

Posted by Bryan McQuade, Software Engineer, and Pierre Far, Webmaster Trends Analyst
Original version: Making smartphone sites load fast

スマートフォン ユーザーは、インターネット ユーザーの中でも成長が非常に早く、重要なユーザー層となってきています。そして Google ではスマートフォンから Google を利用するユーザーにデスクトップ環境と変わらない、リッチなウェブ体験を提供したいと考えています。こうした携帯端末向けのリッチなウェブ サイト作成のため、「携帯端末に最適化されたウェブサイトの構築方法（推奨事項）」や「スマートフォン サイトによく見られるミス」といった情報をご提供してきました。

Original version: Changes in rankings of smartphone search results

これらのおすすめコンテンツの追加や設定を簡単に行うための方法も用意されています。モバイル サイトに JavaScript を 1 行追加するだけで、ウェブ エディタを使わずに、Google+ ページ ダッシュボードの [サイト向け] セクションで変更を加えることができます。


この最新の機能を試してみるには、お気に入りの iOS 搭載端末や Android 搭載端末で Forbes サイト内のいずれかの 記事ページ にアクセスしてみてください。この機能については、デベロッパー ドキュメント（https://developers.google.com/+/features/recommendations）でも詳しくご紹介しています。

Google では、Google+ のコンテンツおすすめ機能と Google+ ログイン機能についてより多くの方に使って頂くための改善を計画しており、先日開催した Google I/O では Google+ ログイン機能を利用している 50 社以上の企業の中からいくつかの事例について詳しくお話を伺うことができました。

「Google+ ログインは、当社の Android アプリで最も利用されているソーシャル ログイン機能です。ソーシャル ログイン経由のユーザーの 41% が Google+ ログイン経由です。」
- Tom Grinstead、Guardian News プロダクト マネージャー

「Google+ ログインの統合による最初の成果には大変満足しています。当社の分析では、ウェブ、Android、さらには iOS でも、Google からの膨大なログインがその他の一般的なソーシャル ネットワークを圧倒していることは明らかです。この成功により、他のログイン ソースを廃止して、この新しく成長著しいチャネルをさらに活用していくことを検討しています。」
- Haisoo Shin、Fancy エンジニアリング ディレクター

Posted by Mario Anima, Product Manager, Google+
Original version: Google+: Content Recommendations for your Mobile Website @ The Google+ Developers Blog

データを重要視している Google では、アクセス解析を行い自分たちのウェブサイトを分析することに多くの時間を費やしています。みなさんも同じように分析をされてみると、最近の傾向としてモバイル端末からのトラフィックが増加していることに気が付くでしょう。この 1 年、多くの主要なサイトではスマートフォンやタブレットからのページ ビューの割合が大幅に増加しました。つまり、多くの人が最新の HTML や CSS、JavaScript に対応したブラウザでサイトにアクセスしているということです。しかしこれは同時に、例えば幅が 320px というような狭い画面に表示されているということも意味します。

Google では、アクセシビリティ (英語) の観点から、すべてのユーザーが、心地よくウェブページを閲覧できることを目指しています。モバイル用のウェブサイトを作るのか、あるいはデスクトップとモバイル環境の両方でうまく表示されるように、既存サイトや新規サイトを適合させるのかという点について Google は深く検討してきました。複数のサイトを用意すれば、ハードウェアごとに最適化したサイトを提供できます。しかし、1 種類のサイトで両環境に対応できるなら、正規化 された URL を保持できる上、複雑なリダイレクトを避け、ウェブ アドレスの共有をよりシンプルにできます。このような保守性の観点から、Google では、1 つのページをモバイル端末とデスクトップの両方に対応させるよう、次のガイドラインを満たす方法の検討を始めました。

1. ページは、どの画面解像度でも読みやすく表示される
2. どの端末でも表示できるようにコンテンツをひとかたまりごとにマークアップする
3. ウィンドウサイズにかかわらず、水平方向のスクロール バーは表示しないようにする

画像サイズを変更すると、コンテンツは縦に並び、ナビゲーションは適切に変化し、画像はリサイズされる - Chromebooks （英語）

それでは、Google の実施している施策と、そこから得られた発見をご紹介します。

実装

まずなによりも、、シンプルでセマンティックなマークアップを用いることです。これによって、レイアウトの変更が必要な場合でも、コンテンツがうまくリフローするような柔軟性をページに与えることができます。サイトを リキッド レイアウト (英語) なスタイルにしたなら、既にモバイル対応の第一歩を踏み出していると言えるでしょう。コンテナ要素には width を指定するのではなく、代わりに max-width を指定します。同じく height の代わりに min-height を使います。こうすることで、大きめのフォントや複数行に渡るテキストの場合でも、コンテナからはみ出すことがなくなります。固定幅の画像によってリキッド カラムが強制的に広げられた状態になるのを防ぐため、下記の CSS ルールを適用します。

img {
  max-width: 100%;
}

リキッド レイアウトから始めるのはよい方法ですが、精巧さに欠けるところがあります。ありがたいことに メディアクエリ (英語) には現在、ほとんどのモバイル端末や IE9+ などの最新ブラウザが対応しています (英語)。メディアクエリによって、「モバイル環境ではグレードをうまく落としたサイト」になるか、「合理的な UI をうまく利用してグレードアップしたサイト」になるか、大きな違いが生じます。しかしまずは、スマートフォンがウェブ サーバーからどのように認識されているのかを考慮する必要があります。

viewport メタ タグ

1 ピクセルが 1 ピクセルでなくなるのはどんなときでしょうか。それはスマートフォン上で表示されるときです。初期設定では、スマートフォンのブラウザは、高解像度のデスクトップ ブラウザと同じような挙動を見せ、まるでデスクトップのモニターで表示しているかのようにページをレイアウトします。ズームインしなければ判読できない小さな文字の「オーバービュー モード」で表示されるのはそのためです。デフォルトのビューポート幅 (英語) は、画面の実際の物理的なピクセル (英語) の数にかかわらず、初期設定の Android ブラウザでは 800px、iOS では 980px です。 より読みやい縮尺でブラウザにページを表示させるには、 viewport メタ タグを使用する必要があります。

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

モバイル端末の画面解像度は多岐にわたりますが、最新のスマートフォン用ブラウザの多くは現在、320px ほどの標準的な device-width であるとされています。モバイル端末が実際には物理的に 640px の場合、320px 幅の画像は、画面の横幅に合ったサイズに変更され、その過程で倍の数のピクセルを使用します。小さい画面ではテキストがより鮮明に見えるのはこのためでもあります。標準的なデスクトップのモニターに比べるとピクセルの密度が倍になっているのです。
viewport を指定するメタ タグで width = device-width を設定する利点は、ユーザーがスマートフォンやタブレットの向きを変えたときに表示を更新してくれる点です。これをメディアクエリと組み合わせて用いることで、ユーザーが端末を回転させた時のレイアウトを微調整できます。

@media screen and (min-width:480px) and (max-width:800px) {
  /* ランドスケープモードのスマートフォン、ポートレートモードのタブレットまたはウィンドウ幅の狭いデスクトップ向けのスタイル
  */
}
 
@media screen and (max-width:479px) {
  /* ポートレートモードのスマートフォン向けのスタイル */
}

実際には、サイトの流れや各種端末上での表示に応じて、異なるブレークポイントを使用する必要があるかもしれません。また、メディアクエリの orientation を使って、ピクセルで幅などのサイズを指定することなしに特定の向きに対応させることも可能ですが、ブラウザが対応している場合 (英語) に限ります。

@media all and (orientation: landscape) {
  /*ランドスケープモード向けのスタイル */
}
 
@media all and (orientation: portrait) {
  /*ポートレートモード向けのスタイル */
}

コンテンツは縦に並び、画像は縮小して表示する - Google 選ぼう 2012

メディアクエリの例

2012 年春、Google について のページをリニューアルしました。リキッド レイアウトの設定以外にも、メディアクエリをいくつか追加して、タブレットやスマートフォンなどの小さな画面での閲覧性を向上させました。
さまざまなデバイスの解像度に対応させる代わりに、比較的広いブレークポイントを設定するという方法を取りました。1024px を超える画面解像度では、Google が標準で使っている 12 カラム グリッドに従って、元々デザインした通りにページを表示します。801px から 1024px の画面解像度では、リキッド レイアウトによって、若干圧縮されたバージョンが表示されることになります。
画面解像度が 800px まで下がる場合に限り、主要なコンテンツとはみなされないコンテンツはページの下部へと送られます。

@media screen and (max-width: 800px) {
  /* この場合のみ適用されるスタイル */
}


最後に記述するメディアクエリにはスマートフォンを想定した幅を指定します。
 
@media screen and (max-width: 479px) {
  /* この場合のみ適用されるスタイル */
}

ここまで来たら、もう大きな画像はロードしませんし、コンテンツ ブロックも縦に並べるだけです。また、コンテンツの項目の間に少し余白を足して、それらが別々のセクションであることがわかりやすくなるようにします。 こういったいくつかのシンプルな方策によって、さまざまな端末上でサイトを利用できるようにしました。

コンテンツは縦に並び、大きな画像は表示しない - Google について

まとめ

モバイル端末や狭いビューポートでもサイトをアクセスシブルにする、シンプルで簡単な「たったひとつの冴えたやりかた」のようなものはないということを覚えておきましょう。リキッド レイアウトは、第一歩としては非常に優れていますが、デザインにおける何らかの妥協が必要となる場合があります。メディアクエリは、さまざまな端末上での表示をより洗練されたものにするのに役立ちはしますが、トラフィックの 25% (英語) は、現在この技術をサポートしていないデスクトップ ブラウザからのアクセスであることや、ある程度 パフォーマンスへの影響 (英語) が生じることにも注意しなければなりません。 また、サイト内で趣向を凝らしたウィジェットを使用している場合、細かいコントロールが難しいタッチ端末では、マウスほどの素晴らしい挙動が望めない場合があります。
ポイントは、より早い段階でより頻繁にテストを行うことです。実際にスマートフォンやタブレットから自分のサイトを使ってみることも大変重要です。本物の端末でテストできない場合は、Android SDK (英語) や iOS Simulator (英語) を使用してください。友人や会社の同僚に頼んで、彼らの端末からサイトを表示してもらい、彼らがどのように操作するのかを観察するのもよいでしょう。
モバイル ブラウザにサイトを対応させることは、新たなトラフィックを得ることにつながります。そして、「それらにどのように対応していくか」という課題は、多くのウェブマスターにとって、取り組みがいのある新たな課題と言えるでしょう。
下記のサイトで Google におけるレスポンシブ ウェブ デザインの例をご覧いただけます。

• http://www.google.co.jp/intl/ja/about/
• http://www.google.co.jp/intl/ja/goodtoknow/
• http://www.google.com/culturalinstitute/
• http://www.google.com/intl/ja/events/sciencefair/index.html
• http://www.google.com/intl/en/chrome/devices/ (英語)
• http://picasa.google.com/
• http://www.google.co.jp/landing/senkyo2012/

ご質問やご意見がありましたら ウェブマスター ヘルプフォーラム までお知らせください。




Written by Rupert Breheny, Edward Jung, & Matt Zürrer, Google Webmaster Team
Original version: Responsive design – harnessing the power of media queries

The NY Times は閲覧端末がモバイルか、より大きなサイズの Android デバイスのどちらであるかを認識し、タブレット端末に最適化したページの表示を行っています。