ロード時間が遅いのはトップページに情報を詰め込みすぎだからじゃないの？トップページに必要ないものは別のページを作成したら？
テキストは結構書いても大半の画像よりサイズが小さいので、ロード時間への影響は小さいです。構造 (DOM) が複雑だとレンダリングに時間がかかるかもしれませんが、今の程度だと何てことないです。何にどのくらい時間がかかっているかは、たとえば Google Chrome のデベロッパーツールで Network の項を見ると分析できるので、バックアップと今とで比較すると平均的には画像でロード時間がかかっているのが分かります。たとえば私の環境だとwiki内のアイコン画像へのリンクは時間がかかっているようです。
デベロッパーツールで見てみると現状一番サイズの大きいものはHTMLで次がCSSです。
Ctrl+Shift+R でなくて Ctrl+R をして、キャッシュが効いていませんか？ Google Chrome のデベロッパーツールの Network で解析する限り、Doc は最大で 13 KB、CSS は 53 KB なのに対して Img は 213 KB (マップサムネイル画像) ですが……。
話をしている内にどんどんＨＴＭＬが軽量化されているので、ＨＴＭＬはそろそろ限界ですかね。
諸々の話が始まる前でも Doc は 140 KB 程度だったのでやはりマップサムネイルの方がサイズ大きかったです。
あ、キャッシュを無視した場合の話をしています。キャッシュがあると2回目以降で時間が変わるので……。
……とは言ったものの、ページ内容がほぼ無い「MAD関連」の処理時間と比較するとこのページはサーバー側で内容を処理するのに時間がかかっているっぽいので、ダイエットするならそこの時間を削るのに意味ありそうですね……。
ウィキペディアのルールに詳しいプロの人いたら、ページを分けてほしいです。
ページを分けるとしてもこのページのユーザー層としてどこが副次的な情報になるかを考える必要があります。たとえば既に名所部分は別ページに分かれているものを include しているわけですが、ここを include でなくリンクにするとしたら、このページを見る人が不便になるかどうかが知りたいです。
あまり配信を見ない人にとっては名所情報の方が大事そうだし、高頻度に見ている人にとっては最近の活動の方が大事そう。こういったバランスを考えると、個人的にはどっちもあって欲しいし、今のトータルの読み込み時間的にはまだ別ページに隔離するほどではないかなと思っています。
wikiwiki.jp には行数制限があるので、それにひっかっかったらページ分割の機運かなあ。
参加ライバーとか、名物、ペット、別サーバ、modとかこのページに必要ないものはたくさんありますよね。とりあえずここら辺分けて軽くなるかやってみますか？
いつの間にかページ分割編集が入っていましたが、バックアップ170とバックアップ180を比べるに、私の環境ではドキュメント部分は Time to First Byte が 0.2 秒早くなった程度ですね。このくらいなら残したままで良いのでは。
名所のincludeをリンクに変えてみました。すぐに戻せますので、軽くなるか見てみます。
細い回線の人どうですか？軽くなりましたか？
やっぱりサーバの負担あまり減ってないかんじか、他に何がだめなんだろう
私の環境だとこのページのロードより https://twitter.com のロードの方が時間かかるんですが、まだ短くしますか……？
試しに一昨日まで情報を別ページにしてみました。ロード時間はどうでしょうか
不適切なコンテンツとして通報するには以下の「送信」ボタンを押して下さい。 管理チームへ匿名通報が送信されます。あなたが誰であるかを管理チームに特定されることはありません。
どのように不適切か説明したい場合、メッセージをご記入下さい。空白のままでも通報は送信されます。
通報履歴 で、あなたの通報と対応時のメッセージを確認できます。
テキストは結構書いても大半の画像よりサイズが小さいので、ロード時間への影響は小さいです。構造 (DOM) が複雑だとレンダリングに時間がかかるかもしれませんが、今の程度だと何てことないです。何にどのくらい時間がかかっているかは、たとえば Google Chrome のデベロッパーツールで Network の項を見ると分析できるので、バックアップと今とで比較すると平均的には画像でロード時間がかかっているのが分かります。たとえば私の環境だとwiki内のアイコン画像へのリンクは時間がかかっているようです。
デベロッパーツールで見てみると現状一番サイズの大きいものはHTMLで次がCSSです。
Ctrl+Shift+R でなくて Ctrl+R をして、キャッシュが効いていませんか？ Google Chrome のデベロッパーツールの Network で解析する限り、Doc は最大で 13 KB、CSS は 53 KB なのに対して Img は 213 KB (マップサムネイル画像) ですが……。
話をしている内にどんどんＨＴＭＬが軽量化されているので、ＨＴＭＬはそろそろ限界ですかね。
諸々の話が始まる前でも Doc は 140 KB 程度だったのでやはりマップサムネイルの方がサイズ大きかったです。
あ、キャッシュを無視した場合の話をしています。キャッシュがあると2回目以降で時間が変わるので……。
……とは言ったものの、ページ内容がほぼ無い「MAD関連」の処理時間と比較するとこのページはサーバー側で内容を処理するのに時間がかかっているっぽいので、ダイエットするならそこの時間を削るのに意味ありそうですね……。
ウィキペディアのルールに詳しいプロの人いたら、ページを分けてほしいです。
ページを分けるとしてもこのページのユーザー層としてどこが副次的な情報になるかを考える必要があります。たとえば既に名所部分は別ページに分かれているものを include しているわけですが、ここを include でなくリンクにするとしたら、このページを見る人が不便になるかどうかが知りたいです。
あまり配信を見ない人にとっては名所情報の方が大事そうだし、高頻度に見ている人にとっては最近の活動の方が大事そう。こういったバランスを考えると、個人的にはどっちもあって欲しいし、今のトータルの読み込み時間的にはまだ別ページに隔離するほどではないかなと思っています。
wikiwiki.jp には行数制限があるので、それにひっかっかったらページ分割の機運かなあ。
参加ライバーとか、名物、ペット、別サーバ、modとかこのページに必要ないものはたくさんありますよね。とりあえずここら辺分けて軽くなるかやってみますか？
いつの間にかページ分割編集が入っていましたが、バックアップ170とバックアップ180を比べるに、私の環境ではドキュメント部分は Time to First Byte が 0.2 秒早くなった程度ですね。このくらいなら残したままで良いのでは。
名所のincludeをリンクに変えてみました。すぐに戻せますので、軽くなるか見てみます。
細い回線の人どうですか？軽くなりましたか？
やっぱりサーバの負担あまり減ってないかんじか、他に何がだめなんだろう
私の環境だとこのページのロードより https://twitter.com のロードの方が時間かかるんですが、まだ短くしますか……？
試しに一昨日まで情報を別ページにしてみました。ロード時間はどうでしょうか