PageSpeed Insights、Lighthouse の使用を開始しました

Google では、スピードが重視されていることを考慮し、どなたでもページやサイトのパフォーマンスを把握できるよう各種ツールをご用意しています。これまで、こうしたツールでは異なる分析エンジンを使用していたため、ツールごとに最適化案が異なり、混乱を招くこともありました。そこで、本日、PageSpeed Insights(PSI)の分析エンジンとして Lighthouse の使用を開始する運びとなりましたことをお知らせいたします。これにより、デベロッパーはウェブ、コマンドライン、Chrome DevTools を問わず、どこでも同じパフォーマンス分析結果と最適化案を参照できるようになります。また、PSI には、Chrome ユーザー エクスペリエンス レポート(CrUX)で提供されるフィールド データも組み込まれます。PageSpeed Insights API バージョン 5 では、CrUX のデータのほか、Lighthouse 監査のすべてのデータが提供されるようになります。PSI API の以前のバージョンは 6 か月後にサポートを終了いたします。

Pagespeed Insights で Lighthouse の使用を開始

PageSpeed Insights で提供される情報は次のとおりです。

  • ラボデータ: PSI では、Lighthouse を使用してページを取得、分析し、モバイル端末でページがどのように読み込まれるかのシミュレーションが行われます。ページの一連のパフォーマンス指標(First Contentful Paint、Time to Interactive など)を計算し、これらの指標を要約して 0~100 のパフォーマンス スコアで表します。スコアは 3 つのレベルに分類され、90 以上は「良」と見なされます。
  • フィールド データ: PSI には、ページの実際のパフォーマンス指標(First Contentful Paint、First Input Delay など)とその origin も表示されます(これを受けて、PSI では origin: クエリのサポートも終了します)。ただし、必ずしもすべてのサイトに表示可能なフィールド データがあるとは限りません。データは、毎日更新される Chrome ユーザー エクスペリエンス レポートを利用し、過去 28 日間かけて収集されます。実際のネットワークの状態や Chrome ユーザーが使用する端末は広範囲に及ぶため、ここでの指標は、ラボデータ欄の指標とは異なることがありますのでご注意ください。
  • 最適化案: PSI では、ページのパフォーマンス指標を改善する方法についての最適化案が提供されます。各最適化案には、実装するとページの読み込みがどのくらい速くなるかの見積もりも表示されます。
  • 診断: この欄には、ページがウェブ開発のおすすめの設定にどの程度沿っているかについての追加情報が表示されます。

PSI v5 API では、所定の URL について、この新しい分析データと CrUX のデータに加え、すべての Lighthouse カテゴリデータ(パフォーマンス、プログレッシブ ウェブアプリ、アクセシビリティ、ベスト プラクティス、SEO)が返されるようになります。

変更内容について詳しくは、よくある質問をご覧ください。ご不明な点がありましたら、Stack Overflow をご利用ください(その際、質問には pagespeed-insights タグの設定をお願いいたします)。

GoogleのPageSpeedモジュールのNginx用バージョンがリリース

GoogleはつねにWebの高速化に真剣だ。2010年には協力者たちのグループを率いてApache Webサーバ用のモジュールPageSpeedをリリースした。そして今日(米国時間4/25)は、同じグループがこのモジュールのWebサーバNginx用をリリースした。NginxはApache同様、オープンソースのプロジェクトで、トラフィック量の膨大なNetflix、Hulu、Pinterest、Airbnb、WordPress.com、Zynga、Zappos、GitHubなどのサイトが使っている。

アルファテストでは、CDNプロバイダMaxCDNが、ページロードタイムの1.57秒減を報告している。バウンスレートは1%減だそうだ。大きな成果ではないように見えるが、一つのサイトで複数のビジターがいろんなことをしてるような場合には、けっこう大きな効果になる。たとえば、誰もかれもがネットしているStarbucksのようなところでHuluを利用すると、わずか2秒の違いでもページやビデオのロード時のいらいらが、かなり減ることに気づくだろう。

このモジュールはGitHubで入手できる。そのオープンソースの開発には、Google、Taobao、We-Amp、それにそのほかの個人デベロッパたちが参加している。

GoogleのMake the Web Faster Team(長いチーム名だ!)のエンジニアJeff Kaufmanがブログ記事で、PageSpeedについて説明している:

Nginxの中で動くngx_pagespeedモジュールは、Webページを書き換えることによって、Webページのユーザへの到達を速くする。具体的には、画像の圧縮、CSSやJavaScriptの最小化、キャッシュの長寿命化など、Webのパフォーマンス面のベストプラクティスの数々だ。mod_pagespeedの最適化フィルタのすべてを、Nginxのユーザも利用できる。

Googleはインターネットの高速化をGoogle自身というより、世界全体のためと考えており、そのためのテストをすでに合衆国の数都市で開始している。この努力には、ほかの企業も参加協力してよいのではないか。Google自身に関しては、Webの高速化はGoogleのCEO CEO Larry Pageのトッププライオリティであり、それはもちろんGoogleの今と将来の全製品に好結果をもたらす。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


どのISPが高速か?–ストリーミングビデオのNetflixが8か国のデータを各月公表

netflix_logo

過去数か月、Netflixは定期的に、ストリーミングビデオを最速で届けてくれるISPのリストを公開していた。そして今日同社は、このデータ専用のサイトNetflix ISP Speed Index立ち上げた。このサイトでISPのスピードデータを見られる国はNetflixが展開している国、すなわち合衆国、メキシコ、アイルランド、イギリス、ノルウェー、スウェーデン、デンマーク、そしてフィンランドだ。驚くに当たらないが、Netflixのストリーミングに対する平均ビットレートのトップはGoogle Fiberの3.35Mbps、そして次位はスウェーデンのOwniteの2.99Mbpsだ。

Netflixによると、これらのデータの源泉は3300万あまりのNetflix会員で、彼らの月間視聴量は合計で10億時間を超える。下図のように、今回発表されている数字は昨年11月から今年2月までの4か月で、顕著なのはトップのGoogle Fiberの成長だ。データは今後も各月に更新される。

netflix_index

Netflixの注記によると、平均速度はISPたちのピーク速度よりも低い傾向がある。Netflixが行うビデオのエンコードや、視聴者の使用機器/ネットワークの条件などにより、結果的に速度が低下する。しかしそれらの条件がISPによって異なることはないから、比較は依然として有意である。そして、データに示された速度は、だいたい各ISPの全ユーザが経験している平均速度と考えてよい、ということだ。

これらのデータを見ると、ISPによってサービスの質に大きな差があるようだが、しかしNetflix自身は、ISPたちと協力して帯域の拡大とユーザのストリーミング体験の改善に努力している。たとえばISPは、同社のCDN Open Connectを直接利用してトランジット費用を下げることができる。Netflixはまた、ISPにストレージハードウェアを提供し、ISPのデータセンターにおけるローカルキャッシュの増強を支援している(もちろんNetflixの人気コンテンツをキャッシュしていただくのだ)。これらのストレージを導入したISPでは実際に、1080p HDや3Dのコンテンツをより高速に提供できている。上の図の上位に位置するISPも、その一部は、そういう意味でのNetflixパートナーISPだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Googleが新しい圧縮アルゴリズムZopfliをオープンソースで発表

Volvo_Large_Asphalt_Compactors

Googleが今日(米国時間2/28)、オープンソースの新しい圧縮アルゴリズムZopfliローンチした。今の標準圧縮技術であるzlibライブラリに比べて5〜8%圧縮率が高いといわれ、また解凍アルゴリズムは今のWebブラウザが現用しているもので間に合うため、Webサーバがこれを採用すれば、データの伝送速度が上がり、Webをやや速くすることができるだろう。

このアルゴリズムはチューリッヒ在住のGoogle社員Lode Vandevenneが20%プロジェクト*として作ったもので、Deflateアルゴリズムの実装だ。それはZIPやgzipが使っているアルゴリズムで、画像ファイルのPNGにも使われている。出力(圧縮結果)はzlibと互換性があるが、圧縮を行うアルゴリズムがzlibとは異なり、より効率的だ。〔*: 20%プロジェクト, 会社の拘束時間の20%は好きなこと(研究開発)をしてよい、というGoogleの内規。〕

Vandevenneは今日の発表声明で、“この徹底的で容赦のない圧縮アルゴリズムは、エントロピーモデルの反復と最短経路アルゴリズムを駆使し、可能なすべてのデフレート表現のグラフ中にビットコストの低い経路を見つける”、と述べている。

ただし、高い圧縮率の代償は長い圧縮時間だ(解凍時間は同じ)。Vandevenneはこう書いている: “最大でzlibの2〜3倍のCPU時間を要するので、Webの静的コンテンツのように、一度圧縮したらそれを今後何度でも使える、というアプリケーションに向いている”。

画像クレジット: Volvo

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))