低速回線(ISDN128K)向けのPCサイト(静止画・テキストからなるWebアプリ・AJaxで一部項目を常に更新させたい)をこれから作成することになりました。この環境下でもできるだけ快適に利用できるようにする為に、抑えておいた方が良い点がまとめられているサイトを教えてください。経験者の方のみお願いします。

サイズをできるだけ 抑えればいいです。

静止画も 大きさを小さくし、画質も悪くする。
デザインは 基本的に 文字(キャラクタ)で行えば
かなり サクサクとなるでしょう。

サイトの閲覧端末はここ数年で発売された、そこそこ性能のいいものですね。

となると、データによっては処理された容量の大きいものではなく、生のデータを送り、それを組み立てるようなタイプのウェブページの方がいいかもしれません。

例えば、いちいちtableタグを送信するのは無駄なのでcsvファイルをテーブルで表示させるjavascriptとcsvファイルのみを送る。

http://javascript.webcreativepark.net/library/csv2table

静止画がどのようなものなのかにもよりますが、単色のものの組み合わせならpngなどを利用するのがいいかもです。

http://www.gizmodo.jp/2010/10/jpgpnggif.html

画像が複数ある場合はCSS spriteなどで複数の画像を1つにまとめるのも有効です。

画像が10枚、20枚ある場合はヘッダの文章の量もシャレにならないので。

http://ja.spritegen.website-performance.org/

回線速度が10倍の場合、小さい容量のものなら0.01秒と0.1秒ではあまり体感時間に差はありませんが、0.5秒と5秒では体感時間にとても差があります。

帯域の狭さは端末のスペックでカバーするつもりで、とにかく通信データを削るつもりで作成することを心掛けるほうがいいでしょう。

離島のお客様向けの業務Webシステム（INS64使用）を構築した経験があります。

ポイントは2つです。

1. データ転送量を減らす。
2. 同時セッション数を制御する。

１ですが、マルチメディアデータ（動画、音声など）を使わないことが第一です。
静止画については、100kb×３～４本ならそれほど重くありません。

２ですが、１ページあたり、コンテンツ本体と画像データ３～４本に絞ることができるのが理想です。
自身でセッションを制御できない広告サイトや、ソース不詳のJavaScriptを埋め込むことは避けるべきです。

動的コンテンツは、あらたな通信が発生しなければＯＫです。
たとえば、サーバサイド（RubyやPHPなど）で動的にコンテンツを作ったり、クライアントサイド（HTML5やJavaScript）でコンテンツを動的に変更するのは大丈夫です。サーバ間通信は問題ありませんが、Ajaxとかでクライアント側に新しい通信が発生するのは避けるべきです。
クライアントがIE10／Chrome26ということなので、クライアント側でかなり動的なコンテンツを作ることはできそうです。

こういうノウハウを纏めたサイトは少ないです。
軽いサイトをキーワードに探すと、単純にコンテンツ容量の軽いものになってしまうので、今回の質問にはマッチしないと思います。

画像を最適化するという点では、下記サイトが参考になります。
http://www.adobe.com/jp/devnet/dreamweaver/articles/smartphone_web_part4.html

作成しようとしている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

制約というのは同時接続数です。
クライアントから最低１本の接続がつながりっぱなしになるので、Webサーバでは通常のトラフィックをさばく分に加えて、クライアント台数分の同時接続を保証しなくてはいけません。
通常のWebシステムよりも多めに同時接続を保証しなくてはいけないのでサーバのスペックや個数、メモリ搭載容量に影響が出てきます。
ただ文面からクライアント数はそれほど多くないのではないかと想像できるので、十分検討の余地はあると思います。

軽いホームページを作るには
http://www.suita.ed.jp/edc/bunsho/hp/make_hp02.html#top
こちらを参考にしてみるのがいいと思います。