サポート

非同期でスクリプトを読み込むメリットとは？

　Steve Souders

2018年12月20日木曜日　

スクリプトを非同期でロードすることの重要性を理解することは、パフォーマンス向上策を増やすのに役立ちます。ここでは、2007年に始まった非同期スクリプトのロードの進化について説明します。Internet Explorer7では、14個のスクリプトのロードは、次のようになっていました。

各スクリプトリクエストの先頭に赤い矢印を追加しました。ここでわかるのは、HTMLパーサーはスクリプトタグを検出すると、そのスクリプトがダウンロードされ、構文解析され、実行されるまで停止するということです。HTMLパーサーが停止したため、すべてのネットワークトラフィックも停止しました(HTTP要求を開始するための解析HTMLタグが他にないため)。これを行ったのはIE7だけではありません。

プリローダーの開始

スクリプトは指定された順序で実行される必要がありますが、実行デイジー・チェーンがより速く移動するように、スクリプトを並行してダウンロードできない理由はありません。これを実現するために、ブラウザーはプリローダーと呼ばれる軽量パーサーを作成しました。

プリローダー(推測または先読みパーサー)は、HTMLをスキップして、SCRIPT、LINK、IMGなどのHTTP要求を開始する可能性のあるタグを探します。プリローダーは、HTMLパーサーが、対応するDOM要素を作成したときに応答準備できる可能性が高くなるように、これらの要求に優先順位を付けて開始します。

このサイトには15の同期スクリプトがあります(主にturner.com)。IE7のように、1度に1つのスクリプトをダウンロードするのに6秒かかる代わりに、プリローダーは、これらのスクリプトを最大1.2秒でダウンロードする事ができます。

※ウォーターフォールチャートの注意:レンダリングフィルムストリップは上部に表示されます。ブラウザのCPUタイムラインは、ウォーターフォールの下に表示されます。スクリプトはオレンジ色で表示されます。同期スクリプトは赤のハッシュ・パターンで表示されます。各スクリプトの右側の赤と緑のバーは、スクリプトがCPUを使用しているときです。各スクリプトの合計CPUタイムは、URLの後のカッコ内に表示されます。

プリローダーは、これまでに作成されたブラウザの中で最も重要なパフォーマンス改善です。IE8は、2009年にプリローダーを備えた最初のブラウザであり、他の主要なブラウザのほとんどは、年内にそれに続きました。

プリローダーはWebパフォーマンスを劇的に改善しましたが、万能薬ではありませんでした。前のウォーターフォールを見ると、次のように見えます。

  • すべての同期スクリプトがダウンロード、解析、および実行されるまで、レンダリングはブロックされます。 非同期でダウンロードした場合は、ブラウザのレンダリングが速くなる可能性があります。
  • 2番目のスクリプトjquery.jsはダウンロードに時間がかかります。このスクリプトは同期的にロードされるため、後続のスクリプトはjquery.jsの前にダウンロードを終了しても、実行されるまで待機する必要があります。その結果、ブラウザのCPUは最初の1,2秒間はアイドル状態になり、すべてのJSとレイアウトが発生すると固定されます。スクリプトが非同期にダウンロードされた場合、スクリプトは解析され、到着するとすぐに実行し、CPUアクティビティが分散されるため、CPUのブロックが回避されます。
  • プリローダーは、同期スクリプトにイメージよりも高いダウンロード優先順位を与えます。同期スクリプトのダウンロードには時間がかかるため、イメージリクエストはブロックされ、最初のレンダリングにはテキストのみが含まれます。スクリプトが非同期でロードされると、イメージのダウンロードが早くなり、ユーザー体験が向上します。

最後に:非同期

前のウォーターフォールを見ると、プリローダーによってパフォーマンスとレンダリングが大幅に向上していることがわかります。しかし、すべての問題が解決したわけではない。このページには15の同期スクリプトがあり、レンダリングをブロックし、CPUに固定し、画像を遅延させる。これらの問題の解決策は、スクリプトを非同期にロードすることです。

スクリプトを非同期でロードする最善の方法は、async属性を使用することです。この属性のサポートは、2010年のFirefoxとChromeに始まり、2012年のSafariとInternet Explorerがブラウザに追加されました。これらが広くサポートされる前は、開発者はさまざまな手法(すなわち、ハッキング)を使って非同期でスクリプトをロードすることができました。これらの手法は現在でも特殊な状況で使用されていますが、マークアップで非同期を使用する方が簡単です。また、プリローダーはこれらのスクリプトを見つけ、HTTP要求をプログラムでロードするよりも早く開始できるため、パフォーマンスも向上します。

スクリプトを非同期でロードする利点は、次のウォーターフォールチャートで強調されています。[http :// www.hp.com/jp/proliantessentials_manual] どのスクリプトにも、同期スクリプトを示す赤いハッシュ・パターンがないことに注意してください。つまり、これらの20以上のスクリプトはすべて非同期でロードされます。その結果、ページは迅速にレンダリングされ(0.7秒)、スクリプトの解析と実行はブロックされず、各スクリプトは到着するとすぐに処理されます。

非同期属性が利用可能でよく知られているのは素晴らしいことですが、同期スクリプトのロードは依然としてデフォルトです。つまり、Webサイトの所有者は、スクリプトを非同期でロードするために特別な努力をする必要があります。作業量はそれほど多くないかもしれませんが(非同期属性を追加するだけでよい)、わずかな変更でさえ、Web上のクリティカル・マスに到達するまでには長い時間がかかります。

下のグラフは、非同期スクリプト・ロードの採用を示しています。これらは、HTTP Archiveの分析に基づく、世界のトップ~50万のウェブサイトの中央値統計である。2015年後半の時点で、中央値は同期スクリプトが10、非同期スクリプトが2でした。2016年6月に同期がドロップし、非同期の数が増加しました。これは、一部の主要なサードパーティ断片(Google Analytics、Facebookなど。)が同期から非同期に切り替えたためと考えられます。それ以来、スクリプトの総数は増え続けていますが、新しいスクリプトはすべて非同期を使用していることを示しています。それにもかかわらず、最新のデータによると、同期スクリプトの数は非同期スクリプトの数7~6を上回っています。

非同期的にロードされるスクリプトの数がこのように増加したことは驚くべきことです。3年は長いですが50万のウェブサイトについて話しています。同期スクリプトを非同期にするための変更は些細なことですが(非同期属性を追加するだけ)、変更によってエラーが発生しないようにするのは容易ではありません。JavaScriptが解析されて順不同で実行されると、未定義のシンボルエラーが発生する可能性があります。相互依存関係を解消して安全な非同期スクリプトのロードを保証するには時間がかかるかもしれませんが、パフォーマンス上のメリットは、皆さんにとってもユーザーにとっても価値があります。

関連記事　https://speedcurve.com/blog/preload-scripts/

関連記事