この記事は Malte Ubl、Ben Galbraith による Chromium Blog の記事 "The State of the Web at Google I/O 2018" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ウェブは世界にとって貴重な存在で、多くのメリットを備えています。ウェブは比類のない配信プラットフォームで、世界中の人々がさまざまなコンテンツにアクセスでき、企業はあらゆる場所の顧客にアプローチできます。ウェブの成功を支えているのはそのコミュニティとオープンな一連の規格です。こうしたコミュニティと規格のおかげで、ウェブのダイナミックな性質が維持され、すべての人々がウェブを利用できます。

Google は、PageRank から Chromium に至るまで、ウェブの継続的な成功に深く関与してきました。先月、毎年開催されるデベロッパー カンファレンスである Google I/O で、ウェブの現状について発表し、ウェブの継続的な発展を推進して、すべての人々に対して適切に機能させようとする Google の最近の取り組みの一部を紹介しました。主要なテーマを次にまとめていますが、YouTube ですべての発表を視聴することをおすすめします。

Service Worker
Service Worker API の導入は、ウェブに最近加えられた最も重要な改善の 1 つです。Service Worker はバックグラウンドで動作して、ネットワーク リクエストを横取りし、リクエストを処理して、ウェブアプリがオフラインで動作できるようにします。そのため、デベロッパーはページの限られたライフサイクルから解放されます。Service Worker を使用すると、サイトでプッシュ通知を受け取ったり、バックグラウンドでデータを同期したりできます。Apple は今年の 3 月、iOS および MacOS に搭載された Safari 11.1 に Service Worker のサポートを追加し、Microsoft Edge には先週から Service Worker が付属するようになりました。つまり、現在、すべての最新ブラウザでこの規格がサポートされています。Service Worker の使用はアーキテクチャに対する大きな変更になる可能性があるため、手軽に使用できるように、Google は Workbox を作成し、汎用的かつ強力な多くの Service Worker パターンを使いやすい API にまとめています。このライブラリのバージョン 3 がリリースされているので、モジュールにビルドして、必要な機能のみを使用することができます。

プログレッシブ ウェブアプリ（PWA）
Service Worker は PWA の多くの機能を根底から支えています。世界中のさまざまな業種の企業が、PWA をビルドして大きな成功を収めています。PWA サイトを昨年から公開している Starbucks では、毎日のアクティブ ユーザーの数が 2 倍に増えました。実際、Google が計測したアドバタイジング サイトでは、サイトが PWA に移行した後、モバイル コンバージョン率が平均して 20% 増加しました。

多くの初期 PWA はモバイルに重点を置いていましたが、そのメリットは PC にも広がっています。Chrome では、PC に PWA を「インストール」する機能が間もなく提供されます。サイトには独自のアイコンが付与され、スタンドアロンのウィンドウで表示されます。また、ページ内検索、共有可能な URL、Google Cast のサポートなど、ユーザーがブラウザに期待する強力な機能が維持されます。I/O では、Spotify がデスクトップ PWA としてリッチメディア エクスペリエンスをどのようにデプロイしているかを紹介しました。デスクトップ PWA の「インストール」サポートは、6 月上旬に ChromeOS の Chrome 67 に追加され、今年中に Windows および macOS にも導入される予定です。

WebAssembly
WebAssembly を使用すると、C や C++ などの言語で記述された、高パフォーマンスの低レベルコードをウェブサイトで実行し、ウェブ プラットフォーム上にまったく新しいクラスのコンテンツを展開することができます。3 月に、Autodesk の AutoCAD チームはウェブ自体よりも古い 35 年の歴史を持つコードベースをコンパイルし、WebAssembly を使ってブラウザ内で直接実行できるようにしました。AutoCAD の機能がリンクされるため、使用している端末やオペレーティング システムに関係なく、ブラウザ内で CAD 図面を直接編集できるようになりました。AutoCAD のエンジニアリング チームは、単一の C++ コードベースを使用して、デスクトップ チームが変更を加えたときに、ウェブアプリにも簡単に変更を組み込めるようにしました。

コードを移植したり、独自のコードを記述したりする方法については、C ライブラリと DOM の連携を解説している WebAssembly コードラボをご覧ください。C で記述された複雑なライブラリを使用しているか、新しいコーデックをウェブ プラットフォームに組み込む必要があるか、または Unity や Unreal Engine などのエンジンを使用しているかどうかに関係なく、どの場合でも WebAssembly は有用です。

Lighthouse
Lighthouse はウェブサイトの品質を分析するためのツールで、サイトのパフォーマンスを測定し、ユーザー エクスペリエンスを改善するためのガイダンスを提供します。Lighthouse は、Chrome の DevTools 内から直接アクセスできるほか、コマンドラインから実行したり、他の開発ツールと統合したりできます。2018 年だけで、50 万人のデベロッパーがサイトに対して Lighthouse を定期的に実行しています。Google はウェブの変化が速いことを認識しています。Lighthouse を使用すると、パフォーマンスに関する最新のベスト プラクティスを常に把握できます。I/O で発表された Lighthouse 3.0 はすでに一般公開されました。

Lighthouse により、制御された環境でサイトの読み込みパフォーマンスが明確に把握できるようになります。ただし、現実世界の実際のユーザーに対するサイトのパフォーマンスを知る必要がある場合は、Chrome ユーザー エクスペリエンス レポートをご覧ください。このレポートでは、最もアクセスが多い 400 万のウェブサイトについてオリジンレベルのパフォーマンス指標が提供されます。これらのツールやその他のツールでサイトのパフォーマンスを包括的に確認する方法の詳細については、スピードツールのインフォグラフィックをご覧ください。

AMP
AMP は、さまざまな優れたユーザー エクスペリエンスを備えた信頼性の高い高速のウェブサイトをビルドするための Web Component ライブラリおよびエコシステムです。現在、4600 万個のドメインに 60 億以上の AMP ページがあり、Google 検索からのページ読み込み時間の中央値は 1 秒未満です。企業は AMP を活用して成功を収めています。たとえば、世界規模のオンライン小売りマーケットプレイスである AliExpress は、AMP を活用したプログレッシブ ウェブアプリとして新しいモバイルサイトを最近公開しました。この新しいサイトでは、非検索トラフィックのコンバージョン率が 31% も増加しました。

モバイルでコンテンツを消費する方法は変化し続けており、全画面で短いストーリーを配信する方式の人気がますます高まっています。AMP プロジェクトでは、サイトオーナーのニーズを満たすため、モバイルファーストのストーリー配信用にビルドされた豊富なウェブ コンポーネントである AMP ストーリーの開発を最近発表しました。このフォーマットの開発は継続中であり、デベロッパーの皆さんには、独自のストーリーをビルドしてみることをおすすめします。AMP チームは、デベロッパーの皆さんからのフィードバックをお待ちしています。

Web Packaging
Web Packaging は一連の新しいテクノロジーであり、Google では、ウェブ コンテンツがウェブに配布されて、ユーザーに共有される方法が Web Packaging によって再定義されるだろうと考えています。Web Packaging を使用すると、サイトオーナーは、HTTPS の整合性保証を維持しながら、他のパーティから配布されるコンテンツをバンドルすることができます。Web Packaging によって可能になる新しいユースケースを探っているときに、AMP には興味深い使用方法があることに気づきました。AMP チームおよびウェブ コミュニティとの連携を通じて、AMP ドキュメントが AMP キャッシュから提供された際にサイトオーナーの元の URL を保持できるソリューションを設計することができました。

私たちの取り組みを示すものとして、AMP プロジェクトの協力企業である Food Network と Pinterest は、以下のような Web Packaging のデモを作成しています。さらに詳しく知りたい方のために、AMP チームは、Web Packaging がユーザーとサイトオーナーにどのようなメリットをもたらすかについて、こちらの記事で詳しく説明しています。AMP アプリケーションに加えて、Web Packaging テクノロジーが可能にする未来に期待するとともに、デベロッパーからの支援を通じて構想を洗練させていくことを楽しみにしています。

Google 検索から読み込まれた AMP ページでウェブ パッケージングを使用しているデモ

Polymer
Polymer とは、再利用可能なカスタム Web Component を作成して、他のデベロッパーと共有したり、そのコンポーネントを組み合わせて高性能なメンテナンス性の高いアプリをビルドしたりできるようにする JavaScript ライブラリです。I/O では、このライブラリのバージョン 3.0 を発表しました。これにより、Polymer エコシステムが大幅にアップグレードされています。パッケージ管理システムとして NPM を、そして構成単位として ES6 モジュールを使用するためのサポートが全面的に提供されるため、Polymer ベースの Web Component を他のお気に入りのウェブ開発ツールやフレームワークと簡単に併用できるようになりました。

また、Web Component の新しい基本クラスである LitElement が導入されました。このクラスでは、Lit-HTML の表現力と Web Component が組み合わされ、最新の表現力の高いテンプレート構文を使用して軽量のリアクティブ コンポーネントを作成することがより簡単になっています。

Web Component 駆動型の PWA をビルドするための包括的な開始点となる PWA Starter Kit もリリースしました。これらの PWA は、高速で信頼性と応答性が高く、テーマ設定が可能であり、Lighthouse PWA およびパフォーマンス基準において最高点を獲得しています。

Angular
今年の I/O で、Angular チームはコミュニティの成長に関する概要を発表し、コア フレームワーク、CLI、およびバージョン 6 の Angular マテリアル ライブラリに追加されたすばらしい新機能をいくつか紹介しました。Angular は何百万人ものデベロッパーによって使用されており、大きな推進力を得て、すばらしいエコシステムが構築されています。「ng update」や「ng add」など、バージョン 6 でリリースされた新しいコマンドを使用すると、アプリケーションを最新の状態に維持できるほか、Angular チームによって引き続き安定性と革新のバランスが保たれるため、デベロッパーは開発を加速させることができます。

また、Angular チーム は、Project Ivy で Angular に加えられるいくつかの改善点を少しだけ紹介しました。これらの改善により、Angular では既存のアプリケーションと連携しながら、デバッグが簡単になり、コンパイルおよび実行がさらに高速化されます。チームは、小さな Hello World アプリケーションの形式でこれらの改善のユーティリティを紹介し、使用されない Angular 機能がアプリケーションの JavaScript バンドルから自動的に削除されることを示しました。

Google および Chrome のミッションは、コミュニティと協力して、統合された高速かつ信頼性の高い魅力的なエクスペリエンスを構築することです。オープン ウェブ プラットフォームになった新しい強力な機能と、ユーザー向けに高品質のサイトをすばやく作成できるようにする包括的な一連のツールに大きな期待を寄せています。ウェブの最新の進化に関する情報を確認するには、デベロッパー ポータルにアクセスするか、Google Developers YouTube チャンネルで今年の I/O の動画をご覧ください。今年の後半に開催される Chrome Dev Summit でデベロッパーの皆さんとお会いするのを楽しみにしています。



Reviewed by Eiji Kitamura - Developer Relations Team

2015 年 4 月 9 日に開催された Google Developers Summit より「Service Worker で作る最新モバイル ウェブ エクスペリエンス」をダイジェストでブログ記事としてお届けします。

ウェブ vs ネイティブ

同じ機能を提供するアプリケーションでも、スマートフォン上のブラウザで動作するのか、それとも単体のソフトウェアとして動作するのかは、大きなテーマとしてここ数年議論されてきました。

デスクトップでは、ブラウザだけで様々なことがこなせるのはもう当たり前です。Chrome OS のように、ブラウザそのものを OS にしてしまうくらいの発展を、ウェブ技術は遂げてきた結果と言えます。

それではモバイルではどうでしょうか？

これは Flurry が行った調査結果です。

アメリカのスマートフォン ユーザーが使用時間の実に 80% 以上をネイティブ アプリケーションに費やし、それに比べるとウェブの利用時間はごく僅かであることがわかります。利用時間だけを基準にすれば、議論の余地もなくネイティブ アプリケーションの圧勝に見えます。

一体なぜなのでしょう？

私が個人的に立てた仮説はこうです。

デスクトップは広大な海、スマートフォンは小さな宇宙

デスクトップでアプリケーションを使う際、ユーザーは通常、キーボードとマウスを使います。デスクトップの世界では、キーボードやマウスさえ使いこなせれば、広大なインターネットという海の中から、自分が欲しい情報やサービスを自在に探し当てることができます。

それに対しスマートフォンでは、指先 1 つで様々なことをこなさなければなりません。ソフトウェア キーボードで文字を打つだけでもちょっとした作業なため、検索するのも楽な作業ではありません。使いたい機能がワンタップですぐに立ち上がるとしたら、どれほど楽でしょう？

つまり、キーボードとマウスでの操作が想定されたデスクトップから、タッチでの操作が想定されたスマートフォンへの最適化がネイティブ プラットフォームの方が早く進んだためではないか、という仮説です。

それでは、ウェブをよりモバイル フレンドリーにしていくために、我々ができることはなんでしょうか？Chrome がブラウザとして提供できる新しい機能、みなさんが開発者として実装できる新しい機能を

• エクスペリエンス
• スピードとオフライン
• エンゲージメント

という 3 つのパートに分けてご紹介していきます。

エクスペリエンス

ウェブとネイティブを比較した際、最も大きく異なるのはそのアクセス方法です。

ウェブでは最初のアクセスの際、検索やリンクを辿ることでサービスに到達します。ネイティブではマーケットプレイスでインストールすることにより、サービスに到達します。

それでは二回目以降はどうでしょうか？ウェブでは、ブックマークしていない限り、検索やリンクをもう一度辿る必要があります。ブックマークしていたところで、フォルダ構造を辿るなどするため、最低でも数タップが必要です。逆にネイティブの場合、インストール済みのアプリケーションはホーム画面にあるため、アイコンを一度タップするだけで済みます。

インストールのハードルが高いとはいえ、リピートしてもらうことを考えれば、スマートフォンにおいて、ネイティブアプリのようなアクセス方法が理想的なのは明らかですね。ウェブでこれを実現することはできないものでしょうか？

ホーム画面に追加

既に Chrome で利用できる機能に「ホーム画面に追加」というものがあります。これを選択することで、ウェブサイトのブックマークがホーム画面に追加され、ユーザーはワンタップでブラウザを開き、アクセスできるようになります。
さらに、もう一工夫加えることで、これをよりネイティブに近いエクスペリエンスにすることができます。そこで登場するのが Web Manifest です。

manifest.json

{
  "name": "Kinlan's Amazing Application ++",
  "short_name": "Kinlan's Amaze App",
  "icons": [
    {
      "src": "launcher-icon-3x.png",
      "sizes": "144x144",
      "type": "image/png"
    }
  ],
  "start_url": "index.html",
  "display": "standalone"
}

index.html

<link rel="manifest" href="/manifest.json">

Web Manifest は JSON で記述されたウェブサイトのメタ データで、サーバー上に配置したものを HTML から link[rel="manifest"] で参照することにより効力を発揮します。上記の例ではアプリの正式名称（name）、ホーム画面に追加された際のショートネーム （short_name）、アイコンの指定（icons）（画面サイズに応じて複数指定可能）、アイコンをタップした際に開く URL（start_url）、表示モード（display）、を指定しています。この Web Manifest により、ウェブサイトをホーム画面に追加した際の挙動を、よりモバイル フレンドリーなものへと変えることができるのです。

参考 URL はこちら：

• Manifest for a web application
• Installable Web Apps with the WebApp Manifest in Chrome for Android
• manifest.json で Web アプリを「ホーム画面に追加」自動バナー表示に対応させる

フルスクリーン

Web Manifest の display を standalone とすることで、ホーム画面のアイコンから起動した際に URL バーを隠し、よりネイティブ アプリに近い見た目にすることもできます。

インストール バナー

実はここまでのエクスペリエンスは、iOS の Safari でも同様のことが随分昔からできていました。とはいえ、ホーム画面にアイコンを追加してもらうには、ユーザーの能動的なアクションが必要で、最低でも 2 回のタップを伴うため、決してよく使われる機能ではありません。ホーム画面に追加することを促すバナーをページ上に表示しているサイトも珍しくはありません。

そこで Chrome では、M42 からこの「ホーム画面に追加」をブラウザが自動的に促してくれる機能を追加しました。

Chrome にこのバナーを表示させるためには、いくつかの条件があります。

• ユーザーがウェブサイトを 1 週間以内に 2 回訪問
• Web Manifest が存在する
• Service Worker を使っている
• HTTPS でサーブされている

※ これらの条件はあくまで現時点のものであり、今後変更される可能性があることにご注意ください。

参考 URL:

• Increasing engagement with Web App install banners
• manifest.json でWebアプリを「ホーム画面に追加」自動バナー表示に対応させる

テーマカラー

Chrome では meta[name="theme-color"] を使うことで URL バーの色を変更することができます。色は hex のカラー コードを content 属性で指定します。

<meta name="theme-color" content="#db5945">

さらに Android 5.0 以降であれば、最近利用したアプリ一覧を表示した際の表示もここで指定した色で表示されるようになります。

参考 URL はこちら：

• Support for theme-color in Chrome 39 for Android

スピード・オフライン

ウェブ アプリも、ネイティブ アプリのようにリソースをローカルに持たせることで、起動速度を向上することができます。作り方によってはオフラインでも動作させることができるはずです。

ご存知のとおり、これはウェブにとって初めての試みではありません。Application Cache はこれを実現しようとした最初の標準仕様でしたが、様々な問題点が指摘されるなど、現在も広く使われている機能とは言えません。

そこで代替技術として現在注目を浴びているのが、Service Worker です。

Service Worker とは

Service Worker はオフライン技術を可能にするためだけのものではありません。Service Worker とは、ひとことで言うならこうです：

ユーザーに見えるウェブページの裏側で動かせるイベント駆動の JavaScript 環境

ウェブページで Service Worker を登録することで、様々なイベントを受け取れるようになり、それに伴い任意の動作をバックグラウンドで行えるようになります。例えば

• ウェブページのリクエストを横取りして、ローカル プロキシのように動作。
• ウェブページが開いていなくても、イベントを受け取り、スクリプトを実行。

Service Worker バックグラウンドで動作すると言っても、常時動いているわけではありません。イベント駆動になっていますので、各種イベントが発生するのに伴い、様々な短い処理を行うことができます。想定されているユースケースは様々です：

• ローカル プロキシ
• オフライン キャッシュ
• プッシュ通知
• バックグラウンド同期
• ジオ フェンシング

fetch イベントを使うと、ドキュメントから発生したあらゆるリクエストをイベントとして受け取り、ローカル プロキシとして動作させることができます。これを使えば、例えば次のようなこともできます：

• 画面サイズを元に動的に URL を書き換えることで、レスポンシブにサイズの異なる画像を取得する
• クエリに応じてテスト用のスタブ データを返す
• JavaScript の依存関係を動的に解決し、必要なリソースを CDN などから取ってくる（ハッカソンで出たアイディア）

なお、Service Worker は非常に強力な機能のため、HTTPS でのみ動作可能（デバッグのため localhost は例外）である点に注意してください。

サンプル コード

コードを見るのが何よりもイメージが湧きやすいと思いますので、簡単な例を示します。

navigator.serviceWorker.register('/sw.js')
  .then(function(registration) {
      // Success!
  }).catch(function(error) {
      // Error...
  });

このコードでは、index.html に存在する JavaScript から Service Worker を登録しています。
登録が成功すると、以後ブラウザのバックグラウンドで Service Worker の JavaScript（この場合 sw.js）が動き続けることになります。

Cache API

この Service Worker 上で fetch イベントを取り、ブラウザからサーバーにリクエストが発行される度に、あらかじめキャッシュしてあるリソースを返すことで、ウェブサイトを高速にしたり、オフラインで利用できるようすることができます。

self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request).then(function(response) {
      return response || fetch(event.request);
    })
  );
});

このコード例では、リクエストに対し、あらかじめキャッシュしてあるリソースをそのまま返しています。ページの本体である index.html ですらオフラインで動作できるのが Service Worker の強力な点です。

なお、Service Worker によるキャッシュ機能はウェブページそのものとは切り離されているため、非対応ブラウザで実行しても、単純に Service Worker 部が動作しないだけで、ページ自体には問題が発生しにくいという特徴があります。ブラウザ互換性をあまり気にしなくても、対応ブラウザにだけ付加的にメリットを提供できるのも ServiceWorker の魅力の一つです。

参考 URL:

• Service Worker の紹介
• Service Workers（仕様）
• Service Worker Primer

エンゲージメント

モバイルプラットフォームでサービスを提供する方たちがウェブではなくネイティブを選ぶ理由のひとつに、プッシュ通知が挙げられます。メールでは見逃される可能性のあるメッセージを、肌身離さず持っている携帯電話の一等地とも言える場所に届けられるのですから、モバイルのプッシュ通知は大変強力です。
では、これがウェブで実現できたらどうでしょう？それを可能にするのが Service Worker を使ったプッシュ通知機能です。

こちらのデモでは "Enable Push Notifications" のスイッチを入れると同時に、パーミッションを求めるダイアログが表示され、許可をするとそれ以降プッシュ通知を受信することが可能になります。自分で "SEND A PUSH TO GCM VIA XHR" をクリックして動作を確認してみてください。

仕組みはこうです：

1. ユーザーがサービスにアクセスし、サイトの最新情報を購読するボタンをクリック
2. 許可を得るダイアログが表示され、ユーザーが許可します。
3. 仕様上は HTTP Push と呼ばれるプロトコルを使って、サーバーからプッシュが行われます。
4. しかし、接続するサーバーが多くなればなるほど、張らなければならないコネクション数が多くなってしまうため、Chrome では Android で既に使われている Google Cloud Messaging というサービスを利用することで、コネクションを束ねます。
5. これにより、端末に必要なコネクションは GCM とのみとなり、サーバーは GCM サーバーに HTTP POST を使ってメッセージを送信するだけで、プッシュが可能になります。

Chrome では現状このような実装になっていますが、Service Worker はオープンスタンダードですので、将来的に Chrome もそれに合わせた挙動になるよう変更されていく予定です。

購読時のサンプル コード：

navigator.serviceWorker.ready().then(function(sw) {
  sw.pushManager.subscribe().then(function(sub) {
    // After permission is granted
    sub.subscriptionId; // registration Id
    sub.endpoint;       // GCM URL
  });
});

ウェブサイトがプッシュ通知の購読を行います。その際、ユーザーに同意を求め、許可された場合のみ、GCM と通信を行い、subscription id を取得します。そしてその subscription id をサーバーに送ります。

プッシュ受信時のサンプル コード：

self.addEventListener('push', function(event) {
  event.waitUntil(
    self.registration.showNotification(title, {
      body: body,
      icon: icon,
      tag:  tag
    }
  });
});

サーバーはその subscription id を使って GCM に Post メッセージを送ることで、プッシュ通知を行います。
Service Worker はプッシュ通知をイベントで受け取り、Notifications API を使って通知を表示します。

参考 URL:

• Push Notifications on the Open Web
• Push API
• Notifications API

Chrome におけるプッシュ通知の現時点での制約

Chrome のバージョン 42 からプッシュ通知が使えると書きましたが、この段階では未実装機能の制約がとても多いのが現状です。ネイティブアプリ並みのプッシュ通知を行いたい場合は、もうしばらく待つ必要があります。

• Push メッセージにデータを乗せられない
• Push されたら通知を出さなければならない
• Notification にデータを乗せられない

とはいえ、プッシュ通知は大変強力な機能ですので、実際に試し、来るべき未来に備えることをオススメします。

SSL について

既にお気付きの方も多いと思いますが、Service Worker の強力な機能の多くは、ウェブサイトが HTTPS であることを前提としています。
HTTPS は、暗号化や証明書といった用途だけでなく、「ホーム画面に追加」のおおすすめや、Service Worker を使うこと、プッシュ通知を使うなどする際に、必須条件になっています。

• 「ホーム画面に追加」のおすすめ
• Service Worker
• プッシュ通知
• 暗号化
• 証明書

この機会にサイト全体を HTTPS にすることをぜひご検討ください。

まとめ

Web Manifest と theme-color を使うことで、あなたのモバイル ウェブサイトは今すぐエクスペリエンスを向上することができます。また、Service Worker の Cache API を使えば、既存の機能を損なうことなく、スピードの改善・オフライン対応することができます。将来に備え、HTTPS やプッシュ通知の導入もご検討ください。

Posted by Eiji Kitamura - Developer Relations Team

Push API を使ったプッシュ通知や、Cache API を使ったページロードの高速化およびオフライン機能など、これまでウェブブラウザでは不可能とされてきたことを可能にする Service Worker を使ったウェブアプリ開発のハッカソンを開催します。

今回のイベントでは、最初に Service Worker での開発に必要な知識をご紹介するセッションを行います。また、実際に Service Worker の開発に携わった Google エンジニアがチューターとして参加し、みなさんのハッキングをお手伝いします。

イベント内容

名称：Service Worker ハッカソン
日時：2015 年 4 月 4 日（土） 9:30 - 19:00 （受付 9:00 - 10:00）
場所：Google 東京オフィス 六本木ヒルズ森タワー
会費：無料
定員：50名
主催：Google
ハッシュタグ：#serviceworker
利用テクノロジー：Service Worker, Cache API, Push API, Web Manifest, Web Notification, Fetch, Streams

* ランチおよび、懇親会で軽食を提供する予定です。

注意事項

• 当日使われる PC はご自身で準備をお願いします。
• Android の場合は Chrome Beta、デスクトップの場合は Chrome Beta / Dev または Chrome Canary を予めインストールしておいてください。iOS は未対応です。

申し込み方法

申し込みフォームよりお申し込みください：
http://goo.gl/forms/XsZ9K7ujcM

お申し込みの受付期間は、3 月 26 日（木）までとなります。ご参加いただける方には、参加証を 3 月 27 日（金）より順次ご登録いただいたメールアドレス宛にお送りする予定です。

多くの皆様のご参加をお待ちしております。


Posted by Eiji Kitamura - Developer Relations Team

[この記事は John Mellor、Michael van Ouwerkerk と ‘appiest Software Engineers による Chromium Blog の記事 "Chrome 42 Beta: Push Notifications, Promoting Add to Home Screen and ES6 Classes" を元に、北村が翻訳・加筆したものです。詳しくは元記事をご覧ください。]

最新の Chrome ベータ版チャンネル リリースでは、ES6 クラスのサポートなど複数の新しい機能が含まれており、さらに迫力のあるウェブ アプリケーションの作成をサポートします。明記されていないかぎり、下記の変更は Android、Windows、Mac、Linux、Chrome OS、それぞれに対応する Chrome に適用されます。

プッシュ通知

この機能によって、ページが閉じられた後でもユーザーへの通知をプッシュできるようになります。もちろん、ユーザーが明示的に許可した場合にかぎります。新しい Push API では、Google Cloud Messaging を使ってデベロッパーがリモートで Service Worker を起動することができます。起動したら Service Worker は任意の JavaScript を実行することができます。ただしこのリリースでは、少なくともユーザーが見られる通知を表示する必要があります。

[ホーム画面に追加] のおすすめ

Chrome 32 から Android ユーザー向けに、新しいメニューアイテムを使ってお気に入りのウェブサイトのショートカットをホーム画面に追加する機能が導入されました。今回のリリースでは、高品質のウェブ アプリを頻繁に使用しているユーザーに対してバナーを表示し、タップ 1 回でそのサイトをホーム画面に追加できるようになります。

この新しい機能を活用するには、そのサイトがホーム画面から起動した際にユーザーに適切なエクスペリエンスを提供している必要があります。この基準は今後、デベロッパーやユーザーからのフィードバックに基づき随時更新されていきますが、現時点では、ウェブ アプリ マニフェストを用意すること、すべてのコンテンツで HTTPS が使用されること、Service Worker を使って少なくとも一部の機能がオフラインでも動作することが挙げられます。

ES6 Class

JavaScript の prototype ベースの継承に対応することは簡単ではありません。また、多くのライブラリでクラスをエミュレートする独自のパターンが導入されていますが、JavaScript 自体はネイティブでクラスを記述する方法を提供していません。
ES6 class では、JavaScript に標準化された class 構文を提供し、この問題を解決しています。新しい構文は Chrome 42 から、strict モードで書かれた JavaScript で使用可能になります。

'use strict';

class Polygon {
    constructor(height, width) {
        this.name = 'Polygon';
        this.height = height;
        this.width = width;
    }

    sayName() {
        log('Hi, I am a ', this.name + '.');
    }
}

let p = new Polygon(300, 400);

その他のアップデート

• デベロッパー ツールで cubic bezier 関数を視覚的に編集できるようになり、簡単にアニメーションの動きを理解して変更できるようになります。
• AJAX リクエストに、Promise ベースの新しい標準仕様を備えた Fetch API を、Window コンテキスト、Shared Worker、Dedicated Workers で使用できるようになりました。
• OfflineAudioContext インスタンスの startRendering メソッドが、Promise を返すようになりました。これによって、オーディオのレンダリングが終了したときに Promise が resolve され、Web Audio API.を使って動作するウェブ アプリのデザインを、よりシンプルにすることができます。
• AudioBufferSourceNode.buffer は 2 回以上セットできなくなりました。これにより、新しい source が始まる際に制御不能に陥る事態を避けることができます。
• ChromeOS で screen.orientation がサポートされ、デバイスの傾きが大きく変化した際、DeviceOrientationEvent を発火するようになりました。
• このリリースには、Encrypted Media Extensions のプレフィックスがつかない最新版の実装が含まれています。これでメディア サイトが著作権管理システムを探してやり取りすることができるようになります。
• 新しいコンテンツ設定を利用することで、主要でないプラグインを電力消費を抑えるために自動的に停止できるようになります。デベロッパーはこの機能をオンにして、コンテンツに応じてどのように作用するかをテストできます。

いつものように chromestatus.com/features で Chrome のデベロッパー機能の概要を確認してください。また、さらに頻繁なアップデートが必要な場合は、+Google Chrome Developers のサークルをご確認ください。

Posted by Eiji Kitamura - Developer Relations Team