JavaScript

序章

JavaScriptはウェブ上で、対話可能で複雑な体験を構築することを可能にするスクリプト言語です。これには、ユーザーの会話への応答、ページ上の動的コンテンツの更新などが含まれます。イベントが発生したときにウェブページがどのように振る舞うべきかに関係するものはすべて、JavaScriptが使用されています。

言語の仕様自体は、世界中の開発者が利用している多くのコミュニティビルドのライブラリやフレームワークとともに、1995年に言語が作成されて以来、変化と進化を続けてきました。JavaScriptの実装やインタプリタも進歩を続けており、ブラウザだけでなく多くの環境で利用できるようになっています。

HTTP Archivehttps://httparchive.org/は毎月数百万ページhttps://httparchive.org/reports/state-of-the-web#numUrlsをクロールし、WebPageTesthttps://webpagetest.org/ のプライベートインスタンスを通して実行し、各ページのキー情報を保存しています（これについての詳細は方法論 で学べます）。JavaScriptのコンテキストでは、HTTP Archiveはウェブ全体の言語の使用法に関する広範な情報を提供しています。この章では、これらの傾向の多くを集約して分析します。

どのくらいのJavaScriptを使っているのか？

JavaScriptは、私たちがブラウザに送るリソースの中で最もコストのかかるものでダウンロード、解析、コンパイル、そして最終的に実行されなければなりません。ブラウザはスクリプトの解析とコンパイルにかかる時間を大幅に短縮しましたが、WebページでJavaScriptが処理される際には、ダウンロードと実行が最もコストのかかる段階になっていますhttps://v8.dev/blog/cost-of-javascript-2019。

ブラウザに小さなJavaScriptのバンドルを送ることは、ダウンロード時間を短縮し、ひいてはページパフォーマンスを向上させるための最良の方法です。しかし、実際にどのくらいのJavaScriptを使っているのでしょうか？

図1.1の説明を表示

10パーセンタイルで70バイト、25パーセンタイルで174バイト、50パーセンタイルで373バイト、75パーセンタイルで693バイト、90パーセンタイルで1,093バイトのJavaScriptを使用していることを示す棒グラフ

上の図1.1を見ると、JavaScriptを373KB使用しているのは、50パーセンタイル（中央値）であることがわかります。つまり、全サイトの50％がこれだけのJavaScriptをユーザーに提供していることになります。

この数字を見ると、これはJavaScriptの使いすぎではないかと思うのは当然のことです。しかし、ページのパフォーマンスに関しては、その影響はネットワーク接続や使用するデバイスに完全に依存します。モバイルクライアントとデスクトップクライアントを比較した場合、どのくらいのJavaScriptを提供しているのでしょうか？

図1.2の説明を表示

デスクトップとモバイルでそれぞれ10パーセンタイルで76バイト/65バイトのJavaScriptを使用していることを示す棒グラフで、25パーセンタイルで186/164バイト、50パーセンタイルで391/359バイト、75パーセンタイルで721/668バイト、90パーセンタイルで1,131/1,060バイトとなっています。

どのパーセンタイルでも、モバイルよりもデスクトップデバイスに送信するJavaScriptの数がわずかに多くなっています。

処理時間

解析とコンパイルが行われた後、ブラウザによって取得されたJavaScriptは、利用する前に処理（または実行）される必要があります。デバイスは様々であり、その計算能力はページ上でのJavaScriptの処理速度に大きく影響します。ウェブ上での現在の処理時間は？

V8のメインスレッドの処理時間を異なるパーセンタイルで分析すると、アイデアを得ることができます。

図1.3の説明を表示

処理時間をデスクトップとモバイルでそれぞれ10パーセンタイルで141ms/377ms、25パーセンタイルで352/988ms、50パーセンタイルで849/2,437ms、75パーセンタイルで1,850/5,518ms、90パーセンタイルで3,543/10,735msとした棒グラフ。

すべてのパーセンタイルにおいて、処理時間はデスクトップよりもモバイルの方が長くなっています。メインスレッドの合計時間の中央値はデスクトップでは849msであるのに対し、モバイルでは2,437msと大きくなっています。

このデータはモバイルデバイスがJavaScriptを処理するのにかかる時間が、より強力なデスクトップマシンに比べてどれだけ長いかを示していますが、モバイルデバイスは計算能力の点でも違いがあります。次の表は、1つのWebページの処理時間がモバイルデバイスのクラスによって大きく異なることを示しています。

図1.4の説明を表示

3つの異なるデバイスを示す棒グラフ: 上部のPixel3は、メインスレッドとワーカースレッドの両方で400ms未満と量が少ないです。Moto G4の場合、メインスレッドで約900ms、ワーカースレッドでさらに300msです。そして最後のバーはAlcatel 1X 5059Dで、メインスレッドで2,000ms以上、ワーカースレッドで500ms以上となっています。

リクエスト数

Webページで使用されているJavaScriptの量を分析しようとする場合、1つの方法として、送信されたリクエスト数を調べる価値があります。HTTP/2では、複数の小さなチャンクを送信することで、より大きなモノリシックなバンドルを送信するよりもページの負荷を改善できます。また、デバイスクライアント別に分解してみると、どのくらいのリクエストがフェッチされているのでしょうか。

図1.5の説明を表示

10パーセンタイルではデスクトップとモバイルそれぞれ4/4のリクエストを示す棒グラフ、25パーセンタイルでは10/9、50パーセンタイルでは19/18、75パーセンタイルでは33/32、90パーセンタイルでは53/52が使用されています。

中央値では、デスクトップ用に19件、モバイル用に18件のリクエストが送信されています。

ファーストパーティ対サードパーティ

これまでに分析した結果のうち、全体のサイズとリクエスト数が考慮されていました。しかし、大多数のウェブサイトでは、取得して使用しているJavaScriptコードのかなりの部分がサードパーティのソースから来ています。

サードパーティのJavaScriptは、外部のサードパーティのソースから取得できます。広告、分析、ソーシャルメディアの埋め込みなどは、サードパーティのスクリプトを取得するための一般的なユースケースです。そこで当然のことながら、次の質問に移ります。

図1.6の説明を表示

デスクトップ上で10パーセンタイルでは0/1リクエストがファーストパーティとサードパーティであることを示す棒グラフが表示されています、25パーセンタイルでは2/4、50パーセンタイルでは6/10、75パーセンタイルでは13/21、90パーセンタイルでは24/38となっています。

図1.7の説明を表示

モバイルで10パーセンタイルでは0/1リクエストがファーストパーティとサードパーティであることを示す棒グラフが表示されています、25パーセンタイルでは2/3、50パーセンタイルでは5/9、75パーセンタイルでは13/20、90パーセンタイルでは23/36となっています。

モバイルクライアントとデスクトップクライアントの両方において、すべてのパーセンタイルにおいて、ファーストパーティよりもサードパーティのリクエストの方が多く送信されています。これが意外に思える場合は、実際に提供されるコードのうち、サードパーティのベンダーからのものがどれくらいあるのかを調べてみましょう。

図1.8の説明を表示

10パーセンタイルでは、ファーストパーティとサードパーティのリクエストに対してデスクトップ上で0/17バイトのJavaScriptがダウンロードされていることを示す棒グラフ、25パーセンタイルでは11/62、50パーセンタイルでは89/232、75パーセンタイルでは200/525、90パーセンタイルでは404/900である。

図1.9の説明を表示

棒グラフは、10パーセンタイルではファーストパーティとサードパーティのリクエストでそれぞれ0/17バイトの JavaScriptがモバイルでダウンロードされていることを示していますが、25パーセンタイルでは6/54、50パーセンタイルでは83/217、75パーセンタイルでは189/477、90パーセンタイルでは380/827です。

中央値では、モバイルとデスクトップの両方で、開発者が作成したファーストパーティのコードよりもサードパーティのコードの方が89％多く使用されています。これは、サードパーティのコードが肥大化の最大の要因の1つであることを明確に示しています。サードパーティの影響についての詳細は、“サードパーティ”の章を参照してください。

リソース圧縮

ブラウザとサーバの会話のコンテキストで、リソース圧縮とは、データ圧縮アルゴリズムを使用して変更されたコードを指します。リソースは事前に静的に圧縮することも、ブラウザからの要求に応じて急ぎ圧縮することもでき、どちらの方法でも転送されるリソースサイズが大幅に削減されページパフォーマンスが向上します。

テキスト圧縮アルゴリズムは複数ありますが、HTTPネットワークリクエストの圧縮（および解凍）に使われることが多いのはこの2つだけです。

• Gziphttps://www.gzip.org/ (gzip): サーバーとクライアントの相互作用のために最も広く使われている圧縮フォーマット。
• Brotlihttps://github.com/google/brotli (br): 圧縮率のさらなる向上を目指した新しい圧縮アルゴリズム。90%のブラウザhttps://caniuse.com/#feat=brotliがBrotliエンコーディングをサポートしています。

圧縮されたスクリプトは、一度転送されるとブラウザによって常に解凍される必要があります。これは、コンテンツの内容が変わらないことを意味し、実行時間が最適化されないことを意味します。しかし、リソース圧縮は常にダウンロード時間を改善しますが、これはJavaScriptの処理で最もコストのかかる段階の1つでもあります。JavaScriptファイルが正しく圧縮されていることを確認することは、サイトのパフォーマンスを向上させるための最も重要な要因の1つとなります。

JavaScriptのリソースを圧縮しているサイトはどれくらいあるのでしょうか？

図1.10の説明を表示

バーチャートを見ると、デスクトップとモバイルでそれぞれJavaScriptリソースの67%/65%がGzipで圧縮されており、15%/14%がBrotliで圧縮されていることがわかります。

大多数のサイトではJavaScriptのリソースを圧縮しています。Gzipエンコーディングはサイトの〜64-67％で、Brotliは〜14％で使用されています。圧縮率はデスクトップとモバイルの両方でほぼ同じです。

圧縮に関するより深い分析については、“圧縮”の章を参照してください。

オープンソースのライブラリとフレームワーク

オープンソースコード、または誰でもアクセス、閲覧、修正が可能な寛容なライセンスを持つコード。小さなライブラリから、Chromiumhttps://www.chromium.org/HomeやFirefoxhttps://www.openhub.net/p/firefoxのようなブラウザ全体に至るまで、オープンソースコードはウェブ開発の世界で重要な役割を果たしています。JavaScriptの文脈では、開発者はオープンソースのツールに依存して、あらゆるタイプの機能をWebページに組み込んでいます。開発者が小さなユーティリティライブラリを使用するか、アプリケーション全体のアーキテクチャを決定する大規模なフレームワークを使用するかにかかわらずオープンソースのパッケージに依存することで、機能開発をより簡単かつ迅速にできます。では、どのJavaScriptオープンソースライブラリが最もよく使われているのでしょうか？

これまでに作成された中で最も人気のあるJavaScriptライブラリであるjQueryhttps://jquery.com/は、デスクトップページの85.03％、モバイルページの83.46％で使用されています。Fetchhttps://developer.mozilla.org/docs/Web/API/Fetch_APIやquerySelectorhttps://developer.mozilla.org/docs/Web/API/Document/querySelectorなど、多くのブラウザAPIやメソッドの出現により、ライブラリが提供する機能の多くがネイティブ形式に標準化されました。jQueryの人気は衰退しているように見えるかもしれませんが、なぜ今でもウェブの大部分で使われているのでしょうか？

理由はいくつか考えられます。

• WordPresshttps://wordpress.org/は、30％以上のサイトで使用されているため、デフォルトでjQueryが含まれています。
• アプリケーションの規模によってはjQueryから新しいクライアントサイドライブラリへの切り替えに時間を要する場合があり、多くのサイトでは新しいクライアントサイドライブラリに加えてjQueryで構成されている場合があります。

他にもjQueryの亜種（jQuery migrate、jQuery UI）、Modernizrhttps://modernizr.com/、Moment.jshttps://momentjs.com/、Underscore.jshttps://underscorejs.org/などがトップで使用されているJavaScriptライブラリです。

フレームワークとUIライブラリ

過去数年の間に、JavaScriptのエコシステムでは、シングルページアプリケーション (SPA) の構築を容易にするオープンソースのライブラリやフレームワークが増えてきました。シングルページアプリケーションとは、単一のHTMLページを読み込み、サーバーから新しいページを取得する代わりにJavaScriptを使用してユーザーの対話に応じてページを修正するWebページのことを指します。これはシングルページアプリケーションの大前提であることに変わりはありませんが、このようなサイトの体験を向上させるために、異なるサーバーレンダリングアプローチを使用できます。これらのタイプのフレームワークを使用しているサイトはどれくらいあるのでしょうか？

図1.12の説明を表示

Reactを使用しているサイトは4.6％、AngularJSを使用しているサイトは2.0％、Backbone.jsを使用しているサイトは1.8％、Vue.jsを使用しているサイトは0.8％、Knockout.jsを使用しているサイトは0.4％、Zone.jsを使用しているサイトは0.3％、Angularを使用しているサイトは0.3％、AMPを使用しているサイトは0.1％、Ember.jsを使用しているサイトは0.1％という棒グラフになっています。

ここでは人気のあるフレームワークのサブセットのみを分析していますが、これらのフレームワークはすべて、これら2つのアプローチのいずれかに従っていることに注意することが重要です。

• モデルビューコントローラhttps://developer.chrome.com/apps/app_frameworks（またはモデルビュービューモデル）アーキテクチャー
• コンポーネントベースアーキテクチャ

コンポーネントベースモデルへの移行が進んでいるとはいえ、MVCパラダイムを踏襲した古いフレームワーク（AngularJShttps://angularjs.org/、Backbone.jshttps://backbonejs.org/、Emberhttps://emberjs.com/）は、いまだに何千ページにもわたって使われています。しかし、Reacthttps://reactjs.org/、Vuehttps://vuejs.org/、Angularhttps://angular.io/はコンポーネントベースのフレームワークが主流です（Zone.jshttps://github.com/angular/zone.jsは現在Angular coreの一部となっているパッケージです）。

差分ロード

JavaScriptモジュールhttps://v8.dev/features/modules、またはESモジュールは、すべての主要ブラウザhttps://caniuse.com/#feat=es6-moduleでサポートされています。モジュールは、他のモジュールからインポートおよびエクスポートできるスクリプトを作成する機能を提供します。これにより、サードパーティのモジュールローダーに頼ることなく、必要に応じてインポートとエクスポートを行い、モジュールパターンで構築されたアプリケーションを誰でも構築できます。

スクリプトをモジュールとして宣言するには、スクリプトタグがtype="module"属性を取得しなければなりません。

<script type="module" src="main.mjs"></script>

ページ上のスクリプトにtype="module'を使用しているサイトはどれくらいあるでしょうか？

図1.13の説明を表示

デスクトップでは0.6%のサイトが「type=module」を使用しており、モバイルでは0.8%のサイトが使用していることを示す棒グラフです。

ブラウザレベルでのモジュールのサポートはまだ比較的新しく、ここでの数字は、現在スクリプトにtype="module"を使用しているサイトが非常に少ないことを示しています。多くのサイトでは、コードベース内でモジュールを定義するためにモジュールローダー（全デスクトップサイトの2.37％がRequireJShttps://github.com/requirejs/requirejsを使用しています）やバンドラー（webpackhttps://webpack.js.org/を使用しています）にまだ依存しています。

ネイティブモジュールを使用する場合は、モジュールをサポートしていないブラウザに対して適切なフォールバックスクリプトを使用することが重要です。これは、nomodule属性を持つ追加スクリプトを含めることで実現できます。

<script nomodule src="fallback.js"></script>

併用すると、モジュールをサポートしているブラウザはnomodule属性を含むスクリプトを完全に無視します。一方、モジュールをサポートしていないブラウザは ¥type="module"属性を持つスクリプトをダウンロードしません。ブラウザはnomoduleも認識しないので、type="module"属性を持つスクリプトを普通にダウンロードします。このアプローチを使うことで、開発者は最新のコードを最新のブラウザに送信してページ読み込みを高速化するhttps://web.dev/serve-modern-code-to-modern-browsers/できます。では、ページ上のスクリプトにnomoduleを使っているサイトはどれくらいあるのだろうか。

図1.14の説明を表示

デスクトップでは0.8％のサイトが「nomobule」を利用しており、モバイルでは0.5％のサイトが利用していることを示す棒グラフ。

同様に、スクリプトにnomodule属性を使用しているサイトはほとんどありません（0.50％-0.80％）。

プリロードとプリフェッチ

プリロードhttps://developer.mozilla.org/docs/Web/HTML/Link_types/preload と プリフェッチhttps://developer.mozilla.org/docs/Web/HTTP/Link_prefetching_FAQはリソースヒントであり、どのリソースをダウンロードする必要があるかを判断する際にブラウザを助けることができます。

• <link rel="preload">でリソースをプリロードすると、ブラウザはこのリソースをできるだけ早くダウンロードするように指示します。これは、ページの読み込みプロセスの後半に発見され、最後にダウンロードされてしまう重要なリソース（例えば、HTMLの下部にあるJavaScriptなど）に特に役立ちます。
• <link rel="prefetch">を使用することで、ブラウザが将来のナビゲーションに必要なリソースを取得するためのアイドル時間を利用できるようにします。

では、プリロードやプリフェッチディレクティブを使っているサイトはどれくらいあるのでしょうか？

図1.15の説明を表示

バーチャートを見ると、デスクトップでは14%のサイトがスクリプトに’rel=preload’を使用しており、モバイルでは15%のサイトがスクリプトにrel=preloadを使用していることがわかります。

HTTP Archiveで測定したすべてのサイトで、デスクトップサイトの14.33％、モバイルサイトの14.84％が<link rel="preload">をページ上のスクリプトに使用しています。

プリフェッチについて以下のようなものがあります。

図1.16の説明を表示

デスクトップでは0.08%のサイトが「rel=prefetch」を使用しており、モバイルでは0.08%のサイトが使用していることを示す棒グラフ。

モバイルとデスクトップの両方で、0.08％のページがスクリプトのいずれかでプリフェッチを利用しています。

新しいAPI

JavaScriptは言語として進化を続けています。ECMAScriptと呼ばれる言語標準そのものの新バージョンが毎年リリースされ、新しいAPIや機能が提案段階を通過して言語そのものの一部となっています。

HTTP Archiveを使用すると、サポートされている（あるいはこれからサポートされる）新しいAPIを調べて、その使用法がどの程度普及しているかを知ることができます。これらのAPIは、サポートしているブラウザで既に使用されているかもしれませんし、すべてのユーザに対応しているかどうかを確認するためにポリフィルを添付しています。

以下のAPIを使用しているサイトはどれくらいありますか？

• Atomicshttps://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Atomics
• Intlhttps://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Intl
• Proxyhttps://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Proxy
• SharedArrayBufferhttps://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer
• WeakMaphttps://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/WeakMap
• WeakSethttps://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/WeakSet

図1.17の説明を表示

バーチャートを見ると、デスクトップとモバイルのサイトの25.5%/36.2%がWeakMap、6.1%/17.2%がWeakSet、3.9%/14.0%がIntl、3.9%/4.4%がProxy、0.4%/0.4%がAtomics、0.2%/0.2%がSharedArrayBufferを使用していることがわかります。

Atomics(0.38％)とSharedArrayBuffer(0.20％)は、使用されているページが少ないので、このチャートではほとんど見えません。

ここでの数値は概算であり、機能の使用状況を測定するためのUseCounterhttps://chromium.googlesource.com/chromium/src.git/+/master/docs/use_counter_wiki.md を活用していないことに注意してください。

ソースマップ

多くのビルドシステムでは、JavaScriptファイルはサイズを最小化し、多くのブラウザではまだサポートされていない新しい言語機能のためにトランスパイルされるようにミニ化されています。さらに、TypeScripthttps://www.typescriptlang.org/のような言語スーパーセットは、元のソースコードとは明らかに異なる出力へコンパイルされます。これらの理由から、ブラウザに提供される最終的なコードは読めず、解読が困難なものになることがあります。

ソースマップとは、JavaScriptファイルに付随する追加ファイルで、ブラウザが最終的な出力を元のソースにマップできます。これにより、プロダクションバンドルのデバッグや分析をより簡単にできます。

便利ではありますが多くのサイトが最終的な制作サイトにソースマップを入れたくない理由は、完全なソースコードを公開しないことを選択するなど、いくつかあります。では、実際にどれくらいのサイトがソースマップを含んでいるのでしょうか？

図1.18の説明を表示

デスクトップサイトの18％、モバイルサイトの17％がソースマップを使用していることを示す棒グラフ。

デスクトップページでもモバイルページでも、結果はほぼ同じです。17～18％は、ページ上に少なくとも1つのスクリプトのソースマップを含んでいます（sourceMappingURLを持つファーストパーティスクリプトとして検出されます）。

結論

JavaScriptのエコシステムは毎年変化し続け、進化し続けています。新しいAPI、改良されたブラウザエンジン、新しいライブラリやフレームワークなど、私たちが期待していることは尽きることがありません。HTTP Archiveは、実際のサイトがどのようにJavaScriptを使用しているかについての貴重な洞察を提供してくれます。

JavaScriptがなければ、ウェブは現在の場所にはなく、この記事のために集められたすべてのデータがそれを証明しているに過ぎません。

CSS

導入

カスケードスタイルシート（CSS）は、Webページの描画、書式設定、およびレイアウトに使用されます。それらの機能は、テキストの色から3Dパースペクティブまでの単純な概念に及びます。また、さまざまな画面サイズ、コンテキストの表示、印刷を処理する開発者を支援するフックもあります。 CSSは、開発者がコンテンツを絞り込み、ユーザーに適切に適合させることを支援します。

CSSをWebテクノロジーに慣れていない人に説明するときは、CSSを家の壁にペイントする言語と考える事が役立ちます。窓やドアのサイズと位置、および壁紙や植物などが栄える装飾と説明できる。そのストーリーの面白いひねりは、ユーザーが家の中を歩いているかどうかに応じて、開発者はその特定のユーザーの好みやコンテキストに家を作り替えることができるということです！

この章では、WebでのCSSの使用方法に関するデータを検査、集計、および抽出します。私たちの目標はどの機能が使用されているか、どのように使用されているか、CSSがどのように成長し採用されているかを全体的に理解することです。

魅力的なデータを掘り下げる準備はできましたか?! 以下の数値の多くは小さい場合がありますが、重要ではないと誤解しないでください! 新しいものがウェブを飽和させるには何年もかかることがあります。

色

色は、Webのテーマとスタイリングに不可欠な部分です。ウェブサイトが色を使用する傾向を見てみましょう。

色の種類

16進数は、色を説明する最も一般的な方法であり93％の使用率、RGB、HSLが続きます。興味深いことに、開発者はこれらの色の種類に関してアルファ透明度の引数を最大限に活用しています。HSLAとRGBAは、HSLとRGBよりもはるかに人気があり、使用量はほぼ2倍です。アルファ透明度は後でWeb仕様に追加されましたが、HSLAとRGBAはIE9までさかのぼってhttps://caniuse.com/#feat=css3-colorsサポートされているため、先に進んで使用することもできます！

図2.1の説明を表示

HSL、HSLA、RGB、RGBA、および16進カラー形式の採用を示す棒グラフ。 Hexはデスクトップページの93％、RGBAは83％、RGBは22％、HSLA 19％、HSL 1％で使用されています。デスクトップとモバイルの採用は、モバイルの採用が9％（9倍）であるHSLを除くすべてのカラー形式で類似しています。s

色の選択

CSSの名前付きカラーは148個https://www.w3.org/TR/css-color-4/#named-colorsあり、transparentおよびcurrentcolorの特別な値は含まれていません。これらを文字列名で使用して、読みやすくできます。最も人気がある名前の付いた色は黒と白であり、当然のことながら赤と青が続きます。

図2.2の説明を表示

最も人気のある名前付きの色を示す円グラフ。白が40％で最も人気があり、次に黒が22％、赤が11％、青が5％です。

言語は色によっても興味深いことに推測されます。イギリス式の「grey」よりもアメリカ式の「gray」の例が多くあります。グレー色https://www.rapidtables.com/web/color/gray-color.html（グレー、ライトグレー、ダークグレー、スレートグレーなど）のほぼすべてのインスタンスは、「e」ではなく「a」で綴ると、使用率がほぼ2倍になりました。 gr [a/e] ysが組み合わされた場合、それらは青よりも上位にランクされ、＃4スポットで固まります。これが、チャートで銀がグレーよりも高いランクになっている理由です。

色の数

ウェブ全体でいくつの異なるフォントの色が使用されていますか？　これは一意の色の総数ではありません。むしろ、テキストに使用される色の数です。このグラフの数値は非常に高く、経験からCSS変数なしでは間隔、サイズ、色がすぐに離れて、スタイル全体で多くの小さな値に断片化することがわかります。これらの数値はスタイル管理の難しさを反映しており、あなたがチームやプロジェクトに持ち帰るための何らかの視点を作り出すのに役立つことを願っています。この数を管理可能かつ合理的な量に減らすにはどうすればよいですか？

図2.3の説明を表示

デスクトップおよびモバイルページごとの色の10、25、50、75、および90パーセンタイルを示す分布。デスクトップ分布は8、22、48、83、および131です。モバイルページは、1〜10までに色が増える傾向があります。

色の複製

さて、私たちはここで興味を持ち、ページにいくつの重複色が存在するかを調べたいと思いました。しっかり管理された再利用可能なクラスCSSシステムがなければ、複製はものすごく簡単に作成できます。中央値には十分な重複があるため、パスを実行してそれらをカスタムプロパティと統合する価値があるかもしれません。

図2.4の説明を表示

ページごとの色の分布を示す棒グラフ。中央のデスクトップページには24の重複した色があります。 10パーセンタイルは4つの重複色であり、90パーセンタイルは62です。デスクトップとモバイルの分布は似ています。

ユニット

CSSには、異なるユニットタイプ（rem、px、em、ch、またはcm）を使用して同じ視覚的結果を達成するためのさまざまな方法があります！　それで、どのユニットタイプが最も人気ですか？

図2.5の説明を表示

さまざまなユニットタイプの人気の棒グラフ。 pxとemは、ページの90％以上で使用されています。 remは、ページの40％で次に人気のあるユニットタイプであり、残りのユニットタイプの人気は急落します。

長さとサイズ

当然のことながら、上の図2.5では、pxが最もよく使用されるユニットタイプであり、Webページの約95％が何らかの形式のピクセルを使用しています（これは要素のサイズ、フォントサイズなどです）。ただし、emユニットの使用率はほぼ同じで約90％です。これは、Webページで40％の頻度しかないremユニットよりも2倍以上人気があります。違いを知りたい場合は、emは親フォントサイズに基づいており、remはページに設定されている基本フォントサイズに基づいています。 em のようにコンポーネントごとに変更されることはないため、すべての間隔を均等に調整できます。

物理的な空間に基づいた単位となると、cm（またはセンチメートル）ユニットが最も人気であり、次にin（インチ）、Qが続きます。これらのタイプのユニットは、印刷スタイルシートに特に役立つことがわかっていますが、この調査までQユニットが存在することさえ知りませんでした！　知ってましたか？

ビューポートベースのユニット

ビューポートベースのユニットのモバイルとデスクトップの使用に関しては、ユニットタイプに大きな違いが見られました。モバイルサイトは36.8％がvh（ビューポートの高さ）を使用していますが、デスクトップサイトは31％しか使用していません。また、vhはvw（ビューポートの幅）よりも約11％一般的です。 vmin（ビューポートの最小値）はvmax（ビューポートの最大値）よりも人気があり、モバイルでのvminの使用率は約8％で、vmaxはWebサイトの1％のみが使用しています。

カスタムプロパティ

カスタムプロパティは、多くの場合CSS変数と呼ばれます。ただし、通常の静的変数よりも動的です！　CSS変数は非常に強力であり、コミュニティとして私たちはまだ彼らの可能性を発見しています。

私たちのお気に入りはCSS追加の1つが健全な成長を示しており、これは刺激的な情報だと感じました。これらは2016年または2017年以降、すべての主要なブラウザで利用可能であったため、かなり新しいと言っても過言ではありません。多くの人々は、CSSプリプロセッサ変数からCSSカスタムプロパティに移行しています。カスタムプロパティが標準になるまであと数年かかると推定されます。

セレクター

ID vs クラスセレクター

CSSには、スタイリングのためにページ上の要素を見つける方法がいくつかあるのでIDとクラスを互いに比較して、どちらがより一般的であるかを確認しましょう。結果は驚くべきものでありません。クラスの方が人気です！

図2.7の説明を表示

IDおよびクラスセレクタータイプの採用を示す棒グラフ。クラスは、デスクトップおよびモバイルページの95％で使用されます。 IDは、デスクトップの89％とモバイルページの87％で使用されます。

素敵なフォローアップチャートはこれです。スタイルシートで見つかったセレクタの93％がクラスを占めることを示しています。

図2.8の説明を表示

セレクタの94％にデスクトップとモバイルのクラスセレクタが含まれていることを示す棒グラフ、一方デスクトップセレクターの7％にはIDセレクターが含まれます（モバイルの場合は8％）。

属性セレクター

CSSには、非常に強力な比較セレクターがいくつかあります。これらは、[target="_blank"]、[attribute^="value"]、[title~="rad"]、[attribute$="-rad"]または[attribute*="value"]などのセレクターです。それらを使用しますか？　よく使われていると思いますか？　それらがWeb全体でIDとクラスでどのように使用されるかを比較しましょう。

図2.9の説明を表示

ID属性セレクターで使用される演算子の人気を示す棒グラフ。デスクトップページとモバイルページの約4％は、スターイコールとキャレットイコールを使用しています。 1％のページで「イコール」と「ダラーイコール」を使用しています。 0％はチルダイコールを使用します。

図2.10の説明を表示

クラス属性セレクターで使用される演算子の人気を示す棒グラフ。 57％のページがスターイコールを使用しています。 36％がキャレットイコールを使用します。 1％はイコールおよびドルイコールを使用します。 0％はチルダイコールを使用します。

スタイルシートのIDセレクターは通常クラスセレクターよりも少ないため、これらの演算子はIDよりもクラスセレクターではるかに人気がありますが、これらすべての組み合わせの使用法は見た目にも優れています。

要素ごとのクラス

OOCSS、アトミック、および機能的なCSS戦略の登場により要素に10以上のクラスを構成してデザインの外観を実現できるため、おそらく興味深い結果が得られるでしょう。クエリは非常に刺激的でなく、モバイルとデスクトップの中央値は要素ごとに1クラスでした。

レイアウト

Flexbox

Flexboxhttps://developer.mozilla.org/docs/Web/CSS/CSS_Flexible_Box_Layout/Basic_Concepts_of_Flexboxは、子を指示、整列するコンテナスタイルです。つまり制約ベースの方法でレイアウトを支援します。 2010年から2013年の間に仕様が2〜3の大幅な変更を経たため、Webでの開始は非常に困難でした。幸いなことに、2014年までにすべてのブラウザに落ち着き実装されました。その歴史を考えると採用率は低かったのですが、それから数年が経ちました！　今では非常に人気があり、それに関する多くの記事とそれを活用する方法がありますが、他のレイアウト戦術と比較してまだ新しいです。

図2.12の説明を表示

フレックスボックスを使用したデスクトップページの49％とモバイルページの52％を示す棒グラフ。

Webのほぼ50％がスタイルシートでflexboxを使用しているため、ここに示したかなりの成功事例です。

Grid

flexboxと同様に、グリッドhttps://developer.mozilla.org/docs/Web/CSS/CSS_Grid_Layoutも早い段階でいくつかの仕様変更を経ましたが、公的に展開されたブラウザの実装を変更することはありませんでした。 Microsoftは、水平方向にスクロールするデザインスタイルの主要なレイアウトエンジンとして、Windows 8の最初のバージョンにグリッドを備えていました。最初にそこで検証され、Webに移行し、その後、2017年の最終リリースまで他のブラウザーによって強化されました。ほぼすべてのブラウザーが同時に実装をリリースしたため、Web開発者はある日目覚めただけで優れたグリッドサポートを得ることができました。今日2019年の終わりに、グリッドはまだ子供のように感じています。人々がまだその力と能力に気付き始めているため。

これは、Web開発コミュニティが最新のレイアウトツールを使用して調査したことがどれほど少ないかを示しています。主要なレイアウトエンジンの人々がサイトを構築する際に頼るので、グリッドの最終的な引継ぎを楽しみにしています。著者にとって、私たちはグリッドを書くのが大好きです。通常、最初にグリッドへ到達し、次にレイアウトを実現し、繰り返しながら複雑さをダイヤルバックします。今後数年間で、この強力なCSS機能を使用して他の地域がどうなるかは今後の課題です。

書き込みモード

WebとCSSは国際的なプラットフォーム機能であり、書き込みモードはHTMLとCSSが要素内でユーザーの好みの読み取りと書き込みの方向を示す方法を提供します。

図2.14の説明を表示

方向値ltrおよびrtlの人気を示す棒グラフ。 ltrは、デスクトップページの32％とモバイルページの40％で使用されています。 rtlは、デスクトップページの32％とモバイルページの36％で使用されています。

タイポグラフィ

ページごとのWebフォント

WebページにいくつのWebフォントをロードしていますか：0？　10？　1ページあたりのWebフォントの中央値は3です！

図2.15の説明を表示

ページごとにロードされるWebフォントの数の分布。デスクトップでは、10、25、50、75、および90パーセンタイルは0、1、3、6、および9です。これは、75パーセンタイルと90パーセンタイルで1つ少ないフォントであるモバイル配布よりわずかに高くなっています。

人気のあるフォントファミリー

ページあたりのフォントの総数の問い合わせに対する自然な回答は、次のとおりです。それらはどのフォントですか?!　デザイナーは、あなたの選択が人気のあるものと一致しているかどうかを確認できるようになります。

図2.16の説明を表示

最も人気のあるフォントの棒グラフ。デスクトップページの中で、Open Sans（24％）、Roboto（15％）、Montserrat（5％）、Source Sans Pro（4％）、Noto Sans JP（3％）、Lato（3％）です。モバイルで最も顕著な違いは、Open Sansが時間の22％で使用され（24％から減少）、Robotoが時間の19％で使用される（15％から増加）ことです。

ここではOpen Sansが大きな勝者であり、CSSの@font-family宣言の4分の1近くがそれを指定しています。私たちは間違いなく、プロジェクトでOpen Sansを使用しています。

また、デスクトップ導入とモバイル導入の違いに注目することも興味深いです。たとえば、モバイルページはデスクトップよりもOpen Sansの使用頻度がわずかに低いです。一方、デスクトップはRobotoを少しだけ頻繁に使用します。

フォントサイズ

これは楽しいものです。ユーザーがページ上にあると感じるフォントサイズの数をユーザーに尋ねた場合、通常5または10未満の数値が返されるからです。デザインシステムでフォントサイズはいくつありますか？　Webに問い合わせたところ、中央値はモバイルで40、デスクトップで38でした。タイプランプの配布に役立つカスタムプロパティや再利用可能なクラスの作成について真剣に考える時間になるかもしれません。

図2.17の説明を表示

ページごとの異なるフォントサイズの分布を示す棒グラフ。デスクトップページの10、25、50、75、および90パーセンタイルは、8、20、40、66、および92のフォントサイズです。デスクトップディストリビューションは、75パーセンタイルでモバイルとは異なり、7〜13の異なるサイズで大きくなっています。

間隔

マージン

マージンとは、自分の腕を押し出すときに要求するスペースのような要素の外側のスペースです。これは多くの場合、要素間の間隔のように見えますが、その効果に限定されません。 Webサイトまたはアプリでは、間隔はUXとデザインで大きな役割を果たします。スタイルシートにどのくらいのマージン間隔コードが入るか見てみましょうか？

図2.18の説明を表示

ページごとの明確なマージン値の分布を示す棒グラフ。デスクトップページの場合、10、25、50、75、および90パーセンタイルは、12、47、96、167、および248の異なるマージン値です。デスクトップディストリビューションは75パーセンタイルでモバイルとは異なり、12〜31の異なる値で小さくなっています。

かなりたくさんのようです！　デスクトップページの中央値には96の異なるマージン値があり、モバイルでは104です。これにより、デザインに多くのユニークな間隔が生まれます。あなたのサイトにいくつのマージンがあるか​​知りたい？　この空白をすべて管理しやすくするにはどうすればよいですか？

論理プロパティ

margin-leftとpadding-topの覇権は限られた期間であり、書き込み方向に依存しない、連続した論理プロパティ構文によりまもなく補完されると推定します。楽観的ではありますが、現在の使用量は非常に低く、デスクトップページでの使用量は0.67％です。私たちにとって、これは業界として開発する必要がある習慣の変化のように感じられますが、新しいシンタックスを使用するために新しい開発者を訓練することを願っています。

z-index

CSSのz-indexを使用して、垂直の階層化またはスタックを管理できます。私たちは、人々が自分のサイトでどれだけ多くの価値を使用しているかに興味がありました。 z-indexが受け入れる範囲は理論的には無限であり、ブラウザーの可変サイズの制限によってのみ制限されます。それらすべてのスタック位置が使用されていますか？　では見てみよう！

図2.20の説明を表示

ページごとの異なるz-index値の分布を示す棒グラフ。デスクトップページの場合、10、25、50、75、および90パーセンタイルは、1、7、16、26、および36の異なるz-index値です。デスクトップの分布はモバイルよりもはるかに高く、90パーセンタイルで16もの異なる値があります。

人気のあるz-index値

私たちの仕事の経験から、9の任意の数が最も一般的な選択肢であると思われました。可能な限り少ない数を使用するように教えたにもかかわらず、それは共同の基準ではありません。じゃあ何ですか?!　人々が一番上のものを必要とする場合、最も人気のあるZインデックス番号は何ですか？　飲み物を置いてください。これはあなたがそれを失うかもしれないので十分面白いです。

図2.21の説明を表示

デスクトップとモバイルの両方について、すべての既知のz-index値とそれらが使用された回数の散布図。 1と2が最も頻繁に使用されますが、残りの人気のある値は数百桁の数字まで桁違いに爆発します：10、100、1,000など。

デコレーション

フィルター

フィルターは、ブラウザーが画面に描画するピクセルを変更するための楽しくて素晴らしい方法です。これは、適用対象の要素、ノード、またはレイヤーのフラットバージョンに対して実行される後処理効果です。 Photoshopによって使いやすくなり、Instagramによって、オーダーメイドの定型化された組み合わせによって大衆がアクセスできるようになりました。それらは2012年頃から存在し、10個あります。それらを組み合わせて独自の効果を作成できます。

スタイルシートの78％にフィルタープロパティが含まれていることがわかりました。その数も非常に高かったので、少し怪しいように思えたので、私たちは深掘りしてその高い数を説明しようとしました。正直に言って、フィルターはきちんとしていますが、すべてのアプリケーションやプロジェクトに組み込まれているわけではありません。しない限り！

さらなる調査の結果、FontAwesomehttps://fontawesome.comのスタイルシートにはフィルターの使用法とYouTubehttps://youtube.com埋め込みが含まれていることがわかりました。そのため、非常に人気のあるいくつかのスタイルシートに便乗することで、バックドアにフィルターが入り込むと考えています。また、-ms-filterの存在も含まれている可能性があり、使用率が高くなっていると考えられます。

ブレンドモード

ブレンドモードは、ターゲット要素のフラットバージョンに対して実行される後処理効果であるという点でフィルターに似ていますが、ピクセル収束に関係しているという点で独特です。別の言い方をすれば、ブレンドモードとは、2つのピクセルが重なり合ったときに互いに影響を与える方法です。上部または下部のどちらの要素でも、ブレンドモードがピクセルを操作する方法に影響します。 16種類のブレンドモードがあります。どのモードが最も人気かを見てみましょう。

全体的に、ブレンドモードの使用はフィルターの使用よりもはるかに低いですが、適度に使用されていると見なすのに十分です。

Web Almanacの今後のエディションでは、ブレンドモードの使用法にドリルダウンして、開発者が使用している正確なモード（乗算、スクリーン、カラーバーン、ライトなど）を把握することをお勧めします。

アニメーション

トランジション

CSSには、トランジションのこれらの値の方法に関する単一のルールを記述するだけで簡単に使用できるこの素晴らしい補間機能があります。アプリの状態を管理するためにCSSを使用している場合、タスクを実行するためにトランジションを使用する頻度はどれくらいですか？　Webに問合せしましょう！

図2.25の説明を表示

ページごとのトランジションの分布を示す棒グラフ。デスクトップページの場合、10、25、50、75、および90パーセンタイルは、0、2、16、49、および118です。デスクトップの分布はモバイルよりもはるかに低く、90パーセンタイルで最大77のトランジション。

それはかなり良いです！　私たちはanimate.cssを含めるべき人気のあるライブラリと考えていました。これはたくさんのトランジションアニメーションをもたらしますが、人々がUIのトランジションを検討しているのを見るのは今でも素晴らしいことです。

キーフレームアニメーション

CSSキーフレームアニメーションは、より複雑なアニメーションやトランジションに最適なソリューションです。これにより、効果をより明確に制御できるようになります。 1つのキーフレームエフェクトのように小さくすることも、多数のキーフレームエフェクトを堅牢なアニメーションに合成して大きくすることもできます。ページあたりのキーフレームアニメーションの数の中央値は、CSSトランジションよりもはるかに低くなっています。

図2.26の説明を表示

ページごとのキーフレームの分布を示す棒グラフ。モバイルページの場合、10、25、50、75、および90パーセンタイルは、0、0、3、18、および76キーフレームです。モバイルの分布は、75パーセンタイルと90パーセンタイルで6キーフレーム分、デスクトップよりわずかに高くなっています。

メディアクエリ

メディアクエリを使用すると、CSSをさまざまなシステムレベルの変数にフックして、訪問ユーザーに適切に適応させることができます。これらのクエリの一部は、印刷スタイル、プロジェクタースクリーンスタイル、ビューポート/スクリーンサイズを処理できます。長い間、メディアクエリは主にビューポートの知識のために活用されていました。デザイナーと開発者は、小さな画面、大きな画面などにレイアウトを適合させることができます。その後、ウェブはますます多くの機能とクエリを提供し始めました。つまり、メディアクエリはビューポート機能に加えてアクセシビリティ機能を管理できるようになりました。

メディアクエリから始めるのに適した場所は、1ページあたりの使用数です。典型的なページが応答したいと感じるのは、いくつの瞬間やコンテキストですか？

図2.27の説明を表示

ページごとのメディアクエリの分布を示す棒グラフ。デスクトップページの場合、10、25、50、75、および90パーセンタイルは、0、3、14、27、および43キーフレームです。デスクトップ配布は、モバイル配布に似ています。

一般的なメディアクエリブレークポイントサイズ

ビューポートメディアクエリの場合、任意のタイプのCSSユニットを評価用のクエリ式に渡すことができます。以前、人々はemとpxをクエリに渡していましたが、時間がたつにつれて単位が追加され、Webで一般的に見られるサイズの種類について非常に興味を持ちました。ほとんどのメディアクエリは一般的なデバイスサイズに従うと想定していますが、想定する代わりにデータを見てみましょう。

図2.28の説明を表示

最も人気のあるメディアクエリスナップポイントの棒グラフ。 768pxと767pxが最も人気があり、それぞれ23％と16％です。その後、リストはすぐに削除され、992pxは6％の時間を使用し、1200pxは4％の時間を使用しました。デスクトップとモバイルの使用方法は似ています。

上記の図2.28は、前提の一部が正しいことを示しています。確かに、大量のモバイル固有のサイズがありますが、そうでないものもあります。また、このチャートの範囲を超えてemを使用するいくつかのトリックエントリで、非常にピクセルが支配的であることも興味深いです。

ポートレートとランドスケープの使用

人気のあるブレークポイントサイズからの最も人気のあるクエリ値は768pxであるため、興味をそそられました。この値は、768pxが一般的なモバイルポートレートビューポートを表すという仮定に基づいている可能性があるため、主にポートレートレイアウトへ切り替えるために使用されましたか？　そこで、ポートレートモードとランドスケープモードの使用の人気を確認するために、フォローアップクエリを実行しました。

図2.29の説明を表示

メディアクエリの縦向きモードと横向きモードの採用を示す棒グラフ。ページの31％は横向き、8％は縦向き、7​​％は両方を指定しています。採用は、デスクトップページとモバイルページで同じです。

興味深いことに、ポートレートはあまり使用されませんが、ランドスケープはより多く使用されます。 768pxはポートレートレイアウトのケースとして十分に信頼できるものであり、到達できるコストははるかに少ないと想定できます。また、デスクトップコンピューターで作業をテストしているユーザーは、ブラウザーを押しつぶすほど簡単にモバイルレイアウトを見るためにポートレートをトリガーできないと想定しています。わかりにくいですが、データは魅力的です。

最も人気のあるユニットタイプ

これまで見てきたメディアクエリの幅と高さでは、ピクセルはUIをビューポートに適合させることを考えている開発者にとって主要な選択単位のように見えます。ただし、これを排他的にクエリしたいので、実際に人々が使用するユニットのタイプを見てみましょう。これは私たちが見つけたものです。

図2.30の説明を表示

ピクセルを指定するメディアクエリスナップポイントの75％、emsを指定する8％、remを指定する1％を示す棒グラフ。

min-widthとmax-width

人々がメディアクエリを書くとき、彼らは通常、特定の範囲を超えているか下にあるビューポート、またはその両方をチェックして、サイズの範囲内にあるかどうかをチェックしてるでしょうか？　ウェブに聞いてみましょう！

図2.31の説明を表示

最大幅を使用するデスクトップページの74％、最小幅を使用する70％、および両方のプロパティを使用する68％を示す棒グラフ。採用はモバイルページでも同様です。

ここには明確な勝者はありません。 max-widthとmin-widthはほぼ同じように使用されます。

printとspeech

Webサイトはデジタルペーパーのように感じますか？　ユーザーとしては、ブラウザーから印刷するだけで、そのデジタルコンテンツを物理コンテンツに変換できることが一般的に知られています。 Webサイトは、そのユースケースに合わせて変更する必要はありませんが、必要に応じて変更できます。あまり知られていないのは、ツールまたはロボットによって読み取られるユースケースでWebサイトを調整する機能です。では、これらの機能はどれくらいの頻度で活用されていますか？

図2.32の説明を表示

「all」のメディアクエリタイプを使用するデスクトップページの35％、printを使用する46％、screenを使用する72％、およびspeechを使用する0％を示す棒グラフ。採用率は、モバイルに比べてデスクトップで約5パーセントポイント低くなっています。

ページレベルの統計

スタイルシート

ホームページから何枚のスタイルシートを参照していますか？　アプリからはどのくらい？　モバイルとデスクトップのどちらにサービスを提供していますか？　ここに他のみんなのチャートがあります！

図2.33の説明を表示

ページごとにロードされるスタイルシートの数の分布。デスクトップとモバイルは、10、25、50、75、および90パーセンタイル（ページごとに1、3、6、12、および20のスタイルシート）を持つ同一の分布を持っています。

スタイルシート名

スタイルシートの名前は何ですか？　あなたのキャリアを通して一貫した名前にしましたか？　ゆっくり収束したか、一貫して発散しましたか？　このチャートは、ライブラリの人気を少し垣間見せています。また、CSSファイルの一般的な名前を垣間見ることもできます。

それらすべてのクリエイティブなファイル名を見てください！　スタイル、スタイル、メイン、デフォルト、すべて。しかし目立ったのは、あなたはわかりますか？ BfWyFJ2Rl5s.cssは、最も人気のある4位になります。少し調べてみましたが、Facebookの「いいね」ボタンに関連していると思われます。そのファイルが何であるか知っていますか？　話を聞きたいので、コメントを残してください。

スタイルシートのサイズ

これらのスタイルシートはどれくらいの大きさですか？　CSSのサイズは心配する必要がありますか？　このデータから判断すると、CSSはページ膨張の主な攻撃者ではありません。

図2.35の説明を表示

ページごとにロードされるスタイルシートのバイト数の分布。デスクトップページの10、25、50、75、および90パーセンタイルは、8、26、62、129、および240KBです。デスクトップ配布は、モバイル配布より5〜10KBわずかに高くなっています。

Webサイトが各コンテンツタイプにロードするバイト数の詳細については、ページウェイトの章を参照してください。

ライブラリ

新しいプロジェクトをスタートする事にCSSライブラリへ手を出すのは一般的で、人気があり、便利で強力です。あなたはライブラリに手を伸ばす人ではないかもしれませんが、私たちは2019年にウェブへ問い合わせて、どれが群を抜いているか調べました。彼らが私たちと同じように結果に驚くなら、開発者バブルがどれだけ小さいかを知る手がかりになると思います。物事は非常に人気がありますが、ウェブに問い合わせると、現実は少し異なります。

このチャートは、Bootstraphttps://getbootstrap.com/がプロジェクトを支援するために知っておくべき貴重なライブラリであることを示唆しています。支援する機会があるすべてを見てください！　すべてのサイトがCSSフレームワークを使用しているわけではないので、これはポジティブなシグナルチャートにすぎないことも注目に値します。100％に達することはありません。すべてのサイトの半分以上が、既知のCSSフレームワークを使用していません。とても面白いですよね！

リセットユーティリティ

CSSリセットユーティリティは、ネイティブWeb要素のベースラインを正規化または作成することを目的としています。あなたが知らなかった場合、各ブラウザはすべてのHTML要素に対して独自のスタイルシートを提供し、それら要素の外観、動作について独自の決定を下すことができます。リセットユーティリティはこれらのファイルを調べ、共通点を見つけた（もしくは見つけなかった）ため、開発者が1つのブラウザーでスタイルを設定し、別のブラウザーでも同じように見える合理的な自信を持たせるため、相違点を解決しました。

それで、どれだけのサイトがそれを使っているかを見てみましょう！　彼らの存在はかなり理にかなっているように思えるので、何人の人々が彼らの戦術に同意し、彼らのサイトでそれらを使用しますか？

図2.37の説明を表示

3つのCSSリセットユーティリティの採用を示す棒グラフ：Normalize.css（33％）、Reset CSS（3％）、およびPure CSS（0％）。デスクトップページとモバイルページで採用に違いはありません。

Webの約3分の1がnormalize.cssを使用していることがわかります。これは、リセットよりもタスクへのより穏やかなアプローチと考えることができます。少し詳しく見てみると、Bootstrapにはnormalize.cssが含まれていることがわかりました。 normalize.cssがBootstrapよりも多く採用されていることも注目に値するので、それを単独で使用する人がたくさんいます。

@supportsと@import

CSS @supportsは、ブラウザが特定のプロパティと値の組み合わせが有効であると解析されたかどうかをチェックし、チェックがtrueを返した場合にスタイルを適用する方法です。

図2.38の説明を表示

@importおよび@supports “@”ルールの人気を示す棒グラフ。デスクトップでは、ページの28％で@importが使用され、31％で@supportsが使用されます。モバイルでは、ページの26％で@importが使用され、29％で@supportsが使用されます。

2013年にほとんどのブラウザで@supportsが実装されたことを考慮すると、大量の使用と採用が見られることはそれほど驚くことでありません。ここでは、開発者のマインドフルネスに感銘を受けています。これは思いやりのあるコーディングです！　すべてのWebサイトの30％は、使用する前にディスプレイ関連のサポートをチェックしています。

これの興味深いフォローアップは、@importsより@supportsの使用が多いことです！　私たちはそれを期待していませんでした！ @importは1994年以来ブラウザに存在しています。

結論

ここには、データマイニングするための非常に多くのものがあります！　結果の多くは私たちを驚かせました、そして同様にあなたも驚いたことを願っています。この驚くべきデータセットにより、要約が非常に楽しくなり、結果の一部がそうである理由を追い詰めたいかどうかを調査するための多くの手がかりと追跡の跡が残されました。

どの結果が最も驚くべきものでしたか？ どの結果を使用して、コードベースにすばやくクエリを移動しますか？

これらの結果からの最大のポイントは、スタイルシートのパフォーマンス、乾燥、スケーラビリティの点で、カスタムプロパティが予算に見合った価値を提供することだと感じました。インターネットのスタイルシートを再度スクラブし、新しいデータムと挑発的なチャートの扱いを探しています。クエリ、質問、アサーションを含むコメントで@unaまたは@argyleinkに連絡してください。私たちはそれらを聞きたいです！

マークアップ

導入

2005年にIan “Hixie” Hicksonはこれまでの研究に基づいたマークアップデータの分析https://web.archive.org/web/20060203035414/http://code.google.com/webstats/index.htmlを投稿しました。この作業のほとんどは、クラス名を調査して、内々で開発者が採用しているセマンティクスを確認し、標準化する意味があるかの確認をすることが目的でした。この研究の一部は、HTML5の新要素の参考として役に立ちました。

14年すぎて、新しい見方をする時が来ました。以降、カスタム要素(Custom Elements)https://developer.mozilla.org/docs/Web/Web_Components/Using_custom_elementsとExtensible Web Manifestohttps://extensiblewebmanifesto.org/の導入により、開発者は要素そのものの空間を探し、標準化団体が辞書編集者のようになるhttps://bkardell.com/blog/Dropping-The-F-Bomb-On-Standards.htmlことで、牛の通り道を舗装する(pave the cowpaths)よりよい方法を見つけることを推奨しています。様々なものに使われる可能性があるCSSクラス名とは異なり、非標準の要素は作成者が要素であることを意識しているため、さらに確実なものとなります。

2019年7月の時点で、HTTP Archiveは、約440万のデスクトップホームページと約530万のモバイルホームページのDOMで使用されているすべての要素名の収集を開始しました。 (方法論の詳細を御覧ください)

このクロールの結果、5,000種類を超える非標準の要素が検出されたため、計測する要素の合計数を「トップ」（以下で説明）5,048種類に制限しました。

方法論

各ページの要素の名前は、JavaScriptの初期化後DOMより収集されました。

現実の要素出現数を確認することは標準の要素であっても有用ではありません、検出されたすべての要素の約25%は<div>です。そして、約17%が<a>で、11%が<span>となっており、これらは10%以上を占める唯一の要素たちです。言語は一般的にこのようなものhttps://www.youtube.com/watch?v=fCn8zs912OEですが、これと比較してみると驚くほど少ない用語が使われています。さらに、非標準の要素の取り込みを検討してみると、１つのサイトが特定の要素を1000回も使用しているために、とても人気があるように見えてしまい、大きな誤解を招く可能性があります。

そのような方法を取らず、私達はHixieの元の研究のようにホームページに各要素が少なくとも1回は含まれているサイトの数に着目しました。

上位の要素と概説

2005年、Hixieはページ中に最もよく使用されていて、頻度の少ない上位要素を調査しました。トップ３は html、head、bodyでした、これらはオプションなので省略されてもパーサーによって作成されており、彼は興味深いと述べています。パーサーによる解析後のDOMを使って調査すると、データは普遍的に表示されます。なので、４番目に使用頻度の高い要素からはじめました。以下は、その時点から現在までのデータの比較です。(ここでは面白いので出現数を含めました)

ページ毎の要素

図3.2の説明を表示

要素数が増加するにつれて相対頻度の分布が減少することを示すグラフ

図3.3の説明を表示

約2,500ページからなるグラフは、約30個の要素から開始します。そして2,000個の要素を含む327ページまで直線的に追従する前の283個の要素を持つ6,876ページあたりでピークに達します。

図3.2の2005年のHixieのレポートと図3.3の最新データを比較すると、DOMツリーの平均サイズが大きくなっていることがわかります。

図3.4の説明を表示

相対周波数が19個の要素点の周りで釣鐘曲線となっていることを示すグラフ

図3.5の説明を表示

308,168,000のサイトで使用されている平均要素数を示すグラフは、マークされた30個の要素の周りで釣鐘曲線になっています。

ページあたりの要素の種類の平均数と、ユニークな要素数の最大値の両方が増加していることがわかります。

カスタム要素

記録された要素のほとんどはカスタム（単純に「非標準」となる物）でした。しかし、どの要素がカスタムであるか、カスタムではないかを議論するのは少し面倒です。実際にかなりの数の要素が仕様や提案のどこかに書かれています。今回、244個の要素を標準として検討しました。（ただし、一部は非推奨またはサポート対象外のものです）

• 145個のHTML要素
• 68個のSVG要素
• 31個のMathML要素

実際は、これらのうち214だけに遭遇しました。

• 137個のHTML要素
• 54個のSVG要素
• 23個のMathML要素

デスクトップのデータセットでは、検出された4,834個の非標準要素のデータを収集しました。次がそれに当たります。

• 155個（3％）は、非常に高い確率でマークアップまたはエスケープの例外として識別できます（解析されたタグ名にマークアップが破損していることを暗示する文字が含まれていました）
• 341個（7％）はXMLスタイルのコロン名前空間を使っています（ただし、HTMLとしてはXML名前空間は使っていません）
• 3,207個（66％）は有効なカスタム要素の名前です
• 1,211個（25％）はグローバルな名前空間にあります（非標準であり、ダッシュもコロンもありません）
  • うち、216個は2文字以上で、<cript>、<spsn>または<artice>などの標準要素名からレーベンシュタイン距離が1であるため、タイプミスの可能性としてフラグを立てました。ただし、これらの一部（ <jdiv>など）には意図的なものも含まれています。

付け加えると、デスクトップページの15％とモバイルページの16％には、既に廃止された要素が含まれています。

図3.6の説明を表示

デスクトップの8.31％（モバイルの7.96％）で使用中の「center」、デスクトップサイトの8.01％（モバイルの7.38％）で使用中の「font」、デスクトップサイトの1.07％（モバイルの1.20％）で使用中の「marquee」 、デスクトップサイトの0.71％（モバイルの0.55％）で使用中の「nobr」、デスクトップサイトの0.53％（モバイルの0.47％）で使用中の「big」、デスクトップサイトの0.39%（モバイルの0.35％）で使用中の「frameset」、デスクトップサイトの0.39％（モバイルの0.35％）による「frame」の使用、デスクトップサイトの0.33％（モバイルの0.27％）による「strike」、デスクトップサイトの0.25％（モバイルの0.27％）で使用中の「noframes」を示す棒グラフ。

上記の図3.6は、最も頻繁に使われている非推奨の要素トップ10を表しています。これらは非常に小さな数値に見えますが、この観点は重要です。

価値観と使用法

要素の使い方に関する数値（標準、非推奨、またはカスタム）を議論する為には、まず何らかの観点を確立する必要があります。

図3.7の説明を表示

使用される要素を減少の割合で降順で並べた棒グラフ：html、head、body、titleは使用率99％を超えるています、meta、a、divは98％を超える使用率です、link、script、img、spanが90％を超 えています、ul、li、p、style、input、br、formなどが70%を超えています、h2、h1、iframe、h3、button、footer、header、navは50％を超えています、50％未満からほぼ0％に低下するその他のあまり知られていないタグもあります。

上記の図3.7は、ページ中に現れたかどうかでカウントされた要素のトップ150を表示しています。利用率がどのように落ちていくかに着目してください。

ページの90%以上で使われている要素は11個しかありません。

• <html>
• <head>
• <body>
• <title>
• <meta>
• <a>
• <div>
• <link>
• <script>
• <img>
• <span>

上を除き、ページ中50％以上使われている要素は15個だけです。

• <ul>
• <li>
• <p>
• <style>
• <input>
• <br>
• <form>
• <h2>
• <h1>
• <iframe>
• <h3>
• <button>
• <footer>
• <header>
• <nav>

また、ページ中に5％以上使われている要素は40個のみでした。

<video>でさえ、ぎりぎりその範囲内に収まっていません。デスクトップデータセット内の4％という結果で現れています（モバイルでは3％）。この数字はとても低いように聞こえますが、実のところ4％はかなり人気だったりします。事実、ページ中1％以上の要素は98個しかありません。

これらの要素の分布を抑え、どの要素が1％以上使われているのかを見るのは興味深いことです。

図3.8の説明を表示

HTML、SVG、Math MLを示す散布図は比較的少数のタグを使用しますが、非標準要素（「in global ns」、「dasherized」、「colon」に分けられる）ははるかに広がっています。

図3.8は、各要素の順位とそれらがどのカテゴリに属するかを示しています。データポイントを単純に見ることができるように、個別の塊へ分割しました（そうしなければ、全データを表現するために十分なピクセル領域がありませんでした）、これは人気を一つの「線」として表します。一番下が最も一般的で、上が一般的では無いものです。矢印は、ページの1％以上に表示される要素の終端を指しています。

ここでは2つのことを確認できます。まず、使用率が1％を超える要素の塊は、HTMLだけではありません。実際、最も人気のある100個の要素のうち27個はHTMLではなくSVGです！ さらに、その隙間または近くには非標準のタグもあります！そして多くのHTML要素がページ毎に1％未満として現れている事に注意してください。

では、これらのページで1％の利用率となっている要素はすべて無駄ですか？、いいえ絶対にあえりえません。これが視点を確立することが重要な理由です。Webには約20億のWebサイトがあります。データセットのすべてのWebサイトの0.1％に何かが表示される時、これはWeb全体で約200万のWebサイトを表していると推定できます。0.01％でさえ20万のサイトを推定できます。これは、良い思想では無い古い要素であったとしても、めったに要素のサポートを打ち切らない理由でもあります。数十万または数百万のサイトを壊すことは、ブラウザベンダーが簡単にできることではありません。

ほとんどの要素は、ネイティブの物も含めてページの1％未満として現れていますが、それでも非常に重要であり成功しています。たとえば<code>は私が頻繁に使用する要素です。 これは間違いなく便利で重要ですが、ページの0.57％でしか使われていません。この部分は私達の測定対象に基づいているため偏っています。通常、ホームページは特定の種類のもの（たとえば<code> など）が含まれる可能性は低いでしょう。例えば、ホームページでは見出し、段落、リンク、リスト以外はあまり一般的ではないでしょう。ただし、データには一般的に価値があります。

また、著者が定義した（ネイティブではない）.shadowRootを含むページに関する情報も収集しました。デスクトップページの約0.22％とモバイルページの約0.15％にシャドウルートが確認できています。数が少ないように聞こえるかもしれませんが、これはモバイルデータセット内の約6.5kサイトとデスクトップ上の10kサイトであり、いくつかのHTML要素よりも多くなっています。たとえば、<summary> はデスクトップ上で同レベルで利用されており、146番目に人気のある要素です。<datalist> はホームページの0.04％に使われており、201番目に人気のある要素です。

実際、HTMLで定義されている要素の15％以上は、デスクトップデータセットのトップ200から圏外です。<meter>は、HTMLがLiving Standardモデルに移行する前、2004-2011頃の最も人気のない「HTML5時代」の要素です。そしてこの要素の人気は1,000番目です。最近導入された要素（2016年4月）である<slot>の人気は1,400番目となっています。

大量データ：実際のWeb上の実際のDOM

データセット中のネイティブ/標準機能をどのように使っているかと言う観点を念頭に置いて、非標準のものについて話しましょう。

測定したほとんどの要素は単一のWebページでのみ使用されると思われるかもしれませんが、実際には5,048個の要素すべてが複数のページに出現しています。データセット中、最も出現数が少ない要素は15ページに存在しています。そして、約5分の1は100ページ以上に存在します。約7％は1,000ページ以上に存在します。

データ分析を支援するためにGlitchで小さなツールhttps://rainy-periwinkle.glitch.meを共同で作りました。このツールはあなたも使うことができます。そして、あなたの観測した内容をパーマリンクと共に@HTTPArchiveへシェアしてください。（Tommy Hodginsは、同じように洞察に使えるCLIツールhttps://github.com/tomhodgins/hadeを作成しています。）

それでは、いくつかのデータを見ていきましょう。

製品（およびライブラリ）とそのカスタムマークアップ

いくつかの標準でない要素の普及率については、ファーストパーティの採用をしたというより、人気のあるサードパーティのツールに含まれていることが関係しているでしょう。たとえば <fb:like> 要素は0.03%のページで見つかります。これはサイト所有者が意図的に記述しているのではなく、Facebookウィジェットに含まれているためです。Hixieが14年前に言及したhttps://web.archive.org/web/20060203031245/http://code.google.com/webstats/2005-12/editors.html要素のほとんどは減少しているように見えますが、大部分が残っています。

• Claris Home Pagehttps://en.wikipedia.org/wiki/Claris_Home_Page（最後の安定版は21年前）で作られた一般的要素は、100ページ以上にまだ現れてます。 たとえば、<x-claris-window>は130ページに現れています。
• 英国のeコマースプロバイダーであるOxatishttps://www.oxatis.co.ukの<actinic:*> 要素の一部はさらに多くのページに出現しています。たとえば、<actinic:basehref>はデスクトップデータ中の154ページに出現しています。
• Macromediaの要素はほとんど消えたようです。一覧にはたった一つの要素<mm:endlock>だけが現れており、その数はわずか22ページだけです。
• Adobe Go-Liveの<csscriptdict>は、デスクトップデータセットの640ページに引き続いて現れています。
• Microsoft Officeの<o:p>要素は、2万ページ以上のデスクトップページとなる0.5％に引き続いて現れています。

そして、Hixieのオリジナルレポートにはなかった多くの新しい要素も現れました。

• <ym-measure>は、YandexのMetrica analytics packagehttps://www.npmjs.com/package/yandex-metrica-watchによって挿入されるタグです。デスクトップとモバイルページの1％以上で使われており、最も利用されている要素トップ100でその地位を確立しています。すごい！
• 今は亡きGoogle Plusの<g:plusone>は、2万1千ページ以上で出現しています。
• Facebookの<fb:like>は、14,000のモバイルページで出現しています。
• 同様に、<fb:like-box>は7.8kモバイルページで出現しています。
• <app-root>は、Angularなどのフレームワークで一般的に含まれており、8.2kモバイルページに出現しています。

これらを5％未満のネイティブHTML要素と比べてみましょう。

図3.9の説明を表示

videoは184,149サイト、canvasは108,355、ym-measure（製品固有のタグ）は52,146、コードは25,075、g:plusone（製品固有のタグ）は21,098、fb:like（製品固有のタグ）は12,773、fb:like-box（製品固有のタグ）は6,792、app-root（製品固有のタグ）は8,468、summaryは6,578、templateは5,913、meterは0を示す棒グラフ。

このような興味深い洞察を一日中行うことができます。

これは少々違うものですが、人気のある要素には製品のエラーによって引き起こされる可能性もあります。たとえば1,000を超えるサイトで<pclass="ddc-font-size-large"> が出現しています。しかしこれは、これは人気のある”as-a-service”製品がスペースを取り忘れているために発生していました。幸いなことに、このエラーは調査中に報告されて、すぐに修正されました。

Hixieはオリジナルの論文で次のように述べています。

この非標準マークアップに対して楽天的でいられる間は少なくとも、これらの要素にはベンダープレフィックスを明確に利用しているため、これは良い考えだと言えます。これにより、標準化団体が新しく作る要素と属性が、それらと衝突する可能性を大幅に減らすことができます。

ただし、上で述べた通りこれは一般的ではありません。記録できた非標準要素の25％以上は、グローバル名前空間の汚染を避けるために、いかなる名前空間戦略も使っていません。例えば、モバイルデータセットにある1157個の要素一覧https://rainy-periwinkle.glitch.me/permalink/53567ec94b328de965eb821010b8b5935b0e0ba316e833267dc04f1fb3b53bd5.htmlを表示します。見ての通り、これらの多くは曖昧な名前やつづりの間違など、問題がない可能性があります。しかし、少なくともこれはいくつかの挑むべき課題を示しています。例えば、 <toast>（Google社員が<std-toast>として最近提案しようとした仕様https://www.chromestatus.com/feature/5674896879255552）がこの一覧に含まれています。

それほど難しくない一般的な要素もいくつかあります。

• Yahoo Mapsの<ymaps>は、〜12.5kのモバイルページに出現します。
• 2008年のフォント置換ライブラリである<cufon>と <cufontext>は、〜10.5kモバイルページに出現しています。
• <jdiv>要素は、Jivo chatの製品によって挿入されており、〜40.3kモバイルページに出現しています。

前回のチャートに今回のデータを配置すると、次のようになります（改めて、データセットに基づいて少しだけ変わっています）

図3.10の説明を表示

videoは184,149サイトで使用され、canvasは108,355、ym-measureは52,416、codeは25,075、g:plusoneは21,098、db:likeは12,773、cufonは10,523、ymapsは8,303、fb:like-boxは6,972、app-rootが8,468、summaryが6,578、templateが5,913、meterが0を示す棒グラフ。

この結果には興味深い点があります、それは一つのツールが他の便利になる手段も提供していると言うことです。データ空間を調べることに興味がある場合に、具体的なタグ名は想定される尺度の一つでしかありません。良い「俗語」の発展を見つけることができれば、それは間違いなく最強の指標でしょう。しかし、それが私たちの興味の範囲外である場合はどうなりますか？

一般的なユースケースとソリューション

たとえば、一般的なユースケースの解決に興味が人々の場合はどうでしょうか？これは、現在抱えているユースケースに対応したソリューションを探している場合や、標準化を促進するために人々が解決しようとしている一般的なユースケースをさらに研究するようなものがあります。一般的な例として「タブ」を取り上げます。長年にわたって、タブのようなものに対して多くの要求がありました。あいまいな検索をしてみるとタブには多くのバリエーションhttps://rainy-periwinkle.glitch.me/permalink/c6d39f24d61d811b55fc032806cade9f0be437dcb2f5735a4291adb04aa7a0ea.htmlがあることがわかります。同一のページに2つの要素が存在しているかを簡単に識別できないため、利用されているかどうかを数えるのは少し難しくなります。そのためこの計測条件は地味ですが、最大のカウントを持つものを単純に使用します。ほとんどの場合、実際のページ数はそれより大幅に増えるでしょう。

また、数多くのアコーディオンhttps://rainy-periwinkle.glitch.me/permalink/e573cf279bf1d2f0f98a90f0d7e507ac8dbd3e570336b20c6befc9370146220b.htmlやダイアログhttps://rainy-periwinkle.glitch.me/permalink/0bb74b808e7850a441fc9b93b61abf053efc28f05e0a1bc2382937e3b78695d9.html、少なくとも65種類のカルーセルhttps://rainy-periwinkle.glitch.me/permalink/651e592cb2957c14cdb43d6610b6acf696272b2fbd0d58a74c283e5ad4c79a12.html、それとポップアップhttps://rainy-periwinkle.glitch.me/permalink/981967b19a9346ac466482c51b35c49fc1c1cc66177ede440ab3ee51a7912187.htmlに関するもの、そして最低でも27種類存在するトグルとスイッチhttps://rainy-periwinkle.glitch.me/permalink/2e6827af7c9d2530cb3d2f39a3f904091c523c2ead14daccd4a41428f34da5e8.htmlがあります。

おそらくですが、非ネイティブである92種類のボタン要素https://rainy-periwinkle.glitch.me/permalink/5ae67c941395ca3125e42909c2c3881e27cb49cfa9aaf1cf59471e3779435339.htmlが必要な理由を調査することで、ネイティブとのギャップを埋めようとすることができます。

人気の有るものがポップアップ（<jdiv>などのチャット）という事に気付く事ができれば 、私達の知っている知識（たとえば、<jdiv>についての目的や<olark>）を知り、それらに取り組むために作り上げた43のことhttps://rainy-periwinkle.glitch.me/permalink/db8fc0e58d2d46d2e2a251ed13e3daab39eba864e46d14d69cc114ab5d684b00.htmlを見て、そこを辿りながら空間を調査することができます。

結論

なのでここには多くのデータがありますが、要約すると。

• ページ中の要素は、14年前よりも平均と最大の両方で増えています。
• ホームページ上に存在する要素の寿命は非常に長いでしょう。要素を非推奨やサポート停止にしたとしても、消えることはありません。
• 世の中には多くの壊れたマークアップがあります。（タグのつづり間違い、スペースの抜け、エスケープ間違い、誤解）
• 「有益」である事を測定するのは難しいでしょう。多くのネイティブ要素は5％の敷居、さらには1％敷居を超えることはありませんが、多くのカスタム要素は多くの理由でその敷居を越えます。少なくとも1%を超えたものには注目をするべきかもしれませんが、データを見る限りは割と良い成功を収めているようなので、おそらく0.5％とすべきでしょう。
• 既に大量のカスタムマークアップがあります。様々な形式がありますが、ダッシュを含む要素は確実に削除されたようです。
• 牛の通り道を舗装する(pave the cowpaths)ために、このデータをさらに調査して、適切な観測結果を出す必要があります。

最後はあなたの出番です。大規模なコミュニティの創造性と好奇心を利用し、いくつかのツール(https://rainy-periwinkle.glitch.me/など)を使うことでこのデータを探索することができます。興味深い観察結果を共有して、知識と理解の共有の場を作ってください。

メディア

序章

画像、アニメーション、動画はウェブ体験の重要な一部です。それらが重要な理由はたくさんあります。ストーリーを伝えたり、視聴者の関心を引きつけたり、他のウェブ技術では簡単には作れないような芸術的な表現を提供したりするのに役立ちます。これらのメディアリソースの重要性は、2つの方法で示すことができます。1つは、1ページのダウンロードに必要なバイト数の多さ、もう1つはメディアで描かれたピクセル数の多さです。

純粋なバイトの観点から見ると、HTTP Archiveは歴史的に報告されているhttps://legacy.httparchive.org/interesting.php#bytesperpageメディアから関連付けられたリソースバイトの平均3分の2を持っています。分布の観点から見ると、事実上すべてのウェブページが画像や動画に依存していることがわかります。10パーセンタイルでさえ、我々はバイトの44％がメディアからであり、ページの90パーセンタイルで総バイトの91％に上昇できることを参照してください。

図4.1の説明を表示

10パーセンタイルでページバイトの44.1％がメディア、25パーセンタイルで52.7％がメディア、50パーセンタイルで67.0％がメディア、75パーセンタイルで81.7％がメディア、90パーセンタイルで91.2％がメディアであることを示す棒グラフです。

メディアは視覚体験には欠かせないものですが、この大量のバイトのインパクトには2つの副作用があります。

まず、これらのバイトをダウンロードするために必要なネットワークのオーバーヘッドは大きく、携帯電話や低速ネットワーク環境（コーヒーショップやUberに乗っているときのテザリングのような）では劇的にページのパフォーマンスを遅くできます。画像はブラウザによる優先度の低いリクエストですが、ダウンロード中のCSSやJavaScriptを簡単にブロックできます。これ自体がページのレンダリングを遅らせることになります。しかし、画像コンテンツは、ページの準備ができたことをユーザーに視覚的に伝える手がかりとなります。そのため、画像コンテンツの転送が遅いと、ウェブページが遅いという印象を与えることがあります。

2つ目の影響は、ユーザーへの金銭的なコストです。これはウェブサイトの所有者の負担ではなく、エンドユーザーの負担となるため、しばしば無視されがちな側面です。逸話として、日本のようなhttps://x.com/yoavweiss/status/1195036487538003968?s=20という市場では、データの上限に達した月末近くは学生の購買意欲が低下し、ユーザーはビジュアルコンテンツを見ることができなくなるということが伝えられています。

さらに、世界のさまざまな地域でこれらのウェブサイトを訪問するための金銭的コストは不釣り合いです。中央値と90パーセンタイルでは、画像のバイト数はそれぞれ1MBと1.9MBです。WhatDoesMySiteCost.comhttps://whatdoesmysitecost.com/#gniCostを使用すると、マダガスカルのユーザーの一人当たりの国民総所得（GNI）コストは90パーセンタイルでウェブページを1回読み込んだだけで、一日の総所得の2.6％になることがわかります。対照的に、ドイツでは、これは1日の総所得の0.3％になります。

図4.2の説明を表示

モバイルの中央値のウェブページでは、90パーセンタイルで1MBの画像と4.9MBの画像が必要です。

ページあたりのバイト数を見ると、ページパフォーマンスとユーザーに対するコストだけを見ることになりますが、それは利点を見落としています。これらのバイトは、画面上のピクセルをレンダリングするために重要です。このように、1ページあたりに使用されるメディアのピクセル数を見ることで、画像や動画リソースの重要性を見ることができます。

ピクセル量を見るときに考慮すべき3つのメトリクスがあります。CSSピクセル、ナチュラルピクセル、スクリーンピクセルです。

• CSSピクセルボリューム はCSSの観点からのレイアウトです。この尺度は、画像や動画を引き伸ばしたり、押し込んだりできる境界ボックスに焦点を当てています。また、実際のファイルのピクセルや画面表示のピクセルは考慮されていません。
• ナチュラルピクセル とは、 ファイル内で表現される論理的なピクセルのことを指します。この画像をGIMPやPhotoshopで読み込んだ場合、ピクセルファイルの寸法は自然なピクセルとなります。
• スクリーンピクセル とは、ディスプレイ上の物理的な電子機器を指します。携帯電話や最新の高解像度ディスプレイが登場する以前は、CSSピクセルとスクリーン上のLEDポイントの間には1:1の関係がありました。しかし、モバイルデバイスは目に近づけられ、ノートPCの画面は昔のメインフレーム端末よりも近づけられているため、現代のスクリーンは従来のCSSピクセルに対する物理ピクセルの比率が高くなっています。この比率は、Device-Pixel-Ratio、または口語でRetina™ディスプレイと呼ばれています。

図4.3の説明を表示

画像コンテンツに割り当てられているCSSの画素数を、実際の画像の画素数と比較した結果、10パーセンタイル（実測は0.07MP、CSSは0.04MP）、25パーセンタイル（実測は0.38MP、CSSは0.18MP）、50パーセンタイル（実測は1.6MP、CSSは0.65MP）、75パーセンタイル（実測は5.1MP、CSSは1.8MP）、90パーセンタイル（実測は12MP、CSSは4.6MP）が表示されていることがわかります。

図4.4の説明を表示

画像コンテンツに割り当てられたCSSの画素数をデスクトップ用の実際の画像の画素数と比較した結果、10パーセンタイル（実際は0.09MP、CSSは0.05MP）、25パーセンタイル（実際は0.52MP、CSSは0.29MP）、50パーセンタイル（実際は2.1MP、CSSは1.1MP）、75パーセンタイル（実際は6.0MP、CSSは2.8MP）、90パーセンタイル（実際は14MP、CSSは6.3MP）が表示されています。

CSSピクセルと自然ピクセル量を見ると、中央値のウェブサイトは1メガピクセル (MP) のメディア コンテンツを表示するレイアウトになっていることがわかります。90パーセンタイルでは、CSSレイアウトのピクセル量はモバイルで4.6MP、デスクトップで6.3MPに増加しています。これはレスポンシブレイアウトが、異なる可能性が高いだけでなく、フォームファクターが異なることも興味深い。要するに、モバイルレイアウトはデスクトップに比べてメディアに割り当てられるスペースが少ないということです。

対照的に、ナチュラル（ファイル）ピクセル量はレイアウト量の2～2.6倍です。デスクトップウェブページの中央値は2.1MPのピクセルコンテンツを送信し、1.1MPのレイアウトスペースに表示されます。モバイルでは、90パーセンタイルの割合で12MPが4.6MPに圧縮されていることがわかります。

もちろん、モバイルデバイスのフォームファクターはデスクトップとは異なります。デスクトップが大きく主に横向きで使用されるのに対し、モバイルデバイスは小さく通常縦向きで使用されます。前述したように、モバイルデバイスは目から近い位置にあるため、一般的にデバイスピクセル比（DPR）が高く、タイムズスクエアのビルボードに必要なピクセル数と比べて1インチあたりのピクセル数が多く必要となります。これらの違いにより、レイアウトの変更を余儀なくされ、モバイルのユーザーはコンテンツの全体を消費するためにサイトをスクロールするのが一般的です。

メガピクセルは、主に抽象的な指標であるため、難しい指標です。ウェブページで使用されているピクセルの量を表現するのに便利な方法は、ディスプレイサイズに対する比率として表現することです。

ウェブページのクロールで使用したモバイル端末では、512 x 360の表示で、0.18MPのCSSコンテンツが表示されています（物理的な画面である3xや3^2以上の画素である1.7MPと混同しないように）。このビューアーのピクセル量を画像に割り当てられたCSSピクセルの数で割ると、相対的なピクセル量が得られます。

もし、画面全体を完璧に埋め尽くす画像が1枚あったとしたら、これは1xピクセルの塗りつぶし率になります。もちろん、ウェブサイトが1枚の画像でキャンバス全体を埋め尽くすことはほとんどありません。メディアコンテンツは、デザインや他のコンテンツと混在する傾向があります。1xよりも大きい値はレイアウトが追加の画像コンテンツを見るため、ユーザーが、スクロールする必要があることを意味します。

図4.5の説明を表示

実際の画面サイズCSSピクセルと比較したページあたりに必要なピクセル量の比較では、10パーセンタイル（モバイル20%、デスクトップ2%）、25パーセンタイル（モバイル97%、デスクトップ13%）、50パーセンタイル（モバイル354%、デスクトップ46%）、75パーセンタイル（モバイル1003%、デスクトップ123%）、および90パーセンタイル（モバイル2477%、デスクトップ273%）が示されています。

デスクトップの中央値のウェブページでは、画像や動画を含むレイアウトが表示されるのはディスプレイの46％に過ぎません。対照的に、モバイルでは、メディアピクセルの量が実際のビューポートサイズの3.5倍を埋めています。レイアウトは、1つの画面で埋められる以上のコンテンツがあり、ユーザーはスクロールする必要があります。最低でも、1サイトあたり3.5ページ分のコンテンツがスクロールしていることになります（飽和度100％を想定）。モバイルの90パーセンタイルでは、これはビューポートサイズの25倍にまで大幅に拡大します！

メディアリソースは、ユーザーエクスペリエンスにとって非常に重要です。

画像

バイトの削減とユーザー体験の最適化に役立つ画像の管理と最適化については、すでに多くのことが書かれています。ブランド体験を定義するのはクリエイティブなメディアであるため、多くの人にとって重要かつクリティカルなトピックとなっています。したがって画像や動画コンテンツの最適化は、意図した体験の忠実性を維持しながら、ネットワーク上で転送されるバイト数を減らすのに役立つベストプラクティスを適用することとの間のバランスをとる行為です。

画像、動画、アニメーションに利用されている戦略は、大まかに似ていますが、具体的なアプローチは大きく異なります。一般的には、これらの戦略は次のようなものです。

• ファイル形式 - 最適なファイル形式を利用
• レスポンシブ - レスポンシブ画像技術を適用して、画面に表示されるピクセルだけを転送する
• 遅延ローディング - 人が見たときだけコンテンツを転送する
• アクセシビリティ - 全人類に一貫した体験を提供する

画像を利用していないウェブページを見つけることは稀です。長年にわたり、ウェブ上でコンテンツを表示するためのさまざまなファイルフォーマットが登場してきましたが、それぞれが異なる問題に対処してきました。主に4つの普遍的な画像フォーマットがあります。JPEG、PNG、GIF、およびSVGです。さらに、Chromeではメディア パイプラインが強化され、5つ目の画像フォーマットのサポートが追加されました。WebP。他のブラウザでも同様にJPEG2000（Safari）、JPEG-XL（IEとEdge）、HEIC（SafariではWebViewのみ）のサポートが追加されています。

それぞれのフォーマットにはそれぞれメリットがあり、Web上での理想的な使い方があります。とても簡単にまとめると以下のようになります。

画像フォーマット

すべてのページを見てみると、これらのフォーマットの普及率が、高いことがわかります。ウェブ上でもっとも古いフォーマットの1つであるJPEGは画像リクエストの60％、全画像バイトの65％で圧倒的に、もっとも一般的に使用されている画像フォーマットです。興味深いことに、PNGは画像要求とバイト数の28％で2番目によく使われている画像フォーマットです。色の正確さやクリエイティブなコンテンツの精度に加えて、サポートがどこにでもあることが広く使われている理由と考えられます。対照的に、SVG、GIF、WebPは4％とほぼ同じ使用率です。

図4.7の説明を表示

ツリーマップを見ると、JPEGが60.27％、PNGが28.2％、WebPが4.2％、GIFが3.67％、SVGが3.63％となっています。

もちろん、ウェブページの画像コンテンツの使い方は一様でありません。画像に依存しているページもあれば、いくつかは他よりも画像に依存しています。google.comのホームページを見てみると、一般的なニュースサイトに比べて画像はほとんどないことがわかります。実際、中央値のウェブサイトには13枚の画像があり、90パーセンタイルでは61枚、99パーセンタイルでは229枚の画像があります。

図4.8の説明を表示

10パーセンタイルでは画像フォーマットが全く使用されていないことを示す棒グラフ、25パーセンタイルではJPGが3枚とPNGが4枚、50パーセンタイルではJPGが9枚、PNGが4枚、GIFが1枚、75パーセンタイルではJPEGが39枚、PNGが18枚、SVGが2枚、GIFが2枚、p99パーセンタイルではJPGが119枚、PNGが49枚、WebPが28枚、SVGが19枚、GIFが14枚使用されていることを示しています。

中央値のページではJPEGが9枚、PNGが4枚となっており、GIFが使用されているのは上位25％のページのみで、採用率は報告されていません。1ページあたりの各フォーマットの使用頻度は、より近代的なフォーマットの採用についての洞察を提供していません。具体的には、各フォーマットに少なくとも1枚の画像が含まれているページの割合は？

図4.9の説明を表示

棒グラフで見ると、90%のページでJPEGが使用されており、89%がPNG、9%がWebP、37%がGIF、22%がSVGとなっています。

これは、90パーセンタイルのページでさえWebPの頻度がゼロである理由を説明するのに役立ちます。WebPがイメージに適していない理由はたくさんありますが、メディアのベストプラクティスの採用は、WebP自体の採用のようにまだ初期段階にとどまっています。

画像ファイルのサイズ

画像ファイルのサイズを見るには、リソースあたりの絶対バイト数とピクセルあたりのバイト数の2つの方法があります。

図4.10の説明を表示

10パーセンタイルではJPEGの4KB、PNGの2KB、GIFの2KBが使用され、25パーセンタイルではJPGの9KB、PNGの4KB、WebPの7KB、GIFの3KBが使用され、50パーセンタイルではJPGの24KB、PNGの11KB、WebPの17KB、GIFの6KBが使用されていることを示すチャート。SVGの1KBが使用され、75パーセンタイルではJPEGの68KB、PNGの43KB、WebPの41KB、GIFの17KB、SVGの2KBが使用され、90パーセンタイルではJPGの116KB、PNGの152KB、WebPの90KB、GIFの87KB、SVGの8KBが使用されています。

このことから、ウェブ上の典型的なリソースの大きさや小ささを知ることができます。しかし、これではこれらのファイル分布の画面上で表現されているピクセルの量を知ることはできません。これを行うには、各リソースのバイト数を画像の自然なピクセル数で割ることができます。1ピクセルあたりのバイト数が低いほど、視覚コンテンツの伝送効率が高いことを示しています。

図4.11の説明を表示

ローソク足チャートは、10パーセンタイルでは、JPEGが0.1175byte/pixel、PNGが0.1197byte/pixel、GIFが0.1702byte/pixel、WebPが0.0586byte/pixel、SVGが0.0293byte/pixelであることを示しています。25パーセンタイルでは、JPEGが0.1848byte/pixel、PNGが0.2874byte/pixel、GIFが0.3641byte/pixel、WebPが0.1025byte/pixel、SVGが0.174byte/pixelとなっています。50パーセンタイルでは、JPEGが0.2997byte/pixel、PNGが0.6918byte/pixel、GIFが0.7967byte/pixel、WebPが0.183byte/pixel、SVGが0.6766byte/pixelとなっています。75パーセンタイルでは、JPEGが0.5456byte/pixel、PNGが1.4548byte/pixel、GIFが2.515byte/pixel、WebPが0.3272byte/pixel、SVGが1.9261byte/pixelとなっています。90パーセンタイルでは、JPEGが0.9822byte/pixel、PNGが2.5026byte/pixel、GIFが8.5151byte/pixel、WebPが0.6474byte/pixel、SVGが4.1075byte/pixelとなっています。

以前はGIFファイルがJPEGよりも小さいと思われていましたが、今ではJPEGのリソースが大きくなった原因はピクセルボリュームにあることがはっきりとわかります。おそらく、GIFが他のフォーマットと比較して非常に低いピクセル密度を示していることは驚きではありません。さらにPNGは高いビット深度を扱うことができ、クロマサブサンプリングのぼやけに悩まされることはありませんが、同じピクセルボリュームではJPGやWebPの約2倍のサイズになります。

なお、SVGに使用されるピクセル量は、画面上のDOM要素のサイズ（CSSピクセル）です。ファイルサイズの割にはかなり小さいですが、これは一般的にSVGがレイアウトの小さい部分で使用されていることを示唆しています。これが、PNGよりも1ピクセルあたりのバイト数が悪く見える理由です。

繰り返しになりますが、この画素密度の比較は、同等の画像を比較しているわけではありません。むしろ、典型的なユーザー体験を報告しているのです。次に説明するように、これらの各フォーマットでも、ピクセルあたりのバイト数をさらに最適化して減らすために使用できる技術があります。

画像フォーマットの最適化

体験に最適なフォーマットを選択することは、フォーマットの能力のバランスをとり、総バイト数を減らすことです。ウェブページの場合、画像を最適化することでウェブパフォーマンスを向上させることが1つの目標です。しかし、それぞれのフォーマットには、バイト数を減らすのに役立つ追加機能があります。

いくつかの機能は、総合的な体験に影響を与えることができます。たとえばJPEGやWebPでは、量子化（一般的には品質レベルと呼ばれる）や クロマサブサンプリング を利用でき、視覚的な体験に影響を与えることなく、画像に格納されているビット数を減らすことができます。音楽用のMP3のように、この技術は人間の目のバグに依存しており、カラーデータが失われるにもかかわらず同じ体験を可能にします。しかし、すべての画像がこれらの技術に適しているわけではありません。

他のフォーマット機能は、単にコンテンツを整理するだけで、時には文脈に沿った知識を必要とします。たとえばJPEGのプログレッシブエンコーディングを適用すると、ピクセルはスキャンレイヤーに再編成されブラウザはより早くレイアウトを完成させることができ、同時にピクセル量を減らすことができます。

1つのLighthouseテストは、ベースラインとプログレッシブにエンコードされたJPEGをA/Bで比較するものです。これは画像全体がロスレス技術でさらに最適化されるか、また異なる品質レベルを使用するなど、潜在的には不可逆技術で最適化されるかどうかを示すための気付きを提供しています。

図4.12の説明を表示

10パーセンタイルでは100%の画像が最適化されており、25パーセンタイルでも同様で、50パーセンタイルでは98%の画像が最適化されており（2%は最適化されていない）、75パーセンタイルでは83%の画像が最適化されており（17%は最適化されていない）、90パーセンタイルでは59%の画像が最適化されており、41%の画像が最適化されていないことを示す棒グラフです。

このAB Lighthouseテストでの節約は、p95で数MBに達することができる潜在的なバイトの節約だけでなく、ページパフォーマンスの向上を実証しています。

図4.13の説明を表示

10パーセンタイルでは0ms、25パーセンタイルでも同じ、50パーセンタイルでは150ms、75パーセンタイルでは1,460ms、90パーセンタイルでは5,720msの保存が可能であることを示す棒グラフです。

レスポンシブ画像

ページパフォーマンスを向上させるもう1つの軸として、レスポンシブ画像の適用があります。これは、画像の縮小によってディスプレイに表示されない余分なピクセルを減らすことで、画像のバイト数を減らすことに重点を置いた手法です。この章の最初の方でデスクトップの中央のウェブページでは、1MPの画像プレースホルダーが使用されているにもかかわらず、実際のピクセル量は2.1MP転送されていることを見ました。これは1xDPRテストだったので、1.1MPのピクセルがネットワーク経由で転送されましたが、表示されませんでした。このオーバーヘッドを減らすために、2つの技術のうちの1つを使用できます（3つの可能性もあります）。

• HTMLマークアップ - srcset要素とsizes要素を組み合わせて使用することで、ブラウザはビューポートの寸法とディスプレイの密度に基づいて最適な画像を選択できます。
• クライアントヒント - これは、リサイズ可能な画像の選択をHTTPコンテントネゴシエーションに移行させます。
• 特典: JavaScriptライブラリーは、JavaScriptがブラウザーDOMを実行して検査し、コンテナーに基づいて正しい画像を挿入できるようになるまで画像のロードを遅らせます。

HTMLマークアップの使用

レスポンシブ画像を実装するもっとも一般的な方法は、<img srcset> または <source srcset>のいずれかを用いて代替画像のリストを作成することです。srcsetがDPRに基づいている場合、ブラウザは追加情報なしでリストから正しい画像を選択できます。しかし、ほとんどの実装では、srcsetのピクセルサイズに基づいて正しい画像を選択するため必要なレイアウト計算の方法をブラウザへ指示するため<img sizes>を利用しています。

図4.14の説明を表示

18%の画像が「sizes」を使用しており、21%が「srcset」を使用しており、2%が「picture」を使用していることを示す棒グラフです。

アートディレクションhttps://developer.mozilla.org/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images#Art_directionのような高度なレスポンシブウェブデザイン（RWD）レイアウトによく使われていることを考えると、<picture>の使用率が著しく低いのは驚くべきことでありません。

サイズの使用

srcsetの有用性は、通常はsizesメディアクエリの精度に依存します。sizesがないと、ブラウザは<img>タグが小さいコンポーネントではなくビューポート全体を埋め尽くすと仮定します。興味深いことに、ウェブ開発者が<img sizes>に採用している共通のパターンは5つあります。

• <img sizes="100vw"> - これは画像がビューポートの幅を埋め尽くすことを示します（デフォルトでもあります）。
• <img sizes="200px"> - これは、DPRに基づいてブラウザを選択する際に便利です。
• <img sizes="(max-width: 300px) 100vw, 300px"> - これは2番目に人気のあるデザインパターンです。これはWordPressとおそらく他のいくつかのプラットフォームで自動生成されるものです。元の画像サイズ（この場合は300px）に基づいて自動生成されているように見えます。
• <img sizes="(max-width: 767px) 89vw, (max-width: 1000px) 54vw, ..."> - このパターンは、CSSレスポンシブレイアウトに合わせてカスタムビルドしたデザインパターンです。ブレークポイントごとに使用するサイズの計算が異なります。

• <img sizes="auto"> - これはもっともよく使われている使い方ですが、実際には非標準であり、lazy_sizesJavaScriptライブラリの使用によるものです。これはクライアント側のコードを使って、ブラウザのためにより良いsizesの計算を注入します。これの欠点は、JavaScriptの読み込みとDOMの準備が完全に整っているかどうかに依存し、画像の読み込みが大幅に遅れることです。

図4.16の説明を表示

1,130万枚の画像が「img sizes=(max-width: 300px) 100vw, 300px」を使用しており、「auto」が160万枚、「img sizes=(max-width: 767px) 89vwなどなど」が100万枚、「100vw」が23万枚、「300px」が13万枚であることを棒グラフで示しています。

クライアントヒント

クライアントヒントhttps://web.dev/user-agent-client-hints/ は、コンテンツ制作者が画像のリサイズをHTTPコンテンツネゴシエーションに移すことを可能にします。この方法では、HTMLはマークアップを乱雑にするための追加の <img srcset> を必要とせず、代わりにサーバや 最適な画像を選択するための画像CDNhttps://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67 に依存できます。これによりHTMLの簡素化が可能になり、オリジンサーバが時間の経過とともに適応し、コンテンツ層とプレゼンテーション層を切り離すことが可能になります。

クライアントヒントを有効にするには、ウェブページでブラウザに追加のHTTPヘッダーAccept-CH: DPR, Width, Viewport-Widthを使ってシグナルを送る必要があります。 または HTML<meta http-equiv="Accept-CH" content="DPR, Width, Viewport-Width">を追加します。どちらか一方の手法の利便性は実装するチームに依存し、どちらも利便性のために提供されています。

図4.17の説明を表示

71%が’meta http-equiv’を使用し、30% が’Accept-CH’HTTPヘッダーを使用し、1%が両方を使用していることを示す棒グラフです。

HTMLでクライアントヒントを呼び出すために<meta>タグを使うのは、HTTPヘッダーに比べてはるかに一般的です。これは、ミドルボックスにHTTPヘッダーを追加するよりも、マークアップテンプレートを変更する方が便利であることを反映していると思われます。しかし、HTTPヘッダーの利用状況を見ると、50％以上が単一のSaaSプラットフォーム（Mercado）からのものです。

呼び出されたクライアントヒントのうち、大部分のページではDPR,ViewportWidth,Widthの3つのユースケースで使用されている。もちろん、Widthのクライアントヒントでは、ブラウザがレイアウトに関する十分なコンテキストを持つために<img sizes>を使用する必要があります。

図4.18の説明を表示

ドーナツ型のパイチャートを見ると、クライアントヒントの26.1%が「dpr」を使用しており、24.3%が「viewport-width」を使用しており、19.7%が「width」を使用しており、6.7%が「save-data」を使用しており、6.1%が「device-memory」を使用しており、6.0%が「downnlink」を使用しており、5.6%が「rtt」を使用しており、5.6%が「ect」を使用していることを示しています。

ネットワーク関連のクライアントヒントdownlink、rtt、ectはAndroid Chromeでのみ利用可能です。

遅延ローディング

ウェブページのパフォーマンスを改善することは、部分的にはイリュージョンのゲームとして特徴付けることができます。このように遅延読み込み画像は、ユーザーがページをスクロールしたときにのみ画像やメディアコンテンツが読み込まれる、これらのイリュージョンの1つです。これにより、遅いネットワークでも知覚パフォーマンスが向上し、ユーザーが他の方法で表示されていないバイトをダウンロードする手間が省けます。

以前、図4.5で、75パーセンタイルの画像コンテンツの量が、理論的には単一のデスクトップやモバイルのビューポートで表示できる量をはるかに超えていることを示しました。オフスクリーン画像https://developers.google.com/web/tools/lighthouse/audits/offscreen-imagesLighthouseの監査は、この疑念を裏付けています。ウェブページの中央値では、折り目の下に27％の画像コンテンツがあります。これは、90パーセンタイルの割合で84％に増加しています。

図4.19の説明を表示

10パーセンタイルでは画像の0%が画面外、25パーセンタイルでは2%が画面外、50パーセンタイルでは27%が画面外、75パーセンタイルでは64%が画面外、90パーセンタイルでは 84%が画面外であることを示す棒グラフです。

Lighthouseの監査では、質の高いプレースホルダーを使用するなど、油断できない状況がいくつもあるため、臭いを嗅ぎ分けてくれます。

遅延ローディングはIntersection Observers、Resize Observersの組み合わせを含め実装可能https://developers.google.com/web/fundamentals/performance/lazy-loading-guidance/images-and-video です、またはlazySizeshttps://github.com/aFarkas/lazysizes、lozadhttps://github.com/ApoorvSaxena/lozad.jsなどのJavaScriptライブラリの使用などさまざまな方法で実装できます。

2019年8月、Chrome76では<img>を使用したマークアップベースの遅延ローディングのサポートが開始されました。2019年のWeb Almanacに使用されたウェブサイトのスナップショットは2019年7月のデータを使用していますが、2,509以上のウェブサイトがすでにこの機能を利用していました。

アクセシビリティ

画像アクセシビリティの中心にあるのは alt タグです。画像に alt タグが追加されると、このテキストは画像を見ることができない（障害のある、インターネット接続が悪いのいずれかの理由で）ユーザーに画像を説明するために使用されます。

データセットのHTMLファイルに含まれるすべての画像タグを検出できます。デスクトップでは1,300万個、モバイルでは1,500万個の画像タグのうち、91.6％の画像にaltタグが存在しています。一見すると、ウェブ上では画像のアクセシビリティは非常に良好な状態にあるように見えます。しかし、よく調べてみると、見通しはあまり良くありません。データセットに存在するaltタグの長さを調べると、altタグの長さの中央値は6文字であることがわかります。これは空のaltタグ（alt=""のように見える）に対応する。6文字以上の長さのaltテキストを使用している画像は全体の39％にすぎない。実際の」altテキストの中央値は31文字で、そのうち25文字が実際に画像を説明しています。

動画

ウェブページで提供されるメディアは画像が主流ですが、ウェブ上でのコンテンツ配信では動画が大きな役割を果たし始めています。HTTP Archiveによると、デスクトップサイトの4.06％、モバイルサイトの2.99％が動画ファイルをセルフホスティングしていることがわかります。つまり、動画ファイルはYouTubeやFacebookのようなウェブサイトがホストしているわけではないということです。

動画フォーマット

動画は、多くの異なるフォーマットやプレイヤーで配信できます。モバイルおよびデスクトップ向けの主要なフォーマットは、.ts（HLSストリーミングのセグメント）と.mp4(H264 MPEG) です。

図4.20の説明を表示

棒グラフは、デスクトップで「ts」が1,283,439件（モバイルで792,952件）、デスクトップで「mp4」が729,757件（モバイルで662,015件）、デスクトップで「webm」が38,591件（モバイルで32,417件）、デスクトップは「mov」が22,194件（モバイルは14,986件）、デスクトップは「m4s」が17,338件（モバイルは16,046件）、デスクトップは「m4v」が7,466件（モバイルは6,169件）となっています。

他にも、webm、mov、m4s、m4v（MPEG-DASHストリーミングセグメント）などのフォーマットが見られます。ウェブ上のストリーミングの大部分はHLSであり、静的動画の主要なフォーマットはmp4であることが明らかです。

各フォーマットの動画サイズの中央値は以下の通りです。

図4.21の説明を表示

「ts」の平均ファイルサイズがデスクトップで335KB(モバイルで156KB)、「mp4」がデスクトップで175KB(モバイルで128KB)、「webm」がデスクトップで359KB(モバイルで192KB)、「mov」がデスクトップで128KB(モバイルで96KB)、「m4s」がデスクトップで324KB(モバイルで246KB)、「m4v」がデスクトップで383KB(モバイルで161KB)であることを示す棒グラフ。

中央値はモバイルの方が小さくなっていますが、これはおそらくデスクトップで非常に大きな動画を持っているサイトがモバイル用へ無効化していたり、動画ストリームが小さい画面に小さいバージョンの動画を提供していたりすることを意味していると思われます。

動画ファイルのサイズ

ウェブ上で動画を配信する場合、ほとんどの動画はHTML5動画プレイヤーで配信されます。HTML動画プレイヤーは、さまざまな目的で動画を配信するために非常にカスタマイズが可能です。たとえば、動画を自動再生するには、パラメーターautoplayとmutedを追加します。controls属性は、ユーザーが動画を開始/停止したり、スキャンしたりすることを可能にします。HTTP Archiveの動画タグを解析することで、これらの属性の使用状況を確認できます。

図4.22の説明を表示

デスクトップ用のバーチャート。’autoplay’は11.84%、’buffered’は0%、’controls’は12.05%、’crossorigin’は0.45%、’currenttime’は0.01%、’disablepictureinpicture’は0.01%、’disableremoteplayback’は0.01%、’duration’は0.05%、’height’は7.33%、’intrinsicsize’は0%、’loop’は14.57%、’muted’は13.92%、’playsinline’は6.49%、’poster’は8.98%、’preload’は11.62%、’src’は3.67%、’use-credentials’は0%、and ’width’は9%。そしてモバイルで’autoplay’は12.38%、’buffered’は0%、’controls’は13.88%、’crossorigin’は0.16%、’currenttime’は0.01%、disablepictureinpicture’は0.01%、’disableremoteplayback’は0.02%、’duration’は0.09%、’height’は6.54%、 intrinsicsize’は0%、’loop’は14.44%、’muted’は13.55%、’playsinline’は6.15%、’poster’は9.29%、’preload’は10.34%、’src’は4.13%、’use-credentials’は0%、’width’は9.03%である。

もっとも一般的な属性はautoplay、muted、loopで、続いてpreloadタグ、そしてwidthとheightです。loop属性の使用は背景の動画や、動画をアニメーションGIFの代わりに、使用する場合に使用されるのでウェブサイトのホームページでよく使用されても不思議ではありません。

ほとんどの属性はデスクトップとモバイルで似たような使い方をしていますが、いくつかの属性には大きな違いがあります。モバイルとデスクトップの間でもっとも大きな違いがあるのはwidthとheightの2つの属性で、モバイルではこれらの属性を使用しているサイトが4％少なくなっています。興味深いことに、モバイルではposter属性（再生前に動画ウィンドウの上に画像を配置する）が少しだけ増加しています。

アクセシビリティの観点からは、<track>タグはキャプションや字幕を追加するために使用できます。HTTP Archiveには<track>タグの使用頻度に関するデータがありますが、調査したところ、データセットのほとんどのインスタンスはコメントアウトされているか、404エラーを返すアセットを指していました。多くのサイトでは、JavaScriptやHTMLのボイラプレートを使用しており、trackが使用されていない場合でもtrackを削除しないようになっているようです。

動画プレイヤー

より高度な再生（および動画ストリームの再生）を行うには、HTML5ネイティブ動画プレイヤーは動作しません。再生に使用する一般的な動画ライブラリがいくつかあります。

図4.23の説明を表示

3,365のデスクトップサイト(3,400のモバイルサイト)、52,375のデスクトップサイト(40,925のモバイルサイト)、110,280のデスクトップサイト(96,945のモバイルサイト)、325のデスクトップサイト(275のモバイルサイト)の「shaka」、377,990のデスクトップサイト(391,330のモバイルサイト)の「video」を示す棒グラフです。

もっとも人気があるのは（圧倒的に）video.jsで、JWPLayerとHLS.jsがそれに続いています。著者は、「video.js」という名前のファイルが、同じ動画再生ライブラリではない可能性があることを認めています。

結論

ほぼすべてのウェブページではユーザー体験を向上させ、意味を生み出すために、画像や動画をある程度使用しています。これらのメディアファイルは大量のリソースを利用し、ウェブサイトのトン数の大部分を占めています（そして、それらがなくなることはありません！）代替フォーマット、遅延ロード、レスポンシブ画像、画像の最適化を利用することは、ウェブ上のメディアのサイズを小さくするために長い道のりを行くことができます。

サードパーティ

導入

オープンWebは広大で、リンク可能で、設計により相互運用可能です。他の誰かの複雑なライブラリを取得し、単一の<link>または<script>要素を使用してサイトで使用する機能により開発者の生産性が大幅に向上し、素晴らしく新しいWeb体験を実現しました。反対に、一部のサードパーティプロバイダーが非常に人気があるため、パフォーマンス、プライバシー、およびセキュリティに関する重要な懸念が生じています。この章では、2019年のWebに対するサードパーティコードの普及と影響、サードパーティソリューションの人気につながる使用パターンと、Web体験の将来への影響の可能性について検討します。

定義

“サードパーティ”

サードパーティとは、サイトとユーザーの主要な関係の外にあるエンティティです。つまり、サイトの側面はサイトの所有者の直接の管理下になく、承認を得て存在します。たとえば、Googleアナリティクススクリプトは、一般的なサードパーティリソースの例です。

サードパーティのリソースは次のとおりです。

• 共有および公開オリジンでホストされています
• さまざまなサイトで広く使用されています
• 個々のサイト所有者の影響を受けない

これらの目標を可能な限り正確に一致させるために、この章で使用されるサードパーティリソースの正式な定義は、HTTP Archiveデータセット内の少なくとも50のユニークなページにリソースを見つけることができるドメインに由来するリソースです。

これらの定義を使用して、ファーストパーティ・ドメインから提供されたサードパーティ・コンテンツはファーストパーティ・コンテンツとしてカウントされることに注意してください。例えば、セルフホスティングのGoogle Fontsやbootstrap.cssは、ファースト・パーティ・コンテンツとしてカウントされます。同様に、サードパーティのドメインから提供されたファーストパーティのコンテンツは、サードパーティのコンテンツとしてカウントされます。たとえば、サードパーティ・ドメインでCDNを介して提供されるファーストパーティの画像は、サードパーティ・コンテンツとみなされます。

プロバイダーカテゴリー

この章では、サードパーティプロバイダをこれらの大まかなカテゴリのいずれかに分類しています。以下に簡単な説明を記載し、ドメインとカテゴリのマッピングについては、サードパーティ・ウェブ・リポジトリhttps://github.com/patrickhulce/third-party-web/blob/8afa2d8cadddec8f0db39e7d715c07e85fb0f8ec/data/entities.json5を参照してください。

• Ad - 広告の表示と測定
• Analytics - トラッキングサイト訪問者の行動
• CDN - 公共の共有ユーティリティやユーザーのプライベートコンテンツを提供
• Content - 公開を容易にし、シンジゲートされたコンテンツを提供
• Customer Success - サポートと顧客関係管理の機能
• Hosting - ユーザー任意のコンテンツを提供
• Marketing - 営業、見込み客獲得、メールマーケティング機能
• Social - ソーシャルネットワークとその連携
• Tag Manager - 他の第三者の包含を管理することを唯一の役割を提供
• Utility - 開発を補助するためのコード
• Video - ユーザーの任意の動画コンテンツ
• Other - 未分類、上記に分類されないカテゴリ

警告事項

• ここで提示されているデータはすべて、非インタラクティブなコールドロードに基づいています。これらの値は、ユーザーとのインタラクションの後では、かなり異なって見えるようになる可能性があります。
• リクエスト量別のサードパーティドメインの約84％が特定され、分類されています。残りの16％は「その他」のカテゴリーに分類されています。

データ

サードパーティのコードは至る所にあります。ページの93％が少なくとも1つのサードパーティリソースを含み、ページの76％がアナリティクスドメインへのリクエストを発行しています。中央のページでは、ネットワークアクティビティ全体の35％を占める少なくとも9つのユニークサードパーティドメインからコンテンツをリクエストしており、最もアクティブな10％のページでは175以上のサードパーティリクエストを発行しています。サードパーティはウェブの不可欠な部分であると言っても過言ではありません。

カテゴリー

サードパーティ製コンテンツの普及が驚くに値しないとすれば、おそらくもっと興味深いのは、サードパーティ製コンテンツのプロバイダタイプ別の内訳です。

ウェブ上でのサードパーティの存在は広告が最もユーザーの目につきやすい例かもしれませんが、アナリティクスプロバイダーが最も一般的なサードパーティのカテゴリーであり、76％のサイトで少なくとも1つのアナリティクスリクエストが含まれています。CDNが63％、広告が57％、Sentry、Stripe、Google Maps SDKなどの開発者向けユーティリティが56％で、最も多くのウェブプロパティに表示されているのは僅差の2位、3位、4位と続いています。これらのカテゴリの人気は、本章で後述するウェブ利用パターンの基礎を形成しています。

プロバイダー

プロバイダーの比較的小さなセットがサードパーティの状況を支配しています：トップ100ドメインは、ウェブ全体のネットワーク要求の30％を占めています。Google、Facebook、YouTubeのような大企業は、それぞれのシェアの完全なパーセンテージポイントでここの見出しを作るが、WixやShopifyのような小さな事業体は同様にサードパーティの人気のかなりの部分を指揮します。

個々のプロバイダの人気とパフォーマンスへの影響については、多くのことが言えるかもしれませんが、このより意見の多い分析は読者やサードパーティ製Webhttps://thirdpartyweb.todayのような他の目的のために構築されたツールの練習として残されています。

リソースの種類

サードパーティコンテンツのリソースタイプの内訳を見ると、サードパーティのコードがWeb全体でどのように使用されているかを知ることができます。ファーストパーティのリクエストが、56％の画像、23％のスクリプト、14％のCSS、4％のHTMLにすぎないのに対し、サードパーティのリクエストはスクリプトとHTMLの割合が高く32％のスクリプト、34％の画像、12％のHTML、6％のCSSとなっています。このことは、サードパーティのコードがデザインを支援するために使用される頻度が低く代わりにファーストパーティのコードよりもインタラクションを促進したり観察したりするために使用される頻度が高いことを示唆していますがパーティの状態別のリソースタイプの内訳を見ると、よりニュアンスのあるストーリーがわかります。CSSと画像がそれぞれ70％、64％と圧倒的にファーストパーティであるのに対し、フォントはほとんどがサードパーティのプロバイダによって提供されており、ファーストパーティのソースから提供されているのは28％ にすぎません。この使用パターンの概念については、この章で後ほど詳しく説明します。

図5.5の説明を表示

サードパーティの各カテゴリのコンテンツタイプの内訳を示すグラフ。画像とスクリプトが各カテゴリのリクエストの大半を占めています。CDNリクエストでは、特にフォントの割合が高いです。

このデータからは、他にもいくつかの興味深い事実が飛び出してきます。トラッキングピクセル（解析ドメインへの画像リクエスト）は全ネットワークリクエストの1.6％を占め、FacebookやTwitterなどのソーシャルネットワークへの動画リクエストの数は、YouTubeやVimeoなどの専用動画プロバイダーの6倍にもなります（YouTubeのデフォルトの埋め込みはHTMLとプレビューサムネイルで構成されていて自動再生動画ではないためと思われます）。

リクエスト数

全リクエストの49％がサードパーティです。ファーストパーティは2019年にも、51％と、ウェブリソースの大部分を占めるという王座にあと一歩まで迫ることができます。全リクエストの半分弱がサードパーティ製であるにもかかわらず、まったく含まれていないページが少数であることを考えると最もアクティブなサードパーティ製ユーザーは、自分の公平なシェアよりもかなり多くのことをしているに違いありません。実際、75％、90％、99％の割合で、ほぼすべてのページがサードパーティのコンテンツで構成されていることがわかります。実際、WixやSquareSpaceのような分散型WYSIWYGプラットフォームに大きく依存しているサイトでは、ルートドキュメントが唯一のファーストパーティのリクエストになっているかもしれません。

各サードパーティプロバイダーが発行するリクエストの数も、カテゴリーによって大きく異なります。アナリティクスはウェブサイトで最も普及しているサードパーティのカテゴリーですが、サードパーティのネットワークリクエスト全体のわずか7％にすぎません。一方、広告は、サイト数が20％近く少ないにもかかわらず、サードパーティのネットワークリクエスト全体の25％を占めています。彼らの人気に比べてリソースへの影響が桁違いに大きいことは、残りのデータからも明らかにしていくテーマになるでしょう。

バイトの重さ

リクエストの49％がサードパーティ製のものであるのに対し、ウェブのバイト数でのシェアは28％とかなり低くなっています。複数のリソースタイプ別の内訳も同様です。サードパーティのフォントはフォント全体の72％を占めていますが、フォントのバイト数に占める割合は53％にすぎません。これらはすべて、サードパーティのプロバイダがレスポンスサイズを低く抑える責任ある管理人であることを示唆しているように見えます。

スクリプトの57％を提供しているにもかかわらず、サードパーティはスクリプトバイトの64％を占めています。つまり、サードパーティのスクリプトはファーストパーティのスクリプトよりも平均で大きくなっています。これは、次のいくつかのセクションで述べるパフォーマンスへの影響を示す早期警告の兆候です。

図5.6の説明を表示

サードパーティのカテゴリ毎でコンテンツタイプ毎のバイト数の内訳を示すグラフ。画像とスクリプトはカテゴリ間で比較的均等に分布しています。フォントの80%はCDNから来ています。動画は「コンテンツ」サードパーティからのものです。

具体的なサードパーティプロバイダについては、リクエスト数リーダーボードの上位にいる大手プロバイダがバイト数でも登場しています。注目すべき動きは、YouTube、Shopify、Twitterのようなメディアを中心とした大手プロバイダがバイトインパクトチャートの上位にランクインしていることくらいです。

スクリプトの実行

スクリプトの実行時間の57％はサードパーティ製のスクリプトによるもので、トップ100のドメインはすでにウェブ上のスクリプト実行時間の48％を占めています。このことは、少数のエンティティがウェブのパフォーマンスに与える影響が実際にどれほど大きいかを明確に示しています。このトピックについては、反響 > パフォーマンスセクションで詳しく説明しています。

スクリプト実行の間のカテゴリの内訳は、主にリソース数の内訳に従っています。ここでも広告が最大の割合を占めています。広告スクリプトはサードパーティのスクリプト実行時間の25％を占めており、ホスティングとソーシャルプロバイダーは12％で2位と大きく引き離されています。

個々のプロバイダの人気とパフォーマンスの影響については、多くのことが言えるかもしれませんが、より意見の多い分析は読者のための演習として残されていますし先に述べた サードパーティウェブhttps://thirdpartyweb.today のような他の目的のために構築されたツールもあります。

使用パターン

サイトオーナーはなぜサードパーティのコードを使うのか？　サードパーティのコンテンツがネットワークリクエストの半分近くを占めるようになったのはなぜでしょうか？　これらのリクエストは何をしているのか？　これらの疑問に対する答えは、サードパーティのリソースの3つの主要な使用パターンにあります。大まかに言えば、サイト所有者はユーザーからデータを生成して消費し、サイト体験を収益化しWeb開発を簡素化するためにサードパーティを利用しています。

データの生成と消費

アナリティクスは、ウェブ上で最も人気のあるサードパーティのカテゴリですが、ユーザーの目に触れることはほとんどありません。ユーザーのコンテキスト、デバイス、ブラウザ、接続品質、ロケーション、ページのインタラクション、セッションの長さ、再訪問者のステータスなどが継続的に生成されています。このような大規模な時系列データをウェアハウスし、正規化し分析するツールを維持するのは困難で面倒で、コストがかかります。アナリティクスがサードパーティプロバイダーの領域に入ることを明確に必要とするものはありませんが、ユーザーを理解することの魅力、問題空間の複雑さ、データを尊重し責任を持って管理することの重要性が増していることから、アナリティクスはサードパーティの人気のある使用パターンとして自然に表面化しています。

しかし、ユーザーデータには消費という裏返しの側面もあります。アナリティクスはサイトの訪問者からデータを生成することですが、他のサードパーティのリソースは、他の人しか知らない訪問者に関するデータを消費することに重点を置いています。ソーシャルプロバイダーは、この利用パターンにぴったりと当てはまります。サイト所有者は、訪問者のFacebookプロフィールからの情報をサイトに統合したい場合、Facebookのリソースを使用する必要があります。サイトオーナーがソーシャルネットワークのウィジェットを使って体験をパーソナライズし、訪問者のソーシャルネットワークを活用してリーチを増やすことに興味がある限り、ソーシャル統合はサードパーティの領域であり続けると思われます。

ウェブトラフィックの収益化

ウェブのオープンモデルは、コンテンツ制作者の金銭的利益を必ずしも満足させるものではなく、多くのサイト所有者は広告でサイトを収益化することに頼っています。広告主との直接の関係を構築し、価格契約を交渉するのは比較的難しく時間のかかるプロセスであるため、この懸念はターゲット広告とリアルタイム入札を行うサードパーティのプロバイダーによって主に処理されています。否定的な世論の広がり、広告ブロッキング技術の普及、ヨーロッパなどの主要な世界市場での規制措置は、収益化のためにサードパーティのプロバイダを継続的に使用する最大の脅威となっています。サイト所有者が突然独自の広告契約を結んだり特注の広告ネットワークを構築したりすることは考えにくいですが、ペイウォールやBraveのBasic Attention Tokenhttps://basicattentiontoken.org/のような実験のような代替的なマネタイズモデルは、将来のサードパーティの広告業界を揺るがす可能性を秘めています。

開発の簡素化

何よりもサードパーティのリソースは、ウェブ開発の経験を単純化するために使用されます。以前の使用パターンでさえも、おそらくこのパターンに当てはまる可能性があります。ユーザーの行動分析、広告主とのコミュニケーション、ユーザー体験のパーソナライズなど、サードパーティのリソースはファーストパーティの開発を容易にするため使用されます。

ホスティングプロバイダは、このパターンの最も極端な例です。これらのプロバイダーの中には、技術的な専門知識がなくても、地球上の誰もがサイトのオーナーになれるようしているところもあります。これらのプロバイダーは、資産のホスティング、コーディングの経験がなくてもサイトを構築できるツール、ドメイン登録サービスを提供しています。

サードパーティ・プロバイダの残りの部分も、この使用パターンに当てはまる傾向がある。フロントエンド開発者が使用するためのjQueryなどのユーティリティライブラリのホスティングであれ、Cloudflareのエッジサーバーにキャッシュされているものであれ人気の高いGoogleCDNから提供されている一般的なフォントの膨大なライブラリであれサードパーティのコンテンツはサイトオーナーが心配することを1つ減らし、もしかしたら素晴らしい体験を提供する仕事を少しだけ楽にしてくれるもう1つの方法です。

反響

パフォーマンス

サードパーティコンテンツのパフォーマンスの影響は、カテゴリ的に良い悪いはありません。善良な行為者と悪良な行為者が存在し、カテゴリーの種類によって影響力のレベルが異なります。

良い点：サードパーティ製のフォントやスタイルシートの共有ユーティリティは、平均的にファーストパーティ製のものよりも効率的に提供されます。

ユーティリティ、CDN、およびコンテンツの各カテゴリーは、サードパーティのパフォーマンスにおいて最も輝かしい存在です。これらのカテゴリは、ファーストパーティのソースから提供されるコンテンツと同じ種類のコンテンツの最適化されたバージョンを提供しています。GoogleFontsとTypekitはファーストパーティのフォントよりも平均的に小さい最適化されたフォントを提供し、CloudflareCDNはサイト所有者によっては開発モードで誤って提供されてしまう可能性のあるオープンソースのライブラリをミニ化したバージョンを提供し、GoogleMapsSDKはそうでなければ素朴に大きな画像として提供されてしまう複雑な地図を効率的に配信します。

悪い：非常に小さなエンティティのセットは、ページ上の機能の狭いセットを実行するJavaScriptの実行時間の非常に大きなチャンクを表しています。

広告、ソーシャル、ホスティング、および特定の分析プロバイダーは、ウェブパフォーマンスへの最大の悪影響を表します。ホスティングプロバイダはサイトのコンテンツの大部分を提供しており、他のサードパーティのカテゴリよりもパフォーマンスへの影響が大きいのは当然ですが、ほとんどの場合、JavaScriptをほとんど必要としない静的なサイトを提供していてスクリプトの実行時間を正当化することはできません。しかし、パフォーマンスに影響を与える他のカテゴリーは言い訳できません。これらのカテゴリは、それぞれのページに表示される役割が非常に狭いにもかかわらず、すぐにリソースの大部分を占有してしまいます。例えば、Facebookの「いいね！」ボタンと関連するソーシャルウィジェットは、画面の面積が非常に小さく、ほとんどのウェブ体験の何分の1かしか占めていませんがソーシャルサードパーティのあるページへの影響の中央値はJavaScriptの総実行時間の20％近くになります。状況はアナリティクスについても同様です。トラッキングライブラリは知覚されたユーザー体験に直接貢献しませんが、アナリティクスのサードパーティがあるページへの影響度は90パーセンタイルで、JavaScriptの総実行時間の44％です。

このような少数の事業体がこれほど大きな市場シェアを享受していることの裏には、非常に限られた集中的な努力がウェブ全体に大きな影響を与えることができるということがあります。上位数社のホスティングプロバイダのパフォーマンスを改善するだけで、全ウェブリクエストの2～3％を改善できます。

プライバシー

サードパーティの最大の利用例は、サイト所有者がユーザーを追跡することであり、一握りの企業がウェブトラフィックの大部分に関する情報を受け取っています。

ユーザーの行動を理解して分析することに対するサイト所有者の関心、それ自体は悪意のあるものではありませんが、ウェブ解析の普及した比較的裏方的な性質は有効な懸念を引き起こし、ヨーロッパのGDPRhttps://ja.wikipedia.org/wiki/EU%E4%B8%80%E8%88%AC%E3%83%87%E3%83%BC%E3%82%BF%E4%BF%9D%E8%AD%B7%E8%A6%8F%E5%89%87やカリフォルニア州のCCPAhttps://en.wikipedia.org/wiki/California_Consumer_Privacy_Actなどのプライバシー規制によりユーザー、企業、法律家は近年注目を集めています。開発者がユーザーデータを責任を持って扱い、ユーザーを尊重して扱い、収集されたデータが透明であることを保証することは、アナリティクスを最も人気のあるサードパーティのカテゴリーとして維持し、将来のユーザー価値を提供するためにユーザーの行動を分析するという共生的な性質を維持するための鍵となります。

スクリプトの実行が上位に集中していることは、パフォーマンス向上の潜在的な影響を考えると素晴らしいことですが、プライバシーへの影響を考えるとあまり刺激的ではありません。ウェブ上の全スクリプト実行時間の29％は、GoogleやFacebookが所有するドメイン上のスクリプトだけです。これは、たった2つの事業体によって制御されているCPU時間の非常に大きな割合です。アナリティクスプロバイダーに適用されているのと同じプライバシー保護が、他の広告、ソーシャル、開発者向けユーティリティカテゴリにも適用されるようにすることが重要です。

セキュリティ

セキュリティのトピックについては セキュリティ の章で詳しく説明していますが、サイトに外部の依存関係を導入することによるセキュリティへの影響は、プライバシーへの懸念と密接に関連しています。第三者が任意のJavaScriptを実行できるようにすることは、あなたのページを完全に制御できます。スクリプトがDOMとwindowを制御できれば、すべてのことができるようになります。たとえコードにセキュリティ上の懸念がなくても、単一の障害点を導入できますこれは以前から潜在的な問題として認識されていましたhttps://www.stevesouders.com/blog/2010/06/01/frontend-spof/。

サードパーティのコンテンツをセルフホスティングするhttps://csswizardry.com/2019/05/self-host-your-static-assets/ は、ここで述べた懸念事項のいくつかとその他の懸念事項に対応しています。さらに、ブラウザが HTTPキャッシュのパーティショニングhttps://chromestatus.com/feature/5730772021411840 を増やしていることから、サードパーティから直接読み込むことのメリットはますます疑問視されています。おそらく多くのユースケースでサードパーティのコンテンツを利用するには、その影響を測定することが難しくなってもこの方法の方が良いでしょう。

結論

サードパーティのコンテンツはどこにでもあります。これは驚くべきことでありません。ウェブの基本は、相互接続とリンクを可能にすることです。この章では、メインドメインから離れてホストされている資産という観点から、サードパーティコンテンツを調べてみました。もし、自己ホスト型のサードパーティ・コンテンツ（例えば、メイン・ドメインにホストされている一般的なオープンソース・ライブラリなど）を含めるとサードパーティの利用率はさらに高まっていたでしょう。

コンピュータ技術での再利用https://en.wikipedia.org/wiki/Code_reuseは一般的にベストプラクティスですが、ウェブ上のサードパーティは、ページのパフォーマンス、プライバシー、セキュリティにかなりの影響を与える依存関係を導入します。セルフホスティングと慎重なプロバイダの選択は、これらの影響を軽減するために長い道のりを歩むことができます。

第三者のコンテンツがどのようにページに追加されるかという重要な問題に関わらず、結論は同じです。サードパーティはWebの不可欠な部分です！

フォント

序章

ウェブフォントは、ウェブ上で美しく機能的なタイポグラフィを可能にします。ウェブフォントを使用することは、デザインに力を与えるだけでなく、デザインのサブセットを民主化します。しかし、どんなに良いことがあってもウェブフォントが適切に読み込まれていないと、サイトのパフォーマンスに大きな悪影響を及ぼすこともあります。

それらはウェブにとってプラスになるのか？　それらは害よりも多くの利益を提供しているか?　Web標準の牛道は、デフォルトでWebフォントの読み込みのベストプラクティスを奨励するために十分に舗装されているだろうか？　そうでない場合、何を変える必要があるのでしょうか？　今日のウェブ上でウェブフォントがどのように使用されているかを調べることで、これらの疑問に答えられるかどうかをデータ駆動型で覗いてみましょう。

そのウェブフォントはどこで手に入れたの？

最初の、そして最も顕著な問題は、パフォーマンスです。パフォーマンスに特化した章がありますが、ここではフォント固有のパフォーマンスの問題について少し掘り下げてみましょう。

ホストされたWebフォントを使用すると、実装やメンテナンスが容易になりますが、セルフホスティングは最高のパフォーマンスを提供します。Webフォントはデフォルトで、Webフォントの読み込み中にテキストを非表示にする（Flash of Invisible Texthttps://css-tricks.com/fout-foit-foft/、またはFOITとしても知られています）ことを考えると、Webフォントのパフォーマンスは画像のような非ブロッキング資産よりも重要になる可能性があります。

フォントは同じホストでホストされているのか、それとも別のホストでホストされているのか？

サードパーティのホスティングに対するセルフホスティングの差別化は、HTTP/2の世界ではますます重要になってきています。同一ホストのリクエストには、ウォーターフォール内の他の同一ホストのリクエストに対して優先順位をつける可能性が高いという大きな利点があります。

別のホストからウェブフォントを読み込む際のパフォーマンスコストを軽減するための推奨事項としては、preconnect、dns-prefetch、preload リソースのヒントの使用がありますが、優先度の高いウェブフォントは、ウェブフォントのパフォーマンスへの影響を最小限に抑えるため、同一ホストからのリクエストにすべきです。これは視覚的に、非常に目立つコンテンツやページの大部分を占める本文コピーで使用されるフォントへ対して特に重要です。

図6.1の説明を表示

ウェブフォントのサードパーティおよびセルフホスティング戦略の人気を示す棒グラフ。モバイルWebページの75%がサードパーティ製ホストを使用し、25%がセルフホストを使用しています。デスクトップのウェブサイトでも、同様の利用状況です。

4分の3がホストされているという事実は、おそらく我々が議論するGoogle Fontsの優位性を考えると意外と知られていません以下。

Googleはhttps://fonts.googleapis.comでホストされているサードパーティのCSSファイルを使ってフォントを提供しています。開発者は、マークアップの<link>タグを使ってこれらのスタイルシートにリクエストを追加します。これらのスタイルシートはレンダーブロッキングされていますが、そのサイズは非常に小さいです。しかし、フォントファイルはhttps://fonts.gstatic.comという別のドメインでホストされています。2つの異なるドメインへの2つの別々のホップを必要とするモデルでは、CSSがダウンロードされるまで発見されない2つ目のリクエストにはpreconnectが最適な選択肢となります。

preloadはリクエストのウォーターフォールの上位にフォントファイルをロードするための素晴らしい追加機能ですが（preconnectは接続を設定するもので、ファイルの内容をリクエストするものではないことを覚えておいてください）、preloadはGoogle Fontsではまだ利用できません。Google Fontsはフォントファイル用のユニークなURLを生成しますこれは変更される可能性がありますhttps://github.com/google/fonts/issues/1067。

最も人気のあるサードパーティ製のホストは何ですか？

ここでのGoogle Fontsの優位性は、同時に驚くべきことであると同時に意外性のないものであった。期待していたという点では予想外でしたが、サービスの圧倒的な人気の高さには驚きました。フォントリクエストの75％というのは驚異的だ。TypeKitは一桁台の遠い2位で、Bootstrapライブラリがさらに遠い3位を占めていました。

ここでのGoogle Fontsの使用率の高さは非常に印象的だが、Google Fonts<link>要素を含むページが29％しかなかったことも注目に値する。これはいくつかのことを意味しているかもしれない。

• ページがGoogle Fontsを使用する場合、彼らはGoogle Fontsを多く使用しています。それらは結局のところ、金銭的なコストなしで提供されています。おそらく、人気のあるWYSIWYGエディタで使われているのではないでしょうか？　これは非常に可能性の高い説明のように思えます。
• あるいは、もっとありそうにない話としては、多くの人が<link>の代わりに@importを使ってGoogle Fontsを使っているということかもしれません。
• あるいは、超ありえないシナリオにまで踏み込んでみたいのであれば、多くの人が代わりにHTTP Link:ヘッダーを使ってGoogle Fontsを使っているということになるかもしれません。

Google Fontsのドキュメントでは、Google Fonts CSSの<link>はページの<head>の最初の子として配置することを推奨しています。これは大きなお願いです！　実際、これは一般的でありません。全ページの半分のパーセント（約20,000ページ）しかこのアドバイスを受けていないので、これは一般的でありません。

さらに言えば、ページがpreconnectやdns-prefetchを<link>要素として使用している場合、これらはいずれにしてもGoogle Fonts CSSの前へ来ることになります。これらのリソースのヒントについては、続きを読んでください。

サードパーティホスティングの高速化

上述したように、サードパーティホストへのウェブフォント要求を高速化する超簡単な方法は、preconnectリソースヒントを使用することです。

うわー！　2％未満のページがpreconnectを使用している！　Google Fontsが75％であることを考えると、これはもっと高いはずです！　開発者の皆さん: Google Fontsを使うなら、preconnectを使いましょう！　Google Fonts:preconnectをもっと宣伝しよう！

実際、もしあなたがGoogle Fontsを使っているのであれば、<head>にこれを追加してください。

<link rel="preconnect" href="https://fonts.gstatic.com/">

最も人気のある書体

ここでの上位のエントリがGoogle Fontsの人気順フォント一覧https://fonts.google.com/?sort=popularityと非常によく似ていることは驚くに値しません。

どのようなフォント形式を使用していますか？

今日のブラウザではWOFF2はかなりサポートされていますhttps://caniuse.com/#feat=woff2。Google FontsはWOFF2というフォーマットを提供していますが、これは前身のWOFFよりも圧縮率が向上したフォーマットで、それ自体はすでに他の既存のフォントフォーマットよりも改善されていました。

図6.7の説明を表示

ウェブフォントのMIMEタイプの人気を示す棒グラフ。フォントの74%でWOFF2が使用されており、次いでWOFFが13%、octet-streamが 6%、TTFが3%、plainが2%、HTMLが1%、SFNTが1%、その他のすべてのタイプが1%未満となっています。デスクトップとモバイルでは、同様の分布となっています。

私から見れば、ここでの結果を見て、WebフォントはWOFF2オンリーにした方がいいという意見もあるかもしれません。二桁台のWOFF使用率はどこから来ているのでしょうか？　もしかして、まだWebフォントをInternet Explorerに提供している開発者がいるのでしょうか？

第3位のoctet-stream(およびもう少し下のplain)は、多くのウェブサーバが不適切に設定されており、ウェブフォントファイルのリクエストで誤ったMIMEタイプを送信していることを示唆しているように見えます。

もう少し深く掘り下げて、@font-face宣言のsrc:プロパティで使われているformat()の値を見てみましょう。

図6.8の説明を表示

フォントフェイス宣言で使用されるフォーマットの人気を示す棒グラフ。デスクトップページの@font-face宣言の 69%がWOFF2形式を指定しており、11%がWOFF、10%がTrueType、8%がSVG、2%がEOT、1%未満でOpenType、TTF、OTFを指定しています。モバイルページの分布も同様です。

SVGフォントhttps://caniuse.com/#feat=svg-fontsが衰退しているのを見て期待していたのですが。バグだらけだし、Safari以外のブラウザでは実装が削除されている。そろそろ捨ててしまおうか。

ここのSVGデータポイントを見ると、どのMIMEタイプでSVGフォントを提供しているのか気になります。図6.7のどこにもimage/svg+xmlは見当たりません。とにかく、それを修正することは気にしないで、ただそれらを取り除くだけです！

WOFF2専用

このデータセットは、大多数の人がすでに@font-faceブロックでWOFF2のみを使っていることを示唆しているように見える。しかし、このデータセットにおけるGoogle Fontsの優位性についての以前の議論によれば、もちろんこれは誤解を招くものです。Google Fontsは合理化されたCSSファイルを提供するためにいくつかのスニッフィングメソッドを実行しており、最新のformat()のみを含んでいる。当然のことながら、WOFF2がここでの結果を支配しているのはこの理由によるもので、WOFF2に対するブラウザのサポートは以前からかなり広くなっている。

重要なのは、この特定のデータはまだWOFF2オンリーのケースを支持しているわけではないということですが、魅力的なアイデアであることに変わりはありません。

見えない文字との戦い

デフォルトのWebフォントの読み込み動作である「読み込み中は見えない」(FOITとしても知られています)に対抗するため持っている第一のツールはfont-displayです。font-display: swapを@font-faceブロックに追加すると、ウェブフォントが読み込まれている間にフォールバックテキストを表示するようにブラウザに指示する簡単な方法です。

ブラウザ対応https://caniuse.com/#feat=mdn-css_at-rules_font-face_font-displayもいいですね。Internet ExplorerやChromium以前のEdgeではサポートされていませんが、Webフォントが読み込まれたときにデフォルトでフォールバックテキストをレンダリングしてくれます（ここではFOITは使えません）。Chromeのテストでは、font-displayはどのくらいの頻度で使われているのでしょうか？

私はこれが時間の経過とともに忍び寄ってくることを想定しています、特に今はGoogle Fontsがすべての新しいコードスニペットに font-display を追加していますが彼らのサイトからコピーされています。

Google Fontsを使っているなら、スニペットを更新しよう！　Google Fontsを使っていない場合は、font-displayを使いましょう！　font-displayについての詳細は MDNhttps://developer.mozilla.org/docs/Web/CSS/@font-face/font-display を参照してください。

どのようなfont-display値が人気あるのか見てみましょう。

図6.11の説明を表示

フォント表示スタイルの利用状況を示す棒グラフ。モバイルページの2.6％がこのスタイルを「swap」、1.5％が「auto」、0.7％が「block」、0.4％が「fallback」、0.2％が「optional」、0.1％が引用符で囲んだ「swap」に設定しているが、これは無効である。デスクトップの分布は、「swap」の利用率が0.4％ポイント低く、「auto」の利用率が0.1％ポイント高くなっている以外は似ている。

ウェブフォントの読み込み中にフォールバックテキストを表示する簡単な方法として、font-display: swapが最も一般的な値として君臨しています。swapは新しいGoogle Fontsのコードスニペットでもデフォルト値として使われています。いくつかの著名な開発者のエバンジェリストがこれを求めてちょっとした働きかけをしていたので、ここではoptional(キャッシュされた場合にのみレンダリングする)がもう少し使われることを期待していたのですが、駄目でした。

ウェブフォントの数が多すぎる？

ある程度のニュアンスが必要な質問です。フォントはどのように使われているのか？　ページ上のコンテンツの量は？　そのコンテンツはレイアウトのどこにあるのか？　フォントはどのようにレンダリングされているのか？　しかし、ニュアンスの代わりに、リクエスト数を中心とした大まかで重い分析に飛び込んでみましょう。

図6.12の説明を表示

ページごとのフォント要求の分布を示す棒グラフ。デスクトップでの10、25、50、75、90パーセンタイルは以下の通りです。0、1、3、6、9のフォント要求があります。モバイルの分布は75パーセンタイルと90パーセンタイルまでは同じで、モバイルページでは要求されるフォントが1つ少なくなっています。

中央値のウェブページでは、3つのウェブフォントをリクエストしています。90パーセンタイルでは、モバイルとデスクトップでそれぞれ6つと9つのウェブフォントをリクエストしています。

図6.13の説明を表示

ページあたりのフォントリクエスト数の分布を示すヒストグラム。最も人気のあるフォントリクエスト数は0で、デスクトップページの22%を占めています。この分布は、1つのフォントを持つページの9%まで落ち込み、2～4つのフォントでは10%で頂点に達し、フォント数が増えるにつれて落ち込んでいきます。デスクトップとモバイルの分布は似ていますが、モバイルの分布はページあたりのフォント数が少ない方にわずかに傾いています。

Webフォントのリクエストがデスクトップとモバイルの間でかなり安定しているように見えるというのは非常に興味深いことです。私は、@mediaクエリの中の@font-faceブロックを隠すことを推奨することが流行らなかったのを見てうれしく思います (何も考えないでください)。

しかし、モバイルデバイスでのフォントのリクエストはわずかに多い。ここでの私の勘は、モバイルデバイスで利用できる書体が少ないということはGoogle Fonts CSSでのlocal()のヒット数が少ないということであり、ネットワークからのフォントリクエストに戻ってしまうのではないかと考えています。

この賞を受賞したくない

最も多くのウェブフォントをリクエストしたページの賞は、718のウェブフォントをリクエストしたサイトに贈られます！

コードに飛び込んだ後、それらの718のリクエストのすべてがGoogle Fontsに向かっています！　どうやらWordPress用の「ページの折り返しの上に」最適化プラグインが誤作動して、このサイトで不正を行い、すべてのGoogle Fonts-oopsにリクエストしている（DDoS-ing？）。

パフォーマンス最適化プラグインは、あなたのパフォーマンスをはるかに悪化させることができることを皮肉っています！

Unicode-rangeを使うとより正確なマッチングが可能になります

unicode-rangeは、ブラウザに、ページがフォントファイルで使用したいコードポイントを具体的に知らせるための優れたCSSプロパティです。@font-face宣言にunicode-rangeがある場合、ページ上のコンテンツは、フォントが要求される前に、その範囲内のコードポイントのいずれかにマッチしなければなりません。これは非常に良いことです。

Google FontsはそのCSSのほとんど（すべてではないにしても）でunicode-rangeを使用しているので、これもGoogle Fontsの使用状況によって偏っていると予想される指標です。ユーザーの世界でこれはあまり一般的でないと思いますが、Web Almanacの次の版ではGoogle Fontsのリクエストをフィルタリングして除外することが可能かもしれません。

システムフォントが存在する場合、ウェブフォントを要求しないようにする

local()は@font-face、srcのシステムフォントを参照するための良い方法です。もし local()フォントが存在するならば、ウェブフォントを要求する必要は全くありません。これはGoogle Fontsによって広く使われており、論争の的にもなっているのでユーザの土地からパターンを得ようとしているのであれば、これも歪んだデータの一例になるでしょう。

ここでは、私よりも賢い人々(TypeKitのBram Stein氏) が、インストールされているフォントのバージョンが古くて信頼性は低い場合があるため、local()を使うことは予測不可能である可能性があると述べていることにも注目しておきましょう。

縮約されたフォントとfont-stretch

歴史的に、font-stretchはブラウザのサポートが悪く、よく知られた@font-faceプロパティではありませんでした。詳しくはMDNのfont-stretchについて を参照してください。しかし、ブラウザのサポートhttps://caniuse.com/#feat=css-font-stretchは広がっています。

小さいビューポートで凝縮されたフォントを使用することで、より多くのテキストを表示できるようになることが示唆されていますが、このアプローチは一般的には使用されていません。とはいえ、このプロパティがモバイルよりもデスクトップで半パーセントポイント多く使われているというのは予想外で、7％というのは私が予想していたよりもはるかに高いと思えます。

可変フォントは未来のもの

可変フォントhttps://developer.mozilla.org/docs/Web/CSS/CSS_Fonts/Variable_Fonts_Guideでは、1つのフォントファイルに複数のフォントの太さやスタイルを含めることができます。

1.8％でさえ、これは予想よりも高かったが、これがうまくいくのを見て興奮している。Google Fonts v2https://developers.google.com/fonts/docs/css2には可変フォントのサポートがいくつか含まれています。

図6.19の説明を表示

font-variation-settingsプロパティの使用状況を示す棒グラフ。デスクトップページのプロパティの42%がopszの値に設定されており、32%がwght、16%がwdth、2%以下がroun、crsb、slnt、inlnなどに設定されています。デスクトップページとモバイルページで顕著な違いは、opszの使用率が26％、wghtの使用率が38％、wdthの使用率が23％となっており、wghtの使用率は、wghtの使用率とwghtの使用率の差が大きい。

この大規模なデータセットのレンズを通して見ると、これらの結果は非常に低いサンプルサイズであることがわかります。しかし、デスクトップページで最も一般的な軸としてopszが注目され、wghtとwdthが後に続く。私の経験では、可変フォントの入門デモはたいていウェイトベースです。

カラーフォントも未来かも？

これらのここでの使用法は基本的に存在しませんが、詳細についてはカラーフォント！　WTF?https://www.colorfonts.wtf/という優れたリソースをチェックできます。フォント用のSVGフォーマット(これは良くないし消えていく)に似ていますが(全くそうではありません)、これを使うとOpenTypeファイルの中にSVGを埋め込むことができ、これは素晴らしくクールです。

結論

ここでの最大の収穫は、Google Fontsがウェブフォントの議論を支配しているということだ。彼らが取ったアプローチは、ここで記録したデータに大きく影響している。ここでのポジティブな点はウェブフォントへのアクセスが容易であること、優れたフォントフォーマット（WOFF2）であること、そして自由なunicode範囲の設定が可能であることだ。ここでの欠点はサードパーティのホスティング、異なるホストからのリクエスト、およびpreloadにアクセスできないことでパフォーマンスが低下することです。

私は、将来的には「バリアブルフォントの台頭」を見ることになるだろうと完全に予想しています。バリアブルフォントは複数の個々のフォントファイルを1つの合成フォントファイルに結合するので、これはウェブフォントのリクエストの減少と対になっているはずです。しかし歴史が示しているように、ここで通常起こることは、あるものを最適化してその空所を埋めるためにさらに多くのものを追加してしまうことです。

カラーフォントの人気が高まるかどうかは非常に興味深いところです。私は、これらは可変フォントよりもはるかにニッチなものになると予想していますが、アイコンフォントのスペースに生命線を見ることができるかもしれません。

フォントを凍らせるなよ。

パフォーマンス

導入

パフォーマンスはユーザー体験で大切なものの一つです。多くのWebサイトでは、ページの読み込み時間を早くする事によるユーザー体験の向上と、コンバージョン率の上昇は一致しています。逆に、パフォーマンスが低い場合、ユーザーはコンバージョンを達成せず、不満を持ち、ページをクリックすると怒りを覚えることさえあります。

Webのパフォーマンスを定量化する方法は色々とあります。ここで一番大切なのは、ユーザーにとって特に重要な点を計測することです。ただ、onloadやDOMContentLoadedなどのイベントはユーザーが実際に目で見て体験できているものとは限りません。例えば、電子メールクライアントを読み込んだ時、受信トレイの内容が非同期に読み込まれる間、画面全体を覆うようなプログレスバーが表示される事があります。ここでの問題はonloadイベントが受信ボックスの非同期読み込みの完了まで待機しないことです。この例において、ユーザーの一番大切にするべき計測値とは「受信トレイが使えるようになるまでの時間」であり、onloadイベントに着目するのは誤解を招く可能性があります。そのために、この章ではユーザーが実際にページをどのように体験しているかを把握し、よりモダンで広く使える描画、読み込み、および対話性の計測を検討します。

パフォーマンスデータにはラボとフィールドの２種類があります。合成テストや実ユーザー測定（またはRUM）でそれらを聞いたことがあるかもしれません。ラボでパフォーマンスを測定すると、各Webサイトが共通の条件でテストされ、ブラウザー、接続速度、物理的な場所、キャッシュ状態などの状態は常に同じになります。この一貫性が保証されることで、それぞれのWebサイトを比較することができます。その反面、フィールドのパフォーマンス測定は、ラボでは決して行うことのできない無限に近い条件の組み合わせで、現実に近いユーザーのWeb体験を計測することを可能にします。この章の目的と実際のユーザー体験を理解するために、今回はフィールドデータを見ていきます。

パフォーマンスの状態

Web Almanacにある他のほとんどの章は、HTTP Archivehttps://httparchive.org/のデータに基づいています。ただ、実際のユーザーがWebをどのように体験するかを取得するには、違うデータセットが必要になります。このセクションでは、Chrome UXレポートhttp://bit.ly/chrome-ux-report（CrUX）を使用しています。この情報はHTTP Archiveとすべて同じウェブサイトで構成されるGoogleの公開データセットとなっており、Chromeを使うユーザーの実際の体験を集約しています。そして体験は次のように分類されます。

• ユーザーデバイスのフォームファクタ
  • デスクトップ
  • 携帯電話
  • タブレット
• モバイル用語で言うユーザーの有効な接続タイプ(ECT)
  • オフライン
  • 遅い2G
  • 2G
  • 3G
  • 4G
• ユーザーの地理的な位置

体験は描画、読み込み、そして対話性の定量化を含めて毎月測定されます。最初に私達が見るべき指標はコンテンツの初回ペイント(First Contentful Paint)https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics#first_paint_and_first_contentful_paint(FCP)です。これはページや画像やテキストなど、ユーザーが画面として見るために必要なものが表示されるのを待つ時間です。次は、読み込み時間の指標である最初のバイトまでの時間(Time to First Byte)https://developer.mozilla.org/docs/Glossary/time_to_first_byte (TTFB)です。これはユーザーがナビゲーションを行ってから、Webページのレスポンスの最初のバイトを受信するまでにかかった時間を計測したものです。そして最後に確認するフィールドの指標は初回入力遅延(First Input Delay)https://developers.google.com/web/updates/2018/05/first-input-delay (FID)です。これは比較的新しい指標で、読み込み以外のパフォーマンスUXの一部を表すものです。ユーザーがページのUIを操作できるようになるまでの時間、つまり、ブラウザのメインスレッドがイベント処理の準備が整うまでの時間を測定したものです。

では、それによってどのような洞察ができるのかを見てきましょう。

コンテンツの初回ペイント(First Contentful Paint)

図7.1の説明を表示

Webサイト1000個から見た、FCPが高速、適度、低速の分布。FCPが早いサイトの分布は100%から0%までが線形になっているように見えます。

図7.1では、FCPの体験がWeb全体でどのように分散しているかを見ることができます。このチャートは、CrUXデータセット内にある数百万のWebサイト分布を1,000個のWebサイトに圧縮しており、図の縦線一つ一つはWebサイトを表しています。このグラフは、１秒未満の高速なFCP体験、３秒以上かかる遅い体験、その中間にある適度な体験（以前は平均と言われていた）の割合で並べられています。グラフには、ほぼ100%高速な体験を備えたWebサイトと、ほぼ100%低速な体験となっているWebサイトが存在しています。その中間にある、高速、適度、及び低速のパフォーマンスが混じり合ったWebサイトは、低速よりも適度か高速に傾いており、良い結果になっています。

Webサイトが十分に高速かどうかを分類するために、新しい方法論である PageSpeed Insights (PSI)を使います。この方法はWebサイトのFCP体験の少なくとも75%が１秒未満でなければなりません。同様に、FCP体験がとても低速となる25%のWebサイトでは３秒以上かかっています。どちらの条件も満たさない場合、Webサイトのパフォーマンスは適度です。

図7.2の説明を表示

Webサイトの13%が高速なFCPで、66%が適度のFCP、20%が低速のFCPを示す棒グラフ。

図7.2の結果は、Webサイトの13％だけが高速と判断されています。これはまだ改善の余地があるようですが、多くのWebサイトで意味を持つコンテンツを素早く一貫して描画できています。Webサイトの３分の２は適度のFCP体験となっているようです。

デバイス毎にFCPのユーザー体験がどの様になっているかを知るために、フォームファクタ別に分類してみましょう。

デバイス毎のFCP

図7.3の説明を表示

1,000個のデスクトップWebサイトの高速、適度、低速のFCP分布、高速なFCPの分布は100%から0%までが線形となっており、中央で少し膨らんでいます。

図7.4の説明を表示

1,000個の携帯電話向けWebサイトの高速、適度、低速のFCP分布、高速なFCPの分布は100%から0%までに膨らみが無く、線形に見えます。

上の図7.3と図7.4は、FCPの分布をデスクトップと携帯電話で分類しています。微妙な差ですが、デスクトップFCP分布の胴部は携帯電話ユーザーの分布よりも凸型となっているように見えます。この視覚的な近似が示すのは、デスクトップユーザーが高速なFCPにおいて全体的に割合が高いことを示しています。これを検証するために、PSIという方法を各分布に適用していきます。

図7.5の説明を表示

デスクトップとモバイルのFCP分布を示す棒グラフ。デスクトップは高速、適度、低速が17%、67%、16%となっており、モバイルは11%、66%、23%となっています。

PSIの分類によると、モバイルユーザーの11%と比べて、デスクトップユーザーは17%に対して高速なFCP体験が全体的に提供されています。全体的な分布を見ると、デスクトップのほうが体験が少しだけ高速に偏っていますが、低速のWebサイトは少なく高速と適度のカテゴリーが多くなっています。

Webサイトでデスクトップユーザーが高確率で携帯電話のユーザーより高速なFCP体験をするのは何故でしょう？それは結局、このデータセットはWebがどのように機能しているかという答えでしかなく必ずそう動いていると言った話では無いからです。ただ、デスクトップユーザーはキャリアの通信ではなく、WiFiのような高速で信頼性の高いネットワークでインターネット接続をしていると推測できます。この疑問に答えるために、ECTでユーザー体験がどのように違うかを調べることもできます。

有効な接続タイプ毎のFCP

図7.6の説明を表示

有効な接続タイプ毎のFCP分布棒グラフ。4Gの高速、適度、低速：14％、67％、19％。 3G：1％、38％、61％。 2G：0％、9％、90％。 低速な2G：0％、1％、99％。

上の図7.6にあるFCP体験は、ユーザーの体験するECT毎にグループ化されています。興味深いことに、ECTの速度と高速FCPを提供するWebサイトの割合との間には相関関係があります。ECTの速度が低下すると、高速な体験の割合はゼロに近づきます。ECTが4Gのユーザーにサービスを提供しているWebサイトの14％は高速なFCPエクスペリエンスを提供していますが、そのWebサイトの19％は低速な体験を提供しています。61％のWebサイトは、ECTが3Gのユーザーに低速のFCPを提供し、ECTが2Gだと90％に、ETCが低速の2Gだと99％となっています。これらの事実から、4Gより遅い接続を持つユーザーには、Webサイトがほぼ一貫して高速のFCPを提供できていないことを示しています。

地理によるFCP

図7.7の説明を表示

最も人気があるトップ23地域のFCP分布棒グラフです。韓国は36%で最も早いWebサイトを持っています。そこから高速なWebサイトの割合は、日本28%、台湾26％、オランダ21%となり、そこから他の地域は急速に減少しています。

最後にユーザーの地理（geo）でFCPを切り分けてみましょう。上記のグラフは、個別に多くのWebサイトを持っているトップ23の地域を表しています。これはオープンWeb全体での人気の計測です。アメリカのWebユーザーは、1,211,002の最も際立ったWebサイトにアクセスします。十分に高速なFCP体験のWebサイトの割合で地理をソートしましょう。リストのトップ3にはアジアパシフィックhttps://en.wikipedia.org/wiki/Asia-Pacific(APAC)が入っています。それは韓国、台湾、日本です。この結果から、これらの地域では非常に高速なネットワーク接続https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speedsが使われていることが説明できます。韓国では高速のFCP基準を満たすウェブサイトが36％あり、低速と評価されているのはわずか7%です。高速/適度/低速のウェブサイトの世界的な分布はおおよそ13/66/20であり、韓国がかなり良い意味で外れ値となっています。

他のAPAC地域の話をしましょう。タイ、ベトナム、インドネシア、インドの高速Webサイトは、ほぼ10％未満です。そして、これらの地域は韓国の3倍以上低速なWebサイトと言う割合になっています。

最初のバイトまでの時間(Time to First Byte) (TTFB)

最初のバイトまでの時間https://web.dev/articles/ttfbは、ユーザーがWebページにナビゲーションしてからレスポンスの最初のバイトを受信するまでにかかった時間の測定値です。

図7.8の説明を表示

ページの読み込みにおけるネットワークフェーズのシーケンスを示す図：startTime（promptForUnload）、リダイレクト、AppCache、DNS、TCP、リクエスト、レスポンス、処理、読み込み。

TTFBとそれに影響する多くの要因を説明するために、Navigation Timing APIの仕様https://developer.mozilla.org/docs/Web/API/Navigation_timing_APIから図を借りました。上の図7.8はstartTimeからresponseStartまでの間を表しており、unload、redirects、AppCache、DNS、SSL、TCPなどのサーバー側のリクエスト処理に費やす全てを含んでいます。このようなコンテキストを考慮して、ユーザーがこの数値をどのように体験しているかを見てみましょう。

図7.9の説明を表示

Webサイト1,000個の高速、適度、低速のTTFBの配布。 高速TTFBの分布は、10番目まで早い割合で、そして約90％から50％に急速に低下します。 その後分布は50％から0％に徐々に減少し、最後の1割は底辺を這います。

図7.1のFCPチャートと同様に、これは高速TTFB毎に並べられた代表的な1,000個の値のサンプルのビューです。 高速TTFBhttps://developers.google.com/speed/docs/insights/Server#recommendationsは0.2秒（200ミリ秒）未満、低速TTFBは1秒以上、その間はすべて適度です。

高速の割合の曲がり方を見ると、形はFCPとかなり異なります。75％を超える高速なTTFBを持つWebサイトは非常に少なく、25％を下回るWebサイトが半分以上となっています。

以前にFCPで使用したPSI方法論からインスピレーションを貰って、TTFB速度のラベルを各Webサイトに適用しましょう。ウェブサイトが75％以上のユーザー体験に対して高速なTTFBを提供する場合、高速とラベル付けされます。それ以外に、25％以上のユーザー体験に対して低速 なTTFBを提供するものを、低速とします。この条件のどちらでもないものを適度とします

図7.10の説明を表示

Webサイトの2%が高速なTTFBを、56%が適度のTTFBを、42%が低速なTTFBとなっていることを示す棒グラフ。

Webサイトの42%で低速のTTFB体験となっています。TTFBは他のすべてのパフォーマンス値の妨げになるため、この値はとても重要です。定義上は、TTFBに1秒以上かかる場合、ユーザーは高速なFCPを体験できない可能性があります。

TTFB by geo

図7.11の説明を表示

最も人気のあるトップ23地域のTTFB分布の棒グラフ。韓国は14%で特に早いWebサイトを持っています。そこから、早いWebサイトの割合は台湾7%、日本5%、オランダ4%となり、他の地域では急速に減少していきます。

次に、さまざまな地域で、高速なTTFBをユーザーに提供しているWebサイトの割合を見てみましょう。韓国、台湾、日本のようなAPAC地域は依然として世界のユーザーを上回っています。しかし、どの地域も15%を超えてた高速なTTFBとなっているWebサイトはありません。インドでは、高速TTFBとなっているWebサイトは1%未満で、低速なTTFBとなっているWebサイトは79%となっています。

初回入力遅延（First Input Delay）

最後に確認するフィールド値は初回入力遅延(First Input Delay)https://developers.google.com/web/updates/2018/05/first-input-delay(FID)です。この値は、ユーザーがページのUIを最初に操作してから、ブラウザのメインスレッドでイベントの処理が可能になるまでの時間です。この時間には、アプリケーションへの実際の入力処理の時間は含まれないことに注意してください。最悪の場合は、FIDが遅いとページが応答しなくなり、ユーザー体験は苛立たしいものとなってしまいます。

いくつかのしきい値を定義することから始めましょう。新しいPSI手法によると、高速なFIDは100ミリ秒未満です。これによりアプリケーションは、入力イベントを処理しユーザーへの応答の結果が瞬時に感じるのに十分な時間を与えることができます。低速なFIDは300ミリ秒以上となっており、その間はすべて適度にあたります。

図7.12の説明を表示

Webサイト1,000個の高速、適度、低速のFID配布。75%を超える高速なFIDの分布は、4分の3でもWebサイトがあり、その後急速に0％に低下します。

貴方はいま難題を抱えています。この表はWebサイトの高速、適度、低速のFID体験の分布を表しています。これは以前のFCPとTTFBの表とは劇的に異なります。(図7.1と図7.9をそれぞれ見る).高速FIDの曲線は100%から75%にゆるやかに下っていき、その後急降下します。FIDの体験は、ほとんどのWebサイトでほぼ高速になっています。

図7.13の説明を表示

40％のWebサイトが高速なFID、45％が適度のFID、15％が低速のFIDであることを示す棒グラフ。

十分に高速や低速のFIDとなるWebサイトのラベル付けを行うため、PSI方法論はFCPと少しだけ異なる方法を取ります。高速なサイトと定義するのは、FID体験の95％以上を高速と定める必要があります。遅いFID体験となる5％のサイトを遅いとして、そのほかの体験を適度とします。

以前の測定と比較して、集計されたFIDパフォーマンスの分布は低速よりも高速および適度の体験に大きく偏っています。Webサイトの40%でFIDが早く、FIDが遅いと言えるのは15%だけです。FIDが対話性の計測であるという性質は、ネットワーク速度によって制限される読み込みの計測と違い、パフォーマンス特性の全く異なる方法になります。

デバイス毎のFID

図7.14の説明を表示

デスクトップWebサイト1,000個の高速、適度、低速FIDの配布。 Webサイトの最速の4分の3で、高速FIDの分布は100％から90％にかけて非常にゆっくりと減少して、その後高速FIDは75％まで減少します。 ほぼすべてのデスクトップWebサイトは、75％以上の高速なFID体験を備えています。

図7.15の説明を表示

モバイルWebサイト1,000個の高速、適度、低速FIDの配布。 高速なFIDの分布は着実に減少していますが、デスクトップよりもはるかに速く減っています。 ウェブサイトの4分の3までが75％となる高速に達していますが、その後すぐに0％に低下します。

FIDをデバイスで分類してみると、この2つはまったく別の話となるようです。デスクトップユーザーの殆どは常に高速なFIDで楽しめているようです。まれに遅い体験をさせられるWebサイトがあるかもしれませんが、結果としては圧倒的に高速となっています。一方モバイルのユーザーは2種類の体験に大別できます。かなり高速(デスクトップほどではないが)か、全く早くないのどちらかとなるようです。後者はWebサイトの10%のみ体験しているようですが、これは大きな違いでしょう。

図7.16の説明を表示

デスクトップとモバイルFID分布の棒グラフ。 デスクトップは高速、適度、低速がそれぞれ82％、12％、5％。 モバイルの場合26％、52％、22％。

PSIラベルをデスクトップと携帯電話の体験に適用してみると、差分が非常に明瞭になります。デスクトップユーザーが経験するWebサイトの82％はFIDが高速であるのに対し、低速は5％だけです。モバイルで体験するWebサイトは、26％が高速であり、22％が低速です。フォームファクターは、FIDなどの対話性計測の成果に大きな役割を果たします。

有効な接続タイプ別のFID

図7.17の説明を表示

有効な接続タイプ毎のFID分布の棒グラフ。4G高速、適度、低速がそれぞれ41％、45％、15％。3G：22％、52％、26％。 2G：19％、58％、23％。 低速な2G：15％、58％、27％。

一見、FIDはCPUの動作速度が影響するように思えます。性能の悪いデバイスを使うと、ユーザーがWebページを操作しようとしたときに待ち状態になる可能性が高いと考えるのは自然でしょうか？

上記のECTの結果からは、接続速度とFIDパフォーマンスの間に相関関係があることが示されています。ユーザーの有効な接続の速度が低下すると、高速なFIDを体験するWebサイトの割合も低下しています。4GのECTを使うユーザーがアクセスするWebサイトの41%は高速なFIDで、3Gは22%、2Gは19%、低速な2Gは15%です。

FID by geo

図7.18の説明を表示

最も人気のある上位23の地域のFID分布の棒グラフ。最速のWebサイトは韓国の69％です。そこから高速なWebサイトの割合は、オーストラリア55％、アメリカ合衆国52％、カナダ51％となり、他の地域で確実に減少しています。

この地理的な位置によるFIDの内訳では、韓国はまたもや他のすべてよりも抜きん出ています。しかし、トップを占める地域にはいくつか新しい顔ぶれが現れています。次に現れるのはオーストラリア、米国、カナダとなっており、50％以上のWebサイトが高速なFIDとなっています。

他の地域固有の結果と同様に、ユーザー体験に影響を与える可能性のある要因は多数あるでしょう。例えば、より裕福な地理的条件が揃う地域に住んでいる人々は、より高速なネットワーク・インフラを購入でき、デスクトップも携帯電話もお金をかけてハイエンドなものを持っている率は高くなる可能性があります。

結論

Webページの読み込み速度を定量化することは、単一の計測では表すことのできない不完全な科学です。従来のonload等を計測する計測する方法は、ユーザー体験とは関係のない部分まで計測してしまい、本当に抑えるべき点を見逃してしまう可能性があります。FCPやFIDなどのユーザーの知覚に相当する計測は、ユーザーが見たり感じたりする内容を着実に伝達できます。ただそれでも、どちらの計測も単独で見てはページ全体の読み込み体験が高速なのか低速かについての結論を導き出すことはできません。多くの計測値を総合的に見ることでのみ、Webサイト個々のパフォーマンスとWebの状態を理解することができます。

この章で表されたデータから、高速なWebサイトとにするためには多くの設定されるべき目標と作業があることを示しています。確かなフォームファクター、効果的な接続の種類、そして地理にはユーザー体験の向上と相関しますが、低いパフォーマンスとなる人口の統計も組み合わせる必要があることを忘れてはいけません。殆どの場合、Webプラットフォームはビジネスで使われています。コンバージョン率を改善してより多くのお金を稼ぐことは、Webサイトを高速化する大きな動機になるでしょう。最終的に、すべてのWebサイトのパフォーマンスとは、ユーザーの邪魔をしたり、イラつかせたり、怒らせたりしない方法で、ユーザーにより良い体験を提供することです。

Webがまた一つ古くなり、ユーザー体験を測定する能力が徐々に向上するにつれて、開発者がより総合的なユーザー体験を捉えて計測された値を身近に思えるようになることを楽しみにしています。FCPは有用なコンテンツをユーザーに表示するタイムラインのほぼ最初部分であり、それ以外にもLarge Contentful Painthttps://web.dev/articles/lcp（LCP）と呼ばれる新しい計測値が出現して、ページの読み込みがどのように認識されるかの可視性が向上しています。Layout Instability APIhttps://web.dev/articles/clsは、ページの読み込み以降でユーザーが不満を持つ体験がある事を新たに垣間見せてくれました。

こういった新しい計測が出来るようになった2020年のWebは、さらに透明性が高まって理解が深まり、開発者がパフォーマンスを改善するための有意義な進歩を遂げることで、より良いユーザー体験を提供できるでしょう。

セキュリティ

序章

Web Almanacのこの章では、Web上のセキュリティの現状を見ていきます。オンラインでのセキュリティとプライバシーの重要性がますます高まる中、サイト運営者とユーザーを保護するための機能が増えています。ここでは、ウェブ上でのこれらの新機能の採用状況を見ていきます。

トランスポートレイヤーセキュリティ

現在、オンラインでのセキュリティとプライバシーを向上させるための最大の後押しは、おそらくトランスポート・レイヤー・セキュリティ（TLS）の普及です。TLS（または古いバージョンのSSL）は、HTTPSの「S」を提供し、安全でプライベートなWebサイトのブラウジングを可能にするプロトコルです。ウェブ上でのHTTPSの使用が大幅に増加しているhttps://httparchive.org/reports/state-of-the-web#pctHttpsだけでなく、TLSv1.2やTLSv1.3のような最新バージョンのTLSが増加していることも重要です。

図8.1の説明を表示

横棒グラフは、モバイルのHTTPSが79%、HTTPが21%、その下にデスクトップのHTTPSが 80.51%、HTTPが19.49%であることを示しています。

プロトコルのバージョン

図8.2の説明を表示

横棒グラフは、デスクトップとモバイルのTLSの使用状況を示しています。TLSv1.2が58%、TLSv1.3が41%、TLSv1.0の使用率はほとんどなく (0.75%)、TLSv1.1の使用率はわずかです。

図8.2は、さまざまなプロトコルバージョンのサポートを示しています。TLSv1.0やTLSv1.1のようなレガシーなTLSバージョンの使用は最小限であり、ほとんどすべてのサポートはプロトコルの新しいバージョンであるTLSv1.2やTLSv1.3に対応しています。TLSv1.3はまだ標準としては非常に若いですが（TLSv1.3は2018年8月https://tools.ietf.org/html/rfc8446に正式に承認されたばかりです）、TLSを使用するリクエストの40％以上が最新バージョンを使用しています！　TLSv1.0やTLSv1.1のようなレガシーバージョンの使用はほとんどありません。

これは、多くのサイトがサードパーティコンテンツのために大きなプレイヤーからのリクエストを使用していることが原因であると考えられます。例えば、どのようなサイトでもGoogle Analytics、Google AdWords、またはGoogle FontsをロードしGoogleのような大規模なプレイヤーは通常新しいプロトコルのためのアーリーアダプターです。

ホームページだけを見て、それ以外のサイトのリクエストをすべて見ない場合、TLSの使用率は予想通りかなり高いですが、WordpressのようなCMSサイトやCDNのようなサイトが原因である可能性は高いです。

図8.3の説明を表示

横棒グラフは、デスクトップとモバイルの類似したTLSの使用状況を示しています。デスクトップでは47%(モバイルでは43%)がTLSv1.2、デスクトップでは20.2%(モバイルでは19.7%)がTLSv1.3を使用しており、TLSv1.0の使用量はほとんどなく(1.1%～1.2%)、TLSv1.1の使用量はわずかです。

一方で、Web Almanacが使用している方法論は、大規模サイトの利用状況を過小評価します。なぜなら、大規模サイトはそのサイト自体が現実世界ではより大きなインターネット・トラフィックを形成している可能性が高いにもかかわらず、これらの統計のために一度しかクロールされないからです。

証明書発行者

もちろん、ウェブサイトでHTTPSを使用するには、認証局（CA）からの証明書が必要です。HTTPSの使用の増加に伴い、CAとその製品／サービスの使用も増加しています。ここでは、証明書を使用するTLSリクエストの量に基づいて、上位10社の証明書発行者を紹介します。

前述したように、Googleのボリュームは他のサイトでGoogleアナリティクス、Google Adwords、またはGoogle Fontsを繰り返し使用していることを反映している可能性が高い。

Let’s Encrypthttps://letsencrypt.org/ja/の台頭は2016年初頭の開始後、急成長を遂げ、それ以来世界でもトップレベルの証明書発行局の1つになりました。無料の証明書の可用性と自動化されたツールは、ウェブ上でのHTTPSの採用に決定的に重要な役割を果たしています。Let’s Encryptは、これらの両方において重要な役割を果たしています。

コストの削減により、HTTPSへの参入障壁は取り除かれましたが、Let’s Encryptが使用する自動化は証明書の寿命を短くできるため、長期的にはより重要であると思われます、これは多くのセキュリ ティ上のメリットがありますhttps://scotthelme.co.uk/why-we-need-to-do-more-to-reduce-certificate-lifetimes/。

認証キーの種類

HTTPSを使用するという重要な要件と並行して、適切な構成を使用するという要件もあります。非常に多くの設定オプションと選択肢があるため、これは慎重にバランスを取る必要があります。

まず、認証に使用される鍵について見ていきましょう。従来、証明書はRSAアルゴリズムを使用した鍵に基づいて発行されてきましたが、より新しく優れたアルゴリズムであるECDSA(Elliptic Curve Digital Signature Algorithm — 楕円曲線DSA) を使用しており、RSAアルゴリズムよりも優れた性能を発揮する小さな鍵の使用を可能にしています。私たちのクロールの結果を見ると、ウェブの大部分がRSAを使用していることがわかります。

ECDSA鍵はより強力な鍵であるため、より小さな鍵の使用が可能となりRSA鍵よりも優れたパフォーマンスを発揮しますが、下位互換性に関する懸念やその間の両方のサポートの複雑さが一部のウェブサイト運営者の移行を妨げる要因となっています。

Forward secrecy

Forward secrecyhttps://ja.wikipedia.org/wiki/Forward_secrecyは将来サーバの秘密鍵が漏洩した場合でも、サーバへの各接続が公開されるのを防ぐような方法で接続を保護するいくつかの鍵交換メカニズムの特性です。これは、接続のセキュリティを保護するために全てのTLS接続で望ましい事として、セキュリティコミュニティ内ではよく理解されています。2008年にTLSv1.2でオプション設定として導入され、2018年にはTLSv1.3でForward Secrecyの使用が必須となりました。

Forward Secrecyを提供するTLSリクエストの割合を見ると、サポートが非常に大きいことがわかります。デスクトップの96.92％、モバイルリクエストの96.49％がForward Secrecyを使用しています。TLSv1.3の採用が継続的に増加していることから、これらの数字はさらに増加すると予想されます。

暗号スイート

TLSでは、さまざまな暗号スイートを使用できます。従来、TLSの新しいバージョンは暗号スイートを追加してきましたが、古い暗号スイートを削除することには消極的でした。TLSv1.3はこれを単純化するために、より少ない暗号スイートのセットを提供し、古い安全でない暗号スイートを使用することを許可しません。SSL Labshttps://www.ssllabs.com/ のようなツールは、ウェブサイトのTLS設定 (サポートされている暗号スイートとその好ましい順序を含む) を簡単に見ることができ、より良い設定を促進するのに役立ちます。TLSリクエストのためにネゴシエートされた暗号化スイートの大部分は確かに優れたものであったことがわかります。

古いCBC暗号は安全性が低いので、GCM暗号がこのように広く使われるようになったのはポジティブなことです。CHACHA20_POLY1305https://blog.cloudflare.com/it-takes-two-to-chacha-poly/はまだニッチな暗号スイートであり、私たちはまだ安全でないトリプルDES暗号https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AA%E3%83%97%E3%83%ABDES#%E5%AE%89%E5%85%A8%E6%80%A7をごくわずかしか使っていません。

これらはChromeを使ったクロールに使われた暗号化スイートですが、サイトは古いブラウザでも他の暗号化スイートをサポートしている可能性が高いことに注意してください。例えばSSL Pulsehttps://www.ssllabs.com/ssl-pulse/ などの他の情報源では、サポートされているすべての暗号スイートとプロトコルの範囲についてより詳細な情報を提供しています。

混合コンテンツ

ウェブ上のほとんどのサイトは元々HTTPサイトとして存在しており、HTTPSにサイトを移行しなければなりませんでした。この「リフトアンドシフト」作業は難しく、時には見落としたり、取り残されたりすることもあります。その結果、ページはHTTPSで読み込まれているが、ページ上の何か（画像やスタイルなど）はHTTPで読み込まれているような、コンテンツが混在しているサイトが発生します。コンテンツが混在していると、セキュリティやプライバシーに悪影響を及ぼし、発見して修正するのが困難になることがあります。

モバイル（645,485サイト）とデスクトップ（594,072サイト）では、約20％のサイトが何らかの形で混合コンテンツを表示していることがわかります。画像のようなパッシブな混合コンテンツの危険性は低いですが、混合コンテンツを持つサイトのほぼ4分の1がアクティブな混合コンテンツを持っていることがわかります。JavaScriptのようなアクティブな混合コンテンツは、攻撃者が自分の敵対的なコードを簡単にページに挿入できるため、より危険です。

これまでのウェブブラウザは、受動的な混合コンテンツを許可して警告を表示していたが、能動的な混合コンテンツはブロックしていた。しかし最近では、Chrome発表https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html はこの点を改善し、HTTPSが標準になるにつれて代わりにすべての混合コンテンツをブロックすることを意図しています。

セキュリティヘッダ

サイト運営者がユーザーをより良く保護するための多くの新しい機能が、ブラウザに組み込まれたセキュリティ保護を設定したり制御したりできる新しいHTTPレスポンスヘッダの形で提供されています。これらの機能の中には、簡単に有効にして大きなレベルの保護を提供するものもあれば、サイト運営者が少し作業を必要とするものもあります。サイトがこれらのヘッダを使用しており、正しく設定されているかどうかを確認したい場合は、Security Headershttps://securityheaders.com/ツールを使用してスキャンできます。

図8.8の説明を表示

デスクトップ、モバイルともに、左から順にセキュリティヘッダリストの使用量が増加していることを縦棒グラフで示しています。左から順に、Cross-origin-resource-policy(両方とも0サイト)、feature policy(デスクトップとモバイルで約8k)、report-to(デスクトップで74k、モバイルで83k)、nel(デスクトップで74k、モバイルで83k)、referrer-policy(デスクトップで142k、モバイルで156k)、content-security-policy(デスクトップで240k)のリストです。252k モバイル）、strict-transport-security（648k デスクトップ、679k モバイル）、x-xss-protection（642k デスクトップ、805k モバイル）、x-frame-options（743k デスクトップ、782k モバイル）、そして最後にx-content-type-options（770k デスクトップ、932k モバイル）です。

HTTP Strict Transport Security

HSTShttps://tools.ietf.org/html/rfc6797 ヘッダーは、Webサイトがブラウザに、安全なHTTPS接続でのみサイトと通信するように指示することを可能にします。これは、http:// URLを使用しようとする試みは、リクエストが行われる前に自動的にhttps://に変換されることを意味します。リクエストの40％以上がTLSを使用できることを考えると、要求するようにブラウザに指示しているリクエストの割合はかなり低いと考えられます。

モバイルページやデスクトップページの15％未満がmax-ageディレクティブ付きのHSTSを発行しています。これは有効なポリシーの最低条件です。また、includeSubDomainsディレクティブでサブドメインをポリシーに含めているページはさらに少なく、HSTSのプリロードを行っているページはさらに少ないです。HSTSのmax-ageの中央値を見ると、これを使用している場合はデスクトップとモバイルの両方で15768000となっており、半年(60X60X24X365/2)に相当する強力な設定であることがわかります。

HSTSプリロード

HTTPレスポンスヘッダーを介して配信されるHSTSポリシーでは、初めてサイトを訪れたときに、ブラウザはポリシーが設定されているかどうかを知ることができません。この初回使用時の信頼https://en.wikipedia.org/wiki/Trust_on_first_useの問題を回避するために、サイト運営者はブラウザ(または他のユーザーエージェント)にポリシーをプリロードしておくことができます。

プリロードにはいくつかの要件があり、HSTSプリロードhttps://hstspreload.org/サイトで概要が説明されています。現在の基準では、デスクトップでは0.31％、モバイルでは0.26％というごく少数のサイトしか対象としていないことがわかる。サイトは、ドメインをプリロードするために送信する前、ドメインの下にあるすべてのサイトをHTTPSに完全に移行させておく必要があります。

コンテンツセキュリティポリシー

ウェブアプリケーションは、敵対的なコンテンツがページへ挿入される攻撃に頻繁に直面しています。最も心配なコンテンツはJavaScriptであり、攻撃者がJavaScriptをページに挿入する方法を見つけると、有害な攻撃を実行できます。これらの攻撃はクロスサイトスクリプティング(XSS)https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0として知られており、コンテンツセキュリティポリシー(CSP)https://www.w3.org/TR/CSP2/ はこれらの攻撃に対する効果的な防御策を提供しています。

CSPとは、ウェブサイトが公開しているHTTPヘッダ(Content-Security-Policy)のことで、サイトで許可されているコンテンツに関するルールをブラウザに伝えるものです。セキュリティ上の欠陥のために追加のコンテンツがサイトに注入され、それがポリシーで許可されていない場合、ブラウザはそのコンテンツの使用をブロックします。XSS保護の他にも、CSPは、HTTPSへの移行を容易にするなど、いくつかの重要な利点を提供しています。

CSPの多くの利点にもかかわらず、その非常に目的がページ上で許容されるものを制限することであるため、ウェブサイトに実装することは複雑になる可能性があります。ポリシーは必要なすべてのコンテンツやリソースを許可しなければならず、大きく複雑になりがちです。レポートURIhttps://report-uri.com/のようなツールは、適切なポリシーを分析して構築するのに役立ちます。

デスクトップページのわずか5.51％にCSPが含まれ、モバイルページのわずか4.73％にCSPが含まれていることがわかりましたが、これは展開の複雑さが原因と思われます。

ハッシュ/ノンス

CSPの一般的なアプローチは、JavaScriptなどのコンテンツをページにロードすることを許可されているサードパーティドメインのホワイトリストを作成することです。これらのホワイトリストの作成と管理は困難な場合があるため、ハッシュhttps://www.w3.org/TR/CSP2/#source-list-valid-hashesとノンスhttps://www.w3.org/TR/CSP2/#source-list-valid-noncesが代替的なアプローチとして導入されました。ハッシュはスクリプトの内容に基づいて計算されるので、ウェブサイト運営者が公開しているスクリプトが変更されたり、別のスクリプトが追加されたりするとハッシュと一致せずブロックされてしまいます。ノンスは、CSPによって許可され、スクリプトにタグが付けられているワンタイムコード(ページが読み込まれるたびに変更され推測されるのを防ぐ必要があります)です。このページのノンスの例は、ソースを見てGoogle Tag Managerがどのように読み込まれているかを見ることで見ることができます。

調査対象となったサイトのうち、ノンスソースを使用しているのはデスクトップページで0.09％、ハッシュソースを使用しているのはデスクトップページで0.02％にとどまっている。モバイルページではノンスソースを使用しているサイトは0.13%とやや多いが、ハッシュソースの使用率は0.01%とモバイルページの方が低い。

strict-dynamic

CSPhttps://www.w3.org/TR/CSP3/の次のイテレーションにおけるstrict-dynamicの提案は、ホワイトリスト化されたスクリプトがさらにスクリプトの依存性をロードできるようにすることで、CSPを使用するためのサイト運営者の負担をさらに軽減します。すでにいくつかの最新ブラウザでサポートhttps://caniuse.com/#feat=mdn-http_headers_csp_content-security-policy_strict-dynamicされているこの機能の導入にもかかわらず、ポリシーにこの機能を含めるのは、デスクトップページの0.03％とモバイルページの0.1％にすぎません。

trusted-types

XSS攻撃には様々な形がありますが、Trusted-Typeshttps://github.com/w3c/webappsec-trusted-typesはDOM-XSSに特化して作られました。効果的なメカニズムであるにもかかわらず、私たちのデータによると、モバイルとデスクトップの2つのページだけがTrusted-Typesディレクティブを使用しています。

unsafe inlineとunsafe-eval

CSPがページにデプロイされると、インラインスクリプトやeval()の使用のような特定の安全でない機能は無効化されます。ページはこれらの機能に依存し、安全な方法で、おそらくノンスやハッシュソースを使ってこれらの機能を有効にできます。サイト運営者は、unsafe-inlineやunsafe-evalを使って、これらの安全でない機能をCSPで再有効にすることもできますが、その名前が示すようにそうすることでCSPが提供する保護の多くを失うことになります。CSPを含むデスクトップページの5.51％のうち、33.94％がunsafe-inlineを、31.03％がunsafe-evalを含んでいます。モバイルページでは、CSPを含む4.73％のうち、34.04％がunsafe-inlineを使用し、31.71％がunsafe-evalを使用していることがわかります。

upgrade-insecure-requests

先に、サイト運営者がHTTPからHTTPSへの移行で直面する共通の問題として、一部のコンテンツがHTTPSページのHTTP上に誤って読み込まれてしまう可能性があることを述べました。この問題は混合コンテンツとして知られており、CSPはこの問題を解決する効果的な方法を提供します。upgrade-insecure-requests‘ディレクティブは、ブラウザにページ上のすべてのサブリソースを安全な接続で読み込むように指示し、例としてHTTPリクエストをHTTPSリクエストに自動的にアップグレードします。ページ上のサブリソースのためのHSTSのようなものと考えてください。

先に図8.7で示したように、デスクトップで調査したHTTPSページのうち、16.27％のページが混合コンテンツを読み込んでおり、3.99％のページがJS/CSS/fontsなどのアクティブな混合コンテンツを読み込んでいることがわかる。モバイルページでは、HTTPSページの15.37％が混合コンテンツを読み込み、4.13％がアクティブな混合コンテンツを読み込みました。HTTP上でJavaScriptなどのアクティブなコンテンツを読み込むことで、攻撃者は簡単に敵対的なコードをページに注入して攻撃を開始できます。これは、CSPのupgrade-insecure-requests ディレクティブが防御しているものです。

upgrade-insecure-requestsディレクティブは、デスクトップページの3.24％とモバイルページの2.84％のCSPに含まれており、採用が増えることで大きな利益が得られることを示しています。以下のようなポリシーで、幅広いカテゴリをホワイトリスト化し、unsafe-inlineやunsafe-evalを含めることで、完全にロックダウンされたCSPや複雑さを必要とせずに比較的簡単に導入できます。

Content-Security-Policy: upgrade-insecure-requests; default-src https:

frame-ancestors

クリックジャッキングhttps://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AA%E3%83%83%E3%82%AF%E3%82%B8%E3%83%A3%E3%83%83%E3%82%AD%E3%83%B3%E3%82%B0として知られているもう1つの一般的な攻撃は、敵対するウェブサイトのiframeの中にターゲットのウェブサイトを配置し、自分たちがコントロールしている隠しコントロールやボタンをオーバーレイする攻撃者によって行われます。X-Frame-Optionsヘッダー(後述)はもともとフレームを制御することを目的としていましたが、柔軟性がなく、CSPのframe-ancestorsはより柔軟なソリューションを提供するために介入しました。サイト運営者は、フレーム化を許可するホストのリストを指定できるようになり、他のホストがフレーム化しようとするのを防ぐことができるようになりました。

調査したページのうち、デスクトップページの2.85％がCSPでframe-ancestorsディレクティブを使用しており、デスクトップページの0.74％がframe-Ancestorsを'none'に設定してフレーミングを禁止し、0.47％のページがframe-ancestorsを'self'に設定して自分のサイトのみがフレーミングできるようにしています。モバイルでは2.52％のページがframe-ancestorsを使用しており、0.71％が'none'を設定し、0.41％がself'を設定しています。

参照元ポリシー

Referrer-Policyヘッダーは、ユーザーが現在のページから離れた場所へ移動したとき、Referererヘッダーにどのような情報を送るかをサイトが制御することを可能とします。これは、検索クエリやURLパラメータに含まれるその他のユーザー依存情報など、URLに機密データが含まれている場合、情報漏洩の原因となる可能性があります。Refererヘッダで送信される情報を制御し、理想的には制限することで、サイトはサードパーティに送信される情報を減らすことで訪問者のプライバシーを保護できます。

リファラーポリシーはReferererヘッダのスペルミスこれはよく知られたエラーとなっていますhttps://stackoverflow.com/questions/3087626/was-the-misspelling-of-the-http-field-name-referer-intentionalに従っていないことに注意してください。

デスクトップページの3.25％とモバイルページの2.95%がReferrerer-Policyヘッダを発行しています。

この表はページによって設定された有効な値を示しており、このヘッダーを使用するページのうち、デスクトップでは99.75％、モバイルでは96.55％のページが有効なポリシーを設定していることがわかる。最も人気のある設定はno-referrer-when-downgradeで、これはユーザがHTTPSページからHTTPページに移動する際Referererヘッダが送信されないようにするものです。2番目に人気のある選択はstrict-origin-when-cross-originで、これはスキームのダウングレード(HTTPSからHTTPナビゲーション)時に情報が送信されるのを防ぎ、Referererで情報が送信される際にはソースのオリジンのみを含み、完全なURLは含まれません(例えば、https://www.example.com/page/ではなくhttps://www.example.com)。その他の有効な設定の詳細は、Referrerer Policy specificationhttps://www.w3.org/TR/referrer-policy/#referrer-policiesに記載されています、unsafe-urlの多用はさらなる調査を必要としますが、アナリティクスや広告ライブラリのようなサードパーティコンポーネントである可能性が高いです。

機能方針

ウェブプラットフォームがより強力で機能も豊富になるにつれ、攻撃者はこれらの新しいAPIを興味深い方法で悪用できるようになります。強力なAPIの悪用を制限するために、サイト運営者はFeature-Policyヘッダを発行して必要のない機能を無効化し、悪用されるのを防ぐことができます。

ここでは、機能方針で管理されている人気の高い5つの機能をご紹介します。

コントロールできる最も人気のある機能はマイクで、デスクトップとモバイルページのほぼ11％がマイクを含むポリシーを発行していることがわかります。データを掘り下げていくと、これらのページが何を許可しているか、またはブロックしているかを見ることができます。

圧倒的に最も一般的なアプローチは、ここではそのアプローチを取っているページの約9％で、完全にマイクの使用をブロックすることです。少数のページでは、独自のオリジンによるマイクの使用を許可しており、興味深いことにページ内のコンテンツを読み込んでいる任意のオリジンによるマイクの使用を意図的に許可しているページの少数選択があります。

X-Frame-Options

X-Frame-Optionsヘッダーは、ページが別のページでiframeに配置できるかどうかを制御することを可能にします。上述したCSPのframe-ancestorsの柔軟性には欠けますが、フレームの細かい制御を必要としない場合には効果的です。

デスクトップ(16.99％)とモバイル(14.77％)の両方でX-Frame-Optionsヘッダの使用率が非常に高いことがわかります。

大多数のページでは、そのページのオリジンのみにフレーミングを制限しているようで、次の重要なアプローチはフレーミングを完全に防止することです。これはCSPのframe-ancestorsと似ており、これら2つのアプローチが最も一般的です。また、allow-fromオプションは、理論的にはサイト所有者がフレーム化を許可するサードパーティのドメインをリストアップできるようにするものですが、決して十分にサポートされていないのでhttps://developer.mozilla.org/docs/Web/HTTP/X-Frame-Options#Browser_compatibility、非推奨とされています。

X-Content-Type-Options

X-Content-Type-Optionsヘッダは最も広く展開されているセキュリティヘッダであり、最もシンプルであり、設定可能な値はnosniffのみです。このヘッダが発行されると、ブラウザはコンテンツの一部をContent-Typeヘッダで宣言されたMIMEタイプとして扱わなければならず、ファイルが異なるタイプのものであることを示唆したときに値を変更しようとはしません。ブラウザが誤ってタイプを嗅ぎ取るように説得された場合、さまざまなセキュリティ上の欠陥が導入される可能性となります。

モバイルとデスクトップの両方で、17.61％のページがX-Content-Type-Optionsヘッダを発行していることがわかりました。

X-XSS-Protection

X-XSS-Protection‘https://developer.mozilla.org/docs/Web/HTTP/Headers/X-XSS-Protectionヘッダーは、サイトがブラウザに組み込まれたXSS AuditorやXSS Filterを制御することを可能にし、理論的には何らかのXSS保護を提供するはずです。

デスクトップリクエストの14.69％とモバイルリクエストの15.2％がX-XSS-Protectionヘッダを使用していた。データを掘り下げてみると、ほとんどのサイト運営者がどのような意図を持っているかが図7.13に示されています。

値1はフィルタ/監査を有効にし、mode=blockは(理論的には)XSS攻撃が疑われる場合にページを表示しないような最も強い保護を設定します。2番目に多かった設定は、単に監査/フィルタがオンになっていることを確認するために1という値を提示したもので、3番目に多かった設定は非常に興味深いものでした。

ヘッダーに0の値を設定すると、ブラウザが持っている可能性のあるXSSの監査やフィルタを無効にするように指示します。歴史的な攻撃の中には監査やフィルタがユーザーを保護するのではなく、攻撃者を助けるように騙されてしまうことが実証されているものもあるのでサイト運営者の中には、XSSに対する十分な保護があると確信している場合にそれを無効にできるものもあります。

これらの攻撃のため、EdgeはXSSフィルタを引退させ、ChromeはXSS監査を非推奨とし、Firefoxはこの機能のサポートを実装しませんでした。現在ではほとんど役に立たなくなっているにもかかわらず、現在でも全サイトの約15％でヘッダーが広く使われています。

Report-To

Reporting APIhttps://www.w3.org/TR/reporting/ は、サイト運営者がブラウザからの遠隔測定https://scotthelme.co.uk/introducing-the-reporting-api-nel-other-major-changes-to-report-uri/の様々な情報を収集できるようにするため導入されました。サイト上の多くのエラーや問題は、ユーザーの体験を低下させる可能性がありますが、サイト運営者はユーザーが連絡しなければ知ることができません。Reporting APIは、ユーザーの操作や中断なしに、ブラウザがこれらの問題を自動的に報告するメカニズムを提供します。Reporting APIはReport-Toヘッダーを提供することで設定されます。

遠隔測定を送信すべき場所を含むヘッダーを指定することでブラウザは自動的にデータの送信を開始し、Report URIhttps://report-uri.com/のようなサードパーティのサービスを使用してレポートを収集したり、自分で収集したりできます。導入と設定の容易さを考えると、現在この機能を有効にしているサイトは、デスクトップ（1.70％）とモバイル（1.57％）のごく一部に過ぎないことがわかります。収集できるテレメトリの種類については、Reporting API仕様https://www.w3.org/TR/reporting/を参照してください。

ネットワークエラーロギング

ネットワークエラーロギング(NEL)https://www.w3.org/TR/network-error-logging/は、サイトが動作不能になる可能性のあるブラウザのさまざまな障害についての詳細な情報を提供します。Report-Toが読み込まれたページの問題を報告するために使用されるのに対し、NELヘッダーを使用すると、サイトはブラウザにこのポリシーをキャッシュするように通知し、将来の接続問題が発生したときに上記のReporting-Toヘッダーで設定されたエンドポイントを介して報告できます。したがって、NELはReporting APIの拡張機能とみなすことができます。

もちろん、NELはReporting APIに依存しているので、NELの使用量がReporting APIの使用量を上回ることはありません。これらの数値が同じであるという事実は、これらが一緒にデプロイされていることを示唆しています。

NELは信じられないほど貴重な情報を提供しており、情報の種類についてはネットワークエラーロギング仕様https://w3c.github.io/network-error-logging/#predefined-network-error-typesで詳しく説明しています。

クリアサイトデータ

クッキー、キャッシュ、ローカルストレージなどを介してユーザーのデバイスにデータをローカルに保存する機能が増えているため、サイト運営者はこのデータを管理する信頼性の高い方法を必要としていました。Clear Site Dataヘッダーは、特定のタイプのすべてのデータがデバイスから削除されることを確実にする手段を提供しますが、すべてのブラウザではまだサポートされていませんhttps://caniuse.com/#feat=mdn-http_headers_clear-site-data。

このヘッダの性質を考えると、使用量がほとんど報告されていないのは驚くに値しません。デスクトップリクエストが9件、モバイルリクエストが7件だけです。私たちのデータはサイトのホームページしか見ていないので、ログアウトのエンドポイントでヘッダーが最もよく使われているのを見ることはないでしょう。サイトからログアウトすると、サイト運営者はClear Site Dataヘッダを返し、ブラウザは指定されたタイプのすべてのデータを削除します。これはサイトのホームページでは行われないでしょう。

クッキー

クッキーには利用可能な多くのセキュリティ保護があり、それらのいくつかは長年にわたって利用可能であるが、それらのいくつかは本当に非常に新しいものでありここ数年の間に導入されただけです。

Secure

クッキーのSecureフラグは、ブラウザに安全な(HTTPS)接続でのみクッキーを送信するように指示し、ホームページでセキュアフラグが設定されたクッキーを発行しているサイトはごくわずかな割合(デスクトップでは4.22％、モバイルでは3.68％)であることがわかります。この機能が比較的簡単に使用できることを考えると、これは憂慮すべきことです。繰り返しになりますが、HTTPとHTTPSの両方でデータを収集したいと考えている分析や広告サードパーティリクエストの高い使用率がこれらの数字を歪めている可能性が高く、認証クッキーのような他のクッキーでの使用状況を見るのは興味深い調査でしょう。

HttpOnly

クッキーのHttpOnlyフラグはブラウザにページ上のJavaScriptがクッキーへアクセスできなくすることを指示します。多くのクッキーはサーバによってのみ使用されるので、ページ上のJavaScriptが必要としないため、クッキーへのアクセスを制限することはクッキーを盗むXSS攻撃からの大きな防御となります。デスクトップでは24.24％、モバイルでは22.23％と、ホームページ上でこのフラグを立ててクッキーを発行しているサイトの方がはるかに多いことがわかります。

SameSite

クッキーの保護に追加された最近の追加機能として、SameSiteフラグは クロスサイトリクエストフォージェリ(CSRF)https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%AA攻撃(XSRFとしてもよく知られています)に対する強力な保護となります。

これらの攻撃は、ブラウザが通常、すべてのリクエストに関連するクッキーを含むという事実を利用して動作します。したがって、ログインしていてクッキーが設定されていて、悪意のあるサイトを訪問した場合、APIを呼び出すことができブラウザは「親切に」クッキーを送信します。クッキーにSameSite属性を追加することで、第三者のサイトからの呼び出しがあった場合にクッキーを送信しないようにウェブサイトがブラウザに通知し、攻撃を失敗させることができます。

最近導入されたメカニズムなので、デスクトップとモバイルの両方でリクエストの0.1％と予想されるように、同じサイトのクッキーの使用率ははるかに低くなっています。クッキーがクロスサイトで送信されるべき使用例があります。例えば、シングルサインオンサイトは認証トークンと一緒にクッキーを設定することで暗黙のうちに動作します。

既にSame-Siteのクッキーを利用しているページのうち、半分以上がstrictモードで利用していることがわかる。これに続いて、laxモードでSame-Siteを利用しているサイト、そして少数のサイトではnoneを利用しているサイトが続いています。この最後の値は、ブラウザベンダーがlaxモードをデフォルトで実装する可能性があるという今後の変更をオプトアウトするために使用されます。

この機能は危険な攻撃からの保護を提供するため、現在のところ、主要なブラウザが デフォルトでこの機能を実装https://blog.chromium.org/2019/10/developers-get-ready-for-new.htmlし、値が設定されていなくてもクッキーに対してこの機能を有効にする可能性があると指摘されています。これが実現した場合、SameSiteの保護機能は有効になりますが、strictモードではなくlaxモードの弱い設定では、より多くの破損を引き起こす可能性があるためです。

プレフィックス

クッキーに最近追加されたもう一つの方法として、クッキープレフィックスがあります。これらはクッキーの名前を使用して、すでにカバーされている保護に加えて、2つのさらなる保護のうちの1つを追加します。上記のフラグはクッキー上で誤って設定を解除される可能性がありますが、名前は変更されませんので、セキュリティ属性を定義するために名前を使用することでより確実にフラグを強制できます。

現在のところ、クッキーの名前の前には__Secure-か__Host-のどちらかを付けることができ、どちらもクッキーに追加のセキュリティを提供しています。

図が示すように、どちらのプレフィックスの使用率も信じられないほど低いのですが、2つのプレフィックスが緩和されているため__Secure-プレフィックスの方がすでに利用率は高いです。

サブリソースの完全性

最近増えているもう1つの問題は、サードパーティの依存関係のセキュリティです。サードパーティからスクリプトファイルを読み込む際には、スクリプトファイルが常に欲しいライブラリ、おそらく特定のバージョンのjQueryであることを期待します。CDNやサードパーティのホスティングサービスが危殆化した場合、それらをホスティングしているスクリプトファイルを変更される可能性があります。このシナリオでは、アプリケーションは訪問者に危害を加える可能性のある悪意あるJavaScriptを読み込んでいることになります。これが、サブリソースの完全性が保護する機能です。

スクリプトやリンクタグにintegrity属性を追加することで、ブラウザはサードパーティのリソースの整合性をチェックし、変更された場合は拒否できます。

<script
  src="https://code.jquery.com/jquery-3.4.1.min.js"
  integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo="
  crossorigin="anonymous"></script>

整合性属性が設定されたリンクまたはスクリプトタグを含むデスクトップページの0.06％（247,604）とモバイルページの0.05％（272,167）しかないため、SRIの使用には多くの改善の余地があります。現在、多くのCDNがSRIの整合性属性を含むコードサンプルを提供しているため、SRIの使用は着実に増加していると思われます。

結論

Webの機能が向上し、より多くの機密データへのアクセスが可能になるにつれ、開発者が自社のアプリケーションを保護するためにWebセキュリティ機能を採用することがますます重要になってきています。本章でレビューするセキュリティ機能は、Webプラットフォーム自体に組み込まれた防御機能であり、すべてのWeb制作者が利用可能です。しかし、本章の研究結果のレビューからもわかるように、いくつかの重要なセキュリティメカニズムはウェブの一部にしか適用されていないため、エコシステムのかなりの部分がセキュリティやプライバシーのバグにさらされたままとなっています。

暗号化

ここ数年の間に、転送中データの暗号化については、Webが最も進歩しています。TLSセクションで説明したように、ブラウザーベンダー、開発者、Let’s Encryptのような認証局の様々な努力のおかげで、HTTPSを使用しているウェブの割合は着実に増加しています。本稿執筆時点では、大多数のサイトがHTTPSで利用可能であり、トラフィックの機密性と完全性が確保されています。重要なことに、HTTPSを有効にしているWebサイトの99％以上では、TLSプロトコルの新しい安全なバージョン（TLSv1.2およびTLSv1.3）が使用されています。GCMモードでのAESなどの強力なcipher suitesの使用率も高く、すべてのプラットフォームで95％以上のリクエストを占めています。

同時に、TLS設定のギャップは依然としてかなり一般的です。15％以上のページが混合コンテンツの問題に悩まされており、ブラウザに警告が表示され、4％のサイトではセキュリティ上の理由から最新のブラウザにブロックされています。同様に、HTTP Strict Transport Securityの利点は、主要なサイトのごく一部にしか及ばず、大多数のWebサイトでは最も安全なHSTS構成を有効にしておらず、HSTS プリロードの対象外となっています。HTTPSの採用が進んでいるにもかかわらず、未だに多くのクッキーがSecureフラグなしで設定されており、クッキーを設定しているホームページのうち、暗号化されていないHTTPでの送信を防止しているのはわずか4％に過ぎません。

一般的なウェブの脆弱性からの防御

機密データを扱うサイトで作業するウェブ開発者は、XSShttps://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0wiki/Cross-site_scripting、CSRFhttps://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%AA、クリックジャッキングhttps://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AA%E3%83%83%E3%82%AF%E3%82%B8%E3%83%A3%E3%83%83%E3%82%AD%E3%83%B3%E3%82%B0、およびその他の一般的なウェブバグからアプリケーションを保護するために、オプトインウェブセキュリティ機能を有効にしていることがよくあります。これらの問題は、X-Frame-Options、X-Content-Type-Options、コンテンツセキュリティポリシーを含む、多くの標準的で広くサポートされているHTTPレスポンスヘッダを設定することで緩和できます。

セキュリティ機能とウェブアプリケーションの両方共複雑であることが大部分を占めていますが、現在これらの防御機能を利用しているウェブサイトは少数派であり、多くの場合、リファクタリングの努力を必要としないメカニズムのみを有効にしています。最も一般的なオプトインアプリケーションのセキュリティ機能は、X-Content-Type-Options (17％のページで有効)、X-Frame-Options (16％)、および非推奨のX-XSS-Protectionヘッダ(15％)です。最も強力なWebセキュリティメカニズムであるコンテンツセキュリティポリシーは、5％のWebサイトでしか有効になっておらず、そのうちのごく一部(全サイトの約0.1％)だけがCSP ナンスとハッシュに基づいたより安全な設定を使用しています。関連する 参照元ポリシーは、Refererヘッダーで第三者に送信される情報量を減らすことを目的としているが、同様に使用しているのは3％のウェブサイトのみです。

現代のウェブプラットフォームの防御

近年、ブラウザーは、主要な脆弱性や新たなWeb脅威からの保護を提供する強力な新しいメカニズムを実装しています; これには、サブリソースの完全性、同じサイトのクッキー、およびクッキーのプレフィックスが含まれます。

これらの機能は比較的少数のウェブサイトでしか採用されていません。Trusted Typeshttps://w3c.github.io/webappsec-trusted-types/dist/spec/、オリジン間リソース共有https://developer.mozilla.org/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)、オリジン間オープナー共有https://www.chromestatus.com/feature/5432089535053824のような、さらに最近のセキュリティメカニズムは、まだ広く採用されていません。

同様に、Reporting API、ネットワークエラーロギング、Clear-Site-Dataヘッダのような便利な機能もまだ初期段階であり、現在は少数のサイトで利用されています。

結びつき

ウェブの規模では、オプトインプラットフォームのセキュリティ機能の全体的なカバー率は、現在のところ比較的低い。最も広く採用されている保護であっても、一般的なセキュリティ問題に対するプラットフォームのセーフガードを持たないウェブの大部分を残して、ウェブサイトの4分の1未満で有効になっています。

しかし、これらのメカニズムの採用は、より機密性の高いユーザーデータを頻繁に扱う大規模なウェブアプリケーションに偏っていることに注意することが重要です。これらのサイトの開発者は、一般的な脆弱性に対する様々な保護を可能にすることを含め、ウェブの防御力を向上させるために投資することが多くなっています。Mozilla Observatoryhttps://observatory.mozilla.org/やSecurity Headershttps://securityheaders.com/などのツールは、ウェブで利用可能なセキュリティ機能の便利なチェックリストを提供してくれます。

ウェブアプリケーションが機密性の高いユーザーデータを扱う場合はユーザーを保護し、ウェブをより安全にするためこのセクションで概説されているセキュリティメカニズムを有効にすることを検討してください。

アクセシビリティ

導入

Webのアクセシビリティは、包摂的で公平な社会の上では無くてはならない存在です。私たちの社会性と仕事や生活の多くがオンラインの世界に推移するにつれて、障害のある人々も分け隔てなく、すべてのオンラインの対話に参加できることがさらに重要になってきます。建築家が車椅子用の傾斜路のようなアクセシビリティ機能を作成や省略できるように、Web開発者はユーザーが頼りにしている支援技術を助けたり邪魔したりできます。

障害を持つユーザーの事を考えた時ユーザージャーニーはほぼ同じとなることを忘れないでください、彼らは異なるツールを使っているだけでしかありません。よく知られてるツールとして、スクリーンリーダー、画面拡大鏡、ブラウザまたは文字の拡大、音声コントロールなどがありますが、これ以外にも色々とあります。

ほとんどの場合、アクセシビリティを改善することでサイトを訪れるすべての人に対してメリットを与える事ができます。私達は普通、障害者は生涯その障害を抱えていると思っていますが、一時的だったり状況的に障害を持つような人も居ます。たとえばその誰かが全盲なのか、一時的な目の感染症なのか、はたまた野外で眩しい太陽の下という状況なのか。これらすべて、その誰かが画面を見ることができない理由の説明になります。誰もが状況により障害を持ちうるため、Webページのアクセシビリティを改善することは、あらゆる状況ですべてのユーザーの体験を向上させることに繋がります。

Webコンテンツのアクセシビリティガイドラインhttps://www.w3.org/WAI/WCAG21/quickref/ (WCAG)はWebサイトの利便性を向上する方法についてのアドバイスが纏められています。このガイドラインを分析の基礎に使いました。しかし、ほとんどの場合においてWebサイトのアクセシビリティをプログラムによって分析するのは非常に困難です。たとえば、Webプラットフォームは機能的には同じ結果となる複数の方法を提供しており、それを実現するための基盤となるコードはまったく別物になる場合があります。したがって、私達の分析結果はWebアクセシビリティ全体の単なる概算でしかありません。

私達はもっとも興味深い洞察を4種類のカテゴリに分類しました。それは読みやすさ、Web上のメディア、ページナビゲーションのしやすさ、補助技術との互換性です。

テスト中にデスクトップとモバイルの間でアクセシビリティに大きな違いは見つかりませんでした。この結果で提示されているメトリックは、とくに明記していない限りはデスクトップの分析結果です。

読みやすさ

Webページの主な目的はユーザーの興味を引くコンテンツを配信することです。このコンテンツはビデオや画像の組み合わせなどありますが、ほとんどの場合、シンプルなページ上のテキストです。テキストコンテンツが読者にとって読みやすいことは、とても重要です。訪問者がWebページを読めない場合、訪問者はWebページに興味を持つことがなくなり、最終的には離脱してしまうでしょう。この節ではサイトが苦労するであろう3つの分野を見ていきます。

色のコントラスト

あなたのサイトの訪問者が完璧な内容を見ることができない、さまざまな可能性があります。訪問者は色覚多様性を持ち、フォントと背景色を区別できない場合があります（ヨーロッパ系の男性12人に1人、女性200人に1人http://www.cvrl.org/people/stockman/pubs/1999%20Genetics%20chapter%20SSJN.pdf）。おそらく、彼らは太陽の下で画面の明るさを最大にして読んでいるため、視力を著しく損なっているのでしょう。もしくは年をとってしまい、彼らの目が以前と同じように色を区別できなくなったのでしょう。

このような条件下であっても、あなたのWebサイトが確実に読めるようにするため、テキストと背景で十分な色のコントラストがあることを確認することは重要です。

図9.1の説明を表示

褐色とグレー4色のボックスに白いテキストがあり、2列に並んでいます。左の列は、色の薄い、 #FCA469 と書かれた褐色色の背景色があります。右の列は、推奨と表示されており、褐色色の背景色に #BD5B0E と書かれています。各列の上のボックスには白いテキスト#FFFFFFに褐色色の背景で、下のボックスは灰色の背景に白いテキスト#FFFFFFとなっています。同等のグレースケールは、それぞれ ＃B8B8B8 および ＃707070 です。LookZook提供。

すべてのテキストに十分な色のコントラストが適用されているサイトは22.04％のみでした。これは言い換えると、5つのサイトのうち4つは背景に溶け込んで読みにくいテキストを持っていると言うことです。

ズーミングとページのスケーリング

読みやすいフォントサイズhttps://accessibleweb.com/question-answer/minimum-font-size/やターゲットサイズhttps://www.w3.org/WAI/WCAG21/quickref/#target-sizeを使うことで、ユーザーがWebサイトを読んだり操作するのを手助けできます。しかし、このガイドラインに対して完全に準拠しているWebサイトですら、訪問者一人ひとりの特定のニーズを満たすことはできません。これがピンチズームやスケーリングなどのデバイスによる機能が非常に重要となる理由です。ユーザーが貴方のページを微調整できるようにして彼らのニーズを満たします。また、小さなフォントやボタンが使われて操作が非常に難しいサイトであっても、ユーザーにそのサイトを使う機会を与えることができます。

まれですが、スケーリングの無効化が許容される場合はあります。それは問題となるページがタッチコントロールを使ったWebベースのゲームなどの場合です。このような場合、有効にしてしまうとプレイヤーがゲームで2回タップをするたびにプレイヤーのスマホがズームインやズームアウトしてしまい、皮肉なことに操作できなくなってしまいます。

なので、開発者はメタビューポートタグhttps://developer.mozilla.org/docs/Web/HTML/Viewport_meta_tagで次の2つのプロパティのどちらかを設定することで、この機能を無効化できます。

1. user-scalableを0かnoに設定

2. maximum-scaleを1もしくは1.0などに設定

悲しいことに、開発者はこの機能を誤用しすぎており、モバイルサイトの3つのうち1つ（32.21％）でこの機能を無効化しています。さらにApple（iOS 10の時点）でWeb開発者がズームを無効化できなくなってしまいました。モバイルSafariは純粋にタグを無視しますhttps://archive.org/details/ios-10-beta-release-notes。すべてのサイトは新しいiOSデバイスでズームとスケーリングができます。

図9.2の説明を表示

20刻みの0から80までの垂直測定パーセンテージデータ。デバイスタイプをデスクトップとモバイルでグループ化しています。デスクトップで有効なのは 75.46%無効が24.54%、モバイルで有効なのは67.79%無効が32.21%.

言語の識別

Webには驚くべき大量のコンテンツが溢れていますが、ここには大きな落とし穴があります。世界には1,000以上の異なる言語が存在しており、探しているコンテンツが流暢な言葉で書かれていない可能性があります。昨今、私たちは翻訳技術で大きな進歩を遂げており、貴方はおそらくその1つをWebで利用しているでしょう（例：Google翻訳）

この機能を円滑に行うために、翻訳エンジンはあなたのページがどの言語で書かれているかを知る必要があります。これにはlang属性が使われます。lang属性がないと、コンピューターはページが記述されている言語を推測する必要が出てきます。想像できると思いますが、ページ中で複数の言語が使われている場合、これは多くの間違いを引き起こします（たとえば、ページナビゲーションは英語なのに投稿されているコンテンツが日本語のような場合）。

この言語が指定されていない場合の問題は、規定のユーザー言語でテキストを読む傾向があるスクリーンリーダーのようなテキスト読み上げ支援技術で顕著になります。

分析の結果、26.13％でlang属性による言語指定がありませんでした。これは4分の1以上のページが上記のような問題の影響を受けやすいという事です。良いニュース？ lang属性を使っているサイトの99.68％で有効な言語コードが適用されています。

煩わしいコンテンツ

認知障害などの一部のユーザーは、1つの作業に対して長時間集中することが困難です。こういったユーザーは、とくに表面的なエフェクトが多く、それが目の前の作業に関わらない場合、動きやアニメーションが多く含まれるページを利用したくありません。

残念なことに、私達の調査結果では無限ループアニメーションがWebでは非常に一般的であり、21.04％のページが無限CSSアニメーションや<marquee>および<blink>要素が使われている事を示しています。

ただし、この問題の大部分は人気のあるサードパーティー製のスタイルシートが規定で無限ループのCSSアニメーションが含まれている事が原因であることに注意してください。このようなアニメーションスタイルを実際に適用したページ数がいくつあるのか、私達は特定できませんでした。

Web上のメディア

画像の代替テキスト

画像はWebの体験の根幹です。それらは強い物語性を伝えることができ、注意を引いて感情を引き出すことができます。しかし、ストーリーの一部を伝えるために私達が頼っている画像は、誰でも見ることができるわけではありません。幸いなことに、1995年、HTML 2.0でこの問題に対する解決策が提供されました、それはalt属性https://webaim.org/techniques/alttext/です。alt属性は使われている画像にテキストの説明を追加できる機能をWeb開発者に提供します。これによって、画像を見ることができない（もしくは読み込めない）ときに、altテキストに書かれた説明を読むことができます。altテキストは、彼らが見逃していたかもしれないストーリーの一部を埋めることができます。

alt属性は25年前から存在していますが、49.91％のページで画像の一部にalt属性が提供されておらず、8.68％のページでまったく使用されていませんでした。

ビデオやオーディオの字幕

画像が強力なストーリーテラーであるように、オーディオとビデオも注目を集めたりアイデアを表現する事ができます。オーディオやビデオコンテンツに字幕が付けられていない場合、コンテンツが聞こえないユーザーはWebのほとんどを見逃してしてしまいます。耳が聞こえない、もしくは難聴のユーザーから一番よく聞くのは、すべてのオーディオとビデオコンテンツに字幕を含めて欲しいというお話です。

<audio>や<video>要素を使うサイトのうち、字幕を提供しているのは0.54％のみでした（<track>要素を含むサイトで測定）一部のWebサイトには、ユーザーにビデオとオーディオの字幕を提供するカスタムソリューションがあります。これらは検出できなかったので、字幕を利用しているサイトの本当の割合は、おそらく少し高いでしょう。

使いやすいページナビゲーション

レストランでメニューを開くとき、おそらく最初にするのは前菜、サラダ、主料理、デザートなどのセクションヘッダーをすべて読むことでしょう。ここから、すべてのメニューの選択肢を見渡し、もっとも興味のある料理に飛ぶことができます。同様に、訪問者がWebページを開く時、訪問者の目標はもっとも興味を持っている情報を見つけることです（それがページにアクセスした理由のはずです）ユーザーが目的のコンテンツをできるだけ早く見つけることができるように（それと、戻るボタンを押させないため）ページのコンテンツをいくつかの視覚的に異なるセクションに分割する必要があります。たとえば、ナビゲーション用のサイトヘッダーを置き、記事の見出しをユーザーが素早く見渡せるようにしたりその他の無関係なリソースを纏めたフッターなどをに分割する等です。

これは非常に重要な事で、訪問者のコンピューターがこれらの異なるセクションを認識できるよう、注意してページのマークアップをする必要があります。それはなぜかと言うと、ほとんどの読者はマウスを利用してページを探索しますが、それ以外の読者はキーボードとスクリーンリーダーに依存しています。これらのテクノロジーは、コンピューターがあなたのページをどの程度理解できるかに大きく依存します。

見出し

見出しは見た目上で有用なだけではなく、スクリーンリーダーでも役立ちます。見出しによってスクリーンリーダーはセクション間を素早く移動でき、さらに、セクションが終了して別のセクションが開始される場所を明示的にします。

スクリーンリーダーを使うユーザーの混乱を避けるために、見出しのレベルを飛ばさないようにしてください。たとえば、H2をスキップして、H1の次にH3を使うのは止めてください。なぜこれが重要なのか？　それはスクリーンリーダーを使うユーザーが、予期せぬ変化からコンテンツを見逃したと勘違いしてしまうためです。このような場合、本当は見逃しがないにもかかわらず、見逃している可能性があるものを探し始めてしまいます。あわせて、より一貫したデザインを維持することで、すべての読者を支援します。

そうは言いつつも、結果としては次のようになっています。

1. 89.36％のページが何らかの方法で見出しを使っています。素晴らしことです。
2. 38.6％のページは見出しのレベルを飛ばしています。
3. 不思議な事に、H2はH1よりも多くのサイトで見つかりました。

図9.3の説明を表示

20毎に0から80の範囲のパーセンテージデータを測定する垂直棒グラフ。各見出しはh1〜h6レベルを表します。H1：63.25％、H2：67.86％、H3：58.63％、H4：36.38％、H5：14.64％、H6：6.91％。

Mainランドマーク

mainランドマークhttps://developer.mozilla.org/docs/Web/Accessibility/ARIA/Roles/Main_roleはWebページのメインコンテンツが始まる場所をスクリーンリーダーに示すことで、ユーザーがーすぐその場所に飛ぶことができます。mainランドマークがない場合、スクリーンリーダーのユーザーはサイト内の新しいページにアクセスするたび、手動でナビゲーションをスキップする必要が出てきます。これは明らかにイライラするでしょう。

ページの4分の1（26.03％）にだけmainランドマークが含まれていることが判明しました。さらに驚くべきことに、8.06％のページに複数のmainランドマークが誤って含まれているため、ユーザーは実際のメインコンテンツがどのランドマークなのかを推測する必要が出ていました。

図9.4の説明を表示

20毎に0〜80の範囲のパーセントデータを表示する垂直棒グラフと、0〜4のページごとの「main」ランドマークの数を表すバー。ソース：HTTP Archive （2019年7月）。 0：73.97％、1：17.97％、2：7.41％、3：0.15％; 4：0.06％。

HTML section要素

HTML5は2008年リリースされ、2014年に公式の標準となっているので、コンピューターとスクリーンリーダーがページの見た目と構造を理解するのに有用なHTML要素がたくさんあります。

<header>、<footer>、<navigation>、<main>などの要素は特定の種類のコンテンツがどこにあるか明示的にして、ユーザーがそのページへ素早く飛ぶことを可能にします。これらはWeb全体で幅広く使われており、ほとんどがページの50％以上で使われています。(<main>は外れ値です。)

<article>、<hr>、<aside>のようなものは、読者がページのメインコンテンツを理解するのに役立ちます。たとえば、<article>は記事が終了して別の記事が開始される場所を示します。これらの要素はほとんど使われておらず、使用率は約20％ですが、これらはすべてのWebページで必要となるわけではないため、とくに驚くべき統計ではありません。

これらの要素はすべてアクセシビリティサポートを主目的として設計されており、見た目の変化はありません。つまりこれは、既存の要素を安全に置き換えることが可能なので意図しない影響で苦しむことはないでしょう。

図9.5の説明を表示

各要素のバーと20毎に0〜60の範囲のページの割合を表す水平線を含む縦棒グラフ。nav：53.94％、header：54.82％、footer：55.92％、main：18.47％、aside：16.99％、article：22.59％、hr：19.1％、section：36.55%。

ナビゲーションで使われているその他のHTML要素

よく使われているスクリーンリーダーは、ユーザーがリンク、一覧、一覧のアイテム、iframe、それと編集フィールド、ボタン、リストボックスなどのフォームフィールドに素早く飛び、誘導できます。図9.6はこういった要素を使うページの表示頻度を表しています。

図9.6の説明を表示

各要素を示すバーと、25毎に0~100の範囲でページの割合を示す縦棒グラフ。a：98.22％、ul：88.62％、input：76.63％、iframe：60.39％、button：56.74％、select：19.68％、textarea：12.03%。

スキップリンク

スキップリンクhttps://webaim.org/techniques/skipnav/はスクリーンリーダーやキーボードだけを使うユーザーが、メインコンテンツに直接飛ぶことができるようにする、ページ上部に配置されるリンクです。これは、ページの上部にあるすべてのナビゲーションリンクとメニューを効率的に「スキップ」します。スキップリンクは、スクリーンリーダーを利用していないキーボードユーザーにとってとくに便利です。それは、このようなユーザーは通常他のクィックナビゲーションモード（ランドマークや見出しなど）にアクセスできないためです。サンプリングされたページの14.19％にスキップリンクが使われていました。

スキップリンクの動作を試す事ができます！　シンプルにGoogle検索を実行し、検索結果ページが表示されたらすぐに「Tab」キーを押します。図9.7のような、事前に隠されたリンクが表示されます。

図9.7の説明を表示

「Http Archive」を検索するためのGoogle検索結果ページのスクリーンショット。表示される「メインコンテンツにスキップ」のリンクは青色のフォーカスハイライトと、スキップリンクを示す赤い矢印の付いた黄色のオーバーレイボックスに囲まれ「google.comのスキップリンク」と表示されます。

実際、ここでも使用するhttps://github.com/HTTPArchive/almanac.httparchive.org/pull/645ので、このサイトを離れる必要もありません。

サイトを分析するときに、正しいスキップリンクを判断するのは困難です。なのでこの分析ではページの最初の3つのリンク内にアンカーリンク（href=#heading1）が見つかった場合、それをスキップリンクのあるページと定義しました。つまり14.19％というのは厳密には上限です。

ショートカット

aria-keyshortcutsやaccesskey属性を介して設定されたショートカットキーは、次の2つの方法のどちらかで使うことができます。

1. リンクやボタンなどのページ上の要素を活性化させます。

2. 特定の要素に対するページフォーカスを提供します。たとえばページ上にある特定の入力にフォーカスを移動させて、すぐさまユーザーが入力できるようにします。

サンプルを見る限りaria-keyshortcutsはほとんど採用されておらず、400万以上ある分析対象のうち、たった159のサイトでだけ使われていました。accesskey属性はかなり利用されており、Webページの2.47％（モバイルだと1.74％）で使われています。デスクトップでショートカットの利用率が多いのは、開発者がモバイルでサイトにアクセスする時、キーボードでなくタッチスクリーンのみで利用することを期待しているためと考えています。

とくに驚くべき点は、ショートカットキーを適用しているモバイルサイトの15.56％とデスクトップサイトの13.03％で、1つのショートカットキーを複数の要素に割り当てている事です。これはブラウザがショートカットキーの対象となる要素を推測する必要があることを意味しています。

テーブル

テーブルは大量のデータを整理し表現する主要な方法の1つです。スクリーンリーダーやスイッチ（運動障害のあるユーザーが使ったりします）などのさまざまな支援技術には、この表形式データをより効率的に操作できる特別な機能を持っています。

テーブルの見出し

テーブルの詳細な構造に対応したテーブルヘッダーを使うことで、特定の列または行が参照するコンテキストを失うこと無く、列や行全体を簡単に読み取り可能とします。ヘッダー行や列のないテーブルを操作しないといけないのは、スクリーンリーダーのユーザーにとっては使いづらいでしょう。これは、テーブルが非常に大きい時にスクリーンリーダーのユーザーはヘッダーのないテーブルだと自分の場所を把握するのが難しいからです。

テーブルのヘッダーをマークアップするには、シンプルに（<td>タグの代わりに）<th>タグを使うか、ARIAの columnheaderかrowheaderロールのどれかを使います。この方法のどれかでテーブルがマークアップされていたのは、テーブルを含むページの24.5％だけでした。そのため、テーブルにヘッダーが含まれない四分の三のページは、スクリーンリーダーのユーザーにとって非常に深刻な課題を持っています。

<th>と <td>を利用するのは、テーブルにヘッダーをマークアップするもっとも一般的な方法のようです。columnheaderとrowheaderのロールを使っているサイトはほとんど存在せず、使っているサイトは合計677個（0.058％）のみでした。

キャプション

<caption>要素が使われているテーブルキャプションは、さまざまな読者に対してより多くのコンテキストを提供できます。キャプションはテーブルが共有している情報を読む準備ができてる人や、集中できない環境だったり、作業の中断が必要な人々にとってとくに便利になります。また、スクリーンリーダーユーザーや学習障害、知的障害のある人などの、大きなテーブルだと自分の見ている場所で迷子になる可能性がある人々にとっても有用です。読者が分析している内容を理解しやすくすればするほど、より良い結果を得られるでしょう。

にもかかわらず、表が含まれるページでは4.32％だけでしかキャプションを提供していません。

支援技術との互換性

ARIAの使用

Web上でもっとも一般的かつ広く活用されているアクセシビリティの使用の1つにAccessible Rich Internet Applicationshttps://www.w3.org/WAI/standards-guidelines/aria/ (ARIA)という標準があります。この標準は視覚的要素の背景にある目的（つまり、セマンティクスな意味）と、それにより可能になるアクションの種類を教えるのに役立つ追加のHTML属性をもった大きな配列を提供します。

ARIAを適切かつ正しく使うのは難しい場合があります。例えば、ARIA属性を使っているページでは12.31％の属性に無効な値が割り当てられていました。ARIA属性の利用に誤りがあると、ページに視覚的な影響が及ばないため問題になります。これらの間違いは自動検証ツールを使っても検出できますが、一般的には実際の支援ソフトウェア（スクリーンリーダーなど）を実際に使う必要があります。この節ではARIAがWeb上でどのように使われているか、特に標準のどの部分が最も普及しているのかを検証していきます。

図9.8の説明を表示

0〜25の範囲で5ずつ増加するパーセントデータと、各属性のバーを表示する垂直棒グラフ。 aria-hidden：23.46％、aria-label：17.67％、aria-expanded：8.68％、aria-current：7.76％、aria-labelledby：6.85％、aria-controls：3.56％、aria-haspopup：2.62％、aria-invalid：2.68％、aria-describedby：1.69％、aria-live：1.04％、aria-required：1％

role属性

「ロール」属性は、すべてのARIAの仕様中で最も重要な属性です。これは指定されたHTML要素の目的（セマンティックな意味）をブラウザへ通知するために使用されます。たとえば、CSSを使って視覚的にボタンのようにスタイルが適用された<div>要素にはbuttonのARIAロールを与える必要があります。

実際には46.91％のページが少なくとも1つのARIAロール属性を使っています。以下の図9.9は、最もよく使われているトップ10のARIAロールの値一覧を纏めました。

図9.9の説明を表示

0から25までの範囲で5ずつ増加サイトの割合と各ロールタイプのバーを備えた垂直棒グラフ。Navigation：20.4％。 search：15.49％; main：14.39％; banner：13.62％; contentinfo：11.23％; button：10.59％; dialog：7.87％; complementary：6.06％; menu：4.71％; form：3.75％

図9.9の結果を見ると、2つの興味深い見解が得られます。UIフレームワークを更新すると、Web全体のアクセシビリティおよび操作しやすいダイアログとなっているサイトの数が非常に多くなるようです。

UIフレームワークの更新は、Web全体のアクセシビリティを向上させる方法となる可能性がある

11％以上のページに表示されるトップ5のロールはランドマークロールです。これはコンボボックスなどのヴィジェット機能が何かを説明するためではなく、ナビゲーションを助けるために使われています。ARIAが開発された主な目的は、Web開発者が汎用のHTML要素(<div>など)で作られたヴィジェット機能に対して説明を追加できる機能を提供することだったため、これは予想しなかった結果です。

とても良く使われているWeb UIフレームワークは、テンプレートにナビゲーションロールが含まれているはずです。これはランドマーク属性が普及している説明に繋がります。この見解が正しい場合、一般的なUIフレームワークを更新してアクセシビリティサポートを追加すると、Webのアクセシビリティに大きな影響が出る可能性を持っています。

この結論が導き出されるもう1つの答えは、より「高度」で同じくらい重要なARIA属性が一切使用されていないように見えるという事実です。この属性はUIフレームワークを介してかんたんにデプロイすることはできません。なぜなら、このような属性は各サイトの構造と外観に基づいて個々にカスタマイズする必要がある為です。例えばposinsetやsetsize属性は0.01％のページでしか使われていませんでした。これらの属性は一覧やメニューにあるアイテムの数と現在選択されているアイテムを、スクリーンリーダーユーザーに伝えることができます。そのため、視覚障害のあるユーザーがメニューを操作しようとすると「ホーム、5分の1」「製品、5分の2」「ダウンロード、5分の3」というようなインデックスのアナウンスが聞こえます。

多くのサイトは、ダイアログをアクセス可能にしようとしています

スクリーンリーダーを使っているユーザーはダイアログへのアクセスが難しく、見るからにそれがダイアログロールhttps://developer.mozilla.org/docs/Web/Accessibility/ARIA/Roles/dialog_roleその相対的な人気となっています。そのため、分析されたページの約8％で挑戦しはじめているのを見るのは興奮します。繰り返しますが、これはいくつかのUIフレームワークを使った結果に思えます。

対話的要素のあるラベル

ユーザーがWebサイトを操作する最も一般的な方法は、Webサイトを閲覧するためのリンクやボタンなどのコントロールを使うことです。ただし、殆どの場合においてスクリーンリーダーのユーザーは、活性化されたコントロールが何を実行するのかを判断できません。この混乱が発生する原因の多くは、テキストラベルが無いためです。例えば、左向きの矢印アイコンが表示された「戻る」事を示すボタンですが、テキストが実際は含まれていません。

ボタンまたはリンクを使うページの約4分の1（24.39％）でしか、これらのコントロールにテキストラベルが含まれていませんでした。コントロールにラベルが付いていない場合、スクリーンリーダーのユーザーは「検索」などの意味のある単語ではなく「ボタン」などの一般的なものを読み上げることがあります。

ボタンとリンクはタブオーダーの対象であるため、視認性は非常に高くなります。Tabキーを使ってのWebサイト閲覧は、キーボードだけを使っているユーザーのWebサイト閲覧では普通の事です。なので、ユーザーはTabキーを使ってWebサイトを移動している場合に、ラベルのないボタンとリンクに必ず遭遇するでしょう。

フォームコントロールのアクセシビリティ

フォームへの入力は私達が毎日行う沢山行う作業です。ショッピングや旅行の予約、仕事の申込みなど、フォームはユーザーがWebページと情報を共有する主な方法です。そのため、フォームを便利にすることは非常に重要です。これを達成するための簡単な方法は、各入力にラベルを提供することです（<label>要素やaria-labelまたはaria-labelledbyを用いて）。悲しいことに、すべてのフォーム入力にラベルを提供しているのページは22.33％しかありませんでした。つまり、5ページあるうちの4ページは非常に記入が難しいフォームを持っています。

必須や無効なフィールドであることを示す手がかり

大きなアスタリスクがあるフィールドに出会うと、それが必須フィールドだと理解できます。もしくは、サブミットをクリックして無効な入力があると通知された場合に、異なる色で強調表示されているものは全てを修正してから再送信する必要があります。しかし、視力が低い人や無い人はこのような視覚的合図に頼ることができないため、htmlの入力属性である requiredやaria-requiredとaria-invalid などが非常に重要になります。これらは、スクリーンリーダーに対して赤いアスタリスクや赤い強調表示されたフィールドと同等の物を提供します。更に良いことに、必要なフィールドをブラウザに教えればフォームの一部を検証https://developer.mozilla.org/docs/Learn/HTML/Forms/Form_validationすることも可能です。これにはJavaScriptが必要ありません。

フォームを使っているページのうち21.73％は必須フィールドをマークアップするときに requiredかaria-required を適用しています。５分の１のサイトでだけ、これらは使用されています。これはサイトを使いやすくするための簡単な手続きです、すべてのユーザーに対してブラウザの役立つ機能を開放します。

フォームを持つサイトの3.52％でaria-invalidが使われていることも判明しました。しかし、ほとんどのフォームは誤った情報が送信された後にこのフィールドを参照するため、このマークアップを適用しているサイトの本当の割合を確認することはできませんでした。

重複したID

HTMLでIDを使い２つの要素をリンクさせることができます。例えば<label>要素は次のように機能します。ラベルにinputフィールドのIDを指定し、ブラウザはその２つをリンクさせます。結果はどうなるか？　ユーザーはこのラベルをクリックすることでユーザーはinputフィールドにフォーカスすることが可能になり、スクリーンリーダーはこのラベルを説明として使うことができます。

残念ながら34.62％のサイトで重複したIDが確認できます、つまり多くのサイトではユーザーの指定したIDが複数の異なったinputを参照しています。そのため、ユーザーがラベルをクリックしてフィールドを選択すると、意図したものと違う項目が選択されるhttps://www.deque.com/blog/unique-id-attributes-matter/可能性を持っています。想像されている通り、これはショッピングカートのようなものに対して良くない結果をもたらす可能性があります。

この問題はユーザーが選択肢の内容を視覚的に再確認できないスクリーンリーダーユーザーに対してさらに際立ちます。そして、aria-describedbyやaria-labelledbyなどのARIA属性は上で説明したlabel要素と同じように機能します。つまり、サイトを操作しやすくするには、最初に重複するIDを全て削除するのが良いでしょう。

結論

アクセシビリティを必要としているのは障害のある人々だけではありません。例えば、一時的に手首を負傷している人は小さな操作対象を触れるのが難しいと感じているはずです。視力は年齢とともに低下することが多く、小さなフォントで書かれたテキストは読みにくくなります。指の器用さは年齢毎に異なるため、かなりの割合のユーザーが対話的なコントロールに触れたり、モバイルWebサイトのコンテンツをスワイプしたりするのが難しくなっていきます。

同様に支援ソフトウェアは障害のある人のためだけでなく、すべての人の日々の体験を良くしていくためのものです。

• モバイルデバイスと家庭用の両方で音声認識が人気なのは、コンピューティングデバイスを音声コマンドで制御することが多くのユーザーにとって有意義であり不可欠であることを示しています。このような音声制御は、以前はアクセシビリティ機能にしかありませんでしたが現在では商品の主流になりつつあります。
• 運転手は道路から目を離す事無くニュース記事のような長文を読み上げるスクリーンリーダーの恩恵を受けることができるでしょう。
• 字幕はビデオを聞く事ができない人だけでなく、騒々しいレストランや、図書館でビデオを見たい人なども楽しませています。

一度Webサイトが完成すると、既存のサイト構成とウィジェットに対してアクセシビリティを改良する事は殆どの場合で困難になります。アクセシビリティは後で簡単にデコレーションすることが出来るものではなく、設計と実装のプロセスとして必要になります。しかし残念ながら、認識不足または使いやすいテストツールのせいで多くの開発者は、すべてのユーザーのニーズと支援ソフトウェアの要件に精通していません。

これは結論ではありませんが、私達の活動結果からARIAやアクセシビリティのベストプラクティス（代替テキストを使うなど）のようなアクセシビリティ標準の利用はWebのかなりの、しかし実質的でない部分で見つかることが示されています。表面的にはこれは励みになりますが、こういった良い方向にある事柄の多くは特定のUIフレームワークがよく利用されているからだと私達は訝しんでいます。一方、Web開発者にとってはシンプルにUIフレームワークを頼ってサイトにアクセシビリティを差し込むことはできないため、非常に期待はずれです。その一方で、UIフレームワークがWebのアクセシビリティに与える影響の大きさを確認できるのは心強いでしょう。

私達の見解では次の開拓地は、UIフレームワークを介して利用可能なウィジェットをより簡単に操作できるようになることです。世の中で使われている多くの複雑なウィジェット（カレンダーのピッカーなど）はUIライブラリなどに含まれており、こういったウィジェットがそのまま使えるのは素晴らしいことです。私達は次の結果を集める時、より適切に実装された複雑なARIAロールの利用が増えて、より複雑なウィジェットに対しても操作が簡単になっていることを願っています。そして、すべてのユーザーがウェブの豊かさを楽しむことが出来るよう、映画やビデオなどがさらにアクセスしやすいメディアとなった未来を見たいと思います。

SEO

導入

検索エンジン最適化（SEO）はデジタルマーケティングの担当者にとって、単なる趣味やサイドプロジェクトではなくWebサイトを成功に導くための重要な要素です。SEOの主な目標は、Webサイトをクロールする必要のある検索エンジンボットと、Webサイトを操作するコンテンツの消費者向けにWebサイトを最適化することです。SEOはWebサイトを作っている開発者から、新しい潜在顧客に対して宣伝する必要のあるデジタルマーケティング担当者に至るまで、すべてのWebサイトに関わる人に影響を及ぼします。

それでは、SEOの重要性を見ていきましょう。今年のはじめにSEO業界は「困難な年」と言われた後ASOSが利益の87%減少https://www.bbc.co.uk/news/business-47877688を報告したため、その恐ろしさ(と魅力)への注目が集まりました。このブランドの問題は、200以上のマイクロサイトを立ち上げた為に発生した検索エンジンのランキング低下と、Webサイトのナビゲーションの大幅な変更などの技術的変更が原因であると考えられています。驚きです！

Web AlmanacのSEOの章の目的は、検索エンジンによるコンテンツのクロールとインデックス付け、そして最終的にWebサイトのパフォーマンスに影響を与えるWebのオンサイト要素を分析することです。この章では、上位のWebサイトがユーザーおよび検索エンジンに優れた体験を提供するためにどれだけ十分な整備がされているか、そしてどのような作業を行うべきかについて見ていきます。

この分析には、Lighthouseと、Chrome UX Report、HTML要素の分析データが含まれています。<title>要素、様々な種類のページ上リンク、コンテンツ、読み込み速度などによるSEOの基礎だけではなく、500万以上のインデクサビリティ、構造化データ、国際化、AMPなどSEOのさらなる技術的な面にも注目しています。

カスタムメトリクスはこれまで公開されていなかった洞察を提供します。hreflangタグ、リッチリザルトの適格性、見出しタグの使用、さらにシングルページアプリケーションのアンカーによるナビゲーション要素などの採用と実装について断言できるようになりました。

では、Webの現状と検索エンジンの使いやすさについての詳細をお読みください。

基本

検索エンジンにはクロール、インデックスの作成、ランキングの３つの手順があります。それには検索エンジンにとって、ページを見つけやすく、理解でき、search engine results pages(SERPs)（検索エンジンの結果ページ）を閲覧しているユーザーにとって価値が有り高品質なコンテンツが含まれている必要があります。

SEOの基本的なベストプラクティスの基準を満たしているWebの量を分析するため、本文のコンテンツ、metaタグ、内部リンクなどのページ上の要素を評価しました。それでは結果を見てみましょう。

コンテンツ

ページの内容を理解して、最も関連性の高い回答を提供できる検索クエリが何かを決定的にするためには、まず検索エンジンがそのコンテンツを探し出してアクセス出来る必要があります。しかし、検索エンジンは現在どのようにコンテンツを見つけるのでしょうか？、その回答を得るために、単語数と見出しの２つのカスタムメトリクスを作りました。

単語の数

私達は、少なくとも３つの単語グループを探し合計でいくつ見つかったかを数えるようにして、ページのコンテンツを評価しました。デスクトップページには単語グループを持たないものが2.73%見つかりました。これはWebサイトが何を指しているのかを検索エンジンが理解するのに役立つ本文コンテンツが無いことを示しています。

図10.1の説明を表示

ページ毎の単語分布。デスクトップページあたりの単語数の中央値は346でモバイルページの場合は306となっています。デスクトップページには、パーセンタイル全体でより多くの単語があり、90パーセンタイルで120単語もあります

デスクトップ向けホームページの中央値は346単語で、モバイル向けホームページの中央値は306単語とわずかに少ない単語数になっています。これはモバイル向けサイトが少し少ない量をユーザーにコンテンツとして提供していることを示していますが、300単語を超えたとしても読むのには問題ない量でしょう。これは、例えばホームページは記事があるページなどよりコンテンツが自然と少なくなるため特に該当するでしょう。全体を見ると単語の分布は幅があり、10パーセンタイルのあたりでは22単語、90パーセンタイルあたりで最大1,361単語です。

見出し

また、ページに含まれるコンテンツのコンテキストが適切な方法で構造化されて提供されているかを調べました。見出し（H1、 H2、 H3、など）を使ってページを整え構造化すれば、コンテンツは読みやすく、解析しやすいようになります。そんな見出しの重要性にもかかわらず、ページの10.67%には見出しタグがまったくありませんでした。

図10.2の説明を表示

ページ毎の見出しの分布。 デスクトップもモバイルもページ毎の見出しの中央値は10です。10/25/75/90それぞれのパーセンタイルではデスクトップの場合 0、3、21、39となっており、モバイルの見出し分布よりも少しだけ高くなっています。

１ページあたりの見出し要素の中央値は10となっています。見出しにはモバイルページで30単語、デスクトップページで32単語が含まれています。これは、見出しを活用できているWebサイトが、ページが読みやすく、説明的で、ページの構造とコンテキストを検索エンジンボットに明確に概説することに多大な労力を費やしていることを意味します。

図10.3の説明を表示

ページ毎の最初のH1文字数の分布。デスクトップとモバイルの分配はほぼ同様となっており、10、25、50、75、90パーセンタイルで6、11、19、31、47文字です。

具体的な見出しの長さを見ると、最初に見つかったH1要素の長さの中央値はデスクトップで19文字です。

SEOとアクセシビリティのためのH1と見出しの処理に関するアドバイスについては、Ask Google WebmastersシリーズのJohn Muellerによるこのビデオの回答https://www.youtube.com/watch?v=zyqJJXWk0gkをご覧ください。

メタタグ

メタタグを使用すると、ページ上の色々な要素やコンテンツに関する特定の指示や情報を検索エンジンボットに提供できます。特定のメタタグにはページの注目すべき情報や、クロールとインデックス付けの方法などを伝えることができます。私達はWebサイトの提供するメタタグが、これらの機会を最大限に活用しているかどうかを評価したいと考えました。

ページのタイトル

ページのタイトルはページの目的をユーザーや検索エンジンに伝える重要な手段です。<title>タグはSERPSの見出にも、ページにアクセスする時のブラウザーのタブのタイトルとしても使われるので、モバイルページの97.1%にドキュメントタイトルが存在することは驚くことではないでしょう。

図10.5の説明を表示

ページ毎のタイトル要素毎の文字数分布。デスクトップのタイトルの長さそれぞれの10、25、50、75、90パーセンタイルは、4、9、20、40、66文字です。モバイルの分布も非常に似ています。

一般的にGoogleのSERPはページタイトルの最初の50〜60文字を表示https://moz.com/learn/seo/title-tagしますが、<title>タグの長さの中央値はモバイルページで21文字、デスクトップページで20文字でした。75パーセンタイルでも、境界を下回っています。これは、一部のSEOとコンテンツの記者が、検索エンジンによって割り当てられたSERPsのホームページを記述するために割り当てられた領域を最大限利用できていないことを示します。

メタディスクリプション

<title>タグと比べると、メタディスクリプションが検出されたページは少なくなっており、モバイル用ホームページの64.02%にだけメタディスクリプションが設定されています。Googleが検索者のクエリに応じてSERP内のメタディスクリプションの記述を頻繁に書き換えることを考慮すると、おそらくWebサイトの所有者はメタディスクリプションを含めることを重要視しないでしょう。

図10.6の説明を表示

ページ毎のメタ記述毎の文字数分布。デスクトップのタイトルの長さの10、25、50、75、90パーセンタイルはそれぞれ、9、48、123、162、230文字です。モバイルの分布は任意のパーセンタイルでは10文字未満だけわずかに高くなっています。

メタディスクリプションの長さは155-160文字が推奨https://moz.com/learn/seo/meta-descriptionとなっていますが、デスクトップページの中央値ははそれより短い123文字となっています。さらに興味深い事があります、モバイルのSERPはピクセル制限により従来よりも短かくなるにも関わらず、メタディスクリプションは一貫してデスクトップよりもモバイルが長くなっています。この制約は最近拡張されたばかりなので、おそらく多くのWebサイトの所有者がモバイルの結果に対して、より長くて説明的なメタディスクリプションの影響を確認しているのでしょう。

画像のaltタグ

SEOとアクセシビリティのためのaltテキストの重要性を考えたとき、モバイルページの46.71%でしか画像にalt属性が使われていないのを見ると理想とはほど遠い状況です。これは、Web上の画像をユーザーにとってさらにアクセスしやすく、検索エンジンにとって理解しやすくすることに関しては、まだ改善する点が多く有ることを意味します。この問題に対する詳細についてはアクセシビリティの章を御覧ください。

インデクサビリティ

SERPでユーザーにページのコンテンツを表示するためには検索エンジンのクローラーがそのページにアクセスしてインデックスを作れるようにする必要があります。検索エンジンによるページのクロールとインデックス登録の機能に影響を与える要因には次の様なものがあります。

• ステータスコード
• noindexタグ
• canonicalタグ
• robots.txtファイル

ステータスコード

検索エンジンにインデックスを付けたい重要なページは常に200 OKステータスコードにしておく事をお勧めします。テストされたページの殆どは検索エンジンにアクセス可能で、デスクトップでは最初のHTML要求の87.03%が200ステータスコードを返しました。モバイルの場合は少しだけ低く、82.95%のページだけが200となるステータスコードを返しました。

モバイルでは次によく見られるステータスコードは一時的なリダイレクトである302となっており、これはモバイルページの10.45%で見つけることができました。この結果はデスクトップよりも多く、デスクトップ用のホームページで302ステータスコードを返すのは6.71%しかありませんでした。これは、モバイル用のホームページがレスポンシヴでなくデバイスごとにWebサイトのバージョンが異なるようなhttps://developers.google.com/search/mobile-sites/mobile-seo/separate-urls、デスクトップページの代替が用意されていることに起因している可能性があります。

noindex

noindex指示はHTMLの <head>もしくはHTTPヘッダーのX-Robots指示で使うことができます。noindex指示は基本的に検索エンジンにそのページをSERPに含めないように指示しますが、ユーザーがWebサイトを操作しているときでもページはアクセス可能です。一般的にnoindex指示は、同一コンテンツを提供するページの複製バージョン、またはオーガニック検索からWebサイトにアクセスするユーザーに価値を提供しないであろう低品質のページ(フィルタ、ファセット、内部検索ページなど)に追加されます。

モバイル用ページの96.93%がLighthouseのインデックス作成監査に合格しておりhttps://developers.google.com/web/tools/lighthouse/audits/indexing、これらのページにはnoindex指示が含まれていませんでした。ただし、これはモバイルホームページの3.07%にnoindex指示が含まれていたことも意味しています。これは心配の種であり、Googleはこれらのページのインデックスを作成できないことを意味しています。

canonicalによる最適化

canonicalタグを使い重複ページと優先代替ページを指定します。これにより検索エンジンは、グループ内の複数のページに散っているオーソリティを1つのメインページに統合してランキングの結果を上げることができます。

モバイル用ホームページの48.34%でcanonicalタグが使われていることが検出https://developers.google.com/web/tools/lighthouse/audits/canonicalされました。自分を指ししめすcanonicalタグは必須でなく、普通は複製されたページにcanonicalタグを必要とします。ホームページがサイトのどこか他の場所に複製されることはめったに無いので、canonicalタグがページ毎で半分未満になっているのは驚くことではありません。

robots.txt

検索エンジンのクロールを制御する最も効果的な方法の1つは、robots.txtファイルです。これは、Webサイトのルートドメインに置かれる事で、検索エンジンのクロールに対し許可しないURLとURLパスを指定する事ができるファイルです。

Lighthouseの結果https://developers.google.com/web/tools/lighthouse/audits/robotsからモバイル用サイトの72.16%でしか有効なrobots.txtを持っていないことがわかりました。見つかった問題の主な内訳は、robots.txtファイルをまったく持たないサイトが22%、無効なrobots.txtファイルを提供する約6%で、それぞれ検査に失敗しています。クロールバジェットの問題https://webmasters.googleblog.com/2017/01/what-crawl-budget-means-for-googlebot.htmlに悩まされないような小規模Webサイトを運営していたりするなど、robots.txtファイルを持たない妥当な理由もあったりしますが、無効なrobots.txtが有るというのは、それだけで心配の種になります。

リンク

Webページの最も重要な属性の1つはリンクです。リンクは検索エンジンがインデックスに追加してWebサイトをナビゲートするための新しい関連ページを発見するのに役立ちます。データセットにあるWebページの96%には最低でも1つの内部リンク存在し、93%は少なくとも１つの別ドメインへの外部リンクが存在しています。内部や外部リンクを持たないごく一部のページは、ターゲットページへ通じるリンクという大きな価値を取りこぼしています。

デスクトップ用のページに含まれる内部と外部リンクの数は、モバイル用のページよりも全ての場合で多くなっています。これは殆どの場合、モバイルのデザインはビューポートが小さく空間が限られているために、リンクが含まれるテキストはデスクトップに比べて少なくなっているためです。

モバイル用のページで内部リンクが少ない場合、Webサイトで問題が発生する可能性https://moz.com/blog/internal-linking-mobile-first-crawl-pathsが有るため注意が必要です。新しいWebサイトでGoogleの規定であるモバイルファーストインデックスhttps://www.deepcrawl.com/knowledge/white-papers/mobile-first-index-guide/が適用されると、そのページがデスクトップ用ではリンクされているがモバイル用からリンクが無い時、検索エンジンはそのページを見つけてランク付けするのがとても難しくなってしまいます。

図10.7の説明を表示

ページ毎の内部リンク数の分布。デスクトップの内部リンクは10、25、50、75、90パーセンタイルごとに、7、29、70、142、261となっています。モバイル分布はかなり低く、90パーセンタイルでリンク数は30、中央値で10となっています。

図10.8の説明を表示

ページ毎の外部リンク数の分布。デスクトップの外部リンクは10、25、50、75、90パーセンタイルごとに、1、4、10、22、51となっています。モバイルの分布はかなり低く、90パーセンタイルでリンク数は11、中央値で2となっています。

デスクトップ用ページの内部リンク(同一サイト)数は中央値で70となっていますが、モバイル用ページの内部リンク数の中央値は60になっています。外部リンク数のページ毎中央値も同じような傾向となっており、デスクトップ用ページの外部リンク数は10で、モバイル用ページは8になっています。

図10.9の説明を表示

ページ毎のアンカーリンク数の分布。デスクトップの内部アンカーは10、25、50、75、90パーセンタイルに対して、0、0、0、1、3となっています。モバイルの分布も同様です。

同一ページの特定スクロール位置にリンクするアンカーリンクはあまり人気が無いようです。ホームページの65%以上でアンカーリンクは使われていません。これはおそらく、一般的なホームページには長文形式のコンテンツが含まれていないからでしょう。

説明的なリンクテキストの測定からは良いニュースが伺えます。モバイル用ページの89.94%がLighthouseの説明的なリンクテキストの監査https://developers.google.com/web/tools/lighthouse/audits/descriptive-link-textで合格しています。つまり、これらのページは一般的な「ここをクリック」「リンク」「続きを読む」「全文表示」のようなリンクを使わず、より有意義なリンクテキストを使うことで、ユーザーと検索エンジンにページのコンテキストやページ同士のつながりがあることを理解できるようにしています。

Advanced

説明的で有用なコンテンツ以外に対してnoindexやDisallowという指示を出してページを検索エンジンからブロックするだけでは、Webサイトをオーガニックサーチさせるには不十分です。これらは単なる基本でしかありません。WebサイトのパフォーマンスやSERPsの外観を向上させるなど、できることはたくさんあります。

Webサイトのインデックス作成とランク付成功のために重要となっている技術的に複雑な局面として、速度、構造化データ、国際化、セキュリティ、モバイルフレンドリーなどがあります。

Speed

モバイルの読み込み速度は、2018年にGoogleからランキング要素として初めて発表https://webmasters.googleblog.com/2018/01/using-page-speed-in-mobile-search.htmlされました。しかしGoogleにとって速度は新しい観点ではありません。2010年に既に速度がランキングシグナルとして導入されたことが明らかhttps://webmasters.googleblog.com/2010/04/using-site-speed-in-web-search-ranking.htmlにっています。

Webサイトが高速であることは、優れたユーザー体験のためにも重要です。サイトの読み込みに数秒待たされるユーザは、すぐ離脱してSERPsから別の似たような内容の素早く読み込まれるページを探す傾向があります。

Web全体の読み込み速度の分析に使った指標は Chrome UX Report（CrUX）を基にしています。このレポートは、実際のChromeユーザーからデータを収集します。このデータで驚くべき点は、48%のWebサイトが遅いとラベル付されていることです。FCPの25%が3秒より遅い場合、もしくは FIDの5%が300ミリ秒より遅い場合にWebサイトは低速とラベル付されます。

図10.10の説明を表示

デスクトップ、電話、タブレットのパフォーマンスにおけるユーザー体験の分布。 デスクトップ：2%高速、52%中程度、46%低速。 電話：高速1%、中程度41%、低速58%。 タブレット：高速0%、中程度35%、低速65%。

デバイスごとに分けるとより鮮明になります、この画像ではタブレット(65%)、電話(58%)を示しています。

数字だけ見るとWebの速度には暗雲が立ち込めるように思えますが、良いニュースもあります。それはSEOの専門家とツールがWebサイトの高速化のための技術課題に集中しているという点です。Webパフォーマンスの状態についてはパフォーマンスの章で詳しく知ることができます。

構造化データ

構造化データを使うことでWebサイトの所有者は、JSON-LDhttps://en.wikipedia.org/wiki/JSON-LDスニペットやMicrodatahttps://developer.mozilla.org/docs/Web/HTML/Microdataなどを加える事で、Webページに付属的なセマンティックデータを付与できます。検索エンジンはこのデータを解析してこれらのページを深く理解し、マークアップにより検索結果に追加の関連情報を表示も行う事ができます。よく見る構造化データの種類には次のようなものがあります。

• reviewshttps://developers.google.com/search/docs/data-types/review-snippet
• productshttps://developers.google.com/search/docs/data-types/product
• businesseshttps://developers.google.com/search/docs/data-types/local-business
• movieshttps://developers.google.com/search/docs/data-types/movie
• その他https://developers.google.com/search/docs/guides/search-gallery

構造化データがWebサイトに提供できる追加の可視性https://developers.google.com/search/docs/guides/enhance-siteはユーザーがサイトに訪れる機会を増やすのに役立つため、サイトの所有者にとっては魅力的です。たとえば、比較的新しいFAQスキーマhttps://developers.google.com/search/docs/data-types/faqpageはスニペットとSERPsの領域を２倍にできます。

調査の結果、モバイルでリッチな結果を得ることが出来るサイトは14.67%しか無いことが解りました。興味深いことに、デスクトップサイトの適格性はわずかに低くなり12.46%となっています。これはサイト所有者がホームページ検索で表示されるための最適化に対して、もっと出来ることが有ることを示しています。

構造化データのマークアップを持つサイトの中で、最もよく見る種類は次の５つでした。

1. WebSite (16.02%)
2. SearchAction (14.35%)
3. Organization (12.89%)
4. WebPage (11.58%)
5. ImageObject (5.35%)

興味深いことに、一番良く利用されている検索エンジンの機能をトリガーするデータ型はサイトリンクの検索ボックスhttps://developers.google.com/search/docs/data-types/sitelinks-searchboxを強化するSearchActionです。

トップ5のマークアップタイプはすべてGoogleの検索結果の可視性を高める物で、これらのタイプの構造化データをさらに採用する理由になるかもしれません。

今回の分析はホームページだけを見ているため、インテリアページも考慮した場合は結果は大きく異なった結果が見えてくる可能性があります。

レビューの星はWebのホームページ上で1.09%だけにしかありません。(AggregateRatinghttps://schema.org/AggregateRatingより)また、新しく導入されたQAPagehttps://schema.org/QAPageは48の例しかなく、FAQPagehttps://schema.org/FAQPageは少しだけ高い数が出現して218となっています。この最後の2種類の数については、クロールを更に実行してWeb Almanacの分析を掘り下げていくと、将来増加することが予想されています。

国際化

一部のGoogle検索の従業員https://x.com/JohnMu/status/965507331369984002によれば、国際化はSEOの最も複雑な面の1つとなっているようです。SEOの国際化は、ユーザーが特定の言語のコンテンツをターゲットしていることを確認し、それに合わせて複数の言語や国のバージョンを持つWebサイトから適切なコンテンツを提供することに重点をおいています。

HTML lang属性が英語に設定されているデスクトップ用サイトの38.40%（モバイルでは33.79%）で、別の言語バージョンへの hreflangリンクが含まれるサイトはたった7.43%（モバイルで6.79%）しかありませんでした。これから、分析したWebサイトの殆どが言語ターゲティングを必要とするホームページの別バージョンを提供していないことを示しています。しかしそれは、個別のバージョンは存在するが構成が正しく無い場合を除きます。

英語の次に最もよく見る言語は、フランス語、スペイン語、およびドイツ語です。この後にアメリカ人向けの英語（en-us）やアイルランド人向けのスペイン語（es-ie）などの不明瞭な組み合わせなどの、特定の地域を対象とした言語が続いています。

この分析では、異なる言語バージョン同士が相互で適切にリンクしているかどうかなどの正しい実装は確認しませんでした。しかし、推奨にあるhttps://www.google.com/url?q=https://support.google.com/webmasters/answer/189077?hl%3Den&sa=D&ust=1570627963630000&usg=AFQjCNFwzwglsbysT9au_I-7ZQkwa-QvrAx-defaultバージョン（デスクトップでは3.77%、モバイルでは1.30%）の採用が少ない点を考慮すると、この要素が複雑で常に正しいとは限らないということを示しています。

SPAのクロールに関する可能性

ReactやVue.jsなどのフレームワークで構築されたシングルページアプリケーション（SPA）には、独特のSEOの複雑さが伴っています。ハッシュを使ったナビゲーションを使用するWebサイトは検索エンジンがクロールして適切にインデックスを作成するのがとても難しくなります。例を上げると、Googleには「AJAXクロールスキーム」という回避策がありましたが、開発者だけでなく検索エンジンにとっても難解であることが判明し、この仕様は2015年に廃止https://webmasters.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.htmlされました。

ハッシュURLを介して提供されるリンクの数が比較的少なく、Reactモバイルページの13.08%がナビゲーションにハッシュURLを使用し、モバイルVue.jsページで8.15%、モバイルAngularページで2.37%で使用されているという結果になっています。この結果はデスクトップ用ページでも非常に似通った結果でした。ハッシュURLからコンテンツの発見に対する影響を考慮すると、この結果はSEOの観点からは良い状態と言えるでしょう。

特に驚いた点は、ハッシュURLの数がAngularページでは少ないのとは対照的に、ReactページでのハッシュURLの数が多くなっている点です。両方のフレームワークはハッシュURLに依存せず、代わりにリンク時にHistory APIhttps://developer.mozilla.org/docs/Web/API/Historyが標準となっているルーティングパッケージの採用を推奨しています。Vue.jsはvue-routerパッケージのバージョン3から、History APIを標準で使うことを検討https://github.com/vuejs/rfcs/pull/40しています。

AMP

AMP（以前は「Accelerated Mobile Pages」として知られていました）は、2015年にGoogleによってオープンソースのHTMLフレームワークとして初めて導入されました。キャッシュ、遅延読み込み、最適化された画像などの最適化手法を使うことで、Webサイトのサイトのコンポーネントと基盤構造を提供することで、ユーザーに高速な体験を提供します。特に、Googleは検索エンジンにもこれを採用し、AMPページも独自のCDNから提供されています。この機能は後にSigned HTTP Exchangeshttps://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.htmlという名前の標準提案になりました。

にも関わらず、AMPバージョンへのリンクが含まれるモバイルホームページはわずか0.62%しかありません。このプロジェクトの可視性を考慮しても、これは採用率が比較的低い事が示されています。ただし、今回のホームページに焦点を宛てた分析なので、他のページタイプの採用率は見ていません、記事ページを配信する場合はAMPのほうが有利な場合が多いでしょう。

セキュリティ

近年、WebがデフォルトでHTTPSに移行するという強力なオンラインの変化がありました。HTTPSでは、例えばユーザー入力データが安全に送信されないパブリックWi-FiネットワークでもWebサイトのトラフィックが傍受されるのを防ぎます。GoogleはサイトでHTTPSを採用するよう推進しており、ランキングシグナルとしてHTTPShttps://webmasters.googleblog.com/2014/08/https-as-ranking-signal.htmlを作りました。Chromeはブラウザで非HTTPSページを非セキュアhttps://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/としてラベル付けすることでセキュアなページへの移行もサポートしています。

HTTPSの重要性とその採用方法に関するGoogleの詳細な情報と手引については、HTTPSが重要な理由https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-httpsをご覧ください。

現在、デスクトップ用Webサイトの67.06%がHTTPS経由で配信されていますWebサイトの半分以下がまだHTTPSに移行しておらず、ユーザーに安全でないページを提供しています。これはかなりの数です。移行は大変な作業になる場合が多く、そのために採用率が高くない可能性がありますが、HTTPSの移行に必要なのは大抵の場合SSL証明書と.htaccessファイルの簡単な変更です。  HTTPSに切り替えない理由はありません。

Googleの透明性レポートhttps://transparencyreport.google.com/https/overviewでは、Google以外の上位100ドメインでhttpsの採用率は90%であると報告されています(これは世界中のWebサイトトラフィックの25%です)。この数字と私たちの数字の違いから、比較的小規模なサイトはゆるやかにHTTPSを採用しているという事実によって説明できます。

セキュリティの状態の詳細については、セキュリティの章を御覧ください。

結論

分析の結果、ほとんどのWebサイトでは基礎がしっかりしている事が判明しました。ホームページはクロール可能で、インデックス付け可能で、検索エンジンの結果ページでのランキングに必要な主要コンテンツが存在しています。Webサイトを所有する人々がSEOを熟知しているわけではなく、ベストプラクティスの指針などは言うまでもありません。つまり、これらの非常に多くのサイトが基本をカバーしていることは非常に頼もしいことです。

しかし、SEOとアクセシビリティのより高度な面のいくつかに関しては、予想していたよりも多くのサイトが注目していません。サイトの速度については、特にモバイルのときに多くのWebサイトが苦労している要因の一つになっており、これは大きな問題です。なぜなら速度はUXの最大の要因の1つで、ランキングに影響を与える可能性があるためです。HTTPS経由でまだ提供されていないWebサイトの数も、セキュリティの重要性を考慮してユーザーデータを安全に保つという点に問題があるように見えます。

私達全員がSEOのベストプラクティスを学んだり、業界の発展に貢献できることはたくさんあります。これは、検索業界が進化する性質を持ちながら、その変化の速度から必要な事です。検索エンジンは毎年数千のアルゴリズムを改善しています、Webサイトがオーガニックサーチでより多くの訪問者に届くようにしたい場合、置いていかれないようにする必要があります。

PWA

導入

プログレッシブWebアプリ（PWA）は、Service Worker APIhttps://developer.mozilla.org/docs/Web/API/Service_Worker_APIなどのプラットフォームプリミティブ上に構築される新しいクラスのWebアプリケーションです。Service Workerは、ネットワークプロキシとして機能し、Webアプリの発信要求をインターセプトしプログラムまたはキャッシュされた内容で応答することによりアプリがネットワークに依存しない読み込みをサポートできるようにします。Service Workerは、プッシュ通知を受信し、対応するアプリが実行されていなくてもバックグラウンドでデータを同期できます。さらに、Service Workerは、Webアプリマニフェストhttps://developer.mozilla.org/docs/Web/Manifestと共にユーザーがデバイスのホーム画面にPWAをインストールできるようにします。

Service Workerは2014年12月にChrome 40で初めて実装https://blog.chromium.org/2014/12/chrome-40-beta-powerful-offline-and.htmlされ、プログレッシブWebアプリという用語は2015年にFrances BerrimanとAlex Russellによって作られましたhttps://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/。Service Workerはすべての主要なブラウザでようやく実装されたため、この章の目標は実際に存在するPWAの数と、これらの新しいテクノロジーをどのように利用するかを決定します。バックグラウンド同期https://caniuse.com/#feat=background-syncのような特定の高度なAPIは、現在もChromiumベースのブラウザでのみ利用できるため、追加の質問として、これらのPWAが実際に使用する機能を調べました。

Service Worker

Service Workerの登録とインストール可能性

最初に検討する指標は、Service Workerのインストールです。 HTTP Archiveの機能カウンターを介して公開されたデータを見ると、すべてのデスクトップの0.44％とすべてのモバイルページの0.37％がService Workerを登録しており、時間の経過に伴う両方の曲線が急成長しています。

図11.2の説明を表示

Service Workerのインストールの時系列チャート。 2017年1月以降、デスクトップとモバイルは約0.0％から約0.4％に着実に増加しています。

これはあまり印象的でないかもしれませんが、Chromeプラットフォームステータスからのトラフィックデータを考慮すると、Service Workerがすべてのページロードの約15％https://www.chromestatus.com/metrics/feature/timeline/popularity/990を制御していることがわかります。トラフィックの多いサイトがますますService Workerを受け入れ始めています。

Lighthouseは、ページがインストールプロンプトhttps://developers.google.com/web/tools/lighthouse/audits/install-promptの対象かどうかを確認します。モバイルページの1.56％にインストール可能なマニフェストhttps://web.dev/i18n/ja/installable-manifest/があります。

インストール体験をコントロールするために、全デスクトップの0.82％と全モバイルページの0.94％がOnBeforeInstallPromptインターフェイスを使用します。現在、サポートはChromiumベースのブラウザに限定されていますhttps://caniuse.com/#feat=web-app-manifest。

Service Workerイベント

Service Workerでは、いくつかのイベントをリッスンできますhttps://developers.google.com/web/fundamentals/primers/service-workers/lifecycle。

• install, Service Workerのインストール時に発生します。
• activate, Service Workerのアクティベーション時に発生します。
• fetch, リソースがフェッチされるたびに発生します。
• push, プッシュ通知が到着したときに発生します。
• notificationclick, 通知がクリックされたときに発生します。
• notificationclose, 通知が閉じられたときに発生します。
• message, postMessage()を介して送信されたメッセージが到着したときに発生します。
• sync, バックグラウンド同期イベントが発生すると発生します。

図11.4の説明を表示

さまざまなService Workerイベントの人気を示す棒グラフ。 Fetchは、モバイルService Workerの73％、インストール71％、アクティブ化56％、通知クリック10％、プッシュ8％、メッセージ5％、通知クローズ2％、同期1％で使用されます。デスクトップService Workerの使用方法は似ていますが、取得、インストール、およびアクティブ化の場合は若干低くなります。

HTTP Archiveで見つけることのできるService Workerがこれらのイベントのどれをリッスンしているかを調べました。モバイルとデスクトップの結果は非常によく似ており、fetch、install、およびactivateが3つの最も人気のあるイベントであり、それに続いてnotificationclickとpushが行われます。これらの結果を解釈すると、Service Workerが有効にするオフラインユースケースは、プッシュ通知よりもはるかに先のアプリ開発者にとって最も魅力的な機能です。可用性が限られているため、あまり一般的ではないユースケースのため、現時点ではバックグラウンド同期は重要な役割を果たしていません。

Service Workerのファイルサイズ

一般に、ファイルサイズまたはコード行は、手元のタスクの複雑さの悪いプロキシです。ただし、この場合、モバイルとデスクトップのService Workerの（圧縮された）ファイルサイズを比較することは間違いなく興味深いです。

図11.5の説明を表示

Service Workerの転送サイズの分布を示す棒グラフ。デスクトップService Worker転送サイズの10、25、50、75、および90パーセンタイルは、176、350、895、2,010、および4,138バイトです。デスクトップService Workerは、90パーセンタイルの1,000バイトから、パーセンタイルごとに大きくなります。

デスクトップのService Workerファイルの中央値は895バイトですが、モバイルでは694バイトです。すべてのパーセンタイルを通じて、デスクトップService WorkerはモバイルService Workerよりも大きくなっています。これらの統計は、importScripts()メソッドを使用して動的にインポートされたスクリプトを考慮しないため、結果は大きく歪む可能性が高いことに注意してください。

Webアプリマニフェスト

Webアプリマニフェストのプロパティ

Webアプリマニフェストは、ブラウザーにWebアプリケーションと、ユーザーのモバイルデバイスまたはデスクトップにインストールされたときの動作を通知する単純なJSONファイルです。典型的なマニフェストファイルには、アプリ名、使用するアイコン、起動時に開く開始URLなどに関する情報が含まれています。検出されたすべてのマニフェストの1.54％のみが無効なJSONであり、残りは正しく解析されました。

Web App Manifest仕様https://w3c.github.io/manifest/#webappmanifest-dictionaryで定義されているさまざまなプロパティを調べ、非標準の独自プロパティも検討しました。仕様によると、次のプロパティが許可されています。

• dir
• lang
• name
• short_name
• description
• icons
• screenshots
• categories
• iarc_rating_id
• start_url
• display
• orientation
• theme_color
• background_color
• scope
• serviceworker
• related_applications
• prefer_related_applications

私たちが野生で観察しなかった唯一のプロパティはiarc_rating_idでした。これは、Webアプリケーションの国際年齢評価連合（IARC）認定コードを表す文字列です。 Webアプリケーションがどの年齢に適しているかを判断するために使用することを目的としています。

図11.6の説明を表示

デスクトップおよびモバイル向けのWebアプリマニフェストプロパティの人気を示す棒グラフ。デスクトップWebアプリマニフェストの88％には、名前プロパティ、82％はアイコン、61％はディスプレイ、55％はテーマカラー、49％は背景色、45％はショートネーム、36％は開始URL、19％はGCM送信者ID、9％はGCMユーザーのみ表示、9％はオリエンテーション、説明7％、範囲5％、言語4％。モバイルWebアプリマニフェストでのプロパティの人気は似ており、プラスまたはマイナス2パーセントポイントです。

頻繁に遭遇した独自のプロパティは、従来のGoogle Cloud Messaging（GCM）サービスのgcm_sender_idとgcm_user_visible_onlyでした。興味深いことに、モバイルとデスクトップにはほとんど違いがありません。ただし、両方のプラットフォームで、ブラウザーによって解釈されないプロパティの長いテールがありますが、作成者やバージョンなどの潜在的に有用なメタデータが含まれています。また、重要なタイプミスのプロパティもありました。私たちのお気に入りは、short_nameではなくshot_nameです。興味深い外れ値はserviceworkerプロパティです。これは標準ですが、ブラウザベンダーによって実装されていません。それでも、モバイルおよびデスクトップページで使用されるすべてのWebアプリマニフェストの0.09％で見つかりました。

値を表示する

開発者がdisplayプロパティに設定した値を見ると、PWAがWebテクノロジーの起源を明かさない「適切な」アプリとして認識されることを望んでいることがすぐに明らかになります。

図11.7の説明を表示

Webアプリマニフェストの表示プロパティがデスクトップおよびモバイルWebサイトでどのように使用されるかを示す棒グラフ。どちらの場合も、57％の時間で「standalone」値が使用されます。マニフェストの38％でプロパティがまったく設定されていません。 「minimal UI」、「browser」、および「fullscreen」の各値は、使用量の1〜2％のみを占めています。

standaloneを選択することで、エンドユーザーにブラウザUIが表示されないようにします。これは、prefers_related_applicationsプロパティを使用するアプリの大部分に反映されています。モバイルアプリケーションとデスクトップアプリケーションの両方の97％がネイティブアプリケーションを優先していません。

Category値

categoriesプロパティは、Webアプリケーションが属する予想されるアプリケーションカテゴリを記述します。これは、Webアプリケーションをリストするカタログまたはアプリストアへのヒントとしてのみ意図されており、Webサイトは1つ以上の適切なカテゴリに自分自身をリストするために最善を尽くすことが期待されます。

図11.8の説明を表示

上位のWebアプリマニフェストカテゴリを示す棒グラフ。 60個のモバイルマニフェストは「ショッピング」カテゴリ、15個は「ビジネス」、9個は「ウェブ」、9個は「テクノロジー」、8個は「ゲーム」、8個は「エンターテイメント」、7個は「ソーシャル」などです。 「ショッピング」の場合、デスクトップマニフェストは1つだけです。

このプロパティを利用したマニフェストはあまり多くありませんでしたが、モバイルで最も人気のあるカテゴリである「ショッピング」から「ビジネス」「テクノロジー」、そして最初の場所を均等に共有するデスクトップ上の「ウェブ」（それが意味するものは何でも）。

アイコンのサイズ

Lighthouseには少なくとも192X192ピクセルのサイズのアイコンが必要https://developers.google.com/web/tools/lighthouse/audits/manifest-contains-192px-iconですが、一般的なファビコン生成ツールは他のサイズのアイコンも大量に作成します。

図11.9の説明を表示

上位のWebアプリマニフェストアイコンサイズプロパティ値の使用状況を示す棒グラフ。すべての値は高さと幅のピクセルで指定されます。たとえば、マニフェストの23％のトップ値は192X192ピクセルです。次に人気のあるサイズは、11％で144、11％で96、10％で72、10％で48、9％で512、9％で36％、5％で256、2％で384、1%で128、そして1％で152です。デスクトップとモバイルの使用パターンは同じです。

Lighthouseのルールが、おそらくアイコンサイズ選択の犯人で、192ピクセルがデスクトップとモバイルの両方で最も人気があります。Googleのドキュメントhttps://developers.google.com/web/fundamentals/web-app-manifest#iconsで512X512を明示的に推奨していますが、これは特に目立つオプションとしては表示されてません。

Orientation値

orientationプロパティの有効な値は、画面方向API仕様https://www.w3.org/TR/screen-orientation/#dom-orientationlocktypeで定義されています。現在、それらは次のとおりです。

• "any"
• "natural"
• "landscape"
• "portrait"
• "portrait-primary"
• "portrait-secondary"
• "landscape-primary"
• "landscape-secondary"

図11.10の説明を表示

上位のWebアプリマニフェストの方向の値を示す棒グラフ。 「Portrait」はデスクトップマニフェストの6％に設定され、2％に「any」が続き、マニフェストの1％未満に他のすべてが設定されます。これはモバイルマニフェストでの使用に似ていますが、マニフェストの8％で「portrait」が設定され、1％で「portrait-primary」が設定されます。

「portrait」オリエンテーションは両方のプラットフォームで明確な勝者であり、「any」オリエンテーションがそれに続きます。

Workbox

Workboxhttps://developers.google.com/web/tools/workboxは、一般的なService Workerのユースケースを支援する一連のライブラリです。たとえばWorkboxには、ビルドプロセスにプラグインしてファイルのマニフェストを生成できるツールがあり、Service Workerによって事前にキャッシュされます。 Workboxには、ランタイムキャッシング、リクエストルーティング、キャッシュの有効期限、バックグラウンド同期などを処理するライブラリが含まれています。

Service Worker APIの低レベルの性質を考慮すると、多くの開発者は、Service Workerロジックをより高レベルで再利用可能なコードの塊に構造化する方法としてWorkboxに注目しています。 Workboxの採用は、create-react-appやVueのPWAプラグインhttps://www.npmjs.com/package/@vue/cli-plugin-pwaなど、多くの一般的なJavaScriptフレームワークスターターキットの機能として含まれることによっても促進されます。

HTTP Archiveは、Service Workerを登録するWebサイトの12.71％が少なくとも1つのWorkboxライブラリを使用していることを示しています。この割合は、デスクトップ（14.36％）と比較してモバイルではわずかに低い割合（11.46％）で、デスクトップとモバイルでほぼ一貫しています。

結論

この章の統計は、PWAがまだごく一部のサイトでしか使用されていないことを示しています。ただし、この比較的少ない使用量はトラフィックのシェアがはるかに大きい人気のあるサイトによってもたらされ、ホームページ以外のページはこれをさらに使用する可能性があります。ページのロードの15％がService Workerを使用することがわかりました。特にモバイル向けのパフォーマンスとキャッシングのより優れた制御に与える利点は、使用が増え続けることを意味するはずです。

PWAは、Chrome主導のテクノロジーと見なされることがよくあります。一部のプラットフォームでは一流のインストール可能性が遅れているものの、他のブラウザは、基盤となるテクノロジーのほとんどを実装するために最近大きく進歩しました。サポートがさらに普及するのを前向きに見る事ができます。 Maximiliano Firtmanhttps://x.com/firtは、Safari PWAサポートの説明https://medium.com/@firt/iphone-11-ipados-and-ios-13-for-pwas-and-web-development-5d5d9071cc49など、iOSでこれを追跡する素晴らしい仕事をしています。 AppleはPWAという用語をあまり使用せず、HTML5アプリはApp Storeの外部に最適配信されると明示的に述べていますhttps://developer.apple.com/news/?id=09062019b。Microsoftは逆の方向に進み、アプリストアでPWAを奨励するだけでなく、Bing Webクローラーを介して検出されたPWAを自動的にショートリストに追加しましたhttps://web.archive.org/web/20190711051508/https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/microsoft-store。 Googleは、信頼できるWebアクティビティhttps://developers.google.com/web/updates/2019/02/using-twaを介して、Google PlayストアにWebアプリをリストする方法も提供しています。

PWAは、ネイティブプラットフォームやアプリストアではなくWeb上でビルドおよびリリースすることを希望する開発者に道を提供します。すべてのOSとブラウザがネイティブソフトウェアと完全に同等であるとは限りませんが、改善は継続され、おそらく2020年は展開が爆発的に増加する年になるでしょうか？

モバイルウェブ

序章Introduction

2007年に少し戻ってみましょう。「モバイルウェブ」は現在、レーダー上ではほんの一瞬の出来事に過ぎませんが、それには正当な理由があります。なぜでしょうか？　モバイルブラウザはCSSをほとんどサポートしていないため、サイトの見た目がデスクトップとは全く異なります。画面は信じられないほど小さく、一度に数行のテキストしか表示できません。また、マウスの代わりとなるのは、「タブを使って移動する」ための小さな矢印キーです。言うまでもなく、携帯電話でウェブを閲覧することは本当に愛の労働です。 しかし、このすべてをちょうど変更しようとしている。

プレゼンの途中、スティーブ・ジョブズは発表されたばかりのiPhoneを手にして座り、それまで夢見ていた方法でウェブサーフィンを始めます。大きな画面とフル機能のブラウザで、ウェブサイトをフルに表示します。そして最も重要なことは、人間に知られている最も直感的なポインターデバイスを使ってウェブサーフィンをすることです：私たちの指。小さな矢印キーを使って、これ以上のタブ操作はありません。

2007年以降、モバイルウェブは爆発的な成長を遂げました。そして13年後の現在、2019年7月のAkamai mPulsehttps://developer.akamai.com/akamai-mpulse-real-user-monitoring-solutionのデータによると、モバイルは全検索の 59%https://www.merkleinc.com/thought-leadership/digital-marketing-reportと全ウェブトラフィックの58.7％を占めています。モバイルはもはや余計なものでなく、人々がウェブを体験する主要な方法となっています。モバイルの重要性を考えると、私たちは訪問者にどのような体験を提供しているのでしょうか？　どこが不足しているのか？　それを探ってみましょう。

ページの読み込み体験

私たちが分析したモバイルウェブ体験の最初の部分は、私たちが最も身近に感じているものです。ページの読み込み体験です。しかし、今回の調査結果へ飛び込む前に、典型的なモバイルユーザーが実際にどのようなユーザーであるかについて全員が同じ見解を持っていることを確認しておきましょう。これは、これらの結果を再現するのに役立つだけでなく、これらのユーザーをよりよく理解することにもつながるからです。

まずは、典型的なモバイルユーザーがどのような電話を持っているかから始めましょう。平均的なAndroid携帯電話価格は～250ドルhttps://web.archive.org/web/20190921115844/https://www.idc.com/getdoc.jsp?containerId=prUS45115119で、その範囲内の最も人気のある携帯電話https://web.archive.org/web/20190812221233/https://deviceatlas.com/blog/most-popular-android-smartphonesの1つは、サムスンのギャラクシーS6です。だから、これはおそらく典型的なモバイルユーザーが使用している携帯電話の種類であり、実際にはiPhone 8よりも4倍遅いです。このユーザーは、高速な4G接続へのアクセス権を持っていませんが、むしろ2G接続（29%https://www.gsma.com/r/mobileeconomy/時間の）または3G接続（28%https://www.gsma.com/r/mobileeconomy/時間の）を使用しています。そして、これが全ての足し算になります。

この結果に驚かれる方もいらっしゃると思います。あなたがこれまでにサイトをテストしたことのある条件よりも、はるかに悪い条件かもしれません。しかし、モバイルユーザーが本当にどのようなものなのかということについては、今はみんな同じページにいるのでさっそく始めてみましょう。

JavaScriptで肥大化したページ

モバイルウェブのJavaScriptの状態が恐ろしい。HTTP Archiveの JavaScript レポートhttps://httparchive.org/reports/state-of-javascript?start=2016_05_15&end=2019_07_01&view=list#bytesJsによると、モバイルサイトの中央値では、携帯電話が375KBのJavaScriptをダウンロードする必要があります。圧縮率を70％と仮定すると、携帯電話は中央値で1.25MBのJavaScriptを解析、コンパイル、実行しなければならないことになります。

なぜこれが問題なのでしょうか？　なぜなら、これだけの量のJSをロードしているサイトは、一貫してインタラクティブになるまで10秒https://httparchive.org/reports/loading-speed?start=earliest&end=2019_07_01&view=list#ttci以上かかるからです。言い換えればページは完全に読み込まれているように見えるかもしれませんが、ユーザーがボタンやメニューをクリックするとJavaScriptの実行が終了していないために、ユーザーは多少の速度低下を経験するかもしれません。最悪の場合、ユーザーは10秒以上ボタンをクリックし続けなければならず、何かが実際に起こる魔法のような瞬間を待つことになります。それがどれほど混乱し、イライラさせるかを考えてみてください。

図12.2の説明を表示

2つのWebページのロードを示すビデオ。各ページは、ビデオ全体でボタンを繰り返しタップする図がありますが、効果はありません。上部には0秒から刻々と刻む時計があり、各Webサイトの最初の幸せな絵文字の顔は、時計が6秒を過ぎると幸せになり始め、8秒で目が大きく、10秒で怒り、 13秒、19秒で泣いてすぐにビデオが終了します。

さらに深く掘り下げて、各ページがJavaScriptをどの程度利用しているかに焦点を当てた別の指標を見てみましょう。例えば、読み込み中のページは本当に多くのJavaScriptを必要としているのでしょうか？　私たちはこの指標をWeb bloat scorehttps://www.webbloatscore.com/に基づいたJavaScript Bloat Scoreと呼んでいます。その背後にある考え方は次のようなものです。

• JavaScriptは、ページの読み込みに合わせて生成と変更の両方を行うためによく使われます。
• また、ブラウザにテキストとして配信されます。そのため、よく圧縮され、ただのページのスクリーンショットよりも速く配信されるはずです。
• そのため、ページがダウンロードするJavaScriptの総量がビューポートのPNGスクリーンショットよりも多い場合（画像やCSSなどを含まない）、私たちはあまりにも多くのJavaScriptを使用していることになります。この時点では、スクリーンショットを送信してページの初期状態を取得した方が早いでしょう!

その結果は？　分析した500万以上のウェブサイトのうち75.52％がJavaScriptで肥大化していました。まだまだ先は長いですね。

分析した500万以上のサイトすべてのスクリーンショットをキャプチャして測定できなかったことに注意してください。代わりに、1000のサイトからランダムにサンプリングして、ビューポートのスクリーンショットサイズの中央値（140KB）を見つけ各サイトのJavaScriptダウンロードサイズをこの数値と比較しました。

JavaScriptの効果をもっと詳しく知りたい方は、Addy OsmaniのThe Cost of JavaScript in 2018https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4をチェックしてみてください。

サービスワーカーの使い方

ブラウザは通常、すべてのページを同じように読み込みます。いくつかのリソースのダウンロードを他のリソースよりも優先したり、同じキャッシュルールに従ったりします。サービスワーカーhttps://developers.google.com/web/fundamentals/primers/service-workersのおかげで、リソースがネットワーク層によってどのように処理されるかを直接制御できるようになりました。

2016年から利用可能になり、すべての主要ブラウザに実装されているにもかかわらず、利用しているサイトはわずか0.64％にとどまっています!

読み込み中にコンテンツを移動する

ウェブの最も美しい部分の1つは、ウェブページのロードが自然と進んでいくことです。ブラウザはできる限り早くコンテンツをダウンロードして表示するため、ユーザーはできるだけ早くあなたのコンテンツに引き込む事ができます。しかし、このことを念頭に置いてサイトを設計しないと、悪影響を及ぼす可能性があります。具体的には、リソースのロードに合わせてコンテンツの位置がずれることで、ユーザー体験の妨げになることがあります。

図12.3の説明を表示

Webサイトの読み込みが進んでいく様子を動画で紹介しています。テキストは素早く表示されますが、画像が読み込まれ続けると、テキストはページの下にどんどん移動していき、読むのに非常にイライラします。この例の計算されたCLSは42.59%です。画像提供：LookZook

あなたが記事を読んでいるときに突然、画像が読み込まれ、読んでいるテキストが画面の下に押し出されたと想像してみてください。あなたは今、あなたがいた場所を探すか、ちょうど記事を読むことをあきらめなければなりません。または、おそらくさらに悪いことに、同じ場所に広告がロードされる直前にリンクをクリックし始め、代わりに広告を誤ってクリックしてしまうことになります。

では、どのようにしてサイトの移動量を測定するのでしょうか？　以前はかなり困難でしたが（不可能ではないにしても）、新しい レイアウトの不安定性APIhttps://web.dev/articles/cls のおかげで、2ステップで測定を行うことができます。

1. レイアウトの不安定性APIを使用して、各シフトがページに与える影響を追跡します。これは、ビューポート内のコンテンツがどれだけ移動したかのパーセンテージとして報告されます。

2. あなたが追跡したすべてのシフトを取り、それらを一緒に追加します。その結果が 累積レイアウトシフトhttps://web.dev/articles/cls#a-cumulative-layout-shift-score(CLS)スコアと呼ばれるものです。

訪問者ごとに異なるCLSを持つことができるため、Chrome UX Report (./methodology#chrome-UX-report)(CrUX)を使用してウェブ全体でこのメトリックを分析するために、すべての体験を3つの異なるバケットにまとめています。

• SmallCLSを持っている方。CLSが5%未満になった経験あり。つまり、ページはほとんど安定していて、まったくズレないということです。参考までに、上の動画のページのCLSは42.59％です。
• LargeCLSを持っている方。CLSが100%以上ある経験。これは小さな個別シフトが多い場合と、大きく目立つシフトが多い場合の2つあります。
• Medium CLSを持っている方。SmallとLargeの間にあるもの。

では、ウェブをまたいでCLSを見ると、何が見えてくるのでしょうか？

1. 3サイトに2サイト近く（65.32％）が、全ユーザー体験の50％以上を占めるMediumかLargeCLSを持っています。

2. 20.52％のサイトでは、全ユーザー体験の少なくとも半分がLargeCLSを持っています。これは、約5つのウェブサイトの1つに相当します。図12.3の動画のCLSは42.59％に過ぎないことを覚えておいてください - これらの体験はそれよりもさらに悪いのです。

この原因の多くは広告や画像など、テキストが画面にペイントされた後、読み込まれるリソースの幅や高さをウェブサイトが明示的に提供していないことにあるのではないかと考えられています。ブラウザがリソースを画面に表示する前、そのリソースがどのくらいのスペースを占めるかを知る必要があります。そのため、CSSやHTML属性でサイズが明示的に指定されていない限り、ブラウザはリソースが実際にどのくらいの大きさなのかを知ることができず、読み込まれるまでは幅と高さを0pxにして表示します。リソースが読み込まれ、ブラウザがリソースの大きさをようやく知ると、ページの内容がずれるため、不安定なレイアウトになってしまいます。

パーミッションリクエスト

ここ数年、ウェブサイトと「アプリストア」アプリの境界線が曖昧になり続けています。今でもユーザーのマイク、ビデオカメラ、ジオロケーション、通知を表示する機能などへのアクセスを要求する機能があります。

これは開発者にとってさらに多くの機能を開放していますが、これらのパーミッションを不必要に要求するとユーザーがあなたのウェブページを警戒していると感じたままになり、不信感を抱くことになりかねません。これは私たちが常に「私の近くの劇場を探す」ボタンをタップするようなユーザーのジェスチャーにパーミッションリクエストを結びつけることをお勧めする理由です。

現在、1.52％のサイトがユーザーとの対話なしに許可を要求しています。このような低い数字を見ると励みになります。しかし、我々はホームページのみを分析できたことに注意することが重要です。そのため、例えば、コンテンツページ（例えばブログ記事）のみにパーミッションを要求しているサイトは考慮されていませんでした。詳細については、方法論のページを参照してください。

テキストの内容

ウェブページの第一の目標は、ユーザーが興味を持ってくれるコンテンツを配信することです。このコンテンツは、YouTubeのビデオや画像の詰め合わせかもしれませんが、多くの場合、ページ上のテキストだけかもしれません。テキストコンテンツが訪問者にとって読みやすいものであることが非常に重要であることは言うまでもありません。なぜなら、訪問者が読めなければ何も残っておらず、離脱してしまうからです。テキストが読みやすいかどうかを確認するには、色のコントラストとフォントサイズの2つが重要です。

カラーコントラスト

サイトをデザインするとき、私たちは最適な状態で、多くの訪問者よりもはるかに優れた目を持っている傾向があります。訪問者は色盲で、テキストと背景色の区別をできない場合があります。ヨーロッパ系の人は、男性の12人に1人、女性の200人に1人http://www.cvrl.org/people/stockman/pubs/1999%20Genetics%20chapter%20SSJN.pdfが色盲です。あるいは、太陽の光が画面にまぶしさを与えている間にページを読んでいる可能性があり、同様に読みやすさが損なわれている可能性があります。

この問題を軽減するために、テキストや背景色を選択する際に従うことのできるアクセシビリティ・ガイドラインhttps://dequeuniversity.com/rules/axe/2.2/color-contrastがあります。では、これらの基準を満たすにはどうすればよいのでしょうか？　すべてのテキストに十分な色のコントラストを与えているサイトは22.04％にすぎません。この値は実際には下限値であり、背景が無地のテキストのみを分析したためです。画像やグラデーションの背景は分析できませんでした。

図12.4の説明を表示

褐色とグレーの4色のボックスに白のテキストを重ねて、背景色が白のテキストに比べて薄い色になっている場合と、白のテキストに比べて背景色が推奨されている場合の2つの列を作ります。各色の16進数コードが表示され、白は #FFFFFF 、褐色色の背景の薄い色合いは #FCA469 、褐色色の背景の推奨色合いは #BD5B0E となっています。同等のグレースケールは、それぞれ ＃B8B8B8 および ＃707070 です。画像提供：LookZook

他の人口統計における色覚異常の統計については、本論文https://web.archive.org/web/20180304115406/http://www.allpsych.uni-giessen.de/karl/colbook/sharpe.pdfを参照してください。

フォントサイズ

読みやすさの第二の部分は、テキストを読みやすい大きさにすることです。これはすべてのユーザーにとって重要ですが、特に年齢層の高いユーザーにとっては重要です。フォントサイズが12px未満では読みにくくなる傾向があります。

ウェブ上では、80.66％のウェブページがこの基準を満たしていることがわかりました。

ページの拡大、縮小、回転

ズームと拡大縮小

何万もの画面サイズやデバイスで完璧に動作するようサイトをデザインすることは、信じられないほど難しいことです。ユーザーの中には読むために大きなフォントサイズを必要としたり、製品画像を拡大したり、ボタンが小さすぎて品質保証チームの前を通り過ぎてしまったためにボタンを大きくしたりする必要がある人もいます。このような理由から、ピンチズームやスケーリングなどのデバイス機能が非常に重要になります。

問題のページがタッチコントロールを使用したWebベースのゲームである場合など、この機能を無効にしても問題ない場合が非常に稀にあります。この場合この機能を有効にしておくと、プレイヤーがゲームを2回タップするたびにプレイヤーの携帯電話がズームインしたりズームアウトしたりしてしまい、結果的に利用できなくなってしまいます。

このため、開発者はメタビューポートタグに以下の2つのプロパティのいずれかを設定することで、この機能を無効にできます。

1. user-scalableを0またはnoに設定

2. maximum-scaleを1、1.0などに設定

図12.5の説明を表示

“ズームとスケーリングは有効ですか？”と題された縦方向のグループ化された棒グラフでは、0から80までのデータを20刻みで計測し、デバイスの種類をデスクトップとモバイルに分類しています。デスクトップが有効：75.46％、デスクトップが無効：24.54％、モバイルが有効：67.79％、モバイルが無効：32.21％。

しかし開発者はこれを悪用しすぎて、3つのサイトのほぼ1つ(32.21％)がこの機能を無効にしており、Appleは(iOS 10の時点で)ウェブ開発者がズームを無効にすることを許さなくなっています。モバイルSafariは単にタグを無視するhttps://archive.org/details/ios-10-beta-release-notes。世界中のウェブトラフィックの11%https://gs.statcounter.com/以上を占める新しいアップルのデバイスでは、どんなサイトでもズームや拡大縮小が可能です。

ページの回転

モバイルデバイスでは、ユーザーが回転できるので、あなたのウェブサイトをユーザーが好む形式で閲覧できます。ただし、ユーザーはセッション中に常に同じ向きを保つわけではありません。フォームに記入するとき、ユーザーはより大きなキーボードを使用するため横向きに回転できます。また、製品を閲覧しているときには、横向きモードの方が大きい製品画像を好む人もいるでしょう。このようなユースケースがあるため、モバイルデバイスに内蔵されているこの機能をユーザーから奪わないことが非常に重要です。そして良いニュースは、この機能を無効にしているサイトは事実上見当たらないということです。この機能を無効にしているサイトは全体の87サイト（または0.0016％）のみです。これは素晴らしいことです。

ボタンとリンク

タップターゲット

デスクトップではマウスのような精密なデバイスを使うことに慣れていますが、モバイルでは全く違います。モバイルでは、私たちは指と呼ばれる大きくて不正確なツールを使ってサイトにアクセスします。その不正確さゆえに、私たちは常にリンクやボタンを「タップミス」して、意図していないものをタップしています。

この問題を軽減するためにタップターゲットを適切に設計することは、指の大きさが大きく異なるために困難な場合があります。しかし現在では多くの研究が行われており、どの程度の大きさのボタンが必要で、どの程度の間隔で離す必要があるかについては安全な基準https://developers.google.com/web/tools/lighthouse/audits/tap-targets があります。

図12.6の説明を表示

タップしにくいボタンの例を2つ表示した図です。1つ目の例では、2つのボタンの間に間隔を空けていますが、その下の例では、同じボタンを推奨される間隔(8pxまたは1-2mm)で表示しています。その下の例では、同じボタンを40～48px（約8mm）の推奨サイズに拡大して表示しています。画像提供：LookZook

現在のところ、34.43％のサイトで十分なサイズのタップターゲットを持っています。つまり、「タップミス」が過去のものになるまでには、かなりの道のりがあるということです。

ラベリングボタン

デザイナーの中には、テキストの代わりにアイコンを使うのが好きな人もいます。しかし、あなたやあなたのチームのメンバーはアイコンの意味を知っていても、多くのユーザーがそうではありません。これは悪名高いハンバーガーのアイコンにも当てはまります。もし私たちを信じられないのであれば、ユーザーテストをしてみて、どれくらいの頻度でユーザーが混乱しているかを見てみましょう。驚くことでしょう。

だからこそ、混乱を避けるためにも、ボタンにサポートテキストやラベルを追加することが重要なのです。現在のところ、少なくとも28.59％のサイトでは、補助テキストを含まないアイコン1つだけのボタンが表示されています。

セマンティックフォームフィールド

新しいサービスへのサインアップ、オンラインでの購入、あるいはブログからの新着情報の通知を受け取るためにフォームフィールドはウェブに欠かせないものであり、私たちが日常的に使用するものです。しかし残念なことに、これらのフィールドはモバイルで入力するのが面倒であることで有名です。ありがたいことに、近年のブラウザは開発者に新しいツールを提供し、私たちがよく知っているこれらのフィールドへの入力の苦痛を和らげることができるようになりました。ここでは、これらのツールがどの程度使われているかを見てみましょう。

新しい入力タイプ

過去に、デスクトップではtextとpasswordがほとんどすべてのニーズを満たしていたため、開発者が利用できる入力タイプはtextとpasswordだけでした。しかし、モバイルデバイスではそうではありません。モバイルキーボードは信じられないほど小さく、電子メールのアドレスを入力するような単純な作業では、ユーザーは複数のキーボードを切り替える必要があります。電話番号を入力するだけの単純な作業では、デフォルトのキーボードの小さな数字を使うのは難しいかもしれません。

その後、多くの新しい入力タイプhttps://developer.mozilla.org/docs/Web/HTML/Element/Inputが導入され、開発者はどのようなデータが期待されるかをブラウザに知らせ、ブラウザはこれらの入力タイプに特化したカスタマイズされたキーボードを提供できるようになりました。例えば、emailのタイプは”@”記号を含む英数字キーボードをユーザに提供し、telのタイプはテンキーを表示します。

メール入力を含むサイトを分析する際には、56.42％がtype="email"を使用している。同様に、電話入力では、type="tel"が36.7％の割合で使用されています。その他の新しい入力タイプの採用率はさらに低い。

利用可能な大量の入力タイプについて自分自身や他の人を教育し、上の図12.7のようなタイプミスがないことを再確認するようにしてください。

入力のオートコンプリートを有効にする

入力属性autocomplete は、ユーザーがワンクリックでフォームフィールドへ記入できるようにします。ユーザーは膨大な数のフォームに記入しますが、毎回全く同じ情報を記入することがよくあります。このことに気付いたブラウザは、この情報を安全に保存し、将来のページで使用できるようにし始めました。開発者がすべきことは、このautocomplete属性を使用してどの情報を正確に入力する必要があるかをブラウザに伝えるだけで、あとはブラウザが行います。

現在、入力フィールドを持つページのうち、この機能を利用しているのは29.62％に過ぎません。

パスワードフィールドへの貼り付け

ユーザーがパスワードをコピーしてページに貼り付けることができるようにすることは、パスワードマネージャーを使用するための1つの方法です。パスワードマネージャーは、ユーザーが強力なパスワードを生成（記憶）し、ウェブページ上で自動的に記入するのに役立ちます。テストしたウェブページの0.02％だけがこの機能を無効にしています。

結論

13年以上もの間、私たちはモバイルウェブをデスクトップの単なる例外のように後回しにしてきました。しかし、今こそこの状況を変える時です。モバイル・ウェブは今や「ウェブ」であり、デスクトップはレガシーウェブになりつつあります。現在、世界では40億台のアクティブなスマートフォンが存在し、潜在的なユーザーの70％をカバーしています。デスクトップはどうでしょうか？　デスクトップは現在16億台となっており、毎月のウェブ利用の割合は少なくなっています。

モバイルユーザーへの対応はどの程度できているのでしょうか？　当社の調査によると、71％のサイトがモバイル向けに何らかの努力をしているにもかかわらず、その目標を大きく下回っています。ページの読み込みに時間がかかり、JavaScriptの乱用により使用不能になり、テキストは読めないことが多く、リンクやボタンをクリックしてサイトにアクセスするとエラーが発生しやすくイライラさせられます。

モバイルウェブは今では十分に長い間存在しています。子供たちの世代全体がこれまでに知っていた唯一のインターネットです。私たちは彼らにどのような経験を与えているのでしょうか？　私たちは本質的にダイヤルアップ時代に彼らを連れ戻しています。(私はAOLがまだ無料のインターネットアクセスの1000時間を提供するCDを販売していると聞いて良かった!)

図12.9の説明を表示

1,000時間無料で提供しているAOLのCD-ROMの写真。

Eコマース

序章

この調査では、ホームページの10％近くがEコマース・プラットフォーム上にあることが判明しました。「Eコマースプラットフォーム」は、オンラインストアを作成し、運営することを可能にするソフトウェアまたはサービスのセットです。Eコマースプラットフォームのいくつかのタイプがあります。

• Shopifyhttps://www.shopify.com/のような有料サービスは、あなたのお店をホストし、あなたが始めるのを手助けしてくれます。彼らはウェブサイトのホスティング、サイトやページのテンプレート、商品データの管理、ショッピングカートや支払いを提供しています。
• Magento Open Sourcehttps://magento.com/products/magento-open-sourceのようなソフトウェアプラットフォームは自分で設定し、ホストし、管理できます。これらのプラットフォームは強力で柔軟性がありますが、Shopifyのようなサービスよりもセットアップや運用が複雑になることがあります。
• Magento Commercehttps://magento.com/products/magento-commerceのようなホスト付きプラットフォームは、ホスティングがサードパーティによってサービスとして管理されていることを除いて、彼らのセルフホスティングされた対応と同じ機能を提供しています。

この分析では、Eコマース・プラットフォーム上に構築されたサイトのみを検出できました。つまり、Amazon、JD、eBayなどの大規模なオンラインストアやマーケットプレイスはここには含まれていません。また、ここでのデータはホームページのみを対象としており、カテゴリ、商品、その他のページは含まれていないことにも注意してください。当社の方法論の詳細については、こちらをご覧ください。

プラットフォーム検出

ページがEコマースプラットフォーム上にあるかどうかを確認するにはどうすればいいですか？

検出はWappalyzerで行います。Wappalyzerは、Webサイトで使用されている技術を発見するためのクロスプラットフォームユーティリティです。コンテンツ管理システム、Eコマースプラットフォーム、Webサーバー、JavaScriptフレームワーク、アナリティクスツールなどを検出します。

ページ検出は常に信頼できるものでなく、サイトによっては自動攻撃から保護するために検出を明示的にブロックしている場合もあります。特定のEコマースプラットフォームを使用しているすべてのウェブサイトを捕捉することはできないかもしれませんが、検出したウェブサイトは実際にそのプラットフォームを使用していると確信しています。

Eコマースプラットフォーム

検出された116のEコマースプラットフォームのうち、デスクトップまたはモバイルサイトの0.1％以上で検出されたのは6つだけでした。これらの結果には国別、サイトの規模別、その他の類似した指標による変動は示されていません。

上記の図13.3を見ると、WooCommerceの採用率が最も高く、デスクトップおよびモバイルサイトの約4％を占めていることがわかります。Shopifyは約1.6％の採用で2位です。Magento、PrestaShop、Bigcommerce、Shopwareが0.1％に近づき、採用率が小さくなっています。

ロングテール

図13.4の説明を表示

上位20のEコマースプラットフォームの採用状況の棒グラフ。上位6プラットフォームの採用状況のデータ表は、上記の図13.3を参照してください。

110のEコマースプラットフォームがあり、それぞれがデスクトップまたはモバイルのウェブサイトの0.1％未満を持っています。そのうち約60社は、モバイルかデスクトップのウェブサイトの0.01％未満を占めています。

図13.5の説明を表示

上位6つのEコマースプラットフォームは、すべてのウェブサイトの8％を占めています。残りの110のプラットフォームはウェブサイトの1.5％を占めているに過ぎません。デスクトップとモバイルの結果は似ています。

モバイルでのリクエストの7.87％、デスクトップでのリクエストの8.06％は、上位6つのEコマース・プラットフォームのうちの1つのホームページが対象となっています。さらにモバイルでのリクエストの1.52％、デスクトップでのリクエストの1.59％は、他の110のEコマース・プラットフォームのホームページが対象となっています。

Eコマース（すべてのプラットフォーム）

合計で、デスクトップページの9.7％、モバイルページの9.5％がEコマースプラットフォームを利用していました。

図13.6の説明を表示

デスクトップページの9.7%がEコマースプラットフォームを使用しており、モバイルページの9.5%がEコマースプラットフォームを使用しています。

ウェブサイトのデスクトップ比率は全体的に若干高くなっていますが、一部の人気プラットフォーム（WooCommerce、PrestaShop、Shopwareを含む）では、実際にはデスクトップウェブサイトよりもモバイル性が高くなっています。

ページの重さと要望

Eコマースプラットフォームのページの重さは、すべてのHTML、CSS、JavaScript、JSON、XML、画像、オーディオ、およびビデオを含んでいます。

図13.7の説明を表示

10、25、50、75、およびEコマースページの重量の90パーセンタイルの分布。中央値のデスクトップEコマースページは2.7MBをロードします。10パーセンタイルは1.0MB、25パーセンタイルは1.6MB、75パーセンタイルは4.5MB、90パーセンタイルは7.6MBです。デスクトップのウェブサイトは、メガバイトの10分の1の割合でモバイルよりもわずかに高くなっています。

図13.8の説明を表示

Eコマースページあたりのリクエストの10、25、50、75、および 90パーセンタイルの分布。中央値のデスクトップ Eコマースページは108リクエストを行います。10パーセンタイルは53リクエスト、25パーセンタイルは76、75パーセンタイルは153、90パーセンタイルは210です。デスクトップのウェブサイトは、約10リクエストでモバイルよりもわずかに高くなっています。

デスクトップEコマースプラットフォームのページの読み込み量の中央値は108リクエストと2.7MBです。すべてのデスクトップページの重量の中央値は74リクエストと1.9 MB です。言い換えれば、Eコマースページは他のウェブページよりも50％近く多くのリクエストを行い、ペイロードは約35％大きくなっています。比較すると、amazon.comhttps://amazon.comのホームページは、最初のロード時に約5MBのページ重量に対して約300リクエストを行い、ebay.comhttps://ebay.comは約3MBのページウェイトに対して約150リクエストを行います。Eコマースプラットフォーム上のホームページのページ重量とリクエスト数は、各パーセンタイルでモバイルの方が若干小さくなっていますが、すべてのEコマースのホームページの約10％が7MB以上をロードし200以上のリクエストをしています。

このデータは、ホームページのペイロードとスクロールなしのリクエストを含んでいます。明らかに、最初のロードに必要なはずのファイル数よりも多くのファイルを取得しているように見えるサイトがかなりの割合で存在しています(中央値は100以上)。以下のサードパーティのリクエストとバイト数も参照してください。

Eコマース・プラットフォーム上の多くのホームページが、なぜこれほど多くのリクエストを行い、これほど大きなペイロードを持つのかをよりよく理解するために、さらに調査を行う必要があります。著者らはEコマース・プラットフォーム上のホームページで、最初のロード時に数百回のリクエストを行い、数メガバイトのペイロードを持つホームページを定期的に目にします。リクエスト数とペイロードがパフォーマンスの問題であるならば、どのようにしてそれらを減らすことができるのでしょうか？

タイプ別のリクエストとペイロード

以下の表は、デスクトップでのリクエストの場合のものです。

Eコマースページでは、画像が最大のリクエスト数とバイト数の割合を占めています。デスクトップEコマースページの中央値には、1,514KB(1.5MB)の重さの画像が39枚含まれています。

JavaScriptリクエストの数は、より良いバンドル(および/またはHTTP/2多重化)によってパフォーマンスを向上する可能性があることを示しています。JavaScriptファイルの総バイト数はそれほど大きくありませんが、個別のリクエストが多くなっています。HTTP/2の章によると、リクエストの40％以上はHTTP/2経由ではないそうです。同様に、CSSファイルは3番目にリクエスト数が多いですが、一般的には少ないです。CSSファイル(またはHTTP/2)をマージすることで、そのようなサイトのパフォーマンスを向上させることができるかもしれません。著者の経験では、多くのEコマースページでは、未使用のCSSとJavaScriptの割合が高い。ビデオ のリクエスト数は少ないかもしれませんが、(驚くことではありません) 特にペイロードが重いサイトでは、ページの重量の割合が高くなります。

HTMLペイロードサイズ

図13.11の説明を表示

EコマースページあたりのHTMLバイトの10、25、50、75、および90パーセンタイルの分布。中央値のデスクトップ Eコマースページには、36KBのHTMLがあります。10パーセンタイルは12KB、25パーセンタイルは20、75パーセンタイルは66、90パーセンタイルは118です。デスクトップWebサイトの HTMLバイト数は、モバイルよりも1～2KB多いです。

HTMLペイロードには、外部リンクとして参照されるのではなく、マークアップ自体にインラインJSON、JavaScript、CSSなどの他のコードが直接含まれている場合があることに注意してください。EコマースページのHTMLペイロードのサイズの中央値は、モバイルで34KB、デスクトップで36KBです。しかし、Eコマースページの10％には、115KB以上のHTMLペイロードがあります。

モバイルのHTMLペイロードのサイズは、デスクトップとあまり変わりません。言い換えれば、サイトは異なるデバイスやビューポートのサイズに対して、大きく異なるHTMLファイルを配信していないように見えます。多くのEコマースサイトでは、ホームページのHTMLペイロードが大きくなっています。これがHTMLの肥大化によるものなのか、それともHTMLファイル内の他のコード（JSONなど）によるものなのかはわかりません。

画像の統計

図13.12の説明を表示

Eコマースページあたりの画像バイト数の10、25、50、75、および90パーセンタイルの分布。中央値のモバイルEコマースページには、1,517KBの画像があります。10パーセンタイルは318KB、25パーセンタイルは703、75パーセンタイルは3,132、90パーセンタイルは5,881です。デスクトップとモバイルのウェブサイトでは、同様の分布を示しています。

図13.13の説明を表示

Eコマースページあたりの画像リクエストの10、25、50、75、および90パーセンタイルの分布。中央値のデスクトップEコマースページでは、40件の画像リクエストが発生します。10パーセンタイルはリクエストが16件、25パーセンタイルは25件、75パーセンタイルは62件、90パーセンタイルは97件です。デスクトップの分布は、各パーセンタイルで2～10件のリクエストがモバイルよりもわずかに高くなっています。

上記の図13.12と13.13で中央値のEコマースページには、モバイルでは37枚の画像と1,517KBの画像ペイロードがあり、デスクトップでは40枚の画像と1,524KBの画像ペイロードがあることを示しています。ホームページの10％は、90以上の画像と6MB近くの画像ペイロードを持っています！

Eコマースページのかなりの割合で、大きな画像ペイロードを持ち、最初のロード時に大量の画像リクエストを行います。詳細については、HTTP ArchiveのState of Imageshttps://httparchive.org/reports/state-of-imagesレポート、およびmediaと[page weight](./page weight)の章を参照してください。

ウェブサイトの所有者は、自分のサイトを最新のデバイスで見栄えの良いものにしたいと考えています。その結果、多くのサイトでは、画面の解像度やサイズに関係なく、すべてのユーザーに同じ高解像度の製品画像を配信しています。開発者は、異なるユーザーに可能な限り最高の画像を効率的に配信できるレスポンシブ技術に気づいていない（または使いたくない）かもしれません。高解像度の画像が必ずしもコンバージョン率を高めるとは限らないことを覚えておきましょう。逆に重い画像の使いすぎは、ページの速度に影響を与える可能性が高く、それによってコンバージョン率を低下させる可能性があります。サイトレビューやイベントでの著者の経験では、開発者やその他の関係者の中には、画像に遅延ローディングを使用することにSEOなどの懸念を持っている人もいます。

一部のサイトがレスポンシブ画像技術や遅延読み込みを使用していない理由をよりよく理解するために、より多くの分析を行う必要があります。またEコマースプラットフォームが、ハイエンドのデバイスや接続性の良いサイトに美しい画像を確実に配信すると同時に、ローエンドのデバイスや接続性の悪いサイトにも最高の体験を提供できるようなガイダンスを提供する必要があります。

Popular image formats

図13.15の説明を表示

様々な画像フォーマットの人気を示す棒グラフ。JPEGが最も人気のあるフォーマットで、デスクトップEコマースページの画像の54％を占めています。次いでPNGが27％、GIFが14％、SVGが2％、WebPとICOがそれぞれ1％となっています。

PNG

Eコマースページの4つに1つの画像はPNGです。Eコマースプラットフォーム上のページでPNGのリクエストが多いのは、商品画像のためと思われます。多くのコマースサイトでは、透過性を確保するために写真画像と一緒にPNGを使用しています。

PNGフォールバックでWebPを使用することは、画像要素http://simpl.info/picturetypeを介して、またはCloudinaryhttps://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpgのような画像サービスを介してユーザーエージェントの能力検出を使用することで、はるかに効率的な代替手段となります。

WebP

Eコマースプラットフォーム上の画像の1％だけがWebPであり、これはサイトレビューやパートナーの仕事での著者の経験と一致しています。WebPはSafari以外のすべての最新ブラウザでサポートされていますhttps://caniuse.com/#feat=webpし、フォールバックの仕組みも充実しています。WebPは透過性をサポートしており、写真画像のためのPNGよりもはるかに効率的なフォーマットです（上記のPNGのセクションを参照してください）。

WebPをPNGのフォールバックで使用したり、無地の色の背景でWebP/JPEGを使用して透明化を可能にするため、Webコミュニティとして、より良いガイダンスや提唱を提供できます。WebPは、ガイドhttps://web.dev/i18n/ja/serve-images-webp やツール (例:Squooshhttps://squoosh.app/やcwebphttps://developers.google.com/speed/webp/docs/cwebpなど)があるにもかかわらず、電子商取引プラットフォームではほとんど使用されていないようです。現在10年近く経っているhttps://blog.chromium.org/2010/09/webp-new-image-format-for-web.htmlWebPの利用が増えていない理由をさらに調査する必要があります。

画像の寸法

Eコマースページで要求された画像の中央値（「中間値」）は、モバイルで247X196px、デスクトップで240X192pxです。Eコマースページで要求される画像の10％は、モバイルでは693X512px以上、デスクトップでは800X546px以上です。これらの寸法は画像の本質的なサイズであり、表示サイズではないことに注意してください。

中央値までの各パーセンタイルでの画像のサイズがモバイルとデスクトップで似ていることを考えると、多くのサイトではビューポートごとに異なるサイズの画像を配信していない、言い換えればレスポンシブ画像技術を使用していないように思えます。モバイル向けに大きな画像が配信されている場合もありますが、これはデバイス検出や画面検出を使用しているサイトによって説明できるかもしれません（そうでないかもしれません！）。

なぜ多くのサイトが（一見して）異なる画像サイズを異なるビューポートに配信していないのか、もっと研究する必要があります。

サードパーティからのリクエストとバイト

多くのウェブサイト、特にオンラインストアでは、分析、A/Bテスト、顧客行動追跡、広告、ソーシャルメディアのサポートなどのためにサードパーティのコードやコンテンツを大量にロードしています。サードパーティのコンテンツは、パフォーマンスに大きな影響を与えるhttps://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascriptことがあります。 Patrick Hulcehttps://x.com/patrickhulceのサードパーティウェブツールhttps://github.com/patrickhulce/third-party-webは、本レポートのサードパーティのリクエストを判断するために使用されており、これについてはサードパーティの章で詳しく説明しています。

図13.17の説明を表示

Eコマースページあたりのサードパーティリクエストの10、25、50、75、90パーセンタイルの分布。デスクトップでのサードパーティリクエストの数の中央値は19です。10、25、75、90パーセンタイルは4、9、34、54となっています。デスクトップの分布は、各パーセンタイルでモバイルよりも1-2件のリクエスト数だけ高くなっています。

図13.18の説明を表示

Eコマースページあたりのサードパーティのバイト数の10、25、50、75、90パーセンタイルの分布。デスクトップでのサードパーティのバイト数の中央値は320KBです。10、25、75、90パーセンタイルは次のとおりです。42、129、651、1,071。デスクトップの分布は、各パーセンタイルでモバイルよりも10～30KB高くなっています。

Eコマースプラットフォーム上の中央値（「中規模」）のホームページでは、サードパーティのコンテンツに対するリクエストは、モバイルで17件、デスクトップで19件となっています。Eコマース・プラットフォーム上のすべてのホームページの10％は、サードパーティのコンテンツに対して50件以上のリクエストを行い、その総ペイロードは1MBを超えています。

他の研究https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/loading-third-party-javascript/で、サードパーティのコンテンツはパフォーマンスの大きなボトルネックになる可能性であることが指摘されています。この調査によると、17以上のリクエスト（上位10％では50以上）がEコマースページの標準となっています。

プラットフォームごとのサードパーティリクエストとペイロード

以下の表は、モバイルのみのデータを示しています。

図13.19の説明を表示

各プラットフォームのEコマースページあたりのサードパーティリクエストの10、25、50、75、および90パーセンタイルの分布。ShopifyとBigcommerceは、分布の中央値で約40件のサードパーティのリクエストをロードしています。

図13.20の説明を表示

各プラットフォームのEコマースページあたりのサードパーティのバイト数(KB)の10、25、50、75、および90パーセンタイルの分布。ShopifyとBigcommerceは、中央値で1,000KBを超え、分布全体で最も多くのサードパーティのバイトをロードします。

Shopifyのようなプラットフォームでは、クライアントサイドのJavaScriptを使ってサービスを拡張することがありますが、Magentoのような他のプラットフォームではサーバーサイドの拡張機能が多く使われています。このアーキテクチャの違いが、ここで見る数字に影響を与えています。

明らかに、一部のEコマースプラットフォームのページでは、サードパーティコンテンツへのリクエストが多く、サードパーティコンテンツのペイロードが大きくなっています。一部のプラットフォームのページで、サードパーティコンテンツへのリクエストが多く、サードパーティコンテンツのペイロードが他のプラットフォームよりも大きいのはなぜかについて、さらに分析を行うことができます。

コンテンツの初回ペイント(FCP)

図13.21の説明を表示

上位6つのEコマースプラットフォームのFCPエクスペリエンスの平均分布の棒グラフ。WooCommerceは、遅いFCP体験の密度が43%と最も高くなっています。Shopifyは、高速FCP体験の密度が47%で最も高くなっています。

コンテンツの初回ペイントは、ナビゲーションからテキストや画像などのコンテンツが最初に表示されるまでの時間を測定します。この文脈では、速いは1秒未満のFCP、遅いは3秒以上のFCP、中程度はその中間のすべてを意味します。サードパーティのコンテンツやコードは、FCPに大きな影響を与える可能性があることに注意してください。

上位6つのEコマースプラットフォームはすべて、モバイルでのFCPがデスクトップよりも悪くなっています。FCPは、接続性だけでなく、デバイスの能力（処理能力、メモリなど）にも影響されることに注意してください。

FCPがデスクトップよりもモバイルの方が悪い理由を明らかにする必要があります。原因は何でしょうか？　接続性やデバイスの能力、それとも何か他の要因でしょうか？

プログレッシブウェブアプリ（PWA）のスコア

Eコマースサイト以外のこのトピックの詳細については、PWAの章も参照してください。

図13.22の説明を表示

EコマースページのLighthouseのPWAカテゴリスコアの分布。0（失敗）から1（完璧）のスケールで、ページの40％が0.33のスコアを取得します。ページの1％が0.6以上のスコアを取得しています。

Eコマースのプラットフォーム上のホームページの60％以上は、0.25と0.35の間にLighthouse PWAスコアhttps://developers.google.com/web/ilt/pwa/lighthouse-pwa-analysis-toolを取得します。Eコマースのプラットフォーム上のホームページの20％未満は、0.5以上のスコアを取得し、ホームページの1％未満は0.6以上のスコアを取得します。

Lighthouseは、プログレッシブWebアプリ（PWA）のスコアを0から1の間で返します。PWAの監査は、14の要件をリストアップしたBaseline PWA Checklisthttps://developers.google.com/web/progressive-web-apps/checklistに基づいています。Lighthouseは、14の要件のうち11の要件について自動監査を実施しています。残りの3つは手動でしかテストできません。11の自動PWA監査はそれぞれ均等に重み付けされているため、それぞれがPWAスコアに約9ポイント寄与します。

PWA監査のうち少なくとも1つがnullスコアを取得した場合、LighthouseはPWAカテゴリ全体のスコアをnullアウトします。これは、モバイルページの2.32％が該当しました。

明らかに、大多数のEコマースページは、ほとんどのPWA チェックリスト監査https://developers.google.com/web/progressive-web-apps/checklist に失敗しています。どの監査が失敗しているのか、なぜ失敗しているのかをよりよく理解するために、さらに分析を行う必要があります。

結論

Eコマースの使用法のこの包括的な研究はいくつかの興味深いデータを示し、また同じEコマースのプラットフォーム上に構築されたものの間でも、Eコマースのサイトの広いバリエーションを示しています。ここでは多くの詳細を説明しましたが、この分野ではもっと多くの分析が可能です。例えば、今年はアクセシビリティのスコアを取得していませんでした（それについての詳細はアクセシビリティの章をチェックアウトしてください）。同様に、これらのメトリクスを地域別にセグメント化することも興味深いことでしょう。この調査では、Eコマース・プラットフォームのホームページ上で246の広告プロバイダーが検出されました。さらなる調査（おそらく来年のWeb Almanacに掲載されるかもしれません）では、Eコマースプラットフォーム上で広告を表示しているサイトの割合を計算できます。この調査ではWooCommerceが非常に高い数値を記録していますので、来年の調査では一部のホスティングプロバイダーがWooCommerceをインストールしているにもかかわらず、有効にしていないために数値が膨らんでいるのではないかという興味深い統計を見ることができます。

CMS

序章

コンテンツ管理システム（CMS）とは、個人や組織がコンテンツを作成・管理・公開するためのシステムを総称しています。具体的には、オープンウェブを介して消費・体験できるコンテンツを作成・管理・公開することを目的としたシステムのことを指します。

各CMSは、ユーザーがコンテンツを中心に簡単かつ効果的にウェブサイトを構築できるように、幅広いコンテンツ管理機能とそれに対応するメカニズムのサブセットを実装しています。このようなコンテンツは多くの場合、何らかのデータベースに保存されており、ユーザーはコンテンツ戦略のために必要な場所であればどこでも再利用できる柔軟性を持っています。CMSはまた、ユーザーが必要に応じてコンテンツを簡単にアップロードして管理できるようにすることを目的とした管理機能を提供します。

サイト構築のためにCMSが提供するサポートの種類と範囲には大きなばらつきがあり、ユーザーコンテンツで「水増し」されたすぐに使えるテンプレートを提供するものもあれば、サイト構造の設計と構築にユーザーの関与を必要とするものもあります。

CMSについて考えるとき、ウェブ上にコンテンツを公開するためのプラットフォームを提供するシステムの実行可能性に関わるすべてのコンポーネントを考慮に入れる必要があります。これらのコンポーネントはすべて、CMSプラットフォームを取り巻くエコシステムを形成しており、ホスティングプロバイダ、拡張機能開発、開発代理、サイトビルダーなどが含まれています。このように、CMSというと、通常はプラットフォームそのものとそれを取り巻くエコシステムの両方を指すことになります。

コンテンツ制作者はなぜCMSを使うのか？

(ウェブの進化）時代の初期にはウェブのエコシステムはユーザーがウェブページのソースを見て、必要に応じてコピーペーストし画像などの個別の要素で新しいバージョンをカスタマイズするだけでクリエイターになれるという、単純な成長ループで動いていました。

ウェブが進化するにつれ、ウェブはより強力になる一方で、より複雑になりました。その結果、その単純な成長のループは破られ、誰でもクリエイターになれるような状況ではなくなってしまいました。コンテンツ制作の道を追求できる人にとっては、その道のりは険しく困難なものになってしまいました。ウェブでできることと実際にできることの差である利用可能性ギャップhttps://medinathoughts.com/2018/05/17/progressive-wordpress/は着実に拡大していきました。

図14.1の説明を表示

左側の1999年頃と書かれたラベルには2本の棒グラフがありますが、できることは、実際に行われていることに近いことを示しています。右側の2018年と書かれたものは、同じような棒グラフですが、できることの方がはるかに大きく、実際に行われていることの方がわずかに大きくなっています。できることと実際にできることのギャップが大きくなっています。

ここでCMSが果たす役割は、技術的な専門性の異なるユーザーがコンテンツ制作者としてウェブのエコシステムのループに入りやすくするという非常に重要なものです。コンテンツ制作への参入障壁を下げることで、ユーザーをクリエイターに変えることで、ウェブの成長ループを活性化させます。それが人気の理由です。

この章の目標

私たちはCMS空間とウェブの現在と未来におけるその役割を理解するための探求の中で、分析すべき多くの興味深い重要な側面があり、答えるべき質問があります。私たちはCMSプラットフォーム空間の広大さと複雑さを認識しており、そこにあるすべてのプラットフォームに関わるすべての側面を完全にカバーする全知全能の知識を主張しているわけではありませんが、私たちはこの空間への魅力を主張しこの空間の主要なプレイヤーのいくつかについて深い専門知識を持っています。

この章では広大なCMSの空間の表面領域のスクラッチを試み、CMSエコシステムの現状とコンテンツがウェブ上でどのように消費され、どのように体験されるかについてのユーザーの認識を形成する上でのCMSの役割について私たちの全体的な理解に光を当てようとしています。私たちの目標はCMSの状況を網羅的に見ることではなく、CMSの状況全般に関連するいくつかの側面と、これらのシステムによって生成されたウェブページの特徴について論じていきたいと思います。このWeb Almanacの初版はベースラインを確立するものであり、将来的には、トレンド分析のためにこのバージョンとデータを比較できるようになるでしょう。

CMS導入

今日では、ウェブページの40％以上が何らかのCMSプラットフォームを利用していることがわかります。40.01％がモバイル用で、39.61％がデスクトップ用です。

他にもW3Techshttps://w3techs.com/technologies/history_overview/content_managementのようにCMSプラットフォームの市場シェアを追跡しているデータセットがあり、CMSプラットフォームを利用したウェブページの割合が50％を超えていることを反映しています。さらに、これらのデータはCMSプラットフォームが成長しており、場合によっては前年比12％の成長率を記録しています。弊社の分析とW3Techの分析との乖離は、調査方法の違いによって説明できるかもしれません。我々の分析については、方法論のページを参照してください。

要するに、多くのCMSプラットフォームが存在するということです。下の写真は、CMSの風景を縮小したものです。

図14.3の説明を表示

WordPress、Drupal、WixなどのトップCMSプロバイダーのロゴマーク。

その中には、オープンソース（WordPress、Drupalなど）のものもあれば、有償（AEMなど）のものもあります。CMSプラットフォームの中には「無料」のホスティングプランやセルフホスティングプランで利用できるものもありますし、企業レベルでも、より高い階層のプランで利用できる高度なオプションもあります。CMS空間全体として複雑で連携したCMSエコシステムの世界であり、全てが分離され、同時にウェブの広大な構造に絡み合っています。

またCMSプラットフォームを利用したウェブサイトが何億もあり、これらのプラットフォームを利用してウェブにアクセスし、コンテンツを消費するユーザーが桁違いに増えていることを意味しています。このように、これらのプラットフォームは、常緑で健康的で活力に満ちたウェブを目指す私たちの集団的な探求を成功させるために重要な役割を果たしています。

CMSの風景

今日のウェブの大部分は、ある種のCMSプラットフォームを利用しています。この現実を反映して、さまざまな組織が収集した統計となります。Chrome UXレポート(CrUX)とHTTP Archiveのデータセットを見ると、データセットの特殊性を反映して定量的には記載されている割合は異なるかもしれませんが、他の場所で発表されている統計と一致している図が得られます。

デスクトップとモバイルデバイスで提供されているウェブページを見てみると、何らかのCMSプラットフォームによって生成されたページとそうでないページの割合が約60-40％に分かれていることがわかります。

図14.4の説明を表示

デスクトップサイトの40％、モバイルサイトの40％がCMSを使用して構築されていることを示す棒グラフ。

CMSを搭載したウェブページは、利用可能なCMSプラットフォームの大規模なセットによって生成されます。そのようなプラットフォームの中から選択するには多くのものがあり、1つを使用することを決定する際に考慮できる多くの要因があり、以下のようなものがあります。

• コア機能
• 作成・編集のワークフローと体験
• 参入障壁
• カスタマイズ性
• コミュニティ
• 他にもたくさん

CrUXとHTTP Archiveのデータセットには、約103のCMSプラットフォームが、混在したウェブページが含まれています。これらのプラットフォームのほとんどは、相対的な市場シェアが非常に小さいものです。今回の分析では、データに反映されているウェブ上でのフットプリントという観点から、上位のCMSプラットフォームに焦点を当ててみたいと思います。完全な分析については、この章の結果のスプレッドシートを参照してくださいhttps://docs.google.com/spreadsheets/d/1FDYe6QdoY3UtXodE2estTdwMsTG-hHNrOe9wEYLlwAw/edit#gid=0。

図14.5の説明を表示

WordPressがCMSサイト全体の75％を占めていることを示す棒グラフ。次に大きなCMSであるDrupalは、CMS市場の約6%のシェアを持っています。残りのCMSは急速に採用率が1%未満に縮小しています。

データセットに含まれる最も顕著なCMSプラットフォームを図14.5に示す。WordPressはモバイルサイトの74.19%、デスクトップサイトの73.47% を占めています。CMSの世界におけるWordPressの優位性は、後述するいくつかの要因に起因していますが、WordPressは主要なプレイヤーです。DrupalやJoomlaのようなオープンソースのプラットフォームと、SquarespaceやWixのようなクローズドなSaaSが上位5つのCMSを占めています。これらのプラットフォームの多様性は、多くのプラットフォームからなるCMSエコシステムを物語っています。また、興味深いのは、上位20位までの小規模CMSプラットフォームのロングテールです。企業向けに提供されているものから、業界特有の用途のために社内で開発された独自のアプリケーションまで、コンテンツ管理システムは、グループがウェブ上で管理、公開、ビジネスを行うためのカスタマイズ可能なインフラストラクチャを提供しています。

WordPressプロジェクトhttps://ja.wordpress.org/about/は、そのミッションを「出版の民主化」と定義しています。その主な目標のいくつかは、使いやすさと、誰もがウェブ上でコンテンツを作成できるようにソフトウェアを無料で利用できるようにすることです。もう1つの大きな要素は、このプロジェクトが育んでいる包括的なコミュニティです。世界のほとんどの大都市ではWordPressプラットフォームを理解し、構築しようと定期的に集まり、つながりを持ち共有し、コードを書く人々のグループを見つけることができます。地域のミートアップや年次イベントに参加したり、ウェブベースのチャンネルに参加したりすることは、WordPressの貢献者、専門家、ビジネス、愛好家がそのグローバルなコミュニティに参加する方法の一部となっています。

WordPressの人気は参入障壁の低さと、ユーザー（オンラインと対面）がプラットフォーム上でのパブリッシングをサポートし、拡張機能（プラグイン）やテーマを開発するためのリソースが要因となっています。またWordPressのプラグインやテーマは、ウェブデザインや機能性を追求した実装の複雑さを軽減してくれるので、利用しやすく経済的です。これらの側面が、新規参入者によるリーチと採用を促進するだけでなく、長期的な使用を維持しています。

オープンソースのWordPressプラットフォームは、ボランティア、WordPress Foundation、そしてウェブエコシステムの主要なプレイヤーによって運営されサポートされています。これらの要素を考慮すると、WordPressを主要なCMSとすることは理にかなっています。

CMSを搭載したサイトはどのように構築されているのか

それぞれのCMSプラットフォームのニュアンスや特殊性とは無関係に、最終的な目標は、オープンウェブの広大なリーチを介してユーザーに提供するウェブページを出力することにあります。CMSを搭載したウェブページとそうでないウェブページの違いは、前者では最終的な結果の構築方法のほとんどをCMSプラットフォームが決定するのに対し後者ではそのような抽象化された層がなく、すべての決定は開発者が直接またはライブラリの設定を介して行うという点にあります。

このセクションでは、CMS空間の現状を出力の特徴（使用された総リソース、画像統計など）の観点から簡単に見ていき、ウェブエコシステム全体とどのように比較するかを見ていきます。

リソースの総使用量

どんなWebサイトでも、その構成要素がCMSサイトを作っています。HTML、CSS、JavaScript、media（画像や動画）です。CMSプラットフォームは、これらのリソースを統合してWeb体験を作成するための強力に合理化された管理機能をユーザーに提供します。これは、これらのアプリケーションの最も包括的な側面の1つですが、より広いウェブに悪影響を及ぼす可能性があります。

図14.6の説明を表示

CMSページの重さの分布を示す棒グラフ。デスクトップCMSページの重さの中央値は2.3MBです。10パーセンタイルでは0.7MB、25パーセンタイルでは1.2MB、75パーセンタイルでは4.2MB、90パーセンタイルでは7.4MBとなっています。デスクトップの値は、モバイルよりもわずかに高くなっています。

図14.7の説明を表示

ページあたりのCMSリクエストの分布を示す棒グラフ。中央値のデスクトップCMSページは86リソースをロードします。10パーセンタイルでは39リソース、25パーセンタイルでは57リソース、75パーセンタイルでは127リソース、90パーセンタイルでは183リソースをロードします。デスクトップはモバイルよりも3～6リソースの僅差で一貫して高い。

上の図14.6と7では、デスクトップCMSページの中央値は86のリソースと2.29MBの重さをロードしていることがわかります。モバイルページのリソース使用量は、83のリソースと2.25 MBと、それほど大きくはありません。

中央値は、すべてのCMSページが上か下かの中間点を示しています。つまり全CMSページの半分はリクエスト数が少なく、重量が少ないのに対し、半分はリクエスト数が多く、重量が多いということになります。10パーセンタイルではモバイルとデスクトップのページはリクエスト数が40以下で重量が1MBですが、90パーセンタイルではリクエスト数が170以上で重量が7MBとなり、中央値の3倍近くになっています。

CMSのページは、ウェブ全体のページと比較してどうでしょうか？　ページ重量の章では、リソースの使用量についてのデータを見つけることができます。中央値では、デスクトップページは74リクエストで1.9MBを読み込み、ウェブ上のモバイルページは69リクエストで1.7MBを読み込みます。中央値では、CMSページはこれを上回っています。また、CMSページは90パーセンタイルでウェブ上のリソースを上回っていますが、その差はもっと小さいです。要するに、CMSページは最も重いページの1つと考えられます。

モバイルやデスクトップのCMSページにロードされるリソースの種類を詳しく見ると、画像や動画は、その重さの主な貢献者としてすぐに目立ちます。

影響は必ずしもリクエスト数と相関するわけではなく、個々のリクエストにどれだけのデータが関連付けられているかということです。例えば、中央値で2つのリクエストしかない動画リソースの場合、1MB以上の負荷がかかります。マルチメディア体験には、スクリプトを使用してインタラクティブ性を統合したり、機能やデータを提供したりすることもあります。モバイルページとデスクトップページの両方で、これらは3番目に重いリソースです。

CMSの経験がこれらのリソースで飽和状態にある中で、フロントエンドのウェブサイト訪問者に与える影響を考慮しなければなりません。さらに、モバイルとデスクトップのリソース使用量を比較すると、リクエストの量と重さにはほとんど差がありません。つまり、同じ量と重量のリソースがモバイルとデスクトップの両方のCMS体験を動かしていることになります。接続速度とモバイルデバイスの品質のばらつきは、もう一つの複雑さの層https://medinathoughts.com/2017/12/03/the-perils-of-mobile-web-performance-part-iii/を追加します。この章の後半では、CrUXのデータを使用して、CMS空間でのユーザー体験を評価します。

サードパーティのリソース

リソースの特定のサブセットを強調して、CMSの世界での影響を評価してみましょう。サードパーティリソースとは、送信先サイトのドメイン名やサーバーに属さないオリジンからのリソースです。画像、動画、スクリプト、その他のリソースタイプがあります。これらのリソースは、例えばiframeを埋め込むなど、組み合わせてパッケージ化されていることもあります。当社のデータによると、デスクトップとモバイルの両方で、サードパーティのリソースの中央値は近いことがわかります。

モバイルCMSページのサードパーティリクエストの中央値は15、重さ264.72KBでデスクトップCMSページのサードパーティリクエストの中央値は16、重さ271.56KBです。(これは「ホスティング」の一部とみなされる3Pリソースを除いたものであることに注意)。

図14.10の説明を表示

デスクトップとモバイルのCMSページにおけるサードパーティのキロバイトの分布を示すパーセンタイル10、25、50、75、90の棒グラフ。デスクトップのサードパーティ重量の中央値（50パーセンタイル）は272KB。10パーセンタイルは27KB、25位104KB、75位577KB、90位940KBとなっています。モバイルはパーセンタイルが小さい方がわずかに小さく、大きい方がわずかに大きくなっています。

図14.11の説明を表示

デスクトップとモバイル用のCMSページのサードパーティリクエストの分布を示すパーセンタイル10、25、50、75、90の棒グラフ。デスクトップのサードパーティリクエスト数の中央値（50パーセンタイル）は16。10パーセンタイルは3、25パーセンタイルは7、75パーセンタイルは31、90パーセンタイルは52です。デスクトップとモバイルでは、ほぼ同等の分布となっています。

中央値は、少なくとも半分のCMSウェブページが、ここで報告している値よりも多くのサードパーティのリソースを提供していることを示しています。90パーセンタイルではCMSページは約940KBで52のリソースを配信できますが、これはかなりの増加です。

サードパーティのリソースがリモートドメインやサーバーからのものであることを考えると、送信先のサイトは、これらのリソースの品質やパフォーマンスへの影響をほとんどコントロールできません。この予測不可能性が速度の変動につながり、ユーザー体験に影響を与える可能性があります。

画像の統計

図14.12の説明を表示

デスクトップとモバイルのCMSページの画像キロバイトの分布を示すパーセンタイル10、25、50、75、90の棒グラフ。デスクトップの画像重量の中央値（50パーセンタイル）は1,232KB。10パーセンタイルは198KB、25パーセンタイル507KB、75パーセンタイル2,763KB、90パーセンタイル5,694KBとなっています。デスクトップとモバイルでは、ほぼ同等の分布となっています。

先に図14.8と14.9を見て、画像はCMSページの総重量に大きく寄与していることを思い出してください。上記の図14.12と14.13は、デスクトップCMSページの中央値は31枚の画像とペイロードが1,232KBであるのに対し、モバイルCMSページの中央値は29枚の画像とペイロードが1,263KBであることを示しています。ここでも私たちは、デスクトップとモバイルの両方の経験のためのこれらのリソースの重量のための非常に近いマージンを持っています。ページ重量の章では、さらに、画像リソースがウェブ全体で同じ量の画像を持つページの重量の中央値を十分に上回っていることが示されています。その結果は以下の通りです。CMSページは重い画像を供給している。

モバイルやデスクトップのCMSページでよく見られるフォーマットは何ですか？　当社のデータによると、平均的にJPG画像が最も人気のある画像フォーマットです。次いでPNG、GIFが続き、SVG、ICO、WebPのようなフォーマットが2％強、1％強と大きく後れを取っています。

図14.14の説明を表示

デスクトップとモバイルのCMSページにおける画像フォーマットの採用状況の棒グラフ。JPEGが全体の半分近くを占め、PNGが3分の1、GIFが5分の1を占め、残りの5%はSVG、ICO、WebPで占められています。デスクトップとモバイルでは、ほぼ同等の採用率となっています。

おそらく、これらの画像タイプの一般的な使用例を考えると、このようなセグメンテーションは驚くべきものでありません。ロゴやアイコン用のSVGは、JPEGがユビキタスであるのと同様に一般的です。WebPはまだ比較的新しい最適化されたフォーマットであり、ブラウザの普及が進んでいますhttps://caniuse.com/#search=webp。これが今後数年の間にCMS空間での使用にどのような影響を与えるかを見るのは興味深いことでしょう。

CMSを搭載したウェブサイトのユーザー体験

ウェブコンテンツ制作者として成功するには、ユーザー体験がすべてです。リソースの使用量やウェブページの構成方法に関するその他の統計などの要因は、サイトを構築する際のベストプラクティスの観点から、サイトの品質を示す重要な指標となります。しかし私たちは最終的に、これらのプラットフォームで生成されたコンテンツを消費したり、利用したりする際にユーザーが実際にどのようにウェブを体験しているのかを明らかにしたいと考えています。

これを実現するために、CrUXデータセットに収録されているいくつかの利用者目線のパフォーマンス指標https://developers.google.com/web/fundamentals/performance/user-centric-performance-metricsに向けて分析を行います。これらのメトリクスは、人として私たちが時間をどのように感じるかhttps://paulbakaus.com/tutorials/performance/the-illusion-of-speed/に何らかの形で関連しています。

0.1秒（100ミリ秒）以内に起こることは、私たちにとっては事実上瞬時に起こっていることです。そして、数秒以上の時間がかかる場合、私たちはそれ以上待たずに生活を続ける可能性が非常に高くなります。これは、ウェブでの持続的な成功を目指すコンテンツ制作者にとって非常に重要なことです。なぜならユーザーを獲得し、魅了し、ユーザーベースを維持したいのであればサイトの読み込み速度がどれだけ速くなければならないかを教えてくれるからです。

このセクションでは、ユーザーがCMSを搭載したウェブページをどのように体験しているのかを理解するために、3つの重要な次元を見てみましょう。

• コンテンツの初回ペイント (FCP)
• 入力の推定待ち時間 (FID)
• Lighthouseスコア

コンテンツの初回ペイント

コンテンツの初回ペイントhttps://developers.google.com/web/tools/lighthouse/audits/first-contentful-paint は、ナビゲーションからテキストや画像などのコンテンツが最初に表示されるまでの時間を測定します。成功したFCPの経験、つまり「速い」と認定される経験とは、ウェブサイトの読み込みが正常に行われていることをユーザーへ保証するため、DOM内の要素がどれだけ速くロードされるかということです。FCPのスコアが良ければ対応するサイトが良いUXを提供していることを保証するものではありませんが、FCPが悪ければ、ほぼ確実にその逆を保証することになります。

図14.16の説明を表示

CMSごとのFCP経験値の平均分布を棒グラフにしたもの。以下の図14.17を参照して、上位5つのCMSデータ表を作成した。

CMSの世界におけるFCPの傾向は、ほとんどが中程度の範囲にあります。CMSプラットフォームがデータベースからコンテンツを照会し、送信し、その後ブラウザでレンダリングする必要があるため、ユーザーが体験する遅延の一因となっている可能性があります。前のセクションで説明したリソース負荷も一役買っている可能性があります。さらに、これらのインスタンスの中には共有ホスティング上にあるものやパフォーマンスが最適化されていない環境もあり、これもブラウザ上での体験に影響を与える可能性があります。

WordPressはモバイルとデスクトップで、中程度のFCP体験と遅いFCP体験を示しています。Wixはクローズドなプラットフォームで中程度のFCP体験が強みです。企業向けオープンソースCMSプラットフォームであるTYPO3は、モバイルとデスクトップの両方で一貫して高速な体験を提供しています。TYPO3は、フロントエンドに組み込まれたパフォーマンスとスケーラビリティ機能がウェブサイトの訪問者にプラスの影響を与える可能性があると宣伝しています。

入力の推定待ち時間

入力の推定待ち時間https://developers.google.com/web/updates/2018/05/first-input-delay (FID) は、ユーザーが最初にサイトとやり取りをした時（リンクをクリックした時、ボタンをタップした時、カスタムのJavaScriptを使用したコントロールを使用した時など）から、ブラウザが実際にそのやり取りへ応答できるようになるまでの時間を測定します。ユーザーの視点から見た「速い」FIDとは、サイト上でのアクションからの即時フィードバックであり、停滞した体験ではありません。この遅延(痛いところ)は、ユーザーがサイトと対話しようとしたときに、サイトの読み込みの他の側面からの干渉と相関する可能性があります。

CMS領域のFIDは一般的に、デスクトップとモバイルの両方で平均的に高速なエクスペリエンスを提供する傾向にある。しかし、注目すべきは、モバイルとデスクトップの体験の間に大きな違いがあることです。

図14.18の説明を表示

CMSごとのFCP経験値の平均分布を棒グラフにしたもの。上位5つのCMSデータ表については、下記の図19を参照のこと。

この差はFCPのデータにも見られますが、FIDではパフォーマンスに大きなギャップが見られます。例えば、Joomlaのモバイルとデスクトップの高速FCP体験の差は約12.78％ですが、FIDの体験では27.76％と大きな差があります。モバイルデバイスと接続品質が、ここで見られるパフォーマンスの格差に一役買っている可能性があります。以前に強調したように、ウェブサイトのデスクトップ版とモバイル版に出荷されるリソースにはわずかな差があります。モバイル（インタラクティブ）体験のための最適化は、これらの結果から明らかになります。

Lighthouseスコア

Lighthouse は、開発者がWebサイトの品質を評価して改善するのに役立つように設計された、オープンソースの自動化ツールです。このツールの重要な側面の1つは、パフォーマンス、アクセシビリティ、プログレッシブなWebアプリなどの観点からWebサイトの状態を評価するための監査のセットを提供することです。この章の目的のために、2つの特定の監査カテゴリに興味を持っています。PWAとアクセシビリティです。

PWA

プログレッシブウェブアプリ (PWA)という用語は、信頼できるhttps://developers.google.com/web/progressive-web-apps#reliable、速いhttps://developers.google.com/web/progressive-web-apps#fast、魅力的https://developers.google.com/web/progressive-web-apps#engagingとみなされるウェブベースのユーザー体験を指します。Lighthouseは、0（最悪）から1（最高）の間のPWAスコアを返す一連の監査を提供しています。これらの監査は、14の要件をリストアップしたベースラインPWAチェックリストhttps://developers.google.com/web/progressive-web-apps/checklist#baselineに基づいています。Lighthouseは、14の要件のうち11の要件について自動監査を実施しています。残りの3つは手動でしかテストできません。11の自動PWA監査はそれぞれ均等に重み付けされているため、それぞれがPWAスコアに約9ポイント寄与します。

図14.20の説明を表示

全CMSページのLighthouse PWAカテゴリスコアの分布を示す棒グラフです。最も一般的なスコアは0.3で、CMSページの22%です。この分布には他にも2つのピークがあります。スコアが0.15のページが11％、スコアが0.56のページが8％です。0.6以上のスコアを取得しているページは1%未満です。

図14.21の説明を表示

CMSごとのLighthouse PWAスコアの中央値を示す棒グラフ。WordPressサイトのスコア中央値は0.33です。次の5つのCMS（Joomla、Drupal、Wix、Squarespace、1C-Bitrix）のスコア中央値はすべて0.3です。PWAのスコアがトップのCMSは、Jimdoが0.56、TYPO3が0.41となっています。

アクセシビリティ

アクセシブルなウェブサイトとは、障害者が利用できるように設計・開発されたサイトのことです。Lighthouseは、一連のアクセシビリティ監査を提供し、それらすべての監査の加重平均を返します（各監査の加重方法の完全なリストについては、スコアリングの詳細https://docs.google.com/spreadsheets/d/1Cxzhy5ecqJCucdf1M0iOzM8mIxNc7mmx107o5nj38Eo/edit#gid=1567011065を参照してください）。

各アクセシビリティ監査は合格か、不合格かですが他のLighthouseの監査とは異なり、アクセシビリティ監査に部分的に合格してもページはポイントをもらえません。例えば、いくつかの要素がスクリーンリーダーに優しい名前を持っていて他の要素がそうでない場合、そのページはscreenreader-friendly-names監査で0点を獲得します。

図14.22の説明を表示

CMSページのLighthouseアクセシビリティスコアの分布を示す棒グラフ。この分布は、約0.85のモードで、高いスコアに大きく傾いています。

図14.23の説明を表示

CMSごとのLighthouseアクセシビリティカテゴリスコアの中央値を示す棒グラフ。ほとんどのCMSのスコアは約0.75です。注目すべき例外としては、Wixのスコア中央値が0.93、1C-Bitrixのスコアが0.65のものがあります。

現在、モバイルCMSのホームページで100％のパーフェクトスコアを獲得しているのは1.27％しかありません。上位のCMSの中では、Wixがモバイルページのアクセシビリティスコアの中央値が最も高く、トップに立っています。全体的に見て、これらの数字は、私たちの人口のかなりの部分がアクセスできないウェブサイトはどれだけ多いか（CMSによって駆動されているウェブのどれだけの部分か）を考えると悲惨なものとなります。デジタル体験が私たちの生活の多くの側面に影響を与えるのと同様に、この数字は私たちに 最初からアクセシブルなウェブ体験を構築すること を奨励し、ウェブを包括的な空間にする作業を継続するための指令であるべきです。

CMSイノベーション

ここまでCMSエコシステムの現状をスナップショットで紹介してきましたが、この分野は進化しています。パフォーマンスとユーザー体験の欠点に対処するため、実験的なフレームワークがCMSインフラストラクチャに統合されているのを目の当たりにしています。React.jsやGatsby.js、Next.jsなどの派生フレームワーク、Vue.jsの派生フレームワークであるNuxt.jsなどのライブラリやフレームワークが少しずつ採用されてきています。

また、ホスティングプロバイダーや代理店が企業の顧客に焦点を当てた戦略のためのツールボックスとして、CMSやその他の統合技術を使用した総合的なソリューションとしてデジタルエクスペリエンスプラットフォーム（DXP）を提供しているのも見受けられます。これらのイノベーションは、ユーザー（とそのエンドユーザー）がこれらのプラットフォームのコンテンツを作成し、消費する際に最高のUXを得ることを可能にするターンキーのCMSベースのソリューションを作成するための努力を示しています。目的は、デフォルトでの優れたパフォーマンス、豊富な機能、優れたホスティング環境です。

結論

CMS空間は最も重要な意味を持っています。これらのアプリケーションが力を発揮するウェブの大部分と様々なデバイスや接続でページを作成し、それに遭遇するユーザーの数は、些細なことであってはなりません。この章やこのWeb Almanacに掲載されている他の章が、この空間をより良いものにするためのより多くの研究と技術革新を促してくれることを願っています。深い調査を行うことで、これらのプラットフォームがウェブ全体に提供する強み、弱み、機会について、より良いコンテキストを提供できます。コンテンツ管理システムは、オープン・ウェブの完全性を維持するために影響を与えることができます。コンテンツ管理システムを前進させていきましょう！

圧縮

序章

HTTP圧縮は、元の表現よりも少ないビットを使用して情報をエンコードできる技術です。 Webコンテンツの配信に使用すると、Webサーバーはクライアントに送信されるデータ量を削減できます。これにより、クライアントの利用可能な帯域幅の効率が向上し、ページの重さが軽減され、Webパフォーマンスが向上します。

圧縮アルゴリズムは、多くの場合、非可逆または可逆に分類されます。

• 非可逆圧縮アルゴリズムが使用される場合、プロセスは不可逆的であり、元のファイルを圧縮解除しても復元できません。これは一般に、一部のデータを失ってもリソースに重大な影響を与えない画像やビデオコンテンツなどのメディアリソースを圧縮するために使用されます。
• ロスレス圧縮は完全に可逆的なプロセスであり、HTML、JavaScript、CSSなどのテキストベースのリソースを圧縮するために一般的に使用されます。

この章では、テキストベースのコンテンツがWeb上でどのように圧縮されるかを検討します。非テキストベースのコンテンツの分析は、メディアの章の一部を形成します。

HTTP圧縮の仕組み

クライアントがHTTPリクエストを作成する場合、多くの場合、デコード可能な圧縮アルゴリズムを示すAccept-Encodingヘッダーが含まれます。サーバーは、示されたエンコードのいずれかを選択してサポートし、圧縮されたレスポンスを提供できます。圧縮されたレスポンスにはContent-Encodingヘッダーが含まれるため、クライアントはどの圧縮が使用されたかを認識できます。また、提供されるリソースのMIMEhttps://developer.mozilla.org/docs/Web/HTTP/Basics_of_HTTP/MIME_typesタイプを示すために、Content-Typeヘッダーがよく使用されます。

以下の例では、クライアントはGzip、Brotli、およびDeflate圧縮のサポートを示してます。サーバーは、text/htmlドキュメントを含むGzip圧縮された応答を返すことにしました。

    > GET / HTTP/1.1
    > Host: httparchive.org
    > Accept-Encoding: gzip, deflate, br

    < HTTP/1.1 200
    < Content-type: text/html; charset=utf-8
    < Content-encoding: gzip

HTTP Archiveには、530万のWebサイトの測定値が含まれており、各サイトには少なくとも1つの圧縮テキストリソースがホームページにロードされています。さらに、リソースはWebサイトの81％のプライマリドメインで圧縮されました。

圧縮アルゴリズム

IANAは、Accept-EncodingおよびContent-Encodingヘッダーで使用できる有効なHTTPコンテンツエンコーディングのリストhttps://www.iana.org/assignments/http-parameters/http-parameters.xml#content-codingを保持しています。これらには、gzip、deflate、br（Brotli）などが含まれます。これらのアルゴリズムの簡単な説明を以下に示します。

• Gziphttps://tools.ietf.org/html/rfc1952は、LZ77https://ja.wikipedia.org/wiki/LZ77およびハフマンコーディングhttps://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%95%E3%83%9E%E3%83%B3%E7%AC%A6%E5%8F%B7圧縮技術を使用しており、Web自体よりも古い。もともと1992年にUNIX gzipプログラム用として開発されました。HTTP/ 1.1以降、Web配信の実装が存在し、ほとんどのブラウザーとクライアントがそれをサポートしています。
• Deflatehttps://tools.ietf.org/html/rfc1951はGzipと同じアルゴリズムを使用しますが、コンテナは異なります。一部のサーバーおよびブラウザとの互換性の問題のため、Webでの使用は広く採用されていません。
• Brotlihttps://tools.ietf.org/html/rfc7932は、Googleが発明https://github.com/google/brotliした新しい圧縮アルゴリズムです。 LZ77アルゴリズムの最新のバリアント、ハフマンコーディング、および2次コンテキストモデリングの組み合わせを使用します。 Brotliを介した圧縮はGzipと比較して計算コストが高くなりますが、アルゴリズムはGzip圧縮よりもファイルを15〜25％https://cran.r-project.org/web/packages/brotli/vignettes/brotli-2015-09-22.pdf削減できます。 Brotliは2015年にWebコンテンツの圧縮に初めて使用され、すべての最新のWebブラウザーでサポートされていますhttps://caniuse.com/#feat=brotli。

HTTPレスポンスの約38％はテキストベースの圧縮で配信されます。これは驚くべき統計のように思えるかもしれませんが、データセット内のすべてのHTTP要求に基づいていることに留意してください。画像などの一部のコンテンツは、これらの圧縮アルゴリズムの恩恵を受けません。次の表は、各コンテンツエンコーディングで処理されるリクエストの割合をまとめたものです。

圧縮されて提供されるリソースの大半は、Gzip（80％）またはBrotli（20％）のいずれかを使用しています。他の圧縮アルゴリズムはあまり使用されません。

図15.2の説明を表示

図15.1のデータテーブルの円グラフ。

さらに「none」「UTF-8」「base64」「text」など、無効なContent-Encodingを返す67Kのリクエストがあります。これらのリソースは圧縮されていない状態で提供される可能性があります。

HTTP Archiveによって収集された診断から圧縮レベルを判断することはできませんが、コンテンツを圧縮するためのベストプラクティスは次のとおりです。

• 少なくとも、テキストベースのアセットに対してGzip圧縮レベル6を有効にします。これは、計算コストと圧縮率の間の公平なトレードオフを提供し、多くのWebサーバーのデフォルトhttps://paulcalvano.com/index.php/2018/07/25/brotli-compression-how-much-will-it-reduce-your-content/にもかかわらず、Nginxは依然として低すぎることが多いレベル1のままですhttp://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_comp_level。
• Brotliおよびprecompressリソースをサポートできる場合は、Brotliレベル11に圧縮します。これはGzipよりも計算コストが高くなります。したがって、遅延を避けるためには、事前圧縮が絶対に必要です。
• Brotliをサポートでき、事前圧縮できない場合は、Brotliレベル5に圧縮します。このレベルでは、Gzipと比較してペイロードが小さくなり、同様の計算オーバーヘッドが発生します。

どの種類のコンテンツを圧縮していますか？

ほとんどのテキストベースのリソース（HTML、CSS、JavaScriptなど）は、GzipまたはBrotli圧縮の恩恵を受けることができます。ただし、多くの場合、これらの圧縮技術をバイナリリソースで使用する必要はありません。画像、ビデオ、一部のWebフォントなどが既に圧縮されているため。

次のグラフでは、上位25のコンテンツタイプが、リクエストの相対数を表すボックスサイズで表示されています。各ボックスの色は、これらのリソースのうちどれだけ圧縮されて提供されたかを表します。ほとんどのメディアコンテンツはオレンジ色で網掛けされていますが、これはGzipとBrotliにはほとんどまたはまったく利点がないためです。テキストコンテンツのほとんどは、それらが圧縮されていることを示すために青色で網掛けされています。ただし、一部のコンテンツタイプの水色の網掛けは、他のコンテンツタイプほど一貫して圧縮されていないことを示しています。

図15.3の説明を表示

image/jpeg（167,912,373リクエスト-3.23％圧縮）、application/javascript（121,058,259リクエスト-81.29％圧縮）、image/png（113,530,400リクエスト-3.81％圧縮）、text/css（86,634,570リクエスト-81.81％圧縮）を示すツリーマップグラフ、text/html（81,975,252リクエスト-43.44％圧縮）、image/gif（70,838,761リクエスト-3.87％圧縮）、text/javascript（60,645,767リクエスト-89.52％圧縮）、application/x-javascript（38,816,387リクエスト-91.02％圧縮） 、font/woff2（22,622,918リクエスト-3.87％圧縮）、application/json（16,501,326リクエスト-59.02％圧縮）、image/webp（12,911,688リクエスト-1.66％圧縮）、image/svg + xml（9,862,643リクエスト-64.42％圧縮） 、text/plain（6,622,361リクエスト-24.72％圧縮）、application/octet-stream（3,884,287リクエスト-6.01％圧縮）、image/x-icon（3,737,030リクエスト-37.60％圧縮）、application/font-woff2（3,061,857リクエスト- 5.90％圧縮）、application/font-woff（2,117,999リクエスト-23.61％圧縮） d）、image/vnd.microsoft.icon（1,774,995リクエスト-15.55％圧縮）、video/mp4（1,472,880リクエスト-0.03％圧縮）、font/woff（1,255,093リクエスト-24.33％圧縮）、font/ttf（1,062,747リクエスト- 84.27％圧縮）、application/x-font-woff（1,048,398リクエスト-30.77％圧縮）、image/jpg（951,610リクエスト-6.66％圧縮）、application/ocsp-response（883,603リクエスト-0.00％圧縮）。

最も人気のある8つのコンテンツタイプを除外すると、これらのコンテンツタイプの残りの圧縮統計をより明確に確認できます。

図15.4の説明を表示

font/woff2（22,622,918リクエスト-3.87％圧縮）、application/json（16,501,326リクエスト-59.02％圧縮）、image/webp（12,911,688リクエスト-1.66％圧縮）、image/svg + xml（9,862,643リクエスト-64.42％）を示すツリーマップグラフ圧縮）、text/plain（6,622,361リクエスト-24.72％圧縮）、application/octet-stream（3,884,287リクエスト-6.01％圧縮）、image/x-icon（3,737,030リクエスト-37.60％圧縮）、application/font-woff2（3,061,857リクエスト-5.90％圧縮）、application/font-woff（2,117,999リクエスト-23.61％圧縮）、image/vnd.microsoft.icon（1,774,995リクエスト-15.55％圧縮）、video/mp4（1,472,880リクエスト-0.03％圧縮）、フォント/ woff（1,255,093リクエスト-24.33％圧縮）、font/ttf（1,062,747リクエスト-84.27％圧縮）、application/x-font-woff（1,048,398リクエスト-30.77％圧縮）、image/jpg（951,610リクエスト-6.66％圧縮） 、application/ocsp-response（883,603リクエスト-0.00％圧縮）

application/jsonおよびimage/svg+xmlコンテンツタイプは、65％未満の時間で圧縮されます。

カスタムWebフォントのほとんどは、すでに圧縮形式になっているため、圧縮せずに提供されます。ただし、font/ttfは圧縮可能ですが、TTFフォント要求の84％のみが圧縮で提供されているため、ここにはまだ改善の余地があります。

以下のグラフは、各コンテンツタイプに使用される圧縮技術の内訳を示しています。上位3つのコンテンツタイプを見ると、デスクトップとモバイルの両方で、最も頻繁に要求されるコンテンツタイプの圧縮に大きなギャップがあります。 text/htmlの56％とapplication/javascriptおよびtext/cssリソースの18％は圧縮されていません。これにより、パフォーマンスが大幅に向上します。

図15.5の説明を表示

application/javascriptを示す積み上げ棒グラフは、圧縮タイプ（Gzip/Brotli/None）別で3618万/897万/1047万、text/cssは24.29M/8.31M/7.20M、text/htmlは11.37M/4.89M/20.57Mです。text/javascriptは23.21M/1.72M/3.03M、application/x-javascriptは11.86M/4.97M/1.66M、application/jsonは4.06M/0.50M/3.23M、image/svg+xmlは2.54M/0.46M/1.74M、text/plainは0.71M/0.06M/2.42M、image/x-iconは0.58M/0.10M/1.11Mです。Deflateはいつでもほとんど使用されず、登録されません。チャート上。。

図15.6の説明を表示

application/javascriptを示す積み上げ棒グラフは、圧縮タイプ（Gzip/Brotli/None）で4307万/1017万/1219万、text/cssは28.3M/9.91M/8.56M、text/htmlは13.86M/5.48M/25.79Mです。text/javascriptは27.41M/1.94M/3.33M、application/x-javascriptは12.77M/5.70M/1.82M、application/jsonは4.67M/0.50M/3.53M、image/svg + xmlは2.91M/0.44M/1.77M、text/plainは0.80M/0.06M/1.77M、image/x-iconは0.62M/0.11M/1.22Mです。デフレートはいつでもほとんど使用されず、チャートに登録されません。

圧縮率が最も低いコンテンツタイプには、application/json、text/xml、およびtext/plainが含まれます。これらのリソースは通常、XHRリクエストに使用され、Webアプリケーションが豊かな体験を創造するために使用できるデータを提供します。それらを圧縮すると、ユーザー体験は向上する可能性があります。 image/svg+xmlやimage/x-iconなどのベクターグラフィックスは、テキストベースと見なされることはあまりありませんが、これらを使用するサイトは圧縮の恩恵を受けるでしょう。

図15.7の説明を表示

圧縮タイプ（Gzip/Brotli/None）別にapplication/javascriptが65.1％/16.1％/18.8％、text/cssが61.0％/20.9％/18.1％、text/htmlが30.9％/13.3％/55.8％を示す積み上げ棒グラフ、text/javascriptは83.0％/6.1％/10.8％、application/x-javascriptは64.1％/26.9％/9.0％、application/jsonは52.1％/6.4％/41.4％、image/svg+xmlは53.5％/9.8％/36.7％、text/plainは22.2％/2.0％/75.8％、image/x-iconは32.6％/5.3％/62.1％です。デフレートはいつでもほとんど使用されず、チャートに登録されません。

図15.8の説明を表示

圧縮タイプ（Gzip/Brotli/None）別にapplication/javascriptが65.8％/15.5％/18.6％である積み上げ棒グラフ、text/cssは60.5％/21.2％/18.3％、text/htmlは30.7％/12.1％/57.1％、text/javascriptは83.9％/5.9％/10.2％、application/x-javascriptは62.9％/28.1％/9.0％、application/jsonは53.6％/8.6％/34.6％、image/svg+xmlは23.4％/1.8％/74.8％、text/plainは23.4％/1.8％/74.8％、image/x-iconは31.8％/5.5％/62.7％です。デフレートはいつでもほとんど使用されず、チャートに登録されません。

すべてのコンテンツタイプで、Gzipは最も一般的な圧縮アルゴリズムです。新しいBrotli圧縮はあまり頻繁に使用されず、最も多く表示されるコンテンツタイプはapplication/javascript、text/css、application/x-javascriptです。これは、CDNが通過するトラフィックにBrotli圧縮を自動的に適用することの原因である可能性があります。

ファーストパーティとサードパーティの圧縮

サードパーティの章では、サードパーティとパフォーマンスへの影響について学びました。ファーストパーティとサードパーティの圧縮技術を比較すると、サードパーティのコンテンツはファーストパーティのコンテンツよりも圧縮される傾向であることがわかります。

さらに、サードパーティのコンテンツの場合、Brotli圧縮の割合が高くなります。これは、GoogleやFacebookなど、通常Brotliをサポートする大規模なサードパーティから提供されるリソースの数が原因である可能性と考えられます。

圧縮の機会を見分ける

GoogleのLighthousehttps://developers.google.com/web/tools/lighthouseツールを使用すると、ユーザーはWebページに対して一連の監査を実行できます。テキスト圧縮監査https://developers.google.com/web/tools/lighthouse/audits/text-compressionは、サイトが追加のテキストベースの圧縮の恩恵を受けることができるかどうかを評価します。これは、リソースを圧縮し、オブジェクトのサイズを少なくとも10％と1,400バイト削減できるかどうかを評価することでこれを行います。スコアに応じて、圧縮可能な特定のリソースのリストとともに、結果に圧縮の推奨事項を表示する場合があります。

図15.10の説明を表示

リソースのリスト（名前は編集済み）およびサイズと節約の可能性を示すLighthouseレポートのスクリーンショット。最初の項目では、91KBから73KBに大幅に節約できる可能性がありますが、6KB以下の他の小さなファイルでは、4KBから1KBの小さい節約になります。

各モバイルページに対してHTTP ArchiveはLighthouse監査を実行するため、すべてのサイトのスコアを集計して、より多くのコンテンツを圧縮する機会があるかどうかを知ることができます。全体として、ウェブサイトの62％がこの監査に合格しており、ウェブサイトのほぼ23％が40を下回っています。これは、120万を超えるウェブサイトが追加のテキストベースの圧縮を有効にすることを意味します。

図15.11の説明を表示

7.6％の圧縮が10％未満であり、13.2％のサイトが10-39％のスコア、13.7％のサイトが40-79％のスコア、2.9％のサイトが80-99％のスコア、62.5％のスコアを示す積み上げ棒グラフのサイトにはパスがあり、100％を超えるテキストアセットが圧縮されています。

Lighthouseは、テキストベースの圧縮を有効にすることで、保存できるバイト数も示します。テキスト圧縮の恩恵を受ける可能性のあるサイトのうち、82％がページの重さを最大1MB削減できます！

図15.12の説明を表示

82.11％のサイトが1Mb未満、15.88％のサイトが1〜2Mbを、2％のサイトが3MB以上を節約できることを示す積み上げ棒グラフ。

結論

HTTP圧縮は、Webコンテンツのサイズを削減するために広く使用されている非常に貴重な機能です。 GzipとBrotliの両方の圧縮が使用される主要なアルゴリズムであり、圧縮されたコンテンツの量はコンテンツの種類によって異なります。 Lighthouseなどのツールは、コンテンツを圧縮する機会を発見するのに役立ちます。

多くのサイトがHTTP圧縮をうまく利用していますが、特にWebが構築されているtext/html形式については、まだ改善の余地があります！　同様に、font/ttf、application/json、text/xml、text/plain、image/svg+xml、image/x-iconのようなあまり理解されていないテキスト形式は、多くのWebサイトで見落とされる余分な構成を取る場合があります。

Webサイトは広くサポートされており、簡単に実装で処理のオーバーヘッドが低いため、少なくともすべてのテキストベースのリソースにGzip圧縮を使用する必要があります。 Brotli圧縮を使用するとさらに節約できますが、リソースを事前に圧縮できるかどうかに基づいて圧縮レベルを慎重に選択する必要があります。

キャッシング

導入

キャッシングは、以前にダウンロードしたコンテンツの再利用を可能にする手法です。コストのかかるネットワークリクエストを回避することにより、パフォーマンスが大幅に向上します。また、Webサイトのオリジンインフラストラクチャへのトラフィックを削減することで、アプリケーションの拡張にも役立ちます。「最速のリクエストはあなたがする必要のないものです」という古い格言があり、キャッシュはリクエストを行わなくて済むようにするための重要な方法の1つです。

Webコンテンツのキャッシュには、3つの基本原則があります。可能な限りキャッシュする、できる限りキャッシュする、エンドユーザーのできるだけ近くでキャッシュする。

可能な限りキャッシュする。 キャッシュできる量を検討する場合、レスポンスが静的か動的かを理解することが重要です。静的なレスポンスとして提供される要求は、リソースとそれを要求するユーザーとの間に1対多の関係があるため、通常はキャッシュ可能です。動的に生成されたコンテンツはより微妙である可能性があり、慎重に検討する必要があります。

できるだけ長くキャッシュする。リソースをキャッシュする時間の長さは、キャッシュされるコンテンツの機密性に大きく依存します。バージョン管理されたJavaScriptリソースは非常に長い時間キャッシュされる可能性がありますが、バージョン管理されていないリソースはユーザーが最新バージョンを取得できるように、より短いキャッシュ期間を必要とする場合があります。

エンドユーザーのできるだけ近くでキャッシュする。エンドユーザーの近くでコンテンツをキャッシュすると、待ち時間がなくなり、ダウンロード時間が短縮されます。たとえば、リソースがエンドユーザーのブラウザにキャッシュされている場合、リクエストはネットワークに送信されず、ダウンロード時間はマシンのI/Oと同じくらい高速です。初めての訪問者、またはキャッシュにエントリがない訪問者の場合、通常、キャッシュされたリソースが返される場所はCDNになります。ほとんどの場合、オリジンサーバーと比較して、ローカルキャッシュかCDNからリソースをフェッチする方が高速です。

通常、Webアーキテクチャには複数のキャッシュ層https://blog.yoav.ws/tale-of-four-caches/が含まれます。たとえば、HTTPリクエストは次の場所にキャッシュされる可能性があります。

• エンドユーザーのブラウザ
• ユーザーのブラウザーのService Workerキャッシュ
• 共有ゲートウェイ
• エンドユーザーに近い側でキャッシュする機能を提供するCDN
• バックエンドの仕事長を削減するための、アプリケーションの前のキャッシングプロキシ
• アプリケーション層とデータベース層

この章では、Webブラウザー内でリソースがキャッシュされる方法について見ていきましょう。

HTTPキャッシングの概要

HTTPクライアントがリソースをキャッシュするには、2つの情報を理解する必要があります。

• 「これをキャッシュできる期間はどれくらいですか？」
• 「コンテンツがまだ新しいことを検証するにはどうすればよいですか？」

Webブラウザーがクライアントにレスポンスを送信するとき、通常リソースにキャッシュ可能か、キャッシュする期間、リソースの古さを示すヘッダーが含まれます。 RFC 7234は、これをセクション4.2（新しさ）https://tools.ietf.org/html/rfc7234#section-4.2および4.3（検証）https://tools.ietf.org/html/rfc7234#section-4.3でより詳細にカバーしています。

通常、有効期間を伝えるために使用されるHTTPレスポンスヘッダーは次のとおりです。

• Cache-Control キャッシュの生存期間（つまり、有効期間）を設定できます。
• Expires 有効期限の日付または時刻を提供します（つまり、期限切れになるとき）。

Cache-Control 両方が存在する場合に優先されます。これらについては、以下で詳しく説明します。

キャッシュ内に保存された応答を検証するためのHTTPレスポンスヘッダー、つまりサーバー側で比較するため、条件付き要求を提供するHTTPレスポンスヘッダーは次のとおりです。

• Last-Modified オブジェクトが最後に変更された日時を示します。
• エンティティタグ (ETag) コンテンツの一意の識別子を提供します。

ETag 両方が存在する場合に優先されます。これらについては、以下で詳しく説明します。

以下の例には、HTTP Archiveのmain.jsファイルからのリクエスト/レスポンスヘッダーの抜粋が含まれています。これらのヘッダーは、リソースを43,200秒（12時間）キャッシュでき、最後は2か月以上前に変更されたことを示します（Last-ModifiedヘッダーとDateヘッダーの違い）。

> GET /static/js/main.js HTTP/1.1
> Host: httparchive.org
> User-agent: curl/7.54.0
> Accept: */*

< HTTP/1.1 200
< Date: Sun, 13 Oct 2019 19:36:57 GMT
< Content-Type: application/javascript; charset=utf-8
< Content-Length: 3052
< Vary: Accept-Encoding
< Server: gunicorn/19.7.1
< Last-Modified: Sun, 25 Aug 2019 16:00:30 GMT
< Cache-Control: public, max-age=43200
< Expires: Mon, 14 Oct 2019 07:36:57 GMT
< ETag: "1566748830.0-3052-3932359948"

RedBot.orghttps://redbot.org/というツールにURLを入力すると、レスポンスのヘッダーを元としたキャッシュ方法の詳細な説明が表示できます。たとえば、上記のURLのテストhttps://redbot.org/?uri=https%3A%2F%2Fhttparchive.org%2Fstatic%2Fjs%2Fmain.jsは次のような内容を出力します。

図16.1の説明を表示

リソースがいつ変更されたか、キャッシュがそれを保存できるかどうか、リソースが新鮮であると見なされる期間、および警告に関する詳細情報を示すRedbotの応答例。

レスポンスにキャッシュヘッダーが存在しない場合、クライアントはレスポンスをヒューリスティクスにキャッシュできますhttps://paulcalvano.com/index.php/2018/03/14/http-heuristic-caching-missing-cache-control-and-expires-headers-explained/。ほとんどのクライアントは、RFCの推奨ヒューリスティックバリエーションを実装します。これは、Last-Modifiedから経過した時間の10％です。ただし、レスポンスを無期限にキャッシュする可能性もあります。そのため、特定のキャッシュルールを設定して、キャッシュ可能性を確実に制御することが重要です。

レスポンスの72％はCache-Controlヘッダーで提供され、レスポンスの56％はExpiresヘッダーで提供されます。ただし、レスポンスの27％はどちらのヘッダーも使用していないため、ヒューリスティックキャッシュの対象となります。これは、デスクトップとモバイルサイトの両方で一貫しています。

図16.2の説明を表示

リクエストの72％がCache-Controlヘッダーを使用し、56％がExpiresを使用し、27％がどちらも使用しないことを示す、モバイルとデスクトップの棒グラフ。

キャッシュするコンテンツの種類は何ですか？

キャッシュ可能なリソースは、クライアントによって一定期間保存され、後続のリクエストで再利用できます。すべてのHTTPリクエスト全体で、レスポンスの80％はキャッシュ可能と見なされます。つまり、キャッシュがそれらを格納することを許可されています。

• 要求の6％のTime To Time（TTL）は0秒で、キャッシュされたエントリはすぐに無効になります。
• 27％はCache-Controlヘッダーがないため、ヒューリスティックにキャッシュされます。
• 47％は0秒以上キャッシュされます。

残りのレスポンスは、ブラウザーのキャッシュに保存できません。

図16.3の説明を表示

デスクトップレスポンスの20％がキャッシュ不可、47％が0秒以上のキャッシュ、27％がヒューリスティックにキャッシュ、6％が0秒のTTLを示す積み上げ棒グラフ。モバイルの統計は非常に似ています（19％、47％ 、27％および7％）

次の表は、デスクトップリクエストのキャッシュTTL値をタイプ別に詳細に示しています。ほとんどのコンテンツタイプはキャッシュされますが、CSSリソースは高いTTLで一貫してキャッシュされるようです。

TTLの中央値のほとんどは高いですが、低いパーセンタイルは、見逃されたキャッシングの機会の一部を強調しています。たとえば画像のTTLの中央値は28時間ですが、25パーセンタイルは1〜2時間であり、10パーセンタイルはキャッシュ可能な画像コンテンツの10％が1時間未満キャッシュされることを示します。

以下の図16.5でコンテンツタイプごとのキャッシュ可能性を詳細に調べると、すべてのHTMLレスポンスの約半分がキャッシュ不可と見なされていることがわかります。さらに、画像とスクリプトの16％はキャッシュ不可です。

図16.5の説明を表示

キャッシュ不可、0秒を超えたキャッシュ、デスクトップのタイプごとに0秒だけキャッシュの分割を示す積み上げ棒グラフ。小さいがかなりの割合でキャッシュ不可能でHTMLでは最大50％になり、ほとんどはキャッシュが大きく0で、小さいキャッシュは0 TTLです。

モバイルの同じデータを以下に示します。ご覧のとおり、コンテンツタイプのキャッシュ可能性はデスクトップとモバイルで一貫しています。

図16.6の説明を表示

キャッシュ不可、0秒を超えたキャッシュ、デスクトップのタイプごとに0秒だけキャッシュの分割を示す積み上げ棒グラフ。小さいがかなりの割合でキャッシュ不可能でHTMLでは最大50％になり、ほとんどはキャッシュが大きく0で、小さいキャッシュは0 TTLです。

Cache-ControlとExpires

HTTP/1.0では、Expiresヘッダーは、レスポンスが古くなったと見なされる日時を示すために使用されました。その値は、次のような日付のタイムスタンプです。

Expires: Thu, 01 Dec 1994 16:00:00 GMT

HTTP/1.1はCache-Controlヘッダーを導入し、最新のクライアントのほとんどは両方のヘッダーをサポートしています。このヘッダーは、キャッシングディレクティブを介して、はるかに高い拡張性を提供します。例えば。

• no-store リソースをキャッシュしないことを示すために使用できます。
• max-age 鮮度の寿命を示すために使用できます。
• must-revalidate キャッシュされたエントリは、使用する前に条件付きリクエストで検証する必要があることをクライアントに伝えます。
• private レスポンスはブラウザによってのみキャッシュされ、複数のクライアントにサービスを提供する仲介者によってキャッシュされるべきではないことを示します。

HTTPレスポンスの53％は、max-ageディレクティブを持つCache-Controlヘッダーが含まれ、54％はExpiresヘッダーが含まれます。ただし、これらのレスポンスの41％のみが両方のヘッダーを使用します。つまり、レスポンスの13％が古いExpiresヘッダーのみに基づいてキャッシュされます。

図16.7の説明を表示

レスポンスの53％を示す棒グラフには、「Cache-Control：max-age」、54％-55％が「Expires」、41％-42％が両方を使用し、34％がどちらも使用していません。数字は、デスクトップとモバイルの両方について示されていますが、有効期限の使用率が高いモバイルとほぼ同じです。

Cache-Controlディレクティブ

HTTP/1.1仕様https://tools.ietf.org/html/rfc7234#section-5.2.1には、Cache-Controlレスポンスヘッダーで使用できる複数のディレクティブが含まれており、以下で詳しく説明します。1つのレスポンスで複数を使用できることに注意してください。

たとえば、cache-control：public、max-age = 43200は、キャッシュされたエントリを43,200秒間保存し、共有キャッシュに保存できることを示します。

図16.9の説明を表示

15のcache-controlディレクティブとその使用量の棒グラフ。74.8％のmax-age、37.8％のpublic、27.8％のno-cache、18％のno-store、14.3％のprivate、3.4％のimmutable、3.3％のno-transform、2.4％のstale-while-revalidate、2.2％のpre-check、2.2％のpost-check、1.9％のs-maxage、1.6％のproxy-revalidate、0.3％set-cookieおよび0.2％のstale-if-error。統計は、デスクトップとモバイルでほぼ同じです。

上記の図16.9は、モバイルWebサイトで使用されている上位15のCache-Controlディレクティブを示しています。デスクトップとモバイルの結果は非常に似ています。これらのキャッシュディレクティブの人気について、興味深い観察結果がいくつかあります。

• max-ageはCache-Controlヘッダーのほぼ75％で使用され、no-storeは18％で使用されます。
• privateが指定されない限り、キャッシュされたエントリはpublicであると想定されるため、publicが必要になることはほとんどありません。回答の約38％にpublicが含まれています。
• immutableディレクティブは比較的新しく、2017年に導入https://code.facebook.com/posts/557147474482256/this-browser-tweak-saved-60-of-requests-to-facebookされ、FirefoxおよびSafariでサポートhttps://developer.mozilla.org/docs/Web/HTTP/Headers/Cache-Control#Browser_compatibilityされています。その使用率は3.4％に拡大し、Facebook、Googleのサードパーティのレスポンスhttps://discuss.httparchive.org/t/cache-control-immutable-a-year-later/1195で広く使用されています。

このリストに表示される別の興味深いディレクティブセットは、pre-checkとpost-checkです。これらは、Cache-Controlレスポンスヘッダーの2.2％（約780万件のレスポンス）で使用されます。このヘッダーのペアは、バックグラウンドで検証を提供するためにInternet Explorer 5で導入されたhttps://blogs.msdn.microsoft.com/ieinternals/2009/07/20/internet-explorers-cache-control-extensions/ものですが、Webサイトによって正しく実装されることはほとんどありませんでした。これらのヘッダーを使用したレスポンスの99.2％は、pre-check=0とpost-check=0の組み合わせを使用していました。これらのディレクティブの両方が0に設定されている場合、両方のディレクティブは無視されます。したがって、これらのディレクティブは正しく使用されなかったようです！

ロングテールでは、レスポンスの0.28％で1,500を超える間違ったディレクティブが使用されています。これらはクライアントによって無視され、「nocache」「s-max-age」「smax-age」「maxage」などのスペルミスが含まれます。「max-stale」「proxy-public」「surrogate-control」など存在しないディレクティブも多数あります。

Cache-Control: no-store, no-cache and max-age=0

レスポンスがキャッシュ可能でない場合、Cache-Control no-storeディレクティブを使用する必要があります。このディレクティブを使用しない場合、レスポンスはキャッシュ可能です。

レスポンスをキャッシュ不可に設定しようとすると、いくつかの一般的なエラーが発生します。

• Cache-Control: no-cacheの設定は、リソースがキャッシュできないように聞こえるかもしれません。ただし、no-cacheディレクティブでは、使用する前にキャッシュされたエントリを再検証する必要があり、キャッシュ不可と同じではありません。
• Cache-Control: max-age = 0を設定すると、TTLが0秒に設定されますが、これはキャッシュ不可と同じではありません。 max-ageを0に設定すると、リソースはブラウザーのキャッシュに保存され、すぐに無効になります。これにより、ブラウザは条件付きリクエストを実行してリソースの新しさを検証する必要があります。

機能的には、no-cacheとmax-age=0は似ています。どちらもキャッシュされたリソースの再検証を必要とするためです。 no-cacheディレクティブは、0より大きいmax-ageディレクティブと一緒に使用することもできます。

300万を超えるレスポンスには、no-store、no-cache、max-age=0の組み合わせが含まれます。これらのディレクティブのうち、no-storeが優先され、他のディレクティブは単に冗長です。

レスポンスの18％にはno-storeが含まれ、レスポンスの16.6％にはno-storeとno-cacheの両方が含まれます。no-storeが優先されるため、リソースは最終的にキャッシュ不可になります。

max-age=0ディレクティブは、no-storeが存在しないレスポンスの1.1％（400万を超えるレスポンス）に存在します。これらのリソースはブラウザにキャッシュされますが、すぐに期限切れになるため、再検証が必要になります。

キャッシュTTLとリソースの経過時間はどのように比較されますか？

これまで、Webサーバーがキャッシュ可能なものをクライアントに通知する方法と、キャッシュされる期間について説明してきました。キャッシュルールを設計するときは、提供しているコンテンツの古さを理解することも重要です。

キャッシュTTLを選択するときは、「これらのアセットをどのくらいの頻度で更新しますか？」と自問してください。そして「彼らのコンテンツの感度は何ですか？」。たとえば、ヒーローのイメージがたまに更新される場合、非常に長いTTLでキャッシュします。 JavaScriptリソースが頻繁に変更されることが予想される場合は、バージョン管理して長いTTLでキャッシュするか、短いTTLでキャッシュします。

以下のグラフは、コンテンツタイプごとのリソースの相対的な年を示しています。ここで、より詳細な分析https://discuss.httparchive.org/t/analyzing-resource-age-by-content-type/1659を読むことができます。 HTMLは最も短い年齢のコンテンツタイプである傾向があり、伝統的にキャッシュ可能なリソース（スクリプト、CSS、およびフォント）の非常に大きな割合が1年以上古いです！

図16.10の説明を表示

コンテンツの年を示すスタック棒グラフ。0〜52週に分割され、1年以上と2年以上で、nullと負の数字も表示されます。統計は、ファーストパーティとサードパーティに分かれています。値0は、特にファーストパーティのHTML、テキスト、およびxml、およびすべてのアセットタイプのサードパーティリクエストの最大50％に使用されます。中間年を使用し、その後1年と2年の間かなりの使用量を使用するミックスがあります。

リソースのキャッシュ可能性をその経過時間と比較することにより、TTLが適切であるか短すぎるかを判断できます。たとえば、以下のレスポンスによって提供されるリソースは、2019年8月25日に最後の変更がされました。つまり、配信時に49日経過していました。 Cache-Controlヘッダーは、43,200秒（12時間）キャッシュできることを示しています。より長いTTLが適切かどうかを調査するのに十分古いものです。

< HTTP/1.1 200
< Date: Sun, 13 Oct 2019 19:36:57 GMT
< Content-Type: application/javascript; charset=utf-8
< Content-Length: 3052
< Vary: Accept-Encoding
< Server: gunicorn/19.7.1
< Last-Modified: Sun, 25 Aug 2019 16:00:30 GMT
< Cache-Control: public, max-age=43200
< Expires: Mon, 14 Oct 2019 07:36:57 GMT
< ETag: "1566748830.0-3052-3932359948"

全体的に、Webで提供されるリソースの59％のキャッシュTTLは、コンテンツの年齢に比べて短すぎます。さらに、TTLと経過時間のデルタの中央値は25日です。

これをファーストパーティとサードパーティで分けると、ファーストパーティのリソースの70％がより長いTTLの恩恵を受けることもわかります。これは、キャッシュ可能なものに特に注意を払い、キャッシュが正しく構成されていることを確認する必要があることを明確に強調しています。

鮮度の検証

キャッシュ内に格納されたレスポンスの検証に使用されるHTTPレスポンスヘッダーは、Last-ModifiedおよびETagです。 Last-Modifiedヘッダーは、その名前が示すとおりに機能し、オブジェクトが最後に変更された時刻を提供します。 ETagヘッダーは、コンテンツの一意の識別子を提供します。

たとえば、以下のレスポンスは2019年8月25日に変更され、「1566748830.0-3052-3932359948」のETag値があります。

< HTTP/1.1 200
< Date: Sun, 13 Oct 2019 19:36:57 GMT
< Content-Type: application/javascript; charset=utf-8
< Content-Length: 3052
< Vary: Accept-Encoding
< Server: gunicorn/19.7.1
< Last-Modified: Sun, 25 Aug 2019 16:00:30 GMT
< Cache-Control: public, max-age=43200
< Expires: Mon, 14 Oct 2019 07:36:57 GMT
< ETag: "1566748830.0-3052-3932359948"

クライアントは、If-Modified-Sinceという名前のリクエストヘッダーのLast-Modified値を使用して、キャッシュされたエントリを検証する条件付きリクエストを送信できます。同様に、If-None-Matchリクエストヘッダーを使用してリソースを検証することもできます。これは、クライアントがキャッシュ内のリソースに対して持っているETag値に対して検証します。

以下の例では、キャッシュエントリはまだ有効であり、HTTP 304がコンテンツなしで返されました。これにより、リソース自体のダウンロードが保存されます。キャッシュエントリが最新ではない場合、サーバーは200で更新されたリソースを応答し、再度ダウンロードする必要があります。

> GET /static/js/main.js HTTP/1.1
> Host: www.httparchive.org
> User-Agent: curl/7.54.0
> Accept: */*
> If-Modified-Since: Sun, 25 Aug 2019 16:00:30 GMT

< HTTP/1.1 304
< Date: Thu, 17 Oct 2019 02:31:08 GMT
< Server: gunicorn/19.7.1
< Cache-Control: public, max-age=43200
< Expires: Thu, 17 Oct 2019 14:31:08 GMT
< ETag: "1566748830.0-3052-3932359948"
< Accept-Ranges: bytes

全体としてレスポンスの65％はLast-Modifiedヘッダーで、42％はETagで提供され、38％は両方を使用します。ただし、レスポンスの30％にはLast-Modifiedヘッダー、ETagヘッダーは含まれていません。

図16.12の説明を表示

デスクトップリクエストの64.4％が最後に変更され、42.8％がETagを持ち、37.9％が両方を持ち、30.7％がどちらも持たないことを示す棒グラフ。モバイルの統計は、最終変更が65.3％、ETagが42.8％、両方が38.0％、どちらも29.9％というほぼ同じです。

日付文字列の有効性

タイムスタンプの伝達に使用されるHTTPヘッダーがいくつかあり、これらの形式は非常に重要です。 Dateレスポンスヘッダーは、リソースがいつクライアントに提供されたかを示します。 Last-Modifiedレスポンスヘッダーは、サーバーでリソースが最後に変更された日時を示します。また、Expiresヘッダーは、（Cache-Controlヘッダーの存在しない場合）リソースがキャッシュ可能な期間を示すために使用されます。

これら3つのHTTPヘッダーはすべて、日付形式の文字列を使用してタイムスタンプを表します。

例えば。

> GET /static/js/main.js HTTP/1.1
> Host: httparchive.org
> User-Agent: curl/7.54.0
> Accept: */*

< HTTP/1.1 200
< Date: Sun, 13 Oct 2019 19:36:57 GMT
< Content-Type: application/javascript; charset=utf-8
< Content-Length: 3052
< Vary: Accept-Encoding
< Server: gunicorn/19.7.1
< Last-modified: Sun, 25 Aug 2019 16:00:30 GMT
< Cache-Control: public, max-age=43200
< Expires: Mon, 14 Oct 2019 07:36:57 GMT
< ETag: "1566748830.0-3052-3932359948"

ほとんどのクライアントは、無効な日付文字列を無視します。これにより、提供されているレスポンスを無視します。これは、誤ったLast-ModifiedヘッダーがLast-Modifiedタイムスタンプなしでキャッシュされるため、条件付きリクエストを実行できなくなるため、キャッシュ可能性に影響を与える可能性があります。

通常、Date HTTPレスポンスヘッダーは、クライアントにレスポンスを提供するWebサーバーまたはCDNによって生成されます。ヘッダーは通常、サーバーによって自動的に生成されるため、エラーが発生しにくい傾向はあります。これは、無効なDateヘッダーの割合が非常に低いことを反映しています。 Last-Modifiedヘッダーは非常に類似しており、無効なヘッダーは0.67％のみでした。しかし、驚いたのは、3.64％のExpiresヘッダーが無効な日付形式を使用していたことです！

図16.13の説明を表示

デスクトップレスポンスの0.10％に無効な日付があり、0.67％に無効なLast-Modifiedがあり、3.64％に無効なExpiresがあることを示す棒グラフ。モバイルの統計は非常によく似ており、レスポンスの0.06％に無効な日付があり、0.68％に無効なLast-Modifiedがあり、3.50％に無効な有効期限があります。

Expiresヘッダーの無効な使用の例は次のとおりです。

• 有効な日付形式ですが、GMT以外のタイムゾーンを使用しています
• 0や-1などの数値
• Cache-Controlヘッダーで有効な値

無効なExpiresヘッダーの最大のソースは、人気のあるサードパーティから提供されるアセットからのものです。たとえば、Expires：Tue、27 Apr 1971 19:44:06 ESTなど、日付/時刻はESTタイムゾーンを使用します。

ヘッダーを変更

キャッシングで最も重要な手順の1つは、要求されているリソースがキャッシュされているかどうかを判断することです。これは単純に見えるかもしれませんが、多くの場合、URLだけではこれを判断するには不十分です。たとえば同じURLのリクエストは、使用する圧縮（Gzip、Brotliなど）が異なる場合や、モバイルの訪問者に合わせて変更および調整できます。

この問題を解決するために、クライアントはキャッシュされた各リソースに一意の識別子（キャッシュキー）を与えます。デフォルトでは、このキャッシュキーは単にリソースのURLですが、開発者はVaryヘッダーを使用して他の要素（圧縮方法など）を追加できます。

Varyヘッダーは、1つ以上の要求ヘッダー値の値をキャッシュキーに追加するようにクライアントに指示します。この最も一般的な例は、Vary：Accept-Encodingです。これにより、Accept-Encodingリクエストヘッダー値（gzip、br、deflateなど）のキャッシュエントリが別になります。

別の一般的な値はVary：Accept-Encoding、User-Agentです。これは、Accept-Encoding値とUser-Agent文字列の両方によってキャッシュエントリを変更するようにクライアントに指示します。共有プロキシとCDNを扱う場合、Accept-Encoding以外の値を使用すると、キャッシュキーが弱められ、キャッシュから提供されるトラフィックの量が減少するため、問題発生の可能性があります。

一般に、そのヘッダーに基づいてクライアントに代替コンテンツを提供する場合のみ、キャッシュを変更する必要があります。

Varyヘッダーは、HTTPレスポンスの39％、およびCache-Controlヘッダーを含むレスポンスの45％で使用されます。

以下のグラフは、上位10個のVaryヘッダー値の人気を示しています。 Accept-EncodingはVaryの使用の90％を占め、User-Agent（11％）、Origin（9％）、Accept（3％）が残りの大部分を占めています。

図16.14の説明を表示

accept-encodingは90％で使用、ユーザーエージェントは10％-11％、オリジンは約7％-8％、acceptは少なく、cookie、x-forward-proto、accept-language、host、x-origin、access-control-request-method、およびaccess-control-request-headersの使用はほとんどありません

キャッシュ可能なレスポンスにCookieを設定する

レスポンスがキャッシュされると、そのヘッダー全体もキャッシュにスワップされます。これが、DevToolsを介してキャッシュされたレスポンスを検査するときにレスポンスヘッダーを表示できる理由です。

図16.15の説明を表示

キャッシュされたレスポンスのHTTPレスポンスヘッダーを示すChrome開発者ツールのスクリーンショット。

しかし、レスポンスにSet-Cookieがある場合はどうなりますか？ RFC 7234セクション8https://tools.ietf.org/html/rfc7234#section-8によると、Set-Cookieレスポンスヘッダーはキャッシングを禁止しません。これは、キャッシュされたエントリがSet-Cookieでキャッシュされている場合、それが含まれている可能性があることを意味します。 RFCでは、適切なCache-Controlヘッダーを構成して、レスポンスのキャッシュ方法を制御することを推奨しています。