１．妥当性検証
敢えて言うまでも無い各ページのHTML/XHTML、CSS、RSSなどのバリデート（文書の妥当性検証）。
見た目では分からない問題を摘出してくれてハッとさせられることしきり。時にはプログラム的な問題を解決する手段にも。
２．性能検証
サーバやネットワーク、クライアント端末などの組み合わせや測定時の状態で、正確な性能を測るのは困難ですが、
少なくとも、内部的な”作り”に起因する性能問題はできるだけ摘み取っておきたいもの。
私の場合は、ここ（[^時間測定値^]）が結構役に立ちました。フッターあたりに表示しておくと便利です。
http://www.bodenplatte.jp/osscms/modx/modxtag.html
共用サーバの場合は、計る度に開きのある結果（時間値）が表示されますが、複数計測した結果の平均を取ることで
そこそこ信頼できるデータが取れます。
技術的な用語がよく分からない方のためにもう少し柔らかい説明を試みてみます。
・クエリー ： データベースに格納されているデータを取ってくる処理
・パース ： ページを作成するための処理（クエリーは除く）
・ページソース ： ブラウザから表示要求が来た時に、以前作り出したページ情報（キャッシュ）を使ったかどうか
"database" = キャッシュを使わずに表示した（プログラムがページを作り出した） ※速度性能＝一般的に遅い
"cache" = キャッシュを使って表示した（動的［未解決］な部分は補完される） ※速度性能＝一般的に速い
ページの表示速度を、この情報を基に調整しようとした場合、以下の順序で確認＆改善していくと、スムーズに作業が
進むかもしれません（ボトルネックを探してつぶす）。
ポイント１） 部分的にでもキャッシュされるはずのページが常に"database"なんてことはないか。
ポイント２） クエリー発行回数が予想以上に大きな数字を示してないか
ポイント３） クエリー時間とパース時間に大きな開きがないか（何十倍、何百倍など）
どうすれば改善できるの？となるわけですが、話は簡単。キャッシュの使用率を上げること。
語弊を恐れずに言えば、クエリー回数を極力０（ゼロ）に近づけること。ただこれも、無理をしすぎてパースに負荷を
掛けすぎると返って逆効果になる場合があります。
簡単なチェック方法は、まず、ページ設定の「キャッシュを生成」がOFFになってないか確認。その後、スニペットの
呼び出しで無駄にキャッシュ不可にしてるところを探して対処します（[! abc !] -> [[ abc ]]）。
次に論理的な対処やハードチューニングに向かっていくわけですが、これ以降は職人技の範疇になってくると思い
ますので、この場での言及は控えたいと思います。(
1/20加筆)
小ネタですがご賞味ください。（こんなこともいいよ・・・は継続募集中）
