After Grade A

サイト高速化の「戦略」と「戦術」- GradeAのその先へ

サイト高速化をネタにした記事は星の数ほどありますし、YSlowPageSpeed、あるいは両方同時にチェックできる GTmetrix のおかげで、アドバイスに従って問題点を一つ一つ潰し込んでいけば、着実にスコアを「Grade A」に近づけられるようになりました。

またベスト・プラクティスなんて知らなくても、「CloudFlare 導入、一発 OK!」なんていうお手軽なサービスもあります。

一方、これら個々の Tips、テクニックを断片的に積み上げていくアプローチやブラックボックス方式では、サイト全体を通して「本当に最適なの?」という疑問も生じます。

別な言い方をすれば、「Grade A は取ったけど… その先は?」に対する処方箋が必要なんじゃないかと思っています。

そこで今回は、「スコア」だけでは見えてこない、サイト高速化の「戦略」と「戦術」の話にチャレンジしてみたいと思います。これはフロントエンドという下流のテクニックや Tips の話ではなく、サイトの意図や狙いという上流の要求をフロントエンドという下流に落とし込むための「分析」と「設計」の話です。

ぶっちゃけた話、ろくに設計もしていない(あるいは期せずしてそうなってしまった)乱雑な HTML を、小手先の Tips でいくら弄っても限界があるのは自明の理でしょう。

第1部では、いわゆるベスト・プラクティスの全体を俯瞰しサイト高速化の「戦略」を検討します。第2部では、サイトの要求に適した攻め方、つまり「戦術」を練ります。そして第3部では、戦術に基づいた「実践」について書いてみたいと思います。

第1の戦略:サイト高速化の戦略を俯瞰する

YSlow や PageSpeed は、過去に分析され実践されてきたベスト・プラクティスに基づき、ページ中の問題点とその解決方法をシンプルなテクニックとしてアドバイスしてくれます。もちろんこれらのテクニックは絶対に必要なんですが、エッセンスになり過ぎている、あるいは普遍的になり過ぎているため、サイト全体を俯瞰した視点が抜けがちです。

逆にサイトの特性に合った改善ができれば、より効果的になるハズです。

私は、ページ高速化において最も重要なツールは、ブラウザの要求〜サーバーの応答を時系列で可視化した「ウォーターフォール・チャート」だと思っています。そもそも PageSpeed や YSlow は、このウォーターフォール・チャートを ミクロに分析した結果 や、マクロに俯瞰した結果 のエッセンスを Tips やテクニックとして集約したものです。

それゆえこのチャートには高速化のヒントがたくさん詰まっています。もちろん先人達の知恵が詰まったベスト・ベストプラクティスがある以上、私たちがあらためてミクロに捉え直す必要はありません。サイト高速化の「戦略」と「戦術」は、まずこのチャートをマクロに俯瞰することから始めると良いと思います。

その意味でページの高速化を一言で言い表せば、「縦と横を短くすること」に尽きます。「縦を短くする」とは

  • 外部リソースに対する HTTP リクエストの「数」を減らす

ことに他なりません(ここで「外部リソース」とは画像やスタイルシート、スクリプトなどを指します)。

また「横を短くする」とは

  • リソースの「量」を減らす
  • サーバーの応答時間を短くする
  • HTTP リクエストを並列化(時には平準化)する

ことですネ。

ほぼすべてのテクニックや Tips は、上記のどれかに当てはまるハズです。

次の表は、YSlow と PageSpeed が提唱するベスト・プラクティスのルールを、上記の観点で「縦」と「横」に分類したものです。幾つかのルールは(設定や状況次第で)両方に効きますが、「ファースト・ビュー」、つまりキャッシュが空の、初回訪問時を想定しています。「リピート・ビュー」まで考慮すると分類が少し変わりますが、ここでは子細なこととさせてください。

YSlow のカッコ内数字は、配点の重み各ルールのグレード計算式 から引用した値です。

  YSlow PageSpeed

YSlow や PageSpeed は、この「縦」と「横」を区別することなく効果の高い順にアドバイスしてくれます。これはこれで悪くありませんが、ベストでもありません。

表からは、圧倒的に「縦」のルールが少ないことが分かります。これは、最初から「横」のルールをコマゴマと対策するより、まずは「縦」を徹底的に短くし、それから「横」の施策を打った方が効率が良いことを示唆している、と私は考えます。

また「縦」を短くすることは、「横」を短くする効果にもつながります。何よりウォーターフォール・チャートがシンプルになり、「横」を短くする時の「戦術」を練る上での分析が容易になるという効果も期待できます。

即ち第1の戦略としては、「まずは縦を徹底的に短く、次いで横を短く」です。

サイト高速化とウォーターフォール・チャート

YSlow では「CDN を使いなさい」への配点が高いので(実際、効果が高いんですが)、真っ先に手を付けたくなりますが、リソースの最適化を図ってからでないと二度手間になるのは想像に難くありません。

逆に縦を徹底的に短くする努力をすれば、CDN は使わずとも「Grade A」の取得には近づけます。その後 CDN を導入すれば、ダメ押し的な効果が得られるでしょう。美味しいものは後に取っておきましょう 😀 。

参考情報

  1. High Performance Web Sites – 14 rules for faster-loading pages
    • Steve Souders の書籍 High Performance Web Sites 出版前の、2007年のプレゼンテーションです。ウォーターフロー・チャートの分析に始まり、14のルールが導き出されています。
  2. Google Developers Live: Waterfall AntiPatterns – Web Performance Analysis
    • ウォーターフォール・チャートを大局的な「エンベロープ」で捉え、特徴的な箇所をアンチパターンとし、改善策が解説されています。著者の Rick Viscom さんが 講演 の中で スコアが良いからと言って早いサイトとは限らないし、低いからと言って遅いサイトというワケでもない と語っているのが象徴的です。
  3. After YSlow “A”

縦を短くする時の戦術

HTTP リクエスト削減の重要性を知るには、参考情報4 と一連の記事を読むことをお勧めします。高コストな DNS ルックアップやリクエスト〜レスポンスと RTT の関係が丁寧に説明された素晴らしい記事です。

ところで一口にリクエストの削減と言っても、前章の表に挙げた以外にも

  • 画像の CSS 化や data URI 化、IE 用のマルチパート化
  • 必要になるまでリクエストしない Lazy Loading、Modernizr による条件ローディング

などなど、他にもまだ幾つかのテクニックが存在します。が、ここでは第2部の主題にもつながる「css や js ファイルを束ねて結合する」ことに話を絞らせて下さい。

YSlow や PageSpeed のスコアに関して言えば、css と js それぞれを2本以下にまで減らせれば「Grade A」の範囲内です。逆にその程度までは自由度があるとも言えます。

そこでまずは「分析」の段階として、束ねるべき css と js のリソース群を識別する3つの戦術について述べたいと思います。

Above the fold に関連するリソースを識別する

次の図は、コードのハイライトを行うスクリプトが後から走り出し、装飾される前のコードが一瞬見えてしまう例です。

シンタックス・ハイライトの例

また次の図は、フォームのボタンを押そうと思った瞬間に、後から走りだしたスクリプトによって リフロー が発生し、ボタンの位置が変わってしまう例です。

トップページの例

これらは束ねた js を、ベスト・プラクティス「js は </body> 直前に置け」に従って配置した時に起こりがちなことで、FOUC と呼ぶ事象です(第2部で少しだけ触れますが、スマホ版 Chrome だと起き易いようです)。

勿論、前者の例では display:none を指定しておく、後者の例では予め最終的なサイズを指定しておくといったテクニックで回避は可能です。しかしより本質的には、js の配置と実行タイミングが UX 上、適切ではないことが原因です。

また「真に動的な部分はどこか」を見極め、「Above the fold のコンテンツは、可能な限りサーバーサイドで構築する」ことも重要です。後者の例では、ベースとなるメニューには静的な画像を配置し、ユーザー毎にカスタマイズする部分だけをスクリプトで追加的にレンダリングすれば、UX を大幅に改善できるでしょう。

何はともあれ、「Above the fold(真っ先に目にする部分)のコンテンツ」に直結するリソースを識別することが重要なんだと思います。

サイト共通のリソースとページ個別のリソースを識別する

あるページから別ページに移った時、90%はブラウザに残るキャッシュが再利用できるという状況があります。この場合、リソースを1つのファイルに束ねてしまうのではなく、「サイト共通のリソース」と「ページ個別のリソース」とに分けると、ページ遷移時の最適化が図れます。

つまりサイト全体に渡るリソース群を識別することが、第2の戦術ポイントです。

各リソース間の依存関係や疎密関係を識別する

依存関係のある密なリソース群を束ねたり結合したりする際の候補になるのは当然として、同時に互いに依存しない粗な関係のグループ群も識別しておきます。これによって、それらの配置や実行タイミングなど、設計や実装段階での自由度を確保しておくという戦術です。

オッと、ここでは次のような現実的な問題に直面します。

  • jQuery は独立させるべきか、他と結合させるべきか

大抵の場合、Google CDN などから独立して読み込むことを選択するでしょう。「自サイトより高速」、「クロス・サイト・キャッシングが期待できる」などがその理由です(実際には jQuery のバージョンが色々過ぎて、再利用の期待値は 高くないという報告 もあります)。

しかしこの段階では「分析」に止め、「実装」と分けておくことが肝心です。例えば jQuery をどうするかといった問題は「reduce DNS lookup」のルールとも関連するため、ページ全体で扱うドメイン数が確定した後で決めても良いのです。

他にも戦術上の観点があるかもしれません。いずれにしても分析の段階では「木を見て森を見ず」にならないこと – これが最も大事なことではないでしょうか 😉 。

参考記事

  1. HTTPリクエストを減らすために【序章】HTTPリクエストは甘え

第2の戦略:サイトの特性に合ったリソースの配置

せっかくアレコレ分析しても、リソースの配置が悪いと元も子もありません。つまり第2の戦略は、「サイトの特性に適したリソースの配置を行う」です。

リソースの最適な配置を決めるためには、「ブラウザ動作の基本」をある程度知っておくことが大切です。そしてまたブラウザも進化しています。これらを押さえながら、コンテンツとリソースの配置が「設計」できればベストでしょう。

そこで次回第2部では「サイトに適したリソース配置 – レンダリング優先のグッド・プラクティス」と題し、第1部の分析を元に、サイトの要求を下流のフロントエンドに落とし込む時の「戦術」に話を移します。

「どう見せたいか」→「ブラウザはこう振る舞う」→「じゃあリソースはこう配置しよう!」という話にする予定ですので、ご期待ください 😀 。

番外編 – ブラウザ版 YSlow と GTmetrix 版 YSlow の違い

大抵は GTmetrix 版の方が甘めのスコアとなります。YSlow は onload まで のリクエスト~レスポンスを評価対象にするのが基本ですが、ブラウザ版は Firebug のネットパネルと連携しており、onload 後も 1秒間は観測が延長される ためです。

例えば負荷の高いソーシャル系スクリプトや Disqus 用のスクリプトの読み込みを onload 後に回した場合、GTmetrix では評価対象になりませんが、ブラウザ版 YSlow ではスコアが激しく悪くなります。

こういう違いを知った上でうまく使うのがコツかと思います。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

海外からの投稿は受け付けていません