(^^)v3: 改めてNanoBloggerで思うこと

世界を造り替えることはできない。自分自身をすら、真の意味では造り替えられない。新に造り直せるのは、行動だけである。 - アリス・ウォーカー

2006年05月06日 21:03

改めてNanoBloggerで思うこと

NanoBlogger（以下NB）というソフトをいじり始めてこのソフトを使ったブログサイト構築（大袈裟）に関して使い始めて分かったことというのがある。覚え書きとして書いておこうと思う。

ブログの軽さ。これは結構大きい。もともと「(^^)v2」というiBlogを使ったサイトを作っていた。というかまだこいつは閉じたわけではないけど。このサイトと、NBで作ったサイトを比べて、読み込みに要する時間はやはり小さくなっている。前サイトでは要所要所でJavaScriptを多用していた。JavaScriptを使うことで、様々な表示を自動化させていた。ところが、サイトが大きくなってくるにしたがって、JavaScriptのサイズがどんどん大きくなってきた。Movable Type（以下MT）というブログツールがあるが、アレはサーバーサイドでデータベースを動かし、クライアントへどんなデータを返せばいいか判断させているという代物。対して、サーバーサイドで加工が事実上不可能である.Mac(iDisk)を使っている會澤としては静的なファイルを配置するしかないわけだ。iBlogというツールは静的なファイルに相互関連付けをするために、また動的要素を加味するためにJavaScriptを使用しているわけだが、JavaScriptというのはクライアントサイドで動くと言うことでクライアントに負荷をかけることになるわけ。また、読み込ませるJavaScriptファイルが大きくなれば当然、クライアントが読み込むべきファイルの大きさは大きくなる。何と、今確認したら、「(^^)v2」は単純にhtml+JavaScriptのファイルサイズは250KBにも達していた。これには読み込むべき画像ファイルは含まれていない。これは大きい。

ファイルサイズが大きいだけでなく、読み込んだあとにクライアントサイドではhtmlレンダリングとJavaScriptの解釈という動作が加わってくることになる。最近のパソコンは処理能力が高く、そんなこと気にする必要はない。という意見もあるかもしれないが、負荷をかけずに済むならそれに越したことはない。どのみち個人のサイトに見た目や派手さなど関係ない。ブログサービスのテンプレートをカスタマイズせずに使っている人も多いしね。

企業のトップページなどではフラッシュアニメーションが多用されていたりどうやって作っているんだ？というようなデザインをしているところが少なからずある。メディアになっているわけでそれはしかたないのかもしれない。しかし、ではその１ページから得られる情報はいかほどのものか。実は結構少なかったりする。見た目重視というかそこにこだわるがあまり...とは言い過ぎか。チョット横道にそれてしまった。

NBで作られた現在のトップページは50KB強といったところ。前サイトに比べて、実に５分の一です。これはなぜか。JavaScriptを使って実装していた機能をつけていないから？　イヤ、そうではないんですよね。前にも少し書いたかもしれないけど、NBというのはiBlogがJavaScriptを使って実装していた機能を會澤のメインマシンであるCube上で展開してあらかじめファイルに組み込んでいるんですよね。このブログのサイドバーに「recent entries」というのが用意されています。これは、ソースファイルを見ていただければわかりますが、単純なリンクの羅列になっています。iBlogではどうしていたかというと、すべてのエントリのIDとタイトル文字列、リンク先アドレスを決定できるカテゴリIDなどをリスト形式で持たせて最新から何個表示させなさいというJavaScriptを使っていたわけ。MTの場合も、同じような処理が行われていたことになる。ただし行われていたのはサーバーサイド。

MT………サーバーサイドで処理を実行。
iBlog……クライアントサイドで処理を実行。
NB………発行者の側で処理を実行。

極めて簡単にいえば上記のようなことになる。閲覧者側から見れば最新の何エントリかが表示されていれば「recent entries」としては同じことなわけですね。処理方法（処理場所）は異なるかもしれないけど、結果は（見た目は：機能は）同じ。

どれがいいのだ。というつもりはありません。NBを使い始めた頃に比べてエントリ数が増えてきて登録処理が完了するまでの時間がどんどん長くなってきているのが非常に気になる点になってきました。クライアントサイドでは読み込みも早いし、機能的にも(^^)v2と大差ないんじゃないかと思います。閲覧者にとって・サーバーにとって・発行者にとって。それぞれ利点・弱点があって当然です。會澤はMTを使っていませんが、NBを使い始めてそんなことをボーッと考えてしまいました。

中身を見ることで、作成プロセスが理解できるというのは非常におもしろい。エントリ数が増えてきたことに伴って処理速度が遅くなってきた。これを何とかするためにどうすればいいだろう。中身を見てみると、汎用的に作られているが故にずいぶん余計な処理をくり返していることに気がつく。特に、中間ファイルを数多く作っている。トップページ用、カテゴリページ用、パーマリンクファイル用。マンスリーアーカイブ用等々。これを、テキストファイルで保存しているエントリ内容を次々に引用しながら作成しているのですね。汎用的に作るという趣旨からすればそれはある意味当然なんだろうと思います。しかし、個人用にカスタマイズするときには特化させることも可能だろうと思います。例えば、シェルからDBにアクセスして、エントリのタイトル・要約・内容などを取得できれば、テキストファイルから変形させて作る作業の処理が簡略化され、速度も上がるのではないか。MTが採用している方法を使うわけですね（DBとのれんけい）。ただ、そこまで會澤のスキルは追いついていません。とはいえ、考えてみるのは自由。自由に変更できるのはNBの大きな利点。おもしろいなぁとつくづく思っております。

このエントリに頂いたコメント。この表示は随時更新されます。

by OKAMURA(2006-05-07T16:18:55-05:00)

そうなんですよ。iBlog のサイトってエントリが増えてくると JavaScript が正比例して大きくなって、処理量は下手すると(iBlog オリジナルでは下手してます)その三乗に比例します。

これは長年続けていると破綻するオーダーというのが今僕が注目している最大の iBlog の弱点なんです。

iBlog でも JavaScript 不要のサイトを作ることはできますが、ユーザビリティは相当後処理をしないと高くなりません。JavaScript というかそのデータを XML で分散させて改善するプランがあるのですが、これは結構高度な JavaScript と全体の計画性がないと難しいです。

# 僕にはフリーで作る日曜大工の範疇では

# 面倒くさいなあが先に立ってしまいます。

Thingamablog に期待をかけているのも実はこの辺もあって、Thingamablog には簡易 DB が内蔵されているんですね。それでローカルでの処理もエントリ数に対して強くなっているんじゃないかと。ところが、一定以上を望むと Java プログラミングの領域になるのでこれまたフリーの範疇では頭打ちです。

by 会沢＠会社から(2006-05-08T01:48:01-05:00)

iBlogに関しては正直そろそろつらくなってきています。

NanoBloggerは出来上がったものはスマートですがローカルの処理がかなり重いですね。

ThingamablogはJavaがネックになってさわってもいません。

何とか.Mac(iDisk)を使い倒してやりたいので悪戦苦闘してみます。

コメントを書き込むためには、下の「Comments」リンクをご利用下さい。