http://www.vector.co.jp/soft/dl/win95/art/se257813.html
チビすな!!のダウンロード : Vector ソフトを探す!
CM用のjavascriptが重いのかなぁと思いますが、
実際に そんなに 遅いとは 思いませんね。
試せるならば javascriptをはずしたもので表示時間を計測してみたらいいでしょうね。
また、サイズの大きい画像のサイズを減らすなどしたらいいでしょう。
縦横のサイズは、そのままで容量だけ減らせるソフトもあります。
http://server.hypertown2000.net/index5.html
レンタルサーバーのバックボーンとは??
バックボーンが細いということに尽きると思います。
ユーザーがはてなに貢献して太いバックボーンにつないでもらえば速くなるというのが回答になってしまいますが、それでは話になりませんね。
表示が遅い場合、更新ボタンをクリックしてみたり移動ボタンをクリックしてみたりすると思いますが、そのとき、単に、なかなか表示しないウインドウをそのまま更新させるより、一旦中止ボタンを押してから更新をクリックすると無駄な待ち時間が減るようです。
私の経験では、なかなか表示しないウインドウをそのままにして新たなウインドウを開いて同じURLにアクセスすると、新しいウインドウの方の表示が完了しても古い方のウインドウは真っ白なままということがよくあります。
どこかで引っかかっているという感じですね。
ですから、そのまま待つより新ウインドウを開くか、一旦読み込みを中止してから再読み込みするといいと思います。
> ユーザーがはてなに貢献して
え?はてなは関係ないと思うのですが・・。
す、すみません。
ウインドウが最大表示でない状態で質問一覧を見ていたので、「
http://www.f1racing.net/ja/index.php
F1Racing.jp 2006
」が別の質問のように勘違いし、このはてなの表示速度だと思ってしまいました。
ポイント、お返ししますね。
ご質問のサイト、フラッシュが2箇所使われており、そのうち1つ(F1レーシングの広告)は動きが速いですよね。
この表示にもたついているんだと思います。
また、私のPCで見ると、1.6GのDELLだと他サイトより表示が遅く感じるのですが、400mhzのMacG3で見ると特に遅くありません。
このことから考えると、描画の速いグラフィックボードに交換するか、ブラウザをFLASHに非対応の状態にしてしまうことが対策になるんじゃないかと思います。
んー。このサイト固有の問題だと思うのですが・・。当方光ですので、重さ云々ではありません。マシンスペックもコンシューマ向けでは最強に近いでしょうから考えられません。単にプログラム(PHP)か何かだと思うんですけども。
ソースが長すぎると、レンダリング(ブラウザが画面表示するための計算)時間が長くかかるので、もっともっとシンプルな構成にすることをお薦めします。
特に後部のScript部分は重くなる原因ですから、クライアントサイドスクリプトに頼らない設計に考え直す事をお薦めします。
あ、私のサイトではないんですけどね。
http://www.pat.hi-ho.ne.jp/dimension/tips/tips_mmcache.shtml
Turck MMCacheを導入してみる - キャッシュでパフォーマンスUP - Do You PHP?
基本的におっしゃるとおりPHPによるサーバサイドの話では無いかと思います。ですので、想像の部分もありますが…遅い理由。
・下の部分(more news)および、右側のテストスケジュールの部分はおそらくDBにデータが登録されていて、動的に作成しています。理由としましては、それらのリンクが固定のURLではなく、URLパラメータでIDを渡すことによって生成しているからです。
・指定の”index.php”はおそらくもっとも最新のnewsIDを表示しているので、他のニュースをクリックしたときと同じです。
・この手のサイトは基本的に画面一つを作るのではなく、それぞれの”パーツ”をサーバで組み合わせているものと思われます。アクセスがあるごとに
「それぞれのパーツ(ニュースとか、ランキングとか)の計算⇒組み合わせて一つのPHP」という流れが行なわれています。前のパーツの計算が終わらないと次のパーツの計算がされないために遅いかもしれません。
・あと、adのフラッシュ(メニュー左下の縦長のやつとページ真ん中にある////スポンサー////の下にあるやつ)は両方ともキャッシュされませんので、アクセスするたびにadtechという広告の会社のサーバにアクセスに行っています。
改善策は問題によっていろいろありますが、
・基本的にはアクセスのたびに全て動的に計算するのではなく、ある程度、サーバ側でキャッシュする(オブジェクトキャッシュ、DBキャッシュ)。特にパーツの部分はある程度のキャッシュが可能。
・DBがちゃんと正規化されているか、indexが適切か
・DBの呼び出しが適切か。(テストスケジュールはおそらく最新10件表示なのだが、一回全部検索してそのうち10件を表示する、といったことをしていないか)
・phpのコーディングに無駄がないか。(ループ文のネストが過ぎないか)
といったところでしょうか。見る側だとどうしようもできないものばかりですが。
なるほど〜。勉強になりました。ありがとうございました。
画像の容量の問題ではないと思うんですが・・・。