CGIサイトの方のレイアウトをスマホに合わせるために試行錯誤。
　User-Agent Switcher for Chromeというプラグインで、Chrome上に複数のスマホをエミュレートできるのが便利だった。これで確認しながらデザイン変更していった。
　翌日(昨日：棒グラフ右端)急激にアクセスが増えてPVが9千近くまで行ったが、サイト全体を更新したからロボット巡回が激しくなっているだけかもしれない。詳細見ていない(見る気がしない)。今日以降のアクセスがどうなるかでおのずと分かってくるだろう。転送量は余裕ある。
　WEBデザインは気にしだすとホント難しい。「正しいデザイン」とは何かと考えるより、「より良いデザイン」は何かと考えるべきなんだろうけど。それでも簡単じゃない。たとえば、眼が疲れないデザインは？

　なんやかやしている内に、このブログの上部広告を元に戻してしまった。日付表示の方をサイドバーに移動。

追記(2014/03/04)：
　その後アクセス数乱高下。スマホ対応は必ずしもうまく行っていなかったようだ。さらに修正した。一旦様子見したい。

追記2(2014/03/05)：
　アクセス履歴採って詳細見てみた。google bot のiphone版が来ていた。そんなの初めて見た。反応を軽くするためにCGI側のアクセス記録機能を切っていたのだが、今回forkによりバックグラウンドで処理できてるみたいで、そんなに重くなってない気がした。アンドロイドを強制的に大フォントページに飛ばすと、アンドロイドの大型タブレットでも大フォントで読むことになってしまうわけだが、もとに戻すわけにも行かない。あちらを押せばこちらが...。今回の対応は簡易で、本格的なスマホ対応ページはちょっと無理目か。

追記3(2014/04/08)：
　新機能をつけたためかじりじりPVが上がってきていて、検索サイトのロボット巡回を除いても1万近く行くようになってきた。眠い時に手直ししていてひどい間違い。こんなことをしてるとサイトの信用を失うなぁ。PVが10万くらい行ってしまえば事態がはっきりするんだろうけど、今はまだゆらゆらあわいのような段階が続く。
　PV増加に加えて、新機能が常に特定のファイルを呼び出すこともあってか、転送量が跳ね上がっていて、1日1ギガバイト行くこともあるようになった（つい先月までずっと1日400メガバイトくらいだったのに）。特定ファイルは予めgzip圧縮してありその上での数字。サーバの方の転送量上限は1日40ギガだからまだまだだが、一度ためしにhtml送出に伴うgzip圧縮を切ってみたら1日3ギガも行った。その他の状況を勘案しても、gzipはtxt系のデータならだいたい1/3くらいには圧縮してくれているという感じであろうか。やはりgzip圧縮は重要。
　アクセスログ見ると検索エンジンからの巡回を制御するrobots.txtが効いてない感じが強くする。マニュアル通りにしてるつもりだが...??

追記4(2014/04/10)：
　改良の方向として、むしろシステムをより「ほったらかし」にできるようにすることを目指した方がいいように思えてきた。すでにある程度自動化されてるけども。自動処理が盤石なら、余程じゃなければ人の増減も気にならないし、当然労力的にも負担ではない。そこまで急激に人が増えるということもないだろう。あってもたまにチェックしていれば気づくだろう。作っていてなんだけど、自分自身でよく見るサイトではないということも大きいというか、あるいはネット広告が一定の収益を上げているならまた別なのだろうが(サーバ代くらいは出てるけども...)、距離感がしっくり行ってないのが一番の問題かもしれない。元々perlのSocket接続で遊んでいて妙に発展してきてしまったけど、なんか持て余してる感がないではない。