Webのフロントエンドを構成する技術、特にHTMLやCSS、JavaScript、またそれらに関連する話題を扱うBlogです。

Chrome UX Report APIによるCore Web Vitalsの計測

UI開発者 加藤

Googleが発表した「Core Web Vitals」、すでにその言葉を聞いたことがある方は多いかもしれません。では「Chrome User Experience Report(以下、CrUX)」はご存じでしょうか?

CrUXはBigQueryに保存されているPublic Google BigQuery projectPageSpeed Insightsのデータを組み合わせて、ページごとの定量的な評価をひとまとめにしたビッグデータです。Google Cloud Platform(GCP)のプロジェクトを作成すれば、だれでも、さまざまなサイトのデータを参照できます。

CrUxからは2020年8月現在、Core Web VitalLCPsを構成する3つの指標(LCPCLSFID)にFCPを加えた4つの指標に関するデータを得ることができます。あくまでPageSpeed Insightsで得られた範囲のデータであるという前提のもとですが、CrUXを利用すればCore Web Vitalsとして定義されている指標に関するフィールドデータを計測できるということになります。また、今後は「UX Report」という名の通り、ロード時のパフォーマンスに関する指標だけでなく、UXに関連した指標も今後追加される予定のようです。

CrUXのデータを参照するには4つの方法が存在します。今回はその中から7月に発表されたCrUX APIを使ってデータを参照する方法を紹介します。CrUX APIはRESTfulなAPIですので、指定のURLへリクエストを送ることができれば、あとはお好みの環境で実行することができ、返却されたレスポンスデータをどう使うかも自由にカスタマイズすることができます。BigQueryの操作やSQLに慣れていない方にはおススメです。

※ CrUX APIから得られるデータは直近28日間までとなっています。それよりも過去のデータを参照したい場合はBigQueryを使用しましょう。

Snowpackのapp-template-lit-elementでかんたんWeb Compoments作成

UI開発者 古川

Snowpackはフロントエンド開発環境を構築するためのビルドツールです。

Snowpackには、単体でCreate Snowpack App(CSA)と呼ばれる各開発環境のスターターセットが用意されています。今回はCreate Snowpack Appのひとつであるapp-template-lit-elementを利用して、かんたんなWeb Componentsを作成する手順を紹介します。

これからのWebアニメーションを担うかもしれないWeb Animations API

UI開発者 橋本

今年4月にSafariがWeb Animations APIに対応したことにより、ほぼすべての主要モダンブラウザで使用できるようになりました。
今回はそれを記念して、今後のWebアニメーションを担っていくかもしれないこのAPIを紹介します。

Living Standard機能を取り込むW3C文書プロセスの更新

アクセシビリティ・エンジニア 中村(直)

先月末に公開されたW3C Strategic Highlights - May 2020で取り上げられていますが、2020年でのW3C Process Documentの大規模な更新によって、継続的にW3C技術文書を保守・更新をする新たな仕組みが導入される見込みです。

新たな仕組みが導入される背景として、Webは進化し続けているため、変更の提案やレビューを通して、W3C仕様も継続的に開発し続ける必要があります。しかし、現在のW3C Process Documentでは、仕様がCandidate Recommendation(CR; 勧告候補)に到達した場合、特にRecommendation(REC; 勧告)の場合、仕様の内容を変更することが非常に困難になるため、継続的な仕様の開発を妨げていることが認識されています。

その一方で、HTMLを開発しているWHATWGではLiving Standardという仕様のプロセスで管理されています。これは現在のW3Cのプロセスのように、CRやRECといった特定のステータスを持たないものであり、単一のURLで仕様が更新され続けているものです。

W3Cで公開されている公式の仕様は、w3.org/TRで公開されていますが、これとは別に仕様の編集者が任意のタイミングで発行している非公式のEditor's Draft(ED; 編集者草案)が知られています。W3Cのプロセスにとらわれることなく、頻繁に更新できる一方で、多くの場合W3Cのドメインとは別に公開されています。非公式の文書が、公式の文書よりも優先して参照されているという事態も珍しくありません。

このような状況を打破すべく、現在よりも容易にCRやRECの更新ができるよう、プロセスの改訂が行われます。改訂されるW3C Process Documentにおいて、W3C勧告トラックに関する主な変更点は次のとおりです。

  • 未完成のCRの更新は、CRとしてw3.org/TRに公開できるようになります。これにより仕様を策定しているワーキンググループは、非公式のEditor's Draftに読者を誘導することなく、作業の最新の状態を公開し、公式のコピーでレビューを受けることができます。
  • RECの公開後に発生したエラッタと関連する変更提案は、REC文書のインラインに注釈を付けて、W3Cの承認なしで再発行することができます。これにより、非公式のEditor's Draftや別のエラッタ文書に読者を誘導することなく、ワーキンググループが作業の最新状態を公開し、公式のコピーでレビューを受けることができます。
  • 変更提案のいくつかがRECの一部となるのに十分な成熟度に達し、通常の承認(ディレクターレビュー、ACレビュー)を確保すると、ワーキンググループは、それらを規範的なテキストとして勧告に折り込み、CRやPR(Proposed Recommendation; 勧告案)として中間的に発行することなく、RECを直接再発行することができます。
  • 新しい変更提案の追加と成熟した変更提案の両方のRECへの規範的な組み込みは、段階的に行うことができ、再発行する前にすべてを修正しなくても、徐々に複雑な仕様を改善することができます。
  • エラーを修正する変更提案と同様に、RECへの追加提案は、インラインで注釈を付け、成熟したときに規範とすることができます。これは、新しい機能が許可されていることを明示的に示すRECに限定されます。これにより、この注釈なしで既に公開されているRECに対する機能セットの安定性の期待を壊さないようにします。
  • 特定の客観的な基準を満たすと、CRからRECへの移行とRECからRECへの更新の両方が自動的に承認され、通常の"transition call"(移行コール)をスキップできます。ツールのさらなる開発により、この「ファストパス」の摩擦が軽減される可能性があります。

この変更はあくまで追加的なものです。新たなプロセスは、WHATWG Living Standardのように、CRのステータスを維持したままで再発行し続けることができるようになりますが、従来のW3Cプロセスに従って、CR、PR、RECとステータスを遷移させることもできます。どちらのステータス遷移を選ぶのかは、文書の性質を鑑みて、ワーキンググループが選択することになるでしょう。

詳細の情報については、W3C WikiのProcess2020やGitHubのw3c/w3processから入手することができます。

今回のW3C Process Documentの改訂を進めているのはfantasaiことElika J. Etemad氏とFlorian Rivoal氏ですが、両者ともにCSSワーキンググループで活動している人物です。このプロセスの改訂による、CRのステータスを維持したまま更新され続けるプロセスを取り入れるならば、各CSSモジュール仕様の更新頻度が上がることが予想されます。新プロセス承認後のCSS仕様の更新頻度に注目してみてはいかがでしょうか。

:in-rangeと:out-of-rangeを使ってニムゲームを作る

UI開発者 板垣

突然ですが、みなさんはCSS疑似クラスの種類をいくつくらいご存じですか?
:hover:activeは、ある程度CSSに触れたことある方は、使用された経験があるのではないでしょうか。

では、:in-range:out-of-rangeはどうでしょうか?おそらくあまりなじみのないものだと思います。
今回の記事では、:in-range:out-of-rangeの概要、そしてこれらを使った簡単なゲームをご紹介します。

webpack4でスタイルのみをエントリーし、別ファイルとして出力したときに生成される不要なJavaScriptを削除する方法

UI開発者 古川

webpackを静的サイトジェネレーターとして利用するときなどに、Sassなどのスタイルに関するファイルのみをEntry Pointに設定しCSSファイルとして出力すると、スタイルと同じファイル名のJavaScriptが出力されます。このファイルはwebpackの仕様上どうしても生成されてしまうファイルですが、成果物としては不要なものです。また開発環境にHTML Webpack Pluginを導入していた場合、不要なファイルへのファイルパスが自動的に挿入されてしまいます。

今回は不要なJavaScriptを削除し、HTML Webpack Pluginに自動で挿入される不要なJavaScriptへのパスを削除する方法をご紹介します。

WebpackとWorkboxでらくらくオフライン対応

UI開発者 加藤

昨今の世界的な情勢を受けて、GoogleはWebサイトが常に利用可能であるためのガイダンスを公開しました。「Availability, reliability, resilience, and stability」のセクションでは主にファイルの配信について書かれており、サイトへのトラフィックが増えることによって起こりうる問題に備えるための手法を見ることができます。そのうちの1つがService Workerを利用してオフライン対応をすることです。オフライン対応をするには必要なファイルを適切にキャッシュすることが求められますが、Googleはその手段の1つとしてWorkboxの利用を推奨しています。