作成しようとしているWebアプリケーションのイメージがいまいち分かっていないので、見当違いの箇所については指摘してください。
私が一番重要だと考えるのは、ブラウザのキャッシュをきっちりと効かせることだと思います。
そのためには、静的なリソースと動的なリソースをきちんと分けて設計することです。
CSS や外部スクリプトファイルは、もちろん静的なリソースですが、CGI や php スクリプトで返されるデータについても、例えば、登録された画像などについては、更新の頻度を考えて Expire ヘッダや Cache-Control ヘッダをきちんと制御して、キャッシュが効いてあげるようにすべきです。
(文面から、登録される見取り図は頻繁に更新されないのではないかと思っています。)
静的なリソースについては、一ページ当たりの個数を減らすことです。
ブラウザはキャッシュが有効かどうかを判断するためには、一度問い合わせをして、302 ステータスで判断します。
この問い合わせの数が少なくなるように、CSS や外部スクリプトファイルを統合して、数を減らします。
CSS Sprite は、この最たるものだと思いますが、業務用のアプリケーションのようですから修飾のために画像を使わない方が賢明だと思います。
(CSS Sprite は結構面倒なので。)
また、問い合わせが CGI だとしても、データを返す必要が無ければ 302 ステータスを返すべきです。
利用者から登録された画像や、その情報はデータベースに保存するのだと思いますが、単純に検索結果を返すのではなく、登録日を確認して 302 ステータスを返すようにひと手間くわえる方が良いと思います。
このあたりは、ブラウザの設定でもある程度手を抜くことが可能です。
例えばIEであればインターネット一時ファイルと履歴の設定で「Internet Explorer を開始するたびに確認する」または「確認しない」を選ぶと、通信量は劇的に減ります。
その代わり、URL とデータの結びつきが強くなってしまうので、常に新しいデータを返さなければいけないような問合せでは、パラメータに時刻を入れるなどしてURLが常にユニークになるように設計する必要があります。
もうひとつ思ったのは、状況の監視のような画面を作られるようですが、ある程度の制約がありますがプッシュ型の仕組みを検討しても良いと思います。
http://ja.wikipedia.org/wiki/Comet
制約というのは同時接続数です。
クライアントから最低1本の接続がつながりっぱなしになるので、Webサーバでは通常のトラフィックをさばく分に加えて、クライアント台数分の同時接続を保証しなくてはいけません。
通常のWebシステムよりも多めに同時接続を保証しなくてはいけないのでサーバのスペックや個数、メモリ搭載容量に影響が出てきます。
ただ文面からクライアント数はそれほど多くないのではないかと想像できるので、十分検討の余地はあると思います。