今年の Google I/O にて、Google は Maps JavaScript API 向けクラウドベースのマップスタイル設定の一般提供を発表しました。この度 Google は、クラウドベースのマップスタイル設定の新機能を発表いたします。この新機能は選択肢の幅を広げ、制御性を高め、ユーザーに優れたエクスペリエンスを提供します。その新機能とは、ランドマークとビルディング フットプリント（建物の外形情報）の 2 つです。ウェブ版とアプリ版の一般向け Google マップをご利用の方はこれらの機能をすでにご存知かもしれません。また、業界別に最適化された地図スタイルの新バージョンもリリースします。新しいバージョンではより細やかな設定が設定できるようになると同時に柔軟性が向上し、優れたエクスペリエンスを実現します。それでは詳細を見てみましょう。

ランドマークの表示によりすばやく現在地を把握することが可能に

ウェブ版とアプリ版の一般向け Google マップをご利用の方は、主要なスポットが強調表示されていることにお気づきかもしれません。このランドマークは、ユーザーが自身の現在地を確認し、探索中または訪問中の都市でどのように移動すればよいかを決定するための目印として役立ちます。

サンパウロ（å·¦）とローマ（右）のランドマーク

このたび、クラウドベースのマップスタイル設定を使用して地図を作成することで、一般向け Google マップと同じエクスペリエンスをユーザーに提供できるようになりました。この機能は、ニューヨーク、ドバイ、パリ、ムンバイ、シンガポールなど、世界中の 100 の都市で利用可能です。地図にランドマークを表示するには、Cloud Console にログインし、スタイル エディタで [Points of interest] の機能タイプに移動して、[Marker Style] で [Illustrated] を選択します。


ビルディング フットプリントへの切り替えで地図機能をシンプルに

場合によっては、シンプルな地図のほうが便利なときもあります。高い建物が密集している都市では、高い建物を 3D で表示するとユーザーにはわかりづらくなる場合があります。そのため、建物の 3D 表示の他に、スタイル エディタのオプションとしてビルディング フットプリント機能を追加しました。ビルディング フットプリントにより、基本的な地図のバランスや構成が大きく変更されるため、建物が 3D 表示された複雑な地図を必要としないユースケースにも対応できます。

ビルディング フットプリント

ビルディングフットプリント面の塗りつぶしと線幅も、それぞれ多様なカラーテーマで設定できます。ビルディング フットプリントを有効にするには、スタイル エディタで [Buildings] に移動し、[Building Style] で [Footprints] を選択します。

スタイル エディタのメニューで [Landscape] から [Human-made] を選択し、ビルディング フットプリントを有効にした地図。


業界別に最適化された地図のスタイルでは、ランドマークとビルディング フットプリントに加えて詳細なストリート マップも使用可能

Google は今年の 1 月、旅行、不動産、小売、ロジスティクス業界向けに最適化された地図のスタイルの提供を開始しました。これによりお客様は、クラウドベースのマップスタイル設定を通じて、事前設定されたスタイル付き地図が利用できるようになりました。ランドマークは業界別に最適化されたすべてのスタイル付き地図で使用でき、ビルディング フットプリントは旅行業界向けのスタイル付き地図のみで使用できます。業界別に最適化されたスタイル付き地図をすでに利用している場合、それらの新機能は地図に自動で適用されるため、追加操作は不要です。この変更を無効にしたい場合は、スタイル エディタで機能をオフにします。

また、業界別に最適化された地図のスタイルに限定されますが、詳細なストリート マップが利用可能になります。この機能は、2020 å¹´ 8 月に Google I/O で発表したウェブ版とアプリ版の一般向け Google マップの新しい機能ですでにご覧になっているかもしれません。詳細なストリート マップは、現在サンフランシスコ、ニューヨーク、ロンドン、東京で使用できますが、2021 年の終わりまでに新たに 50 都市をサポートをする予定です。


詳細なストリート マップは、業界別に最適化された地図の全スタイルでデフォルトで有効になります。この表示設定は、新たに作成された設定メニューから必要に応じて変更できます。将来的に、すべてのクラウドベースのマップスタイル設定に、詳細なストリート マップ機能を完全導入できるようこの取り組みを続けています。

ランドマークとビルディング フットプリントおよび業界別に最適化された地図のスタイルの新バージョンは、Google Cloud Console 内のクラウドベースのマップスタイル設定からご利用いただけます。利用料金は Google Maps Platform の料金に含まれています。ランドマーク、ビルディング フットプリント、業界別に最適化された地図スタイルの使用方法については、開発者ドキュメントをご参照ください。また、クラウドベースのマップスタイル設定を開始するには、JavaScript のドキュメントをご覧ください。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。



Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer 

この記事は Google Maps Platform チームによる Google Cloud Blog の記事 "Improved accessibility in the Maps JavaScript API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Google Maps Platform JavaScript チームが行っている、Maps JavaScript API のユーザー補助機能の改善に重点を置いた最近の機能変更をいくつかご紹介します。当チームは 2020 年に、すぐに使えるユーザー補助機能と、デベロッパーがユーザー補助エクスペリエンスを作成するために利用できるフックを増やす新たな取り組みを開始しました。

Google は、Maps JavaScript の UI と API のユーザー補助機能の改善に継続的に取り組んでおり、まだまだできることがあると認識しております。お客様にはこうした新機能を毎週の最新バージョンでお試しいただき、変更点に関するフィードバックの提供と新しいバグの報告にご協力いただけますと幸いです。それらを参考に、最も影響の大きい領域に優先順位を付けさせていただきます。みなさんのウェブサイトに影響を与える既存のバグに +1 し、新しいバグレポートをご提出ください。ユーザー補助機能は、さまざまなユーザーやコミュニティに多様な影響を与える複雑なトピックです。お客様のフィードバックは、Google Maps Platform の機能を誰でも利用できるようにする取り組みの指針として活用されます。


2020 年最初の機能変更は、特に根本的な問題に焦点を絞っていました。タブの順序の最適化、キーボードの有効化とスクリーン リーダーの対話的な機能、スクリーン リーダーに関する説明の追加、各マップコントロールのカラー コントラストの強調を図りました。機能変更の前後での違いをご覧ください。


タブの順序は標準的ではなく、スペースバーでボタンがアクティブになりませんでした。

タブの順序は左から右、上から下に並べられ、スペースバーでボタンがアクティブになり選択でき、色のコントラストが上がって視認性が増しています。

また、デベロッパーがマップに追加するマーカーについても詳しく調べました。マーカーは、img ロールか、インタラクティブな場合（クリック イベント リスナーが登録されている場合など）は button ロールにデフォルト設定されました。インタラクティブなマーカーもキーボードで矢印キーを繰り返し押して操作できます。デベロッパーがマーカーにタイトルを指定すると、このテキストはユーザー補助ラベルにも使用されます。こうした改善は最適化されていないマーカーにのみ適用されm。詳細については、新しい「マーカーを利用可能にする（Make a marker accessible）」ガイドと「マーカーのユーザー補助機能（Marker Accessibility）」コードサンプルをご覧ください。


ユーザー補助のラベルとロールが適用された、キーボードの矢印キーで操作できるマーカー。

マップで特に使用される UI コンポーネントは InfoWindow です。改善点の中で特筆すべきなのは、InfoWindow が開いたり閉じたりした際に、InfoWindow から出入りするタブ選択を自動的に管理する機能です。デフォルトではこれまで多くのユーザーから寄せられたフィードバックを元に、open() が自動的にフォーカスを移動するかどうかを決定します。デベロッパーの皆様は、InfoWindow を開く際に shouldFocus オプションを使用して明示的に選択することをおすすめします。

const infoWindow = new google.maps.InfoWindow({

    content: "Hello Accessibility!",

});

infoWindow.open({

    anchor: marker,

    shouldFocus: true,

});

 

InfoWindow を開くと、最初のフォーカス可能な要素（デベロッパー指定のコンテンツか、組み込みの閉じるボタン）が開きます。閉じると、フォーカスが復元されます。

Maps JavaScript API は 2005 年以降、パンやズームなどのマップ操作のキーボード コントロールをサポートしていますが、ユーザーがキーボード ショートカットを見つけるのは困難でした。今月、UI に新しいキーボード ショートカットのダイアログを追加し、使用できるショートカットをユーザーが見つけやすくしました。こうしたキーボード ショートカットは、マップ自体にフォーカスがあるときに有効になります。

マップ上の「キーボード ショートカット」ボタンをアクティブにすると、使用可能なショートカットのダイアログが表示されます。

今後導入予定の機能


ウェブでは毎日、世界中の何百万人ものユーザーが Maps JavaScript API によって提供される Google basemap を利用しています。Google の目標は、万人向けのマップを作成できるようにするために必要なツールをデベロッパーに提供することです。


Google は、Maps JavaScript の UI と API のユーザー補助機能の改善に継続的に取り組んでおり、まだまだできることがあると認識しております。今回の変更は、その手始めにすぎません。これらの新機能をぜひお試しになり、フィードバックをご提供ください。また、リリースノート ページでは、Maps JavaScript API の新しい機能の追加状況をご確認いただけます。さらに、既存のバグを検索してウェブサイトに影響するバグに +1 する、これまでに修正されたバグを確認する、フィードバックや発生した問題を記載した新しいバグレポートを送信するなどの方法で、Google Maps Platform の改善にご協力いただけますと幸いです。


Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。

編集者のメモ : 以下の抜粋記事の出典は、Google のデータ サイエンティスト、Sixing Chen による HTTP Archive Blog への投稿です。より広い AMP コミュニティで共有するため、著者の許可を得た上で以下に転載します。詳細については、出典元のブログ投稿をご覧ください。

はじめに

HTTP Archive Blog に掲載された最近の分析は、Core Web Vitals（CWV）とさまざまなウェブの特性との相関関係に着目しています。CWV はウェブ体験の質を表し、Google が特に重視する指標です。この調査では多くの技術を分析しており、因果関係を示唆するものではありませんが、AMP に関する結果は早い段階で AMP の大きな可能性を示しています。すなわち、AMP はユーザーにすばらしい体験を提供し続け、デベロッパーにとって費用対効果の高いソリューションとなる可能性をもっています。

この調査の目的は、「さまざまなウェブ開発の選択肢を評価する際の参考として、CWV とウェブの特性との関連性について理解を深めるために役立ててもらうこと」にあります。この調査では、HTTP Archive のデータを使用して、CWV といくつかのウェブ技術（JavaScript フレームワーク、JavaScript ライブラリ、CMS、UI フレームワーク、ウェブ フレームワーク、ウィジェットなど）との相関関係を分析しました。 

AMP についての結果を以下に掲載します。斜体になっている部分は、すべて元の調査からの転載です。 

結果

ここでは、関連性についての結果を示すとともに、特に CWV への影響が大きいと思われる特徴的な点について記載します。

関連性についての結果を解釈するうえで重要な点があります。それは、特定のウェブ特性への正の影響と負の影響は、他のウェブ特性との比較においてのみ、また、多くのウェブ技術、多種多様なコンテンツ、さまざまなサードパーティ リクエストが混在したウェブサイトという前提でのみ解釈すべきであるという点です。たとえば、あるウェブ技術が強い正の影響を示していた場合、その技術は他の技術と比べてパフォーマンスが優れているようだと解釈すべきです。その技術をウェブサイトに導入すれば、ウェブのパフォーマンスが向上すると解釈することはできません。

LCP

LCP は数値の対数としてモデリングするので、高いほど悪いことになります。

%HSM 値が 1 に近い予測値は、数値 / カウントの特性値が高いことを示します。つまり、その技術の存在と高い LCP 値には強い関連性があります。%HSM が 0 に近い予測値では、その逆が成り立ちます（%HSM が高くなるほど悪化する）。

同様に、MSD が比較的大きな正の数である予測値は、数値 / カウントの特性値が高いことを示します。つまり、その技術が存在すると、LCP に強い負の影響を与えます。MSD が大きな負の数である予測値では、その逆が成り立ちます（MSD が大きな正の数になるほど悪化する）。

…

ほとんどの JavaScript フレームワークは LCP と強い正の相関を示すので、悪影響が生じることになりますが、AMP は例外です。特に影響が大きいのは、AngularJS、GSAP、MooTools、RequireJS です。

…

CLS

CLS は、与えられたしきい値を満たすかどうかを示すバイナリ インジケーターとしてモデリングします。1 はウェブサイトの CLS が 0.1 未満、0 はそれ以外であることを示します。そのため、1 は 0 より優れています。

%HSM 値が 1 に近い予測値は、数値 / カウントの特性値が高いことを示します。つまり、その技術の存在と CLS がしきい値を満たすことに強い関連性があります。%HSM が 0 に近い予測値では、その逆が成り立ちます（%HSM が低くなるほど悪化する）。

同様に、MSD が比較的大きな正の数である予測値は、数値 / カウントの特性値が高いことを示します。つまり、その技術が存在すると、CLS がしきい値を満たすことに強い正の影響を与えます。MSD が大きな負の数である予測値では、その逆が成り立ちます（MSD が大きな負の数になるほど悪化する）。

いくつかの JavaScript フレームワークは、CLS がしきい値を満たすことと強い負の相関を示すので、悪影響が生じることになります。ただし、AMP、GSAP、React では相関性と影響が低くなっています。AngularJS、Handlebars、Vuejs は特に負の影響が強いものでしょう。

…

AMP にとっての意味

AMP Project の目的は、常にユーザー ファーストな体験を作れるようにデベロッパーをサポートすることにあります。AMP Performance Working Group は、ウェブ上の AMP ページのパフォーマンスを継続的に管理し、定期的に AMP ライブラリのパフォーマンスを強化するアップデートをています。また、AMP は常に最新の状態を維持するライブラリなので、デベロッパーは何の追加作業も必要なく改善点を活用できます。AMP Project には、デベロッパーが簡単に Core Web Vitals のしきい値を満たせるようにするという役割があります。それを果たしている証拠として、上のような相関性についての調査結果を確認できることは私たちの喜びです。 

Google 検索では、ランキングにおけるページ エクスペリエンス シグナルの利用がまもなくロールアウトされる予定です。それに向けて、AMP はウェブ パフォーマンスのベスト プラクティスの遵守に役立っており、すべての AMP ページが Core Web Vitals に準拠できるように最大限のチャンスを与えています。私たちは、そこまで到達できたことをうれしく思っています。以上のような理由から、デベロッパーの皆さんには AMP ページ エクスペリエンス ガイドの活用をお勧めしています。このガイドは、アクションにつながるアドバイスを AMP デベロッパーに提供し、AMP ページのページ エクスペリエンスの改善に役立つツールです。 

いつものように、問題や機能リクエストがありましたらお知らせください。AMP ページ エクスペリエンス ガイドに関することは、特に遠慮なくご連絡ください。


Reviewed by Chiko Shimizu - Developer Relations team

AMP にとって 2019 年は大きな当たり年でした。コミュニティは拡大を続け、ウェブサイト、 メール、ストーリー、広告の全体にわたってすばらしい体験を作り出しています。ここでは年初に戻って、ともに達成してきたすべてのマイルストーンを振り返ります。こちらの動画を見て、以下をお読みください。








AMP 用の Next.js

React サーバーサイド レンダリングによる AMP ページの構築が人気を博し、このユースケースをサポートする機能の追加は必然だったと実感しています。React で特によく使われているフレームワークである Next.js との統合も、そのためです。豆知識 : nextjs.org は完全に AMP で構築されています！

amp-script

今年、ゲームチェンジャーとなる <amp-script> がとうとう皆さんの画面にデビューしました。大きな期待を集めたこのコンポーネントによって、AMP ページにカスタム JavaScript を追加したり、AMP ページと非 AMP ページでコードを共有したり、以前はできなかったものを作成したりできるようになりました。


OpenJS Foundation が AMP を歓迎









OpenJS Foundation への参加決定を発表し、次のオープンガバナンス モデルを明らかにしました。OpenJS Foundation のミッションは私たちのミッションと一致します。この組織によってテクノロジー業界の多様な声が集まり、公正なウェブを作るという私たちの取り組みも推進されるでしょう。

AMP が皆さんの受信トレイに









Gmail で AMP for email がリリースされ、ユーザー ファーストな体験が皆さんの受信トレイでも実現しました。メールの送信者は、スムーズな体験やインタラクティブなコンテンツを作成し、エンゲージメントを向上できるようになりました。AMP for email の仕様には、Outlook や Yahoo Mail などの主要なメール プロバイダも関与しています。こういったパートナーとともにメールのエコシステムを変革できることを楽しみにしています。

新しいコンポーネントは Mail.ru でも利用でき、先行ユーザーはすでにすばらしい結果を残しています。インド最大のホスピタリティ企業である OYO は、AMP for email のテストでコンバージョンが 60% 上昇しました。

AMP Conf の成功に「アリガトウ」

毎年開催しており、今年で 3 回目となる #AMPConf が東京で開催され、500 名近くの方に会うことができました。プロダクトの発表に加え、デザインを刷新した amp.dev をお披露目しました。amp.dev は、コードサンプル、テンプレート、ドキュメントなどがすべて集約されたウェブサイトです。AMPConf2020 の準備はすでに始まっています。次のイベントはどこで開催されるか、注目です。

ニューヨークでの AMP Contributors Summit

10 月初旬には、毎年行われている #AMPCS2019 がニューヨークで開催され、AMP の新機能について約 100 名の貢献者と情報交換をしました。単なる会話にとどまらず、分科会も開催してプロジェクトの改善に取り組み、その過程で AMP にいくつかの驚きをもたらしました。

強力なコミュニティ

1,000 名近くの人が AMP にコードを寄贈し、あらゆる人のために高速でよりよいウェブをデザインすることに協力してくれています。すべての AMP プロジェクトのリポジトリを合わせると、今年だけで 341 名の貢献者が 18,300 回以上の寄贈をしています。








コードの向こうにいる人々

コミュニティは、AMP の進化に大きな役割を果たしています。知っていることを共有し、知らないことを学ぶ場所こそがコミュニティです。そこで、コミュニティのメンバーが AMP を利用してどのように実世界で違いを生んでいるかを理解するため、「コードの向こうにいる人々」シリーズを始めています。

19 回の新しい Roadshow を実施

今年、AMP は 19 回遠征し、世界中で Roadshow をしました。ヨハネスブルグからソウルまで、合わせて 1,600 名の皆さんが AMP を見に来てくださいました。

Roadshow は、デベロッパーが本格的な AMP ウェブサイトを自信を持って構築できるように企画されています。そのため、4 つの主要な柱であるデザイン、インタラクティブ性、DevOps、収益化について徹底的に取り上げ、一歩抜きんでるために必要なものすべてがそろうようになっています。

2020 年の開催場所については、AMP Roadshow ページをご覧ください。自分の住む場所が掲載されていない方は、ぜひお知らせください。私たちはいつも新しい場所を探しています。または、自分でイベントを開催することもできます。素材はすべて提供します。皆さんに必要なのは、来場することだけです！






2020 年のビジョン

今年はすばらしい 1 年でした。高速でユーザー ファーストなウェブをあらゆる人のために作成している皆さんの創造性と献身に感謝します。私たちは、AMP の今後に大きな期待を寄せています。新しい年も、皆さんとともにこの作業を続けてゆけることが楽しみです。AMP 関連のすべてのプロジェクトの最新情報を得て、2020 年の私たちのビジョンを見るには、ニュースレターに登録してください。

投稿 : Alex Durán（Google の AMP プロジェクト マーケティング）

Reviewed by Chiko Shimizu - Developer Relations Team

上の例を見て興味を持った方は、<amp-script> を試してみてください。なお、AMP のパフォーマンスを保証するために、いくつか制約がある点に注意が必要です。
<amp-script> は、React、Preact、Angular、Vue.js、jQuery、D3.js など、皆さんが既に利用しているかもしれないフレームワークに対応しています。

この点は、AMP を使っているデベロッパーから寄せられた最も重要な要望でした。AMP Project は、スピードという AMP の価値提案を維持しつつ、この要望に対処できたことをうれしく思っています。<amp-script> の動作の詳細については、こちらをご覧ください。また、このガイドに従って <amp-script> を試してみてください。このすばらしい手法を使うと、これまでは不可能だったたくさんのユースケースを実現できるようになります。

<amp-script> の使用に関する問題や機能リクエストがありましたら、遠慮なくお知らせください。


投稿者: Naina Raisinghani（Google AMP Project、プロダクト マネージャー）
Reviewed by Chiko Shimizu - Developer Relations Team
Share on Twitter Share on Facebook


Web Share API 　

ユーザーがソーシャル ネットワークで簡単にコンテンツを共有できるようにするには、各ソーシャル サービス用の共有ボタンを手動でサイトに組み込む必要があります。そのため、ユーザーが実際に使っているサービスで共有できないことも多く、ページサイズの肥大化やサードパーティ製コードを含めることによるセキュリティ リスクも発生しています。 　
Chrome for Android では、新しく navigator.share API が利用できるようになっています。これは、Android ネイティブの共有ダイアログを呼び出すことにより、インストールされている任意のネイティブ アプリで簡単にテキストやリンクを共有できるようにするものです。今後のリリースでは、インストールされているウェブアプリとの共有もできるようになる予定です。 　
navigator.share API を使うと、Android ネイティブの共有ダイアログ経由でさまざまなネイティブ アプリとコンテンツの共有が可能

WebUSB 　

高レベルのウェブ プラットフォーム API は、キーボード、マウス、プリンター、ゲームパッドなど、ほとんどのハードウェア機器をサポートしています。しかし、特殊な教育、科学、産業用の USB 機器を使う場合は、安全ではない可能性があるドライバやソフトウェアを検索してシステムレベルの権限を使ってインストールする必要があります。 　
今回、Chrome で WebUSB API がサポートされました。これにより、ユーザーの同意を得た上で、ウェブアプリが機器と通信できるようになります。各デバイスが提供するすべての機能を利用できますが、ウェブのセキュリティが保証される点は変わりません。 　

今回のリリースに追加されたその他の機能 　


サポートの終了と相互運用性の改善 　


　
Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook





Jacob Wenger
ソフトウェア エンジニア
継続的にフィードバックをお寄せいただいているおかげで、JavaScript SDK のバージョン 3.1.0 で Firebase の React Native サポートが強化されました。それだけではありません。このバージョンでは、Node.js SDK からの認証されていないアクセスも追加されているため、サービス アカウントなしにアプリを初期化できるようになっています。これにはどのような意味があるのでしょうか。詳しく見ていきましょう。

React Native のサポート

Google I/O で Firebase 3.x SDK がリリースされた際、SDK の認証部分は React Native と互換性がなくなっていました。リリース 3.1.0 では、ブラウザ固有の API を置き換えることによって、再び Firebase に React Native との互換性を持たせています。さらに、アプリの再起動をまたぐ認証状態の永続化など、React Native で Firebase を使用する際に問題となってきた点が修正されています。これによって、その他の JavaScript アプリと同様、Firebase プロジェクトを初期化するだけでよくなります。 

import ReactNative from "react-native";
import firebase from "firebase";
// Initialize Firebase
const firebaseConfig = {
  apiKey: "<YOUR-API-KEY>",
  authDomain: "<YOUR-AUTH-DOMAIN>",
  databaseURL: "<YOUR-DATABASE-URL>",
  storageBucket: "<YOUR-STORAGE-BUCKET>"
};
firebase.initializeApp(firebaseConfig);

3.1.0 SDK のアップデートでは、React Native でほぼすべての JavaScript SDK の機能がスムーズに動作するようになっています。ただし、いくつかの注意点があります。

未認証アクセス

リリース 3.1.0 のもう 1 つの特徴は、Node.js SDK で未認証アクセスがサポートされていることです。以前は、Node.js SDK を利用するにはサービス アカウントが必須でした。そのため、Firebase Console でのサービス アカウント キーの作成、サーバーへのダウンロード、コードからファイルを参照して認証、という作業を行う必要がありました。トークンの作成や検証には依然としてサービス アカウントが必要ですが、Node.js のユースケースによっては、サービス アカウントを使わないで済むこともあります。最新の SDK では、この要件を緩和してデータベース URL だけでアプリを初期化できるようにしています。 

import firebase from "firebase";
firebase.initializeApp({
  databaseURL: "<YOUR-DATABASE-URL>",
});

サービス アカウントがない場合、他の未認証クライアントと同様に Realtime Database へのアクセスは制限されます。

フィードバックをお待ちしています

Slack のチームや Google Group、その他のサポート窓口より意見をお寄せいただき、ありがとうございました。新しい SDK で何か問題が発生した場合は、こちらからご連絡ください。React Native や Firebase に関して皆さまからのご意見をお待ちしています。


Posted by Yoshifumi Yamaguchi - Developer Relations Team
Share on Twitter Share on Facebook


Google は Udacity と共同で Promises のオンライン コースを開発し、公開しました。これは、約 1 日で完結する短時間のコースで、Promises を使ってライブデータの読み込みと表示を行う「Exoplanet Explorer」アプリの構築が体験できます。Fetch API の使い方も学べるので、このコースを終えれば、XMLHttpRequest とはお別れです。

この短期コースはシニア ウェブ デベロッパー Nanodegree コースの 必須科目でもあります。Nanodegree コースの受講は有料ですが、本コースを単体で受講する場合は無料です。どちらかのコースを受講して、コードをよりシンプルに、信頼性を高くする方法を本日から学びませんか。

無料コースのお申し込みはこちらから。

 ※ 無料コースのご受講は、Udacity の受講を推進する Study Jams プログラムの一貫となります。上記の Study Jams 申し込みフォームに必要事項をご記入いただき、参加コースを「[上級] JavaScript Promises (ud898) 」としてご登録ください。その後、Udacity コース申し込みリンクをお送りします。　

Posted by Takuo Suzuki - Developer Relations Team
Share on Twitter Share on Facebook

私たちは今後数か月で、TurboFan をより多くの JavaScript で使用できるようにし、最終的には既存の CrankShaft コンパイラーから完全に移行することを目標としています。TurboFan が展開されると、デベロッパーのコードが自動的に高速化されます。コストはかからず、変更の必要もありません。今後の進捗にご期待ください。

Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook



コード キャッシングはもうひとつの新たな技術で、特に同じページを何度も表示するときにページが迅速に読み込まれるようになります。通常、ページの JavaScript はページを表示するたびに V8 エンジンによってコンパイルされ、プロセッサが認識できるインストラクションに変換されますが、このコンパイル済みのコードは、コンパイル実行時のマシンの状況やコンテキストによって大きく左右されるため、ユーザーがそのページから移動すると保持されません。Chrome 42 では、このコンパイル済みコードのローカルコピーを保持する拡張技術を採用することで、ユーザーがそのページに戻ってきたときにダウンロード、パース、コンパイルの手順をすべて省略できるようになります。これによってすべてのページでコンパイル時間の 40% を削減し、モバイル端末において貴重なバッテリーの消費量を減らすことができます。

以上が Chrome によってページの読み込み時間を抑える 2 つの技術についての説明になりますが、ページの読み込み時間はブラウザのパフォーマンスを向上する 1 つの手段にすぎません。Chromium プロジェクトで進められるウェブ パフォーマンスのすべての側面における改善を、今後もご期待ください。

Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook