ページ表示が遅い原因となるレンダリングブロックの解除方法
目次
サイトを閲覧する側の最大のストレスは無反応
サイト表示速度で大事なのはまず何かが表示されることです。
ページ全体の表示完了が遅くても、ファーストビューのコンテンツの表示速度が速ければ、閲覧者はそれほどストレスを感じません。
しかし、時よりそうした、長時間何も表示されないサイトも見受けられます。
ページがなかなか表示されない原因ひとつとして、ファーストビューのレンダリングブロック JavaScript/CSS を排除する方法があります。
画像サイズも軽量化したのになかなか表示されないような時はこの原因を疑ってみてもいいかもしれません。
あるサイトをGoogleDevelopersのPagespeed Insightで調査した際に、以下のような指摘がありました。
このページでスクロールせずに見えるコンテンツを、以下のリソースによる読み込みを待たずにレンダリングできませんでした。ブロッキング リソースを遅延させるか、非同期に読み込むか、これらのリソースの重要部分を HTML 内に直接インライン化してください。
これがどのような指摘なのかということを少々具体的に解説します。
以下はPageSpeed Insights(http://developers.google.com/speed/pagespeed/insights/)の調査結果を（英語）をわかりやすくしたものです。
レンダリングブロック（表示を妨げている）JavaScript を削除
ページのファーストビュー部分でブロックしている外部JavascriptをHTMLが参照している。と言うことを検知した時にこの対処方法が提案されます。
概要
ユーザに対してページを表示する前に、ブラウザはページを解析する必要があります。解析中にブロックしている外部スクリプトを見つけると、ブラウザは解析をストップし、そのJavascriptをダウンロードをしなければなりません。
そうした処理を行う度に、毎回ネットワークの往復が追加的に必要になり、ファーストビューページの表示を遅らせることになります。
推奨する対処
ファーストページビュー領域で表示が必要とされるJavascriptはインライン化されるべきです。
そして、ページへ機能を追加するために必要なJavascriptは、ファーストビューページのコンテンツが表示されるまで待つべきです。
ページのロード時間を改善するのに、CSSの受け渡しについても最適化しなければならないということは、ぜひ覚えておいてください。
ワードプレスに強いサーバ
インライン Small JavaScript
もし、外部スクリプトが充分に小さいなら、HTML文章の中に直接スクリプトを含めてしまうこともできます。
この方法で小さいファイルをインライン化することで、ブラウザーはページの表示を先に進めることができるようになります。
たとえば、HTMLが以下のよう書かれていたとします。
<html>
<head>
<script type="text/javascript" src="small.js"></script>
</head>
<body>
<div>
Hello, world!
</div>
</body>
</html>
そして、small.jsの中身が以下の内容。
/* contents of a small JavaScript file */
だとすると、次のような形でScriptをインラインにできます。
<html>
<head>
<script type="text/javascript">
/* contents of a small JavaScript file */
</script>
</head>
<body>
<div>
Hello, world!
</div>
</body>
</html>
HTMLドキュメントの中にインライン化することによって、small.jsという外部へのリクエストを削減することができます。
JavaScriptのロードを延期する
JavaScriptがページローディングのブロックをしないようにするために、Javascriptロード時のHTML Async 属性（非同期ロード）指定の使用も勧められています。
例としては以下のような形です。
<script async src="my.js">
ただし、もし、JavaScriptでdocument.writeを使用している場合は、この非同期ロード指定は危険です。
そのため、JavaScriptでは、document.writeはない違う技術を推奨しています。
さらに、JavaScriptを非同期でロードする場合は、ふさわしい順序でロードされているか注意しなければなりません。
例えば、もし別のScriptに依存するScriptをロードする場合、その別のScriptが先にロードされているかなど、ふさわしい従属順序でロードされるようにする必要があります。
スクリプトの非同期バージョンを使用
この通知は、非同期バージョンが存在するにもかかわらず、同期バージョンを使用されているケースが認識された時に、このような対処方法が提案されます。
概要
非同期スクリプトを使用するということはより速くページを表示させることができる。ということを意味します。
つまり、ページの表示前にスクリプトのダウンロードでユーザを待たせるのでなく、ページを表示している最中に、バックグラウンドでスクリプトがダウンロードできるということです。
ほとんどのスクリプトはもともと同期型ではありますが、新しいスクリプトは、非同期でロードできるように設計されるようになってきています。
推奨する対処
まず、自分のスクリプトが非同期バージョンを使用しているか確かめましょう。
次のような主要なスクリプトは非同期ロードをサポートしていますので、非同期バージョンを使用しましょう。
- BuySellAds (s3.buysellads.com/ac/bsa.js) : blog post – async by default
- ChartBeat (static.chartbeat.com/js/chartbeat.js) : doc, blog post – async by default
- Clicky (static.getclicky.com/js) : blog post
- Disqus (disqus.com/count.js, disqus.com/embed.js) : doc, blog post – async by default
- Facebook (connect.facebook.net/…/all.js) : doc, blog post – async by default
- Google AdSense (pagead2.googlesyndication.com/pagead/show_ads.js) : doc, blog post
- Google Analytics (google-analytics.com/ga.js) : doc, blog post – async by default
- Google DFP GPT (www.googletagservices.com/tag/js/gpt.js) : doc
- Google Plus (apis.google.com/js/plusone.js) : doc, blog post
- New Relic (d7p9czrvs14ne.cloudfront.net/11/eum/rum.js) : doc – async by default
- Pinterest (assets.pinterest.com/js/pinit.js) : doc
- Shareaholic : doc – async by default
- ShareThis (w.sharethis.com/button/buttons.js) : doc
- ScorecardResearch/Comscore (b.scorecardresearch.com/beacon.js) : doc – async by default
- StumbleUpon (platform.stumbleupon.com/…/widgets.js)
- Quantcast (quantserve.com/quant.js) : doc – async by default
- Twitter (platform.twitter.com/widgets.js) : doc – async by default
- Tynt (cdn.tynt.com/tc.js)
- Yandex (mc.yandex.ru/metrika/watch.js)
CSS 配信を最適化
コンテンツの表示を妨げ、遅延させるような、外部CSSが含まれる場合にこの対策が推奨されます。
概要
ブラウザーはスクリーンにコンテンツを表示させる前に、外部CSSファイル上でブロックします。これは追加的なネットワーク遅延を招き、コンテンツを表示させるために掛かる時間を増加させる。
推奨する対処
もし、外部CSSリソースが小さいなら、HTMLドキュメントに、直接それらを挿入してしまうことができます。
つまり、インライン化です。
この方法でのスモールCSSの初期化はページ表示をブラウザに続行させることができます。
しかしながら、CSSファイルが大きい場合は注意が必要です。そのCSSを完全にインライン化すると、PageSpeed Insightsは「ファーストビューページが大きすぎる」という警告を出します。
（※Prioritize Visible Contentは別途説明予定）
大きなCSSファイルの場合は、ファーストビューページを表示するために必要なCSSを識別してインライン化し、その残りのスタイルのローディングをファーストビューの後にするようにする必要があるということです。
スモールCSSファイルの例
CSSファイルが充分に小さい場合の例を示します。
HTMLドキュメント内に以下のようなコードがある場合
<html>
<head>
<link rel="stylesheet" href="small.css">
</head>
<body>
<div class="blue">
Hello, world!
</div>
</body>
</html>
そして、Small.cssが次のような時
.yellow {background-color: yellow;}
.blue {color: blue;}
.big { font-size: 8em; }
.bold { font-weight: bold; }
こんな感じでクリティカルなCSSだけインライン化します。
<html>
<head>
<style>
.blue{color:blue;}
</style>
</head>
<body>
<div class="blue">
Hello, world!
</div>
</body>
</html>
<link rel="stylesheet" href="small.css">
元のsmall.css はページのロードされた後にロードされています。
CSSルールのアプリケーションの順序は、Javascriptを通して、ドキュメントに全てのstyle要素とlink要素を入れることによって、保守される。
大きいデータのURIはインライン化しない
CSSファイル内のデータURIをインライン化する時は注意が必要です。
CSS内の小さなデータURIの選択的利用については、意味があるかもしれませんが、大きなデータURIのインライン化はファーストビューにあるCSSをより大きくする原因になり、結果的にページ表示時間を遅くします。
CSS属性はインライン化しないこと
例えば< p style=...> のようなHTML要素においてCSS属性をインライン化されることは可能な限りの場所で避けるべきです。
これはよく、不必要なコード重複を起こす原因になります。
さらに、HTML要素のインラインCSSは、既定ではコンテンツセキュリティポリシーにより、ブロックされることになっています。
photo credit: Phil’s 1stPix via photopin cc
