「F5」でXHR通信結果が更新されない

通常、キャッシュが設定された外部ファイル取り込みは、その期限が来るまでは再通信されません。しかしブラウザをF5やCtrl+rなどで明示的にリロードした場合はその限りではなく、ファイルの再取得が行われるのが一般的です。
しかし、キャッシュ指定の条件によっては、XMLHttpRequestを用いた、いわゆるAjax通信時が発生しなくなってしまうとHttpWatchの記事で伝えられました。
これを検証するために、簡単なプログラムを作ってみます。

検証プログラムの説明

まずは、取り込まれるjsファイルを用意します。
サーバサイドで毎回ジェネレートされる、現在時刻を指定された要素に出力するだけのスクリプトです。

検証用スクリプト

呼び出す度に日時が更新されることが分かると思います。

そして必要なのはキャッシュコントロール。
パケット監視などが出来る人は見ていただけばわかるのですが、パラメータに応じて次のようなヘッダを付与します。

cache=1

キャッシュ有効。Expiresを30日後にし、Cache-Controlのmax-ageも30日間に設定します。

cache=-1

キャッシュ無効。Expiresを30日前にし、Cache-Controlのmax-ageは0とします。

cache=0

キャッシュ指定無し。ExpireもCache-Controlも指定しません。

ついでに、画像も用意してみました。同様にサーバサイドで現在時刻の画像を作成して返します。キャッシュ制御も同じです。

検証用画像

これを、テスト用のHTMLで取り込みます。
スクリプトは、scriptタグによる単純な取り込みと、XMLHttpRequestによるAjax通信の2種類。画像はimgタグで指定しています。
前述の3種類のキャッシュ制御を行うページは、次の通りです。

• キャッシュ無効
• キャッシュ有効
• キャッシュ指定無し

これで、ページを開いた時の時刻(正確には、サーバがリクエストを受け付けた時刻)が表示されるはずです。リロードや再訪問時に、キャッシュが効いていれば日時はキャッシュされた時のままになります。

順に見ていきましょう。

キャッシュ無効の場合

いずれの場合も期待通り、キャッシュは全くききませんでした。
ページ遷移を行った場合も、F5でリロードした場合も、全て最新に更新されます。

キャッシュ有効の場合

動作が分かれました。
通常にページ遷移を行った場合は、Opera10を除き一律にキャッシュが使われる期待通りの動作です。(Opera10はまだbetaのため、最終的にどういった仕様になるかは不明です)
F5などでリロードを行うと、画像やscript要素で取り込んだものは、いずれも再読み込みされます。
しかしXMLHttpRequestでの通信は、ChromeやFFでは再通信が行われるのに対し、IEとOpera9ではそのままキャッシュが有効になってしまいました。これはCtrl+F5のようなスーパーリロードを用いても、変わりません。

キャッシュ指定無しの場合

かなり無軌道になっています。Operaに至っては、通常のページ遷移でも動作に違いが出てしまいました。

ETagについて

StevesSuders氏の検証ではETagについても含まれています。
今回は検証結果を見やすくするために、レスポンス304については確認していません。
氏のページによれば、Safari4はIf-Modified-Sinceを送らずに常に再送信されてしまうようです。

まとめ

1. Expiresを指定しないことは、動作を全く制御しないのと同じこと。可能な限りきちんと、用途にあわせてキャッシュの制御を行うべきです。
2. Ajax通信でキャッシュをされたくない場合(多くの場合、この用途でしょう)、Expiresを過去に指定してキャッシュを無効にしましょう。
3. 或いは、通信にエポックタイムのようなユニークなIDをパラメータに付与し、キャッシュできないようにするのも良い方法です。
4. Ajax通信をキャッシュしたい場合、Expiresをキャッシュしたい期間、きちんと指定しましょう。ただし、その際にはF5でリロードしても更新されないブラウザがいることを知っておきましょう。
5. Operaを対応ブラウザにするならば、バージョン10がどのような仕様になるか注意しておきましょう。

No related posts.

今回は本書の5章から「へー」と思った、外部スクリプトを他のファイルのロードを妨げることなく取得し、なおかつそのファイルのロードが終わった際に後続のスクリプトが実行されるための方法(複雑)を確認してみます。

SCRIPTタグを減らすテクニック

この技法はまず、jQueryの作者であるJohn Resig氏のblogポスト Degrading Script Tags に端を発します。
まず、次のコードを見て下さい。

<script src="jquery.js"></script>
<script>
  jQuery(document).ready(function($){
    $("div").text("loaded!");
  });
</script>

これを、次のように書けたら幸せだよね、という話。

<script src="jquery.js"></script>
  jQuery("div").text("loaded!");
</script>

これなら、SCRIPTタグが少なくて済むし、コードの依存関係もハッキリする。srcに記述されたファイルのロードが失敗したら中身のコードが実行されない形なら、万が一の場合にもスクリプトエラーにならずに済むと。

次のようなコードを外部ファイル(この例で言えばjquery.js)の最後に加えれば、これが実装できます。

(function(){
var scripts = document.getElementsByTagName("script");
var curScript = scripts[ scripts.length - 1 ];

if ( curScript.executed )
  return;

// ... jQuery ...

curScript.executed = true;
var script = curScript.innerHTML;
if ( script ) {
  jQuery(document).ready(function(){
    jQuery.globalEval( script );
  });
}
})();

もちろんこれは、jQuery以外のライブラリでも適用可能な、非常にクールな手法です。
正直なところ、自分は最初のこのポストが投稿された際にはそれほど感銘を受けなかった記憶があります。それは「スクリプトのロードと実行が連動する」点に私が着目できていなかったからで、単にscriptタグを減らせるシンタックス程度の認識しかありませんでした。
今回改めて読み返してみて、直観的な良い記述方法だなと思いました。

他ファイルのロードブロック問題

見たように素晴らしいテクニックなのですが、この方法にもまだパフォーマンスの観点から改善の余地があるとSteve Sounders氏は指摘しています。
それが、スクリプトのダウンロードが他の外部ファイルのダウンロードをブロックしてしまう問題の回避についてです。

前述のテクニックはjsファイルのロードについては通常の方法であるため、ブロックは発生してしまいます。これを避け、なおかつロード完了とスクリプト実行がきちんと連動するように改良されたスクリプトが、こちらで紹介されています。

function init(){
  jQuery("div").text("loaded!");
}

var domscript = document.createElement('script');
domscript.src = "jquery.js";
if ( -1 != navigator.userAgent.indexOf('Opera')){
  domscript.innerHTML = 'init();';
}else{
  domscript.text = 'init();';
}
document.getElementsByTagName('head')[0].appendChild(domscript);

この呼び出し方と前述のテクニックを組み合わせることで、高速な外部ファイル呼び出しと、そのロード完了に依存するスクリプトの記述が可能になります。

但し、この方法を使うには外部ファイル側に自要素の中身をコールバック(?)する仕組みを埋め込まなければならず、汎用的に使うのは難しくなってしまいます。
将来的にこの記述をブラウザ側がサポートしてくれた場合であればまだしも、現時点では同書の別項で紹介されているOnload技法の方が優れているとしています。
こちらの検証は、また機会があれば。

Related posts:

1. [Javascript] nullとundefinedとfalseと0と空文字と
2. [Web] Google Page Speedでサイトを高速化(3)

今回は個人的に最も良かったパメラさんのGoogle Maps高速化セッションから、大量マーカーの効果的なプロット方法…は、また今度時間がある時にして、その際に彼女がポロっと漏らした「+=は-=に比べて遅いし」を軽く検証してみました。（FOXでアメリカン・アイドルを観ながら）

検証は、ループカウンタをアップしていく/ダウンしていく方法で比較しています。

※2009.09.27
検証プログラムの問題を指摘いただき、末尾に追加してあります。

検証プログラム

/* (1) sum */
var s = get_ms();
for(var i=0; i<arr.length; ++i){
  arr[i] = i;
}
var e = get_ms();
dump(e-s);

/* (2) subtract */
var s = get_ms();
for(var i=arr.length; i>0; --i){
  arr[i] = i;
}
var e = get_ms();
dump(e-s);

get_msはミリ秒を取得する関数、dumpは結果を出力する関数として用意しました。arrは、500,000個の添え字を持つ単純な配列です。
これを、公平を期すために同一プロセス内で交互に実行します。結果の単位はミリ秒となります。

結果

[Firefox3.0.1]

(1) 107
(2) 92
(1) 106
(2) 92
(1) 107
(2) 90
(1) 107
(2) 92

足し算、引き算の順です。

[Internet Explorer 7]
IEはFFに比べてこの実験では遅く、しかも「スクリプトの実行に時間が…」というエラーが出てしまいます。止める方法はあるのでしょうが、調べるのも面倒なので、配列のサイズを200,000に減らし、繰り返し回数も減らしてあります。

(1) 110
(2) 94
(1) 125
(2) 93
(1) 110
(2) 93

まとめ

疑う余地はなく、減算の方が高速という結果が出ました。FF2やIE8などはTV前のここの環境には無いので試していませんが、傾向としては充分だと思います。
特に大きなループでは可能ならば和算よりも減算を使うようにするのが良さそうです。

なお、カウントダウンでのループが可能なアルゴリズムであれば、比較演算も省略できる次の形の方が、より高速でした。

/* (3) while-subtract */
var s = get_ms();
var i=arr.length;
while(--i){
  arr[i] = i;
}
var e = get_ms();
dump(e-s);

[Firefox3.0.1]

(1) 110
(2) 91
(3) 77
(1) 106
(2) 92
(3) 77

コード量も少なく、お勧めの記述です。

2009.09.27追記

コメント欄で指摘をいただきました。
初歩的なミスで、lengthの評価回数が釣り合っておりませんでしたので、改めてやってみます。

var len = arr.length;

/* (1) sum */
var s = get_ms();
for(var i=0; i<len; ++i){
  arr[i] = i;
}
var e = get_ms();
dump(e-s);

/* (2) subtract */
var s = get_ms();
for(var i=len; i>0; --i){
  arr[i] = i;
}
var e = get_ms();
dump(e-s);

結果

[Firefox3.5.3] (500,000ループ)

(1)100
(2)97
(2)100
(1)95
(2)100
(1)97

[Internet Explorer 8] (200,000ループ)

(1)47
(2)62
(1)47
(2)62
(1)47
(2)63

[Chrome 2] (5,000,000ループ)

(1)29
(2)26
(1)29
(2)26
(1)28
(2)25

再まとめ

結果、FF3.5やChrome2では傾向は変わらないものの、その差は縮まりました。
また、IE8では寧ろ加算の方が速くなっています。
前回テストした際のバージョンに該当するブラウザが手元に無いので比較実験になっていませんが、加減算の速度差は気にするほどではないと言えるかもしれません。

No related posts.

大抵の、特に変数の型宣言を行わないタイプの言語では、型の異なる値の条件式は悩みの種です。
Javascriptもご他聞に洩れずというか、undefinedとnullが異なる分だけ更にややこしくなっているようです。
暗黙の型変換で痛い目にあわないよう、ちょっと実験してまとめてみます。
実験にはとりあえず、手っ取り早いので Jash を使用。
一緒に試してみるならば、こちらのBookmarkletをクリックしてコンソールに入力しながら読むとわかりやすいかもしれません。

nullとundefined

nullとundefined。たまに「同じもの？」と聞かれることもあるので、とりあえず確かめて見ます。

>> null==undefined
true

あれ、同じでしょうか？

>> null===undefined
false

もちろん違います。
しかし、== 演算子で比較する限りは「同じ」と言ってもよいようです。
では、実際は何が違うのでしょうか？typeofで確認してみます。

>> typeof null
object
>> typeof undefined
undefined

nullはobjectなんですね。
根本的に型が違う（undefinedには型が無い？）ようです。

演算子: ==

ではこの == という曖昧な演算子について検証してみます。
登場人物はfalseと、それと等しくなりそうな7つの値「undefined」「null」「”(空文字)」「0(数値のゼロ)」「’0′(文字列としてのゼロ)」「”\n”(改行)」「” “(スペース)」。
先ほどのように、それぞれを == で結んでみましょう。

>> false==null
false

全て試したマトリックスが次のものです。（undefはundefined）

さて、いかがでしょう。
かなりの無秩序さにゲンナリです。
かろうじて文字列同士はキャストが行われない分だけ理解しやすいですが…つまり、ここで挙げた文字列は全てfalseや0と等価になるものの、お互いは等価にはならないと。

演算子: ===

では、型まで含めた === 演算子を用いた場合はどうでしょう。

>> false===0
false

これは、予想通り全ての異なる値間で false となりました。
厳密な比較を行うのならば、やはりこれを使うのが良さそうです。

演算子: !

では、if文の中での暗黙の条件式はではどうでしょう。
前項で false との等価比較だったので、あわせてここは「!」を付けた条件式に真と評価されるかどうかを試してみます。
わかりにくいですね。つまり例えば undefined のテストであれば、次のような式で試したということです。

>> (!undefined ? true : false)
true

先ほどと同じ値を用いて試したのが、次の表です。

なんと、 == 演算子のどの列とも合致しない結果です。
つまり、こういうことなのですね。

>> hoge=null
null
>> (hoge==false?true:false)
false
>> (!hoge?true:false)
true

まとめ

では、実際にはどうコーディングすれば安全なのでしょうか。
動きをある程度ちゃんと把握していれば、あとは用途にあわせて…という言い方に結局はなると思います。
しかし、型が怪しい場合は極力 == は使わない方が良いと言えそうです。

未定義の変数を調べる場合は typeof を使う

( typeof v == 'undefined' )

型を意識して正確に比較するなら === を使う
当然のことながら。
しかし実のところ、Javascriptでこういったケースはあまり多くないと思います。

テキストボックスに入力があるかを確かめる場合
これは、よく見ると結構難問です。
純粋に文字列が全く入っていないことを確かめるならば、=== を使えば確実です。

( text.value==='' )

しかし、この場合は空白や改行が入っただけでも条件をパスしてしまいます。
trim関数が標準で無いので、これはそれなりに厄介。
では、意外とこれではどうでしょう。

( text.value==false )

問題は、「0」や「000」と入力された場合に未入力と判定されてしまうことです。
ここはやはり、正規表現などを用いるのが良さそうです。

まとめてみましたが、あんまりスッキリしませんでした。

Related posts:

1. [PHP] 論理演算子「and, or」と「&&, ||」の違い