2015/01/20(火)ECO-Wiki画像リサイズ
ECO-Wiki画像リサイズ
こちらの記事(ECO-Wikiでの画像縮小・拡大)でふれていた、ブラウザ側でリサイズされていた画像について、一部*1をリサイズ済みの画像と差し替えました。元画像は、サフィックス _big を付けたファイル名にリネームして残してあります。
- 例
ECO-Wiki上の画像サイズ指定について
画像差し替えの際に、画像の実サイズと表示サイズを一通りチェックしたのですが、想像していた以上にいい加減でした＾＾；
例としては、
- 実サイズ：177x111 → 表示サイズ：100x100
- 縦横比が合っていない
- 実サイズ：128x128 → 表示サイズ：127x127
- 周りの画像は表示サイズ128x128に統一しているのに何故か1ピクセルだけ縮小
- 実サイズ：128x123 → 表示サイズ：123x128
- 縦と横が逆
単純ミスのものもあるでしょうし、既存の記述をコピーして修正したときに画像サイズ指定をそのままにしてしまったという可能性もありそうです。不特定の人が編集する場合は、画像サイズ指定は省略した方が無難なのかもしれないですね*2。
画像アップローダーは実サイズを指定した&ref記述を生成するので、これをそのまま使ってくれる分には問題はなさそうですが。
「アンケートページ：今後の ECO wiki について」のコメント
最近、「アンケートページ：今後の ECO wiki について」をチェックしていなかったので気づくのが遅れましたが、
装備品データベース等を面倒ではあるが独立したWikiとしての公開をするべきと思う
acroniaでは別のサイトに飛ぶが検索する閲覧者に酔ってみれば使い勝手が良い物とは言えない
というコメントが付いてますね。
ただ、このコメントの意図がよく分からないです。
- 「検索」がWikiの検索機能を指す場合
- 独立したWikiでは検索は結局別々なので解決にならない。
- 今のECO-Wikiに含めるなら検索はできますが、ECO-Wikiが肥大化しかねない。
- 「検索」がGoogle等の検索を指す場合
- データベースが検索にかかるようにすることを考えるべき。*3
あと、データベースにしておかないと、細かな条件を付けた検索や、データの機械的な再利用が困難になるので、よほどの事が無ければデータベース化が望ましいと思います。
・・・というか、Wiki管理だと数が多すぎて破綻しそう＾＾；*4
2015/01/08(木)圧縮転送による読込時間改善、他
圧縮転送による読込時間改善
以前、ECO-Wiki (acronia) でページ生成時間を表示するようにしましたが、内容が多いページではかなり時間がかかっているのが気になりました。
例えば、Iris/Explanationでは
HTML convert time: 0.007 sec. (total: 2.447 sec.)
と数秒かかり、実際に体感できるロード時間も同程度です。
これは、Iris/Explanationだとページ(HTML)サイズが約700kBとちょっとした画像並みに大きいため、単純に転送に時間がかかっていると思われます。
そこで、転送データをgzip圧縮して転送量を削減してみることにしました。さくらのレンタルサーバーは半年くらい前からmod_deflateが使えるようになったらしいので、以下の記述*1を .htaccess に追記します。
<FilesMatch "\.php$"> SetOutputFilter DEFLATE BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html AddOutputFilterByType DEFLATE text/html </FilesMatch>