静的 HTML を主体としたサイトにして、補助的にクライアントサイドでスクリプトを利用させて「より便利に使える」くらいの使い方の方がサーバーの CPU には優しいですし、圧縮きかせて転送量が 3/4 になって嬉しいと思えるほどのコンテンツを送り込んでるとしたら、元の転送量がでかすぎるでしょう。
サーバー側の負担は軽くなるかもしれませんが、XMLHttpRequest でコンテンツ受け取って HTML に変換して出力するのは、万遍なくクライアントサイドの CPU コストを上げることになるし、非力なスマートフォンなどの端末を考慮するとあり得ない選択肢としか思えませんが。
いろいろ安くなるからねえ (スコア:0)
テンプレートとなるHTMLをますブラウザに送っておき
後はXMLHttpRequestでJSON送ったり受け取ったりで
転送量が格段に抑えられるし ←機能を追加したはずなのに転送量は3/4とか
サーバのCPUにもやさしいし ←HTMLよりはJSONに整形する方が楽なのね
そんなわけで、スクリプトまみれになるのは、勘弁してくれよ。
マークアップ+スクリプト言語、みたいなノリのCurlは最強だと思ったんだけど
開発環境実行環境ともに有料だったのは失敗だよな・・・(今は無料になった?ぽいけど)
Re:いろいろ安くなるからねえ (スコア:1)
テンプレートとなるHTMLをますブラウザに送っておき
後はXMLHttpRequestでJSON送ったり受け取ったりで
転送量が格段に抑えられるし ←機能を追加したはずなのに転送量は3/4とか
サーバのCPUにもやさしいし ←HTMLよりはJSONに整形する方が楽なのね
そんなわけで、スクリプトまみれになるのは、勘弁してくれよ。
その結果、スクリプトが解釈できなかったり、適切な状態に遷移するのが面倒な読み上げブラウザーや点字ディスプレイなどで壊滅的に使いづらいサイトになって、アクセシビリティー最悪になるんですね。
わかりますわかります。
検索エンジンにも引っかからなくなって一石二鳥ですね。
静的 HTML を主体としたサイトにして、補助的にクライアントサイドでスクリプトを利用させて「より便利に使える」くらいの使い方の方がサーバーの CPU には優しいですし、圧縮きかせて転送量が 3/4 になって嬉しいと思えるほどのコンテンツを送り込んでるとしたら、元の転送量がでかすぎるでしょう。
サーバー側の負担は軽くなるかもしれませんが、XMLHttpRequest でコンテンツ受け取って HTML に変換して出力するのは、万遍なくクライアントサイドの CPU コストを上げることになるし、非力なスマートフォンなどの端末を考慮するとあり得ない選択肢としか思えませんが。
ついでに言うと、セッションが張りっぱなしのまま通信できるそれなりに短い間隔での通信でないと、セッションをちょこちょこと張りなおすことによるサーバー側のコスト増もあるのではないでしょうか。
Re:いろいろ安くなるからねえ (スコア:1)
その辺りの話については、普段のアクセス量とサーバー群の数などでもまったく状況は変わるわけです。1byte 削減の効果がどれだけのインパクトがあるか、という点を考慮しましょう。
というか Google の「あの無味乾燥なトップページ」は JavaScript が無効でも利用できますし、検索結果もそうですよね。
ただ、元のコメントは「検索結果ページのベースだけ」サーバーが HTML として出し、検索結果などをすべて JSON で流し込んで転送量を削減する、という話になるんですけど。