swk's log

* トラックバック [logging]

とりあえず用意してみた．tb_standalone です．ちゃんと動くんだろうか．詳細はまた後日．

* ちょっと通りますよ [misc]

実写版．

• http://nini.blogtribe.org/entry-87c2cefe202ec694d7dd0681575c73da.html

* さよなら JavaScript feed [logging]

くっつき BBS を SSI (server-side include) 化してみた．ってもしかして既に「くっつき」と呼べなくなってますか? 作者さんに怒られそうだ…．一応このような改造をしようと考えた理由を議論しておこう．

一言でいうとページ表示の速度改善が目的．もちろんメリット・デメリットがあって，このサイトにとってはメリットの方が大きいと判断したというだけ．

まずメリット: くっつき BBS が採用する CSI (client-side include) だと， include ごとに js ファイルを取ってくるための HTTP request/response が発生する．大抵は日ごと，あるいは記事ごとに include する使い方なので結構な数になる．ブラウザがそれらを受け取ってレンダリングを完了するまでユーザは待たされる．レスポンスの悪いサーバだとこれがかなりいらつく．SSI 化すればこの点が改善される．(というわけなので，インライン画像などをいっぱい貼っているサイトだと，いずれにせよ HTTP トラフィックが多数発生するので，改善率は低いと思う) あとは当り前だけど， JavaScript が使えないクライアントでも大丈夫．

逆にデメリット: サーバに HTML ファイルを parse するための負荷をかけてしまう．HTTP のハンドリングよりこっちの方が遅い状況だと，上記メリットが完全にスポイルされる．でも普通に考えて，かたや system call をばりばり呼び出すネットワーク処理，かたやユーザ空間で閉じた単純な文字列マッチング，後者の方が重いという状況は限られていると思う．よっぽどでかいファイルで，かつ含まれている include の数が少なかったりするとこれが起きるかな． あとはこっちも当り前な点として，そもそも SSI が使えるサーバじゃないと使えない．

というわけでケースバイケースなんだけど，うちの場合は明らかに SSI の方が向いている．ちゃんと測定してないけど体感速度で 1 桁は違う感じ．結果として，javascript feed は一切なくなりました．今後どうなるかわからないけど．

変更点としては，kuttukibbs.cgi の中で js ファイルを書き出すところで生 HTML も別ファイルに書き出すようにしておいて，呼び出したいところで <!--#include virtual="..."--> するだけ．注意点としては

<!--#config errmsg="" -->

を入れておくってのがミソ．これがないと include するものがないときにエラーメッセージが表示されてうっとうしい．