この記事は Web Ecosystem Consultant - Saurabh Rajpal, Swetha Gopalakrishnan による web.dev の記事 "The business impact of core web vitals" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
LCP、FID、CLS

Core Web Vitals の採用について、ステークホルダーをなかなか説得できなかったり、実際にビジネスに役立つかどうか疑問に思ったりしていませんか？この記事では、すでにユーザーやビジネスに好影響が出ている企業の例を紹介し、Core Web Vitals と重要なビジネス指標にどのような相関関係があるのかをわかりやすく説明します。

動画で見たい方は、Google I/O のこちらのトークをご覧ください。

Core Web Vitals がユーザーやビジネスにとって重要な理由 #

組織では、ステークホルダーによって優先度が異なる場合があります。Core Web Vitals を導入すると、ユーザー中心の指標の最適化と、その結果としてのビジネスの成長に重点を置くことで、全員で共通の認識を持つことができます。

CWV について考える

Core Web Vitals のスコアを上げるまでの道のりは、サイトのパフォーマンスが現在どの段階にあるか、デザインがどれだけ複雑かによって、サイトごとに異なります。すぐにたやすく取り組めて有意義な結果につながる場合もあれば、複雑なソリューションを実装して困難な問題を解決しなければならない場合もあります。意思決定者は、費やす時間にかかわらず、これをビジネスの成長のための長期的な投資として扱うべきです。高速でシームレスなナビゲーション体験を提供すれば、ユーザーは喜び、忠実なリピーターになります。プロダクト マネージャーにとって、パフォーマンスは新しいプロダクト機能の質と成功を定義する重要な基準です。また、優れたプロダクトを生み出すことや、やりがいのある課題に取り組むことは、デベロッパーの満足度の向上にもつながります。

ランキング シグナルとしての Core Web Vitals は、パフォーマンスに時間をかけて取り組むもう 1 つの動機となりますが、Core Web Vitals を採用すると、ランキングにとどまらず、さまざまな短期的、長期的メリットが得られます。Core Web Vitals を（ランキングに反映される前に）採用したいくつかのグローバル ブランドやローカル ブランドの事例を確認してみましょう。採用の理由は、Core Web Vitals がユーザー エクスペリエンスに注目しているからです。

ケーススタディ #

Vodafone #

Vodafone（イタリア）は、LCP を 31% 改善することで、売上が 8% 増加しました。

売上が 8% 増加

テクニック #

  • 重要な HTML をサーバー側でレンダリング
  • レンダリングをブロックする JavaScript を削減
  • イメージ最適化テクニック
  • ヒーロー イメージのサイズ変更、重要でないリソースの遅延読み込み

重要な教訓 #

  • 結果の有意義性を測定するには A/B テストが最適
  • A/B はサーバー側で行う

iCook #

iCook は、CLS を 15% 改善することで、広告収入が 10% 増加しました。

広告収入の増加を示すグラフ

テクニック #

  • 広告ユニットのサイズ変化を減らして、UI で固定サイズの広告スロットをあらかじめ割り当てる
  • 広告スクリプト読み込みロジックを最適化してヘッダー入札を優先する、重要でない JS の遅延読み込みをする

重要な教訓 #

フィルレートに影響が出る可能性があるが、広告の視認性が上がるにつれて収益が向上する

Tokopedia #

Tokopedia は、LCP を 55% 改善することで、平均セッション時間が 23% 増加しました。

改善前 3.78 秒、改善後 1.72 秒

テクニック #

  • LCP 要素をサーバー側でレンダリング（SSR）
  • LCP 要素のプリロード
  • イメージ最適化（圧縮、WebP、重要でないイメージの遅延読み込み）

重要な教訓 #

  • パフォーマンス モニタリング ダッシュボードを構築し、すべてのチームの進捗と影響を監視
  • さまざまなレンダリング テクニックの実験（例 : LCP 要素を SSR、スクロールせずに見える範囲を SSR、フル クライアント側 レンダリング）

以上のケーススタディから、ベスト プラクティスを採用してすばやく成果を上げることで、大きな効果が得られることがわかります。この点に関する実例を、さらにいくつか紹介します。

GEDI は CLS を 77% 削減することで直帰率が 8% 減少、Lazada は LCP を 3 分の 1 にすることでモバイルのコンバージョン率が 16.9% 増加、GYAO は LCP 約 3 分の 1 にすることでクリックスルー率が 108% 増加

以上の結果は、以下のようなすぐにたやすく行えることを実施した結果です。

イメージ最適化 JavaScript 最適化 広告と動的コンテンツ
WebP 画像形式の利用 サードパーティ JS の遅延読み込み スクロールせずに見える範囲の広告スペースを予約
イメージ CDN の利用 レンダリングをブロックする未使用 JS の削除 動的コンテンツの高さを設定
圧縮 重要でない JS の遅延読み込み
重要でないイメージの遅延読み込み 重要な JS のプリロード
ヒーロー イメージのプリロード
アスペクト比の指定

その他のベスト プラクティスについては、Web Vitals ガイダンスを参照してください。PageSpeed Insights を使うと、ウェブサイトを監査して即座に実用的な推奨事項を確認できます。

ほかにもいくつものグローバル ブランドが Core Web Vitals に投資して、そのメリットを享受しています。

対応を始めるには #

ステップ 1: 測定を始める #

最初に、フィールド ツールを使ってサイトを計測しましょう。Google を含むプロバイダが、さまざまなツールを公開しています。

Google 製ツール #

  • Search Console
  • PageSpeed Insights
  • web-vitals JS
  • Chrome ユーザー エクスペリエンス レポート

サードパーティ製ツール #

  • Cloudflare
  • New Relic
  • Akamai
  • Calibre
  • WebPageTest
  • Blue Triangle
  • Sentry
  • SpeedCurve

皆さんにとって最適なツールを選択してください。もう一歩踏み込んで Google アナリティクス 4 を組み込むことで、Core Web Vitals とビジネス指標の相関関係を確認することもできます。

ステップ 2: ステークホルダーを説得する #

  • Core Web Vitals を採用してユーザー エクスペリエンスを改善することの重要性と、それが企業のビジネス指標に関連していることを、ステークホルダーに説明する
  • 社内で支援者を募り、小規模な実験を始める
  • すべてのチームで Core Web Vitals を改善するために、すべてのステークホルダーで共通の目標を定める

ステップ 3: 以下のヒントを活用して実装を成功に導く #

  • 優先度 : 有意義な結果につなげるため、トラフィックが高いページやコンバージョンへの影響が大きいページを選択する（広告ランディング ページ、コンバージョン ページ、人気のページなど）
  • A/B テスト : レンダリング コストの発生を避けるためにサーバー側でのテストを利用し、最適化したバージョンと最適化していないバージョンの結果を比較する
  • 監視 : 継続的なモニタリングをし、リグレッションを防ぐ

最後になりますが、Google では、パフォーマンスは目的ではなく過程であると考えています。そのため、注目すべき最新のケーススタディを紹介できるように、今後もこの記事を更新する予定です。ビジネスですばらしい成功を収め、この記事で取り上げてほしい事例がある方は、コンテンツの提案をお送りください。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事はテクニカル プログラム マネージャー、Lutz Vahl による Chromium Blog の記事 "Adjusted timeline for SharedArrayBuffers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今年 2 月、すべてのプラットフォームの Chrome 91 以降で、SharedArrayBuffer や performance.measureUserAgentSpecificMemory() などの API にアクセスするには、クロスオリジン分離が必須になることをお知らせしました。皆さんのフィードバックや報告された問題に基づいて検討した結果、クロスオリジン分離されていないサイトでの SharedArrayBuffer の使用に関するタイムラインを調整し、Chrome 92 で制限することにいたしました。

皆さんのフィードバックは重要です。Google は常に耳を傾けています。

Reviewed by Eiji Kitamura - Developer Relations Team

...
この記事は Devin Chasanoff による Google Ads Developer Blog の記事 "Announcing the New and Improved Interactive Query Builder" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Ads Query Language（GAQL）の新しい改善版インタラクティブ クエリビルダーをリリースします。新しいバージョンはリソース中心型で、FROM 句のリソースを活用して GAQL クエリの作成をサポートします。クエリビルダーには、次の 2 つの方法でアクセスできます。


デベロッパー ドキュメントの [Reports] タブに移動し、ページの左側の [Query Builder] を展開して、リソースを選択します。

または、レポーティング リファレンス ドキュメントで任意のリソースの [Help me build a query] ボタンをクリックします。







ハイライト

ユーザーが新しい検索バーに文字を入力すると、フィールドが動的に絞り込まれます。





このツールは、デベロッパーが Google Ads Query Language を使いながら学習できるように設計されています。クエリビルダーには、動的にヒントが表示されます（フィールドの互換性など）。





プロンプトも表示されます（たとえば、クエリの複数の句にフィールドを追加する際の要件をユーザーに通知するなど）。





新しいクエリビルダーには、クエリを読みやすい形式で表示する "pretty print" モードと、クエリのボックスで直接フィールドを削除したり並び替えたりできる "interactive" モードがあります。





新しいクエリビルダーを使う際は、各ページの右上に表示されている [Send feedback] ボタンをクリックして、遠慮なくフィードバックをお送りください。




ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。

- Devin Chasanoff（Google Ads API チームを代表して）

この記事は Naina Raisinghani（AMP Project、プロダクト マネージャー）による The AMP Blog の記事 "Optimizing your AMP page experience for Core Web Vitals" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Core Web Vitals は、サイトオーナーがウェブサイトのユーザー エクスペリエンスを改善する場所や方法を理解するために役立つ重要な一歩です。Google のページ エクスペリエンス シグナルでも、このような客観的な指標群に注目することを推奨する予定です。これらは、デベロッパーが現在のすばらしいユーザー エクスペリエンスを改善し、維持するために役立つだけではありません。今後もアップデートされていくので、デベロッパーはウェブが満たすべき最新のパフォーマンスについての情報を得ることができます。 

世界中の AMP Project の貢献者のおかげで、サイトオーナーは AMP ページを作成する際に、パフォーマンスに優れた体験の構築に向けて良いスタートを切ることができます。ただし、他の多くのフレームワークと同様に、AMP でもウェブ開発のベスト プラクティスをすべて実装することはできません。このブログ投稿では、AMP ページを確実に最適化するためにデベロッパーが行うべきことについて共有します。この内容は、AMP ページがパブリッシャーのサイトから提供される場合と、AMP キャッシュから提供される場合の両方に適用できます。

AMP ページのパフォーマンスをさらに高め、Core Web Vitals を満たす

AMP の目的は、優れたユーザー エクスペリエンスを簡単に作れるようにすることです。しかし、優れたユーザー エクスペリエンスに不可欠だと AMP チームが確信しているいくつかの開発プラクティスでは、追加の作業が必要になる場合があります。

AMP のトラフィックを理解する

ページの Core Web Vitals 指標は、ウェブページで実際のユーザー インタラクションを測定して算出されます。AMP では、ユーザーがどのようにコンテンツにアクセスしたかによって、パブリッシャーのドメインか AMP キャッシュのどちらかからページが提供されます。多くの場合、AMP へのアクセスの大部分（半分以上）が自分のドメインで発生します。こちらのガイドに従うと、AMP デベロッパーが AMP キャッシュ上とそれ以外での Core Web Vitals 指標を測定できます。

ウェブ開発のベスト プラクティスを導入する

Google の調査によれば、デベロッパーが AMP ページを提供する方法には、まだ最適化の余地があります。主なポイントは以下のとおりです。

  • サーバーの応答時間を改善する : サーバーが遅い、またはエンドユーザーから離れた場所に存在する場合は、ほぼすべてのものが遅くなってしまいます。CDN と同じように、配信は AMP キャッシュによって最適化されますが、ほぼすべての AMP サイトに AMP キャッシュ外のトラフィックが存在します。つまり、優れたユーザー エクスペリエンスを実現するには、高速で応答が速いサーバーが不可欠です。
  • 大きすぎるイメージの使用を控える : サイトでユーザーが期待する速さを実現するには、ユーザーが使っているデバイスのディスプレイよりも大きいイメージは使わないようにします。 
  • フォントによるレイアウトのずれを回避する : レイアウトのずれは、ウェブページの要素が動的に変更され、コンテンツに「ずれ」が発生することによって起こります。ウェブフォントを取得してレンダリングすると、直接的にレイアウトのずれが発生する可能性があります。 現在推奨している方法は、最初のビューポートで利用するすべての重要なフォントについて、フォントのプリロードと font-display: optional を組み合わせることです。このレイアウトのずれはあらゆるウェブページで日常的に起こっているので、標準化団体とともに追加のガイダンスを提供する作業を進めています。
  • data-hero を使ってヒーロー イメージをマークアップする : 多くのウェブページにとって、ヒーロー イメージは重要なパーツです。そのため、ユーザーが期待する速さで読み込む必要があります。<amp-img data-hero src="…"> のようにして data-hero 属性を使ってヒーロー イメージをマークアップすると、AMP Cache と Optimizer がヒーロー イメージを認識して最適化してくれるので、イメージのレンダリング時間が最大 50% 速くなります。

さらに AMP を改善するためのツール

AMP ページで可能な限り充実したユーザー エクスペリエンスを実現するため、すべてのサイトオーナーの皆さんに、ご自身で対応できるさまざまな最適化を追加で実施することを強く推奨します。最も簡単な方法は、最新の AMP Optimizer を使うことです。これにより、AMP の新しいサーバー側最適化をすべて自動で適用できます。また、昨年には、AMP Page Experience Guide（下図）も公開しました。公開以降、アクションにつながるフィードバックが AMP Page Experience Guide にさらに追加され、利便性が高まりました。この取り組みを推進する原動力となっているのは、このツールを使って AMP ページをテストするウェブサイトです。たとえば、カスタム フォントの読み込みに関する推奨事項が表示されるようになったので、LCP と CLS を最適化できます。

AMP Page Experience Guide の結果のスクリーンショット

AMP ページをこれらの基準に適合させるためのアクションにつながる推奨事項が存在しない場合は、お知らせください。直接サポートいたします。次に示すように、リクエストは AMP Page Experience Guide の中から送信できます。または、Github から直接連絡することもできます。

AMP Page Experience Guide から直接 AMP の問題を送信

まとめ

AMP Project は、ユーザー ファーストなオープンウェブを作るというビジョンただ一点に集中しています。AMP Page Experience Guide を使うと、Core Web Vitals に基づく AMP ページのパフォーマンスを確認できます。パブリッシャーのドメインと AMP キャッシュで、推奨された最適化を実施することをお勧めします。

AMP 開発コミュニティや、皆さんのフィードバックに感謝いたします。いつものように、問題や機能リクエストがありましたら遠慮なくお知らせください。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chrome ソフトウェア エンジニア、Gabriel Charette 🤸🏼、Etienne Bergeron 🕵🏻 による Chromium Blog の記事 "Digging for performance gold: finding hidden performance wins" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google は、たくさんの方が日々利用するブラウザとして Chrome を選んでくださっていることをありがたく思っています。Chrome のパフォーマンスを強化する作業に継続的に注力しているのはそのためです。しかし、Chrome のように複雑なソフトウェアでは、通常では積極的に作業しないようなところにまで、たくさんのパフォーマンスが隠されています。速さと好奇心シリーズの最新の投稿では、通常は気づかないパフォーマンスの問題を診断、検出、修正する方法に迫ります。

1%

Google の指標によれば、Chrome は平均すれば速いものの、ときに極端に遅くなることもあります。そのようなユーザーの苦しみは、多くの指標の 99 パーセンタイルを見ればわかりますが、再現できないため、かなり対策が難しい問題です。データを詳しく分析すると、パフォーマンスのロングテールを経験しているのは遅いマシンを使っている 1% のユーザーではなく、多くのユーザーが 1% の確率で経験していることがわかります。

その 1% について考えてみましょう。1% といっても、実際はかなりの数になります。ここで使う中核的な指標は「ジャンク」です。これは、ユーザーが入力してからソフトウェアが反応するまでに明らかな遅延がある状態を指します。Chrome は 30 秒ごとにジャンクを測定します。そのため、あるユーザーの 1% のジャンクのサンプルを集めれば、それは 50 分ごとに 1 回起きているジャンクということになります。そのユーザーはその瞬間、Chrome が遅いと感じます。問題は、ユーザーの環境で Chrome が瞬間的に遅くなることの根本原因を突き止めて修正できるのか、ということです。

アプローチ

私たちエンジニアが習ってきた最適化とは、自分が所有するコンポーネントのアルゴリズムのパフォーマンスを改善することです。しかし、この 3 年間、複雑な Chrome のコードベースを分析してきたことで、実際の問題には複数分野にまたがる原因があることがわかってきました。つまり、関連性のない複数の機能に関するパフォーマンスのロングテール問題には、全体的な共通の根本原因があるということです。局所的な専門性や最適化を適用すると、全体的な最適解が見落とされてしまう可能性が高くなります。最初の直感を捨て、何の前提も設けず、すぐにわかることのさらに奥を探り、わからないことを徹底的に洗い出して、根本原因を見つけなくてはなりません。

見えないバグを追いかける

予測できず、再現性がなく、自分のものではなく、実質的に見ることができないバグを見つけるには、どうすればいいのでしょうか。

まずは、シナリオを決めることです。そのために、ユーザーが認識できるジャンクに注目します。そして Chrome が遅いと感じる瞬間をシステム的に突き止める方法として、ジャンクを実際の環境で測定します。

次に、実用性の高いバグレポートを実際の環境で集めます。そのために、Chrome の BackgroundTracing インフラストラクチャを使って Slow Report と呼ぶものを生成しました。匿名で指標を共有することに同意した一部の Canary ユーザーで、特定のシナリオを調査できる循環バッファ トレースを有効にします。すると、注目する指標があらかじめ設定されたしきい値に達したときに、トレース バッファが取得され、匿名化が行われて Google のサーバーにアップロードされます。

このバグレポートは、次のようなものです。


通常は健全なマシンで、AutocompleteController::UpdateResult() の 2 秒のジャンクを chrome://tracing で表示したもの
犯人がわかりました。AutocompleteController を最適化すればいいのですね。いや、違います。まだ理由がわかっていないのです。何の前提も設けないようにしましょう。

BackgroundTracing をスタック サンプルで補足すると、ストールした AutoComplete イベント内で繰り返し起こっているスタックを見つけることができました。
    RegEnumValueW

    RegEnumValueWStub

    base::win::RegistryValueIterator::Read()

    gfx::`anonymous namespace\'::CachedFontLinkSettings::GetLinkedFonts

    gfx::internal::LinkedFontsIterator::GetLinkedFonts()

    gfx::internal::LinkedFontsIterator::NextFont(gfx::Font *)

    gfx::GetFallbackFonts(gfx::Font const &)

    gfx::RenderTextHarfBuzz::ShapeRuns(...)

    gfx::RenderTextHarfBuzz::ItemizeAndShapeText(...)

    gfx::RenderTextHarfBuzz::EnsureLayoutRunList()

    gfx::RenderTextHarfBuzz::EnsureLayout()

    gfx::RenderTextHarfBuzz::GetStringSizeF()

    gfx::RenderTextHarfBuzz::GetStringSize()

    OmniboxTextView::CalculatePreferredSize()

    OmniboxTextView::ReapplyStyling()

    OmniboxTextView::SetText...)

    OmniboxResultView::Invalidate()

    OmniboxResultView::SetMatch(AutocompleteMatch const &)

    OmniboxPopupContentsView::UpdatePopupAppearance()

    OmniboxPopupModel::OnResultChanged()

    OmniboxEditModel::OnCurrentMatchChanged()

    OmniboxController::OnResultChanged(bool)

    AutocompleteController::UpdateResult(bool,bool)

    AutocompleteController::Start(AutocompleteInput const &)

    (...)


なるほど。オートコンプリートが悪いわけではありません。GetFallbackFonts() を最適化すればいいのですね。でも、待ってください。そもそも、いったいどういうわけで GetFallbackFonts() が呼ばれているのでしょうか。

それを突き止める前に、どうすればこれがパフォーマンスのロングテール問題全体の一番の根本原因だとわかるのでしょうか。とにかく、まだ 1 つのトレースしか見ていないのです ...



測定における難問

指標からは、どのくらいのユーザーが影響を受けているか、どの程度悪い状態なのかはわかります。しかし、根本原因がわかるわけではありません。

Slow Report からは、特定のユーザーの問題はわかりますが、どのくらい多くのユーザーが影響を受けているかはわかりません。また、Slow Report トレースのコーパスを検索することはできますが、これには本質的にバイアスがかかっているので、指標と 1 対 1 で対応することは不可能です。たとえば、Chrome はセッション 1 つにつきパフォーマンス悪化の最初の事例だけをレポートし、対象も Canary/Dev チャンネルのユーザーだけなので、起動と母集団の両方のバイアスがかかっています。

これは測定における難問です。ツールが提供するデータの実用性が高いほど、取得できるシナリオは少なくなり、強いバイアスがかかるようになります。深さをとるか、広さをとるかです。

両方を行おうとするツールはその中間にあたります。その場合、大きなデータセットを集計するので、欠陥のある入力に基づく結果を集計してしまうというリスクがあります（たとえば、注目したい部分が循環バッファ トレースから欠落しており、バイアスがかかった集計になるなど）。


そこで、科学的理論に基づき、最もエンジニアリング的でない選択肢を選びました。つまり、大量の Slow Report のトレースを手動で開くという方法です。これは、すでに定量化できている最重要な問題に対して、最も効果的な手法になりました。

たくさんのトレースを開いた結果、そのほとんどに、なんらかの形で前述のフォントの問題が現れていることがわかりました。影響を受けた厳密なユーザー数はわかりませんが、指標に現れていたユーザーの苦しみの主な原因はこれだと確信するには十分でした。




フォールバック フォント

そもそも GetFallbackFonts() が呼ばれる理由は何なのかを追求しました。先ほどの例の呼び出し元は、あるフォントでレンダリングされる Unicode 文字列のピクセル数を求めようとしていました。

その中のサブ文字列に、指定されたフォントではレンダリングできない Unicode ブロック内の文字がある場合、システムが推奨するフォールバック フォントをリクエストするため、GetFallbackFont() が使われます。それに失敗すると、リンクされているフォントをすべて試してレンダリングに最適なものを決めるため GetFallbackFonts() が呼び出されます。この 2 回目のフォールバックは遅くなります。

GetFallbackFont() が失敗することはないはずですが、実際はそこまで単純ではありません。Windows でこれを確実に行う方法は、DirectWrite に照会することです。しかし、DirectWrite は Chrome がまだ Windows XP をサポートしていたころの Windows 7 で追加されたものでした。そのため、両方のバージョンの OS で動作するように、GetFallbackFont() のロジックで確実性が低い試行錯誤的な Uniscribe+GDI を利用せざるを得ませんでした。それでもほとんどの場合はうまく動作したので、のちに Chrome で Windows XP のサポートが削除されたときも、この処理をクリーンアップできることに誰も気づきませんでした。パフォーマンスのロングテールを調査する新しいツールを使うことで、ジャンクの一番の原因（GetFallbackFonts() の不要な呼び出し）が明らかになったのです。

Google はこれを修正し、GetFallbackFonts() の呼び出し回数を 4 分の 1 に削減しました。


まだゼロではないので、前述の AutoComplete の問題は引き続き Slow Report で確認できます。そのため、調査を続けましょう。DirectWrite の GetFallbackFont() の失敗は予期しないものでしたが、Slow Report は匿名化されているので、ユーザーが生成した文字列はアップロードできません。そのため、どのコードポイントが問題を起こしているのかを突き止めるのは難題です。そこでプライバシーのエキスパートとも相談し、個人を特定できる情報が漏洩しないように、Unicode ブロックとテキスト ブロックのスクリプトを HarfBuzz に通すことにしました。


 

絵文字の物語

この新しい記録が利用できるようになるとともに、Slow Report の次の波がやってきました。大半のレポートでは、DirectWrite に Miscellaneous Symbols and Pictographs（その他の記号とピクトグラフ）内のコードポイント（Unicode 文字）のフォントを見つけるようリクエストしたときに、フォントのフォールバックが失敗していました。ローカルでその Unicode ブロックのすべてのコードポイントを試すスクリプトを書いたところ、問題を起こしていたのは何かがすぐにわかりました。U+1F3FB～U+1F3FF は、Unicode 8.0 で追加された修飾子で、別のコードポイントと組み合わせたときのみ意味を持ちます。たとえば、U+1F9D7（🧗）と U+1F3FF を組み合わせると 🧗🏿 となります。U+1F3FF 自体をレンダリングできるフォントはありません。そのため、フォントのフォールバックに正しいフォントを見つけるよう依頼しても、すべてのリンクされているフォントを調べた後にエラーになるのは正しい動作です。グラフこれはブラウザ側の Unicode セグメンテーション ロジックのバグでした。バグによって 2 つのコードポイントが誤って分割されるため、1 つの書記素としてではなく、別々にレンダリングするように DirectWrite にリクエストしていました。

でも、待ってください。Chrome は最新の Unicode をサポートしているのではなかったでしょうか。確かに、ウェブ コンテンツをレンダリングする Blink はサポートしています。しかし、ブラウザ側のロジックは、絵文字を描画することはないので、最新の絵文字（修飾子付きのもの）をサポートするように更新されてはいませんでした。ブラウザの UI（タブバー、ブックマーク バー、アドレスバーなど）が最新化され、Unicode をサポートするようになったのは、2018 年ごろになってからのことです。そのときから、以前のセグメンテーション ロジックが（見えない）問題になっていました。

そのうえ、キャッシュ ロジックはエラー時にキャッシュを行わないようになっていたので、たくさんのフォントがインストールされたユーザーでは、修飾子を自力でレンダリングしようとするたびに大きなジャンクが起きていました。皮肉なことに、このキャッシュは、ブラウザ UI に初めて Unicode サポートが追加されたとき、誤解されたボトルネックに対処するために追加されたものでした。フォント API のレイヤーでとどまるのではなく、フォントのロジックについて下層の実装に迫り続けたことが、主要なパフォーマンスの問題の修正だけでなく、他の絵文字に関する修正にもつながりました。たとえば、🏳️‍🌈 をコードで表すと、U+1F3F3（🏳️）+U+1F308（🌈）となります。分割ロジックを修正するまで、この書記素はブラウザの UI で 🏳️🌈 と誤ってレンダリングされていました。



そして旅は続く …

Google の旅は、さまざまな Chrome のコンポーネントに迫り続けています。しかしそれは、いつも同じ基本戦術に従っています。それは、何の前提も設けないようにして、予想できず、再現できず、自分のものでもないバグを徹底的に追求することです。スタック ランキングの問題は不可能に近いですが（参照 : 測定の難題）、なんらかのツールで見つけたトップ 5 の問題を修正し、ロングテールに注目すれば、実際のユーザーの苦しみの大半に対処できることになります。

Google はこのアプローチによって、ここ 2 年半の間でユーザーの目に見えるジャンクを 10 分の 1 に減らし、狙いを定めた多くの機能でパフォーマンスのロングテールを改善しました。

30 秒間のサンプルにおいて 100 ミリ秒間隔で無応答になった数の 99 パーセンタイル


すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ。

Reviewed by Eiji Kitamura - Developer Relations Team

...
この記事は Ben Karl による Google Ads Developer Blog の記事 "Upcoming Change to the Enforcement of Temporary IDs with Product Partitions and Listing Groups" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

  2021 年 5 月より、新しく作成された Listing Group（Google Ads API のホテル広告とショッピング広告で使用）と Product Partition（AdWords API のショッピング広告で使用）のすべてのオブジェクトに、一時 ID が一意でなければならないという要件が適用されます。この変更は、すべてのバージョンの AdWords API と Google Ads API に影響します。

一時 ID は、すべての変更リクエスト全体で一意でなければなりません。オブジェクトが異なる Listing Group ツリーや Product Partition ツリーに存在する場合も同様です。

不要な問題を防ぐため、API ユーザーはアプリケーションをアップデートして、個々のリクエストに使用するすべての一時 ID を確実に一意にする必要があります。

以下に、リクエストで一意でない一時 ID を使い続けた場合に予想される動作を示します。

API と変更メソッド 現在の動作 新しい動作
Google Ads API の BatchJobService ユーザーは具体的でないエラーを受け取ります。つまり、問題が一時 ID に関連することがわからない可能性があります。 ユーザーには、MutateError.MUTATE_ERROR_TEMP_ID_ALREADY_EXISTS エラーを含む操作失敗が返されます。
AdWords API の BatchJobService ユーザーは具体的でないエラーを受け取ります。つまり、問題が一時 ID に関連することがわからない可能性があります。 ユーザーには、NewEntityCreationError.DUPLICATE_TEMP_IDS エラーを含む操作失敗が返されます。
Google Ads API の AdGroupCriterionService または GoogleAdsService.Mutate ユーザーはエラーを受け取りません。 ユーザーは MutateError.MUTATE_ERROR_TEMP_ID_ALREADY_EXISTS エラーを受け取ります。
AdWords API の AdGroupCriterionService ユーザーはエラーを受け取りません。 ユーザーは NewEntityCreationError.DUPLICATE_TEMP_IDS エラーを受け取ります。


ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。

- Ben Karl（Google Ads API チーム）

...
この記事は Google Maps Platform チームによる Google Cloud Blog の記事 "Google Maps Platform Announcements from Google I/O 2021" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今回、初めてのバーチャルでの Google I/O デベロッパー カンファレンスが開幕されました。このカンファレンスは、Google の各チームからの発表を世界中の開発者に伝え、共有、視聴していただく場です。この記事では、デベロッパー基調講演で発表された Google Maps Platform に関する最新ニュースを要約してお届けします。


WebGL を利用したマップ機能のベータリリース

クラウドベースのマップのスタイル設定の一部として、ベクトル地図を導入しました。今後数週間以内に JavaScript API 経由で一般提供する予定です。これにより、Google マップのウェブ エクスペリエンスでおなじみの WebGL でアクセラレーションされた高パフォーマンスな地図を、初めてウェブアプリでも利用できるようになります。WebGL は低レベルのブラウザ API であり、クライアント デバイス上の GPU の処理能力とレンダリング能力をブラウザが利用できるようにすることで、複雑な 2D と 3D グラフィックスをウェブ上でレンダリング可能にします。

本日 Maps JavaScript API ベータ版の新機能として、傾斜と回転、そして WebGL Overlay View の 2 つをリリースします。これらはいずれも WebGL を利用した機能です。これらの機能の動作を確認するには、WebGL 機能のガイドツアーおよび Ubilabs の皆さんが構築した WebGL 旅行のデモをご覧ください。


チルトと回転これまで、地図の表示方法は真上から基本地図を見る 2 次元ビューに限定されていました。チルトと回転機能を使用すると、読み込み時と実行時の両方で、67.5 度の傾きと 360 度の回転が可能になり、地図のまったく新しいビューをユーザーに提供できるようになります。これは斜め視点からの 3D の建物モデルが初めてウェブアプリで表示できるようになったということでもあります。

チルトと回転機能が、Maps JavaScript API のベータ版で利用可能になりました。

また、キーボードとマウスによる制御が追加され、ユーザーが地図の傾斜と回転を手動で変更できるようにもなっています。これにより、ウェブアプリでまったく新しいレベルのユーザー操作が可能になります。


WebGL Overlay View

チルトと回転を使用して基本地図を 3 次元で制御できることに興味を引かれる方であれば、WebGL Overlay View も気に入っていただけると思います。これはベクトル地図のレンダリングに使用する WebGL レンダリング表現を背景地図の上に直接重ね合わせて操作できるようにようにするという、まったく新しいマッピング エクスペリエンスの構築方法を提供します。

class google.maps.WebglOverlayView {

  onAdd() {}


  onRemove() {}


  onContextRestored(gl) {}


  onDraw(gl, coordinateTransformer) {}


  onContextLost() {}

}

WebGL Overlay View により、初めて 2 次元と 3 次元のオブジェクトを基本地図に直接レンダリングできるようになりました。つまり、レンダリングされたオブジェクトが地図に表示されるだけでなく、オクルージョンとパースペクティブを備えた 3 次元空間で地図の一部としてレンダリングされます。たとえば、こちらの WebGL Overlay View による 3D マーカーの実装をご覧ください。地図が回転するとマーカーが建物に隠れてビューから非表示になり、カメラから離れるにつれてマーカーが小さくなるのを確認頂けると思います。

WebGL Overlay View（ベータ版）で基本地図に直接レンダリング

使用を開始するには、WebGL の Codelab とドキュメントをご参照ください。Google I/O のセッションに参加できなかった場合は、Travis McPhail のセッション Next generation Maps for the web（ウェブ向けの次世代マップ）で詳細をご覧ください。こちらは、オンデマンドで視聴できます。


JavaScript 向けのクラウドベースのマップスタイル設定が一般提供に

2020 年 6 月にクラウドベースのマップスタイル設定機能のベータ版をリリースしました。これは、Google Cloud Console から地図をカスタマイズ、管理、デプロイできる一連の新機能です。この機能には直感的な UI ベースのスタイル エディタが Cloud コンソール上に導入されており、ズームレベルのカスタマイズから商業地域のカスタム スタイル設定まで、地図の外観と動作を細かくカスタマイズできます。さらに、業界別に最適化されたマップスタイルを導入し、地図の作成後すぐに配信できるようにしました。

このたび、クラウドベースのマップスタイル設定を Maps JavaScript API と Maps Static API で正式に一般提供します。お客様のチーム全体でより良い地図を作成できるように、これまでの 11 か月間、コンソール内のエクスペリエンスと全体のパフォーマンスを改善してまいりました。

クラウドベースのマップスタイル設定を使用して地図のカスタマイズや管理を行います

スウェーデンで業界をリードする不動産プラットフォームである Hemnet のプロダクト チームは、クラウドベースのマップスタイル設定に移行することですでにメリットを得ています。Hemnet のプロダクト マネージャーである Magnus Burell 氏は、次のように述べています。「最近、私たちのチームは、お休み中のお客様に喜んでいただくために、不動産地図のスタイルを一時的に変更しました。クラウドベースのマップスタイル設定によって、このアイデアをすばやく簡単に実現できました。さまざまなマップスタイルに繰り返し手を加えてはプレビューするという作業を数分以内で行い、デプロイしなくてもすぐに公開できました。」

Hemnet は復活祭の際に地図のスタイルを変更しました。

クラウドベースのマップスタイル設定をベータ版でお試しいただいている皆様にお礼を申し上げます。他の Google プロダクトにおけるものも含めて、お客様からのフィードバックは一般提供を開始するうえでたいへん貴重です。カスタム地図によって毎日数千万もの新しい地図表現が配信されていることを大変嬉しく思います。

詳しくは、クラウドベースのマップスタイル設定に関する I/O 2021 セッションをご覧ください。また、Maps JavaScript API や Maps Static API のドキュメントもご確認いただけます。VCCP London がクラウドベースのマップスタイル設定を利用して「Cadbury Worldwide Hide」の仮想イースター エッグ ハントを実現した方法も、ぜひご一読ください。


次のステップ

Google は、今回ご紹介した新機能のレンダリングとパフォーマンスの改善に引き続き取り組んでおり、現実世界と同じくらい豊かなエクスペリエンスを生み出す地図の作成に絶えず努めています。そのためにはお客様のご協力が不可欠です。新しい地図機能を改善できるよう、バグレポート、機能リクエスト、フィードバックを公開バグトラッカーからお寄せくださいますよう、お願いいたします。

16 年ほど前に最初の Google Maps API を提供して以来、地図の概念を覆すお客様のあらゆる手法から刺激をいただいてきました。チルトと回転、WebGL Overlay View、クラウドベースのマップスタイル設定は、新世代のマッピング エクスペリエンスの作成を支援する取り組みの最新の成果です。お客様がどのような素晴らしい地図を作成されるのか、拝見するのを楽しみにしています。

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


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