Google Developers Japan

Chrome 98 ベータ版: カラーグラデーションベクターフォント、リージョンキャプチャのオリジントライアルなど

2022年1月31日月曜日

この記事は Chromium Blog の記事 "Chrome 98 Beta: Color Gradient Vector Fonts, Region Capture Origin Trial, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent }特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネルリリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 1 月 10 日の時点で Chrome 98 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。 COLRv1 カラーグラデーションベクターフォントこのバージョンの Chrome は、新しく追加されたフォント形式として COLRv1 カラーグラデーションベクターフォントをサポートします。カラーフォントのグリフには複数の色が含まれています。例として、絵文字や国旗、多色文字などが挙げられます。 COLRv1 は COLRv0 フォント形式が進化したもので、ウェブでのカラーフォントの普及を目的としています。COLRv1 フォントは、グラデーション、座標変換、合成などのさまざまな視覚表現に対応しながらも、フォントのサイズはとても小さくなっています。また、COLRv1 フォントは OpenType のバリエーションもサポートしています。フォントのサイズがとても小さいのは、内部形状の再利用とコンパクトなフォント形式定義、効率的な圧縮によるものです。次のイメージは、Noto Color Emoji の例を示しています。これはビットマップフォントでは約 9 MB ですが、COLRv1 ベクターフォントでは 1.85 MB しかありません（WOFF2 圧縮後）。

2 つの国立公園の絵文字。片方は明瞭でもう片方はぼやけている。棒グラフは、ビットマップフォントと COLRv1 フォントの Noto Emoji のバイナリサイズ（約 9MB と 1.85MB）を比較している。

明瞭な COLRv1 ベクターフォント（左）と、ビットマップフォント（右）の比較。
WOFF2 圧縮後のビットマップフォントと COLRv1 フォントとしての Noto Emoji のフォントサイズ。

詳細については、Chrome 98 の COLRv1 カラーグラデーションベクターフォントをご覧ください。3 桁のバージョン番号に対する準備今年中に Chrome のバージョン 100 がリリースされ、ユーザーエージェント文字列で報告されるバージョン番号の桁数が増える予定です。サイトオーナーが新しい文字列をテストしやすくするために、Chrome 96 では、Chrome のユーザーエージェント文字列として「100」が返されるようにするランタイムフラグが導入されました。この新しいフラグ chrome://flags/#force-major-version-to-100 は、Chrome 96 以降で利用できます。詳細については、Chrome の User-Agent 文字列のメジャーバージョンを強制的に 100 にするをご覧ください。オリジントライアルこのバージョンの Chrome には、以下のオリジントライアルが導入されています。オリジントライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジントライアルに登録するには、Chrome オリジントライアルダッシュボードをご覧ください。Chrome のオリジントライアルの詳細については、ウェブデベロッパーのためのオリジントライアルガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジントライアルを行っています。詳細については、Microsoft Edge オリジントライアルデベロッパーコンソールをご覧ください。新しいオリジントライアルリージョンキャプチャリージョンキャプチャは、自分でキャプチャした動画トラックをクロップするための API です。現在、アプリケーションは、preferCurrentTab の指定の有無にかかわらず、getDisplayMedia() を使ってアプリケーション自体が実行されているタブをキャプチャできます。その際、（通常はリモートに共有する前に）結果の動画トラックをクロップし、コンテンツの一部を削除する場合があります。今回のリリースに追加されたその他の機能contain-intrinsic-size に auto キーワードを追加contain-intrinsic-size に auto キーワードのサポートが追加され、ウェブサイトで最後に記憶した要素のサイズ（存在する場合）が利用できるようになります。これにより、content-visibility: auto が指定された要素よりもユーザーエクスペリエンスが向上します。この機能がない場合、ウェブデベロッパーは要素がレンダリングされるサイズを推定しなければなりません。この機能と content-visibility: auto を併用すると、要素が飛び回る可能性があります。AudioContext.outputLatency新しい AudioContext.outputLatency プロパティは、オーディオ出力のレイテンシを秒単位で推定します。厳密に言えば、これはユーザーエージェントがホストシステムにバッファリングをリクエストした時間から、オーディオ出力デバイスがバッファ内の最初のサンプルを処理した時間までの間隔です。スピーカーやヘッドフォンなど、音響シグナルを生成するデバイスの場合、後者の時間はサンプルのサウンドが生成された時間です。Firefox では、すでにこの機能が実装されています。CSS の色調整 : color-scheme の 'only' キーワードcolor-scheme の仕様に再追加された only キーワードが Chrome でサポートされるようになりました。これにより、特定の単一要素で color-scheme を無効化できるようになります。たとえば、強制的なダーク化を無効化できます。いくつかの例で使い方を示します。

div { color-scheme: light } これは、div 要素の color-scheme を強制的にダーク以外にします。

div { color-scheme: only light } これは、上の例と同じく、要素の color-scheme をライトに保ち、ユーザーエージェントによる強制ダーク化を無効にします。document.adoptedStyleSheets の変更が可能に仕様に従い、document.adoptedStyleSheets プロパティの変更が可能になります。これにより、push() や pop() などの操作ができるようになります。これまでの adoptedStyleSheets の実装は扱いにくく、たとえばシートを追加する場合、配列全体を代入し直さなければなりませんでした。

document.adoptedStyleSheets = [...adoptedStyleSheets, newSheet];

新しい実装では、同じ操作を次のように行うことができます。document.adoptedStyleSheets.push(newSheet); ハイダイナミックレンジカラーのメディアクエリChrome で CSS メディアクエリ 'dynamic-range' と 'video-dynamic-range' がサポートされ、現在のディスプレイデバイスの HDR サポート状況を検出できるようになります。有効な値は、'standard' と 'high' です。このクエリを使うと、ページで CSS ルールを切り替えたり、Window.matchMedia() を使って変更に対応したりできます。ポップアップ、タブ、ウィンドウのための新たな window.open() の動作仕様の更新に伴い、このバージョンの Chrome では window.open() で新しいウィンドウやタブを開くかどうかを指定できるようになります。次の例に新しい構文を示します。1 つ目は、ポップアップウィンドウを開きます。2 つ目は、新しいタブまたはウィンドウを開きます。

const popup = window.open('_blank','','popup=1');



const tab = window.open('_blank','','popup=0');

また、window.statusbar.visible が正しい値を返すようになります。具体的には、ポップアップでは false を、タブやウィンドウでは true を返します。Private Network Access なサブリソースに Preflight リクエストサブリソースに対するプライベートネットワークリクエストの前に CORS Preflight リクエストが送られ、対象サーバーから明示的なパーミッションを求めるようになります。プライベートネットワークリクエストとは、パブリックなウェブサイトからプライベート IP アドレスや localhost へのリクエスト、またはプライベートなウェブサイト（イントラネットなど）から localhost へのリクエストを指します。プリフライトリクエストを送ることで、ルーターなどのプライベートネットワークデバイスに対する Cross-Site Request Forgery (CSRF) 攻撃のリスクを緩和できます。多くの場合、プライベートネットワークデバイスはこのような脅威から保護されていません。window と worker の structuredClone() メソッドwindow と worker が、オブジェクトをディープコピーする structuredClone() メソッドをサポートします。ディープコピーでは、オブジェクトのプロパティがコピーされますが、その際に別のオブジェクトへの参照を見つけると、自身を再帰的に呼び出してそのオブジェクトもコピーします。これにより、2 つのコードで意図せずにオブジェクトが共有され、知らない間にお互いの状態を変更してしまうことがなくなります。ディープコピーの説明や使い方については、structuredClone による JavaScript のディープコピーをご覧ください。WebAuthn minPinLength 拡張機能Chrome で、Web Authentication を通して CTAP 2.1 minPinLength 拡張機能が公開されるようになります。これにより、あらかじめセキュリティキーが構成されているサイトで、認証システムに設定された最小 PIN 長を知ることができるようになります。インストールした PC ウェブアプリ向けのウィンドウコントロールオーバーレイインストールした PC ウェブアプリでウィンドウコントロールオーバーレイが有効になっている場合、アプリのクライアント領域が拡張され、タイトルバー領域を含むウィンドウ全体を覆います。そのため、ウィンドウコントロールボタン（閉じる、最大化 / 復元、最小化）はクライアント領域の上に重なって表示されます。ウェブデベロッパーは、ウィンドウコントロールオーバーレイを除くウィンドウ全体の描画と入力ハンドリングをする必要があります。この機能を使うと、デベロッパーはインストールされた PC ウェブアプリを OS のアプリのように見せることができます。WritableStream コントローラーの AbortSignalWritableStreamDefaultController が signal プロパティをサポートします。このプロパティは、必要に応じて WritableStream 操作を停止できる AbortSignal のインスタンスを返します。ストリーム API では、データストリームの作成、構成、使用のためのユビキタスで相互運用可能なプリミティブが提供されます。この変更により、ライターからのリクエストがあったときに、下層のシンクが継続中の書き込み操作を即座に中断したりクローズしたりできるようになります。これまでは、writer.abort() が呼び出されても、時間がかかる書き込み操作が完了してからでないとストリームを中断できませんでした。この変更により、書き込みを即座に中断できるようになります。この機能は、JavaScript で作成したストリームだけでなく、プラットフォームが提供する WebTransport などのストリームでも利用できます。サポートの終了と機能の削除このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。WebRTC での SDES 鍵交換の削除 2013 年以降、WebRTC の SDES 鍵交換メカニズムは、関連する IETF 標準で使用禁止と宣言されています。昨年には、Chrome での使用も大幅に減少しました。SDES が削除されるのは、これがセキュリティの問題になっているためです。Javascript にセッションキーが公開されるので、ネゴシエーションの交換にアクセスできるエンティティや Javascript を侵害できるエンティティが、その接続で送信されるメディアを復号化できることになります。Eiji Kitamura - Developer Relations Team

注意: フィードのサポートと提供の終了について

2022年1月28日金曜日

この記事は Nick Birine による Google Ads Developer Blog の記事 "Warning: deprecation and sunset of Feeds" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
以前お知らせしたように、フィードをアセットに移行する作業を行っており、アカウントの自動移行も始まっています。まだ以前のフィードをお使いの方は、やがて API 呼び出しが失敗するようになります。なるべく早めにアセットに移行してください。

現在のステータスと自動移行に関する主な日付は、下記の表をご参照ください。

フィードのタイプ	サブタイプ	ステータス	自動移行の日付
拡張機能	プロモーション	自動移行を実施中	2021 年 10 月 20 日 *
拡張機能	コールアウトサイトリンク構造化スニペット	自動移行を実施中	2021 年 10 月 20 日 *
拡張機能	アプリコールホテルコールアウト価格	サポート終了	2022 年 2 月 15 日
拡張機能	イメージ	2022 年半ばごろに移行準備が整う予定	2022 年 9 月
動的検索広告	ページフィード	サポート終了	2022 年 4 月 27 日
動的リマーケティング	教育	サポート終了	2022 年 4 月 27 日
動的リマーケティング	カスタムフライトホテル不動産旅行地域求人	2022 年 4 月にサポート終了予定	2022 年 10 月 5 日

* 2022 年 1 月 10 日まで延期

イメージ拡張機能は 2022 年 2 月に移行される予定ではなかったでしょうか？
当初の計画ではそうでしたが、イメージ拡張機能の移行は 2022 年 9 月に延期されています。

移行までに、何をする必要がありますか？
できる限り早急に新しいアセットタイプをサポートする必要があります。

フィード ID からアセット ID への移行をトレースするには、手動で移行する必要があります。自動移行によってこの関係を取得する方法はありません。

詳しくは、以下の移行ガイドをご覧ください。

自動移行が行われるとどうなりますか？
移行されたアカウントでは、フィードベースのエンティティに対する変更呼び出しが拒否されます。以前のフィードベースのエンティティに対する統計情報のレポート機能は、近いうちに削除される予定です。前述の移行ガイドで説明されているように、アセットを対象とした同等のレポートデータが提供される予定です。

自動移行からオプトアウトすることはできますか？
できません。初回の自動移行はオプトアウトを提供しましたが、今後の移行にてオプトアウトはご利用いただけません。

ご不明な点などございましたら、フォーラムよりお問合せください。

Nick Birine（Google Ads API チーム）

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

Google Ads API のシミュレーションと AdWords API の入札状況の変更予定について

2022年1月28日金曜日

この記事は Anash P. Oommen による Google Ads Developer Blog の記事 "Upcoming changes to Simulations in the Google Ads API and Bid Landscapes in the AdWords API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。現在、Google Ads API と AdWords API で、SimulationModificationMethod = DEFAULT の広告グループのシミュレーション計算方法を変更する作業を行っています。変更事項優先されるキーワードの入札単価がある広告グループに対しては、広告グループのデフォルト入札単価のさまざまな値ごとに異なる推定トラフィックを提供します。現在は、優先される入札単価があるすべてのキーワードが、この推定値から除外されます。そのため、推定トラフィックが予想より少なくなります。 2022 年 1 月 17 日の週より、広告グループのシミュレーション計算方法を変更し、デフォルト入札を使っているキーワードと、優先される入札があるキーワードの両方の推定を含めるようにしました。さらに、シミュレーションにおいて、広告グループのデフォルト入札のみが変わり、優先されるキーワード入札はすべて同じであると仮定します。この内容は、Google Ads API の AdGroupSimulationService サービスに含まれる GetAdGroupSimulation メソッドや、AdWords API の DataService サービスに含まれる getAdGroupBidLandscape メソッドや queryAdGroupBidLandscape メソッドが返すシミュレーションに影響する可能性があります。必要な対応この機能をお使いの方は、上記のメソッドが返す結果が変わってもコードが引き続き機能することを確認することをお勧めします。質問がある方は、Google Ads API フォーラムでお知らせください。 お知らせ : Google Ads（AdWords）API のフィードバックをお送りください。2021 AdWords API と Google Ads API 年次アンケートへの回答をお願いします。
Thanet Knack Praneenararat - Ads Developer Relations Team

スマートショッピングキャンペーンの共有予算について

2022年1月27日木曜日

この記事は David Wihl による Google Ads Developer Blog の記事 "Shared budget for Smart Shopping Campaigns" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2022 年 2 月 15 日より、すべての（既存と今後の）スマートショッピングキャンペーン（SSC）で、共有予算タイプが使われるようになります。共有と言っても、設定サれた予算は SSC のみで使用され、共有でない標準のキャンペーン予算と同じように動作します。共有予算に新規キャンペーンを追加することはできません。この変更によってキャンペーンのパフォーマンスが影響を受けることはありません。レポートとクエリでは、既存と今後の SSC 予算は explicitly_shared = true（AdWords API では isExplicitlyShared）として返されます。
注 : AdWords API は、2022 年 4 月 27 日に提供終了となる予定です。デベロッパーの皆さんは、それまでに Google Ads API に移行する必要があります。

ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

Google for Startups Accelerator Class 4 に参加するスタートアップ 8 社を発表

2022年1月25日火曜日

Google は、2 月 21 日より、社会課題をテクノロジーで解決に導くスタートアップを対象とした 3 か月集中型のプログラム「Google for Startups Accelerator Class 4」を実施します。このプログラムは Google による技術、組織運営など幅広い分野にわたるトレーニングや個別のメンターシップを提供し、参加企業のさらなる成長を支援します。昨年 9 月より募集を開始し、多くの素晴らしい目標を持ったスタートアップにご応募を頂き、厳正な選考の結果、本プログラムに下記 8 社のスタートアップが参加します。

参加企業一覧（アルファベット順）CogSmart : 頭部 MRI 画像などを利用した脳健康測定、BrainSuite プログラムを通じて、「認知症にならない健康脳づくり」「生涯健康脳」の社会的な普及を目指しているヘルスケアサービス (Healthcare / Brain)Hubble : 契約書の管理・共有をスマートにするリーガルテック SaaS (Legal Tech)Latona : IoT やエッジコンピューティングの技術を使ったビジネスプラットフォームを開発し、企業に提供することで、ワークプロセスの自動化・生産性の向上を目指しているサービス (AI, ML) NearMe : タクシーをシェアしてお得にドアツードア移動できる「相乗り」サービス。NearMe（ニアミー）は、独自の AI によりルーティングを最適化したスマートシャトルなどを展開し、リアルタイムの位置情報を活用して地域活性化に貢献する “瞬間マッチング” プラットフォーム作りを目指している。(Mobility as a Service, Sharing Economy)PocketMarche : 全国の農家・漁師と直接やり取りしながら旬の食材を購入できる産直アプリ。生産者や地域と継続してつながるふるさと納税サービス。(EC, Marketplace)Study Valley : 来年度から必修化される探究学習を効率的に行えるようにし、また社会との接点を創出する学習プラットフォーム (Ed Tech)Tutorial : PC 端末にインストールせず、いつでもどこでも利用できる、クラウド型 RPA Robotic Crowd を提供 (Robotics)unerry : 月 200 億件超の位置情報ビッグデータを扱う AI プラットフォームを開発・運営 (Geo Location AI)
今後の流れ今後 3 か月に渡って、社会課題解決に特化したセッションをはじめ、機械学習などのテクノロジーに関するセッション、世界の外部メンターや Google 社員によるオンラインメンタリングなどを提供していきます。プログラムについての詳細は、Google for Startups のページをご参照ください。

Posted by Reisa Matsuda and Takuo Suzuki - Developer Relations Team

Windows 版 Chrome のパフォーマンス改善とネイティブウィンドウオクルージョンの導入

2022年1月17日月曜日

この記事は Chrome デベロッパー、David Bienvenu による Chromium Blog の記事 "Chrome on Windows performance improvements and the journey of Native Window Occlusion" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 code { background-color: transparent }

ブラウザをタブグループで整理している方でも、ウィンドウに名前を付けている方でも、タブ検索やその他の方法を使っている方でも、目的のタブにたどり着くためにたくさんの機能を使うことができます。速さと好奇心の今回の投稿では、どのウィンドウが表示されているかを利用してどのように Chrome を最適化したかについて説明します。その結果、起動が 25.8% 速くなり、クラッシュは 4.5% 減少しました。背景[1]レンダリングネイティブウィンドウオクルージョンの計算z-order

オクルージョンの計算

理論的には、どのウィンドウがオクルージョン対象かを判断するのは簡単です。しかし実際には、マルチモニタ環境、仮想デスクトップ、透過ウィンドウ、クロークされたウィンドウなど、複雑な要素がたくさん存在します。この点には、慎重に対処しなければなりません。実際にユーザーに表示されているウィンドウをオクルージョン対象と判断してしまうと、ウェブコンテンツが表示されるはずの場所が白くなってしまうからです。また、オクルージョンの計算をしている間に UI スレッドをブロックすることは、Chrome の応答性とユーザーエクスペリエンスが悪化する可能性があるため、避けなければなりません。そこで、次のようにして別のスレッドでオクルージョンの計算をしています。

最小化されたウィンドウは表示されないので、無視する。
別の仮想デスクトップ上にある Chrome ウィンドウはオクルージョン対象とマークする。
ディスプレイのモニターを組み合わせた仮想画面の矩形を計算する。これがオクルージョンされていない画面の矩形になります。
デスクトップで開いているウィンドウについて、前から後の順番に反復処理を行う。見えないウィンドウ、透明なウィンドウ、フローティングウィンドウ（スタイルが WS_EX_TOOLBAR であるウィンドウ）、クロークされたウィンドウ、他の仮想デスクトップのウィンドウ、非矩形ウィンドウ [2] などは無視する。重要な点として、このようなウィンドウを無視すると、オクルージョン対象のウィンドウの一部が表示されているものと見なされる（偽陰性）可能性がありますが、表示されているウィンドウがオクルージョン対象と見なされる（偽陽性）ことはありません。各ウィンドウについて以下を行います。

オクルージョンされていない画面の矩形から対象のウィンドウの領域を引く。
対象のウィンドウが Chrome ウィンドウである場合は、その領域がオクルージョンされていない領域と重なっているかどうかを確認する。重なっていない場合、その Chrome ウィンドウは前にあるウィンドウによって完全に覆われているため、オクルージョン対象になります。

すべての Chrome ウィンドウの計算が終わるまで繰り返す。
この時点で、オクルージョン対象とマークされていない Chrome ウィンドウは表示されていることになり、オクルージョンの計算は終了する。ここで、UI スレッドにタスクをポストし、Chrome ウィンドウの表示状態を更新します。
この操作は、すべて同期ロックを使わずに行われるので、オクルージョンの計算は UI スレッドに最低限の影響しか与えない。たとえば、UI スレッドをブロックしてユーザーエクスペリエンスを悪化させることはありません。

実装についてさらに詳しく知りたい方は、ドキュメントをご覧ください。

オクルージョンの計算タイミングの決定

オクルージョンの計算をし続けると、Chrome のパフォーマンスが低下することになるので、それは避けたいことです。つまり、ウィンドウが表示対象またはオクルージョン対象になるタイミングを検知する必要があります。ありがたいことに Windows では、ウィンドウの移動、リサイズ、最大化、最小化などのさまざまなシステムイベントをトラッキングできます。オクルージョン計算スレッドは、これらのイベントを追跡したいことを Windows に伝えます。そしてイベントが通知されると、イベントを精査して新たにオクルージョン計算を行うかどうかを決定します。非常に短い時間内に複数のイベントを受け取る可能性があるため、オクルージョンの計算は 16 ミリ秒に 1 回を超える頻度では行いません。この時間は、フレームレートが 1 秒あたり 60 フレーム（fps）である場合に 1 フレームが表示される時間に対応します。

リッスンするイベントは、ウィンドウのアクティブ化や非アクティブ化、ウィンドウの移動やリサイズ、ユーザーの画面ロックやロック解除、モニターの電源オフなどです。オクルージョンの計算は必要以上に行いたくありませんが、ウィンドウが表示されるイベントを見逃すわけにはいきません。見逃してしまうと、ウェブコンテンツが表示されるはずの場所が白くなってしまうからです。これは絶妙なバランスです [3]。

リッスンするイベントは、Chrome ウィンドウがオクルージョンされるかどうかに関わるものです。たとえば、マウスを動かすとたくさんのイベントが発生し、カーソルも点滅するたびにイベントを発行しています。そういったイベントはウィンドウオブジェクトとは関係ないので、無視します。また、ツールチップの表示によってオクルージョンの計算がトリガーされることはないので、大半のポップアップウィンドウのイベントも無視します。

オクルージョンスレッドは、さまざまな Windows イベントを検知したいことを Windows に伝えます。UI スレッドは、主要な状態変化（モニターの電源オフ、ユーザーによる画面ロック）が発生した場合にそれを検知したいことを Windows に伝えます。

結果

この機能は、効果を測定する実験と合わせて開発され、2020 年 10 月に M86 リリースの一部としてすべての Chrome Windows ユーザーにロールアウトされました。指標から、この機能をオンにした場合にパフォーマンスが大幅に改善されることがわかります。

起動時間が 8.5% から 25.8% 短縮
GPU メモリ使用量を 3.1% 削減
レンダラー全体の描画フレーム数を 20.4% 削減
レンダラーのクラッシュが発生したクライアントが 4.5% 減少
First Input Delay（初回入力までの遅延時間）が 3.0% 向上
First Contentful Paint（視覚コンテンツの初期表示時間）と Largest Contentful Paint（最大視覚コンテンツの表示時間）が 6.7% 向上

起動時間と初回入力までの遅延時間が改善したのは、Chrome が起動時に 2 つ以上の全画面ウィンドウを復元する場合、いずれかのウィンドウがオクルージョンされる可能性が高いためです。Chrome はそのウィンドウに関する大半の作業を省略できるので、より重要なフォアグラウンドウィンドウのためにリソースを節約できます。

すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ。 [1] 音声や動画を再生しているタブなど、一部のタブは優先度が下がりません。[2] 非矩形ウィンドウの計算は複雑です。これはあまり使われないと考えられていましたが、Windows 7 のデフォルトテーマの特性上、Windows 7 では一般的に使われています。 [3] 最初にこれをリリースしたとき、Citrix で別のユーザーが画面をロックすると、Windows が現在のセッションではないセッションの変化通知を送信してくるため、白いウィンドウが表示されることがすぐにわかりました。詳細はこちらをご覧ください。Eiji Kitamura - Developer Relations Team

Bento のご紹介

2022年1月14日金曜日

この記事は Bento エンジニアリング、Alan Orozco による The AMP Blog の記事 "Introducing Bento" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent } Bento コンポーネントライブラリを公開

AMP コミュニティから特に多く寄せられている要望の 1 つは、AMP の高パフォーマンスなコンポーネントを AMP 以外のページでも利用できるようにすることです。この度、Bento コンポーネントの第 1 ラウンドが完全リリースされたことをお知らせします。Bento コンポーネントは、高パフォーマンス、高ユーザーエクスペリエンスのコンポーネントで、ウェブデベロッパーがページに機能を追加して優れたユーザーエクスペリエンスを実現する際に、直面する現実的な問題を解消できるようになっています。ぜひ試してみて、フィードバックをお送りください。Bento の詳細は、新しい Bento ブログで確認できます。あらゆる場所で AMP コンポーネントを使うAMP Project の目的は、常にユーザーファーストな体験を作れるようにデベロッパーをサポートすることです。この価値提案の中核にあるのは、高パフォーマンスでユーザー中心の AMP コンポーネントです。そこに Bento が加わり、これまで AMP でしか使えなかった高パフォーマンスな Web Component をお気に入りのフレームワークや CMS で使えるようになります。たとえば、非 AMP ページにカルーセルを追加するなど、1 度限りのケースに Bento コンポーネントを使うことができます。また、AMP に注目し、徐々にページを有効な AMP に変換しようと考えているデベロッパーにも便利です。 Bento と AMP の今後の方向性 AMP は今後も、すぐに使えるソリューションをウェブサイトに提供し、ウェブページで優れたユーザーエクスペリエンスを実現し続けます。また、AMP Project では、AMP 形式のサポートと強化を継続します。同時に、ウェブサイトのパブリッシャーには、AMP と互換性のないサイトで機能を使いたいというニーズもあることも理解しています。そういったパブリッシャーは、サイトで Bento コンポーネントを使い、他の機能に妥協することなく、具体的な UX の課題に対処できるようになります。私たちが思い描いているのは、パブリッシャーが自由に AMP を活用して優れたユーザーエクスペリエンスを実現したり、Bento を使って個々のパフォーマンスの問題に対処したり、AMP や Bento の助けを借りることなくページエクスペリエンスの目標を達成したりできる未来です。 今すぐ Bento をお試しください！Bento コンポーネントを試してみたい方は、スタートガイドをご覧ください。チームは、GitHub や Slack チャンネルからフィードバックを送ることを推奨しています。フィードバックは大歓迎です。ぜひご協力ください。質問や問題がある方も、遠慮なくご連絡ください。Eiji Kitamura - Developer Relations Team

Chrome 98 ベータ版: カラーグラデーションベクターフォント、リージョンキャプチャのオリジントライアルなど

注意: フィードのサポートと提供の終了について

Google Ads API のシミュレーションと AdWords API の入札状況の変更予定について

スマートショッピングキャンペーンの共有予算について

Google for Startups Accelerator Class 4 に参加するスタートアップ 8 社を発表

Windows 版 Chrome のパフォーマンス改善とネイティブウィンドウオクルージョンの導入

Bento のご紹介

ラベル

ブログアーカイブ

Feed

Chrome 98 ベータ版: カラー グラデーション ベクター フォント、リージョン キャプチャのオリジン トライアルなど

注意: フィードのサポートと提供の終了について

Google Ads API のシミュレーションと AdWords API の入札状況の変更予定について

スマート ショッピング キャンペーンの共有予算について

Google for Startups Accelerator Class 4 に参加するスタートアップ 8 社を発表

Windows 版 Chrome のパフォーマンス改善とネイティブ ウィンドウ オクルージョンの導入

Bento のご紹介

ラベル

ブログ アーカイブ

Feed

Chrome 98 ベータ版: カラーグラデーションベクターフォント、リージョンキャプチャのオリジントライアルなど

スマートショッピングキャンペーンの共有予算について

Windows 版 Chrome のパフォーマンス改善とネイティブウィンドウオクルージョンの導入

ブログアーカイブ