チューニング」タグアーカイブ

WordPress.com Stats の JavaScript を並列読み込み対応にする

昨日のエントリの続き。
WordPress.com Stats 日本語版の JavaScript を並列読み込み対応にしてみましょう。

WordPress.com Stats 日本語版で JavaScript を読み込み、動作用の JavaScript をフッタに書き出しているのは、stats.php の 107 〜 113 行目の以下のコード。

<script src="http://stats.wordpress.com/e-<?php echo gmdate('YW'); ?>.js" type="text/javascript"></script>
<script type="text/javascript">
st_go({<?php echo stats_array($a); ?>});
var load_cmc = function(){linktracker_init(<?php echo "{$a&#91;'blog'&#93;},{$a&#91;'post'&#93;},2"; ?>);};
if ( typeof addLoadEvent != 'undefined' ) addLoadEvent(load_cmc);
else load_cmc();
</script>

まず、外部 JavaScript http://stats.wordpress.com/e-<?php echo gmdate('YW'); ?>.js を読み込み、その後 st_go() 関数、linktracker_init() 関数を呼び出しています。

外部 JavaScript の読み込みが完了してからでないと st_go() 関数を呼び出すことはできないため、並列読み込みでは問題が生じます。
# JavaScript のロード完了まで待たないで継続処理を行われると処理不可能。

また、st_go() 関数の中では document.write() を使って <img> タグを書き出しているため、単純に DOM 操作で <script> タグを head 内にブチ込むだけでは、うまくいきません。
続きを読む

JavaScript 読み込みの並列化

JavaScript の並列読込Safari, IE8 以外のブラウザでは JavaScript の読み込み中は、画像や CSS、他の JavaScript ファイルなどの読込処理がブロックされる。
これをDOM経由で動的にロードすると、並列で読み込まれるようになりますよと言うお話。
元ネタは、マイコミジャーナルの「JavaScript読み込みブロック回避でページ表示を高速化する方法」と言うエントリ。
右図が、当サイトに実装した際の Firebug のネットワークモニタ結果(JavaScriptのみ)。(クリックで拡大されます)
確かに並列読み込みされている。

JavaScript の並列読込処置前比較のために実装前の Firebug のネットワークモニタ結果(JavaScriptのみ)も載せておきます。
一つの JavaScript が読み込み終わるまで、次の JavaScript の読み込みが待ちになっている様子が分かりますね。
読み込んでいる JavaScript ファイルが少ないのは、並列読み込み用に使った Yahoo! UI Library の Get Utilityを、こちらでは読み込んでいないことと、自サイト内の Javascript を動的結合しているため。
# 読み込みファイル数が少ない実装前の方が、総読み込み時間が多くなっている。
続きを読む

PHP で Javascript を動的結合

Strategic Web Design : ITpro の連載記事「技術者視点のユーザビリティ考」の第30回 JavaScriptの動作を軽くするための工夫で紹介されていた動的に js ファイルを統合する仕組み Supercharged Javascript が、中々興味深い。
要は指定された js ファイルへのアクセスを PHP に送り、結合して送り返すのだが、これが中々良さそうだ。
多少、修正して当サイトにも実装してみたので、自分用にメモ。
時間が有るときに WordPress 用のプラグインとして利用できるようにしてリリースするかも。

続きを読む

コードのサイズを圧縮する!

JavaScript のコードから、不用な文字を削除してコードのサイズを小さくしようと言う提言。
JavaScript圧縮ツールや難読化ツールを用いれば、比較的簡単にできます。
これは、かなり効果が期待できるので、是非対応したいところ。
難読化ツールだと、バグフィックスが面倒なので、圧縮ツールを使えばいいかと思われます。
オリジナルと別に圧縮したコードをサーバにおいておいて、mod_rewrite で置き換えてやれば、メンテナンスも問題ないでしょう。

私が、試してみた圧縮ツールはこの辺り。

続きを読む

scriptは下に!

script がダウンロードされている間は、それより下に配置されたコンテンツはレンダリングされないので、script は可能な限り下に配置しましょうと言う提言。

言ってることは分かるんですが、中々難しいですね。
特に各プラグインが挿入している script タグは念入りにテストしないと、おいそれと下方に配置はできませんね。

ちなみに WordPress のプラグインで、ヘッダに JavaScript 等を挿入している箇所は
add_action('wp_head','hogehoge');
なので、ここを
add_action('wp_footer','hogehoge');
にしてやれば、下方に配置させることができます。
# ただ、JavaScript と同時に CSS も HEAD 内に吐き出してることが多いので、注意が必要。

CSSは上に!

すべての CSS がダウンロードされるまで、ブラウザでのレンダリングが始まらないため、CSS はできるだけ上に書きましょうと言う提言。
また link 要素を使用せずに @import で CSS を読み込んだ場合は、IE で一瞬 CSS が適用されずに素のコンテンツが表示される FOUC (Flash of Unstyled Content) と言う問題が起こります。

これについては、ウチのサイトでは問題は無かった。
普通、スタイルシートは HEAD の外に置くようなことは無いので、あまり気にしなくてもいいのでは?

ただ FOUC については初耳だったので、今後は気をつけるようにしたい。

コンポーネントを圧縮しよう!

最近のブラウザであれば gzip 圧縮されたファイルを送信すれば、ブラウザが圧縮解除して解釈してくれるので、できるだけ gzip 圧縮して送信して転送量を減らそうと言う提言。
CSS / JavaScript / html などのテキストファイルについては、結構効果的だ。
Wordpress の記事本文については、管理画面で設定変更することによって gzip 圧縮転送ができるが、CSS / JavaScript に関しては、設定してやらなければ gzip 転送はされない。

Web サーバとして Apache を採用しているならば、mod_gzip または mod_deflate を設定するのが、現実的だろう。

が、さくらのレンタルサーバでは、どちらのモジュールも使用できない模様。

続きを読む

Expiresヘッダを追加しよう!

コンテンツの有効期限を遠い未来に設定し、クライアントのキャッシュを利用して HTTP リクエストを減らそうと言う提言。
Web サーバとして Apache を採用しているならば、mod_expires を設定するのが、現実的だろう。

が、さくらのレンタルサーバでは mod_expires は使用できない模様。

続きを読む

HTTPリクエストの数を減らそう!

HTTP リクエストの数を減らすための具体的な方法と対応を考えてみる。

パッと思いつくのは、こんな感じ?

  • 分散している JavaScript / CSS を一ファイルにまとめる
  • 画像ファイルを減らす
  • できるだけクライアントにキャッシュさせて、ファイル要求を減らす

続きを読む

サイトのパフォーマンスチューニング

YSlow for FirebugThirteen Simple Rules for Speeding Up Your Web Site(日本語訳)にて、言及されているものについて一つずつ計測して結果を出してくれる。
これに対応すれば、かなりサイトの高速化が図れると言うシロモノだ。

基本的なポリシーは、

  • クライアント側のキャッシュを活用したり、無駄な HTTP リクエストを減らして、ネットワークボトムを解消しよう
  • ページレンダリングに関連するもの(CSS)は先に読み込ませ、関係ないもの(JavaScript)は後で読み込んで見た目の表示を速くしよう

ってな感じだ。

続きを読む