サイトのスピード最適化 - 改善方法は?

これらのパフォーマンステストサイトについて、皆さんのご意見はいかがですか?GTmetrix、PageSpeed、WebpageTestの3つのテストを実施しました。もちろん、いくつかの違いはありますが、いくつかの類似点もありました。昨日、GTmetrixではC評価でしたが、B評価に改善されたのは素晴らしいです。ただし、それがどこから来たのかはよくわかりません。

これらの3つのテストから、私のサイトで最も共通しているのは、JavaScriptとCSSの読み込み時間のように思えます。しかし、JavaScriptは私の制御下にあるのでしょうか?GTmetrixでは、2つのURLが未使用のJavaScriptとしてリストされていますが、それはDiscourseに組み込まれているものではないでしょうか?

https://forums.gonomad.me/assets/chunk.2c7ac65fdfc1f35c61b6.d41d8cd9.js
https://forums.gonomad.me/assets/vendor.47fe1949ff0285dbc995d87a6ae0d449-223fd39128ca149073c28a57e41e969bafdb0a241e1149adab6918b27e7a3265.js

そして、38.8秒のパスレイテンシがリストされているのを見て、少し興味をそそられました。これを最適化/修正するにはどうすればよいのでしょうか?

PageSpeedでも、JavaScript/CSSのレンダリングをブロックするリソースという同様のことがリストされていました。サイトを遅くしている最大のJavaScriptファイルは次のとおりです。

https://forums.gonomad.me/assets/chunk.2c7ac65fdfc1f35c61b6.d41d8cd9.js
https://forums.gonomad.me/assets/locales/en-d255b87afa1b13a48418c34b7c45d8aa69fce223261f36c9a101fb022c7cb8e5.js

しかし、これもDiscourseに組み込まれているものだと思いますか?

最後に、開発者コンソールからの直接のLighthouseテストでは、63点でした。

それは、一部のユーザーが読み込みの問題を抱えていた他のトピックに関連していますか?

ホスティング環境を確認することをお勧めします。 :thinking:
私には結果は問題ないように見えますが。

「いいね!」 1

まあ、そんな感じです。あの件全体が私に考えさせられました、ハハ。

私も主にそう考えていましたが、これらのパフォーマンスサイトの一部のスコアも気に入っていません(これも、ホストの問題である可能性もありますよね?)

CDN を設定することは、常に良いスタートです。 :rocket:

「いいね!」 2

最近、最適化の旅でCDNについてたくさん読みました。調べてみます!

「いいね!」 1

うーん…あまり多くのものに対して、かなりの追加の複雑さですね。

CDNを使用せずに、数年間、成功したコミュニティを運営してきました。

「いいね!」 3

トラフィックが多いですか?サーバー構成を教えていただけますか?

トラフィックが多いはずがありません。登録ユーザーは数人しかいません。サイトを作成したのはわずか12日前です。サーバーがホストされているピーク時間帯に、一部のユーザーには遅いようですが、他のユーザーには問題ありません。サーバー/VPSの仕様は次のとおりです。

3GB RAM
2vCPU
35GB SSD
1Gbps 無制限帯域幅
IPv4 x 1
KVM
Ubuntu 22

編集:おっと、私に返信しているのかロバートに返信しているのか分かりませんでした。

「いいね!」 1

サイトが常に非常に応答性が高くなるほど低い。

4GB/3 vcores + 2GB Swap。

「いいね!」 2

CDNは、グローバルな視聴者が多い場合や、VPSが低スペックのサーバーにある場合に役立ちます。また、PHPベースのサイトでは多少改善されるかもしれませんが、優れたキャッシュポリシーの方がより効果的です。

Discourseの性質上、これらの改善は壊れやすい傾向があります。あるいは、そのように言うならば、そのような助けは必要ありません。

これらのメトリクスサービスには多くの問題があり、そのまま「そのまま」読むことができることはめったにありません。

「いいね!」 1

ええ、それが少し混乱しているところです。基本的に、私が指摘されているすべての点は、Discourse(長いJS読み込み時間/ブロックなど)に組み込まれているように見えます。それに加えて、おそらく私のテーマの組み合わせなので、Discourseサイトではこれらのスコアが絶対に良くならないということでしょうか?いや、そうは思いません。特にフォーラムは。

その通りです。プラグインなどによって(不要な)機能をいくつか削除することで多少は改善できますが…実際には大きなメリットはありません。

良いニュースは、それが全く問題にならないということです。そして、ユーザーのインターネットサービスやデバイスの方がより大きなボトルネックとなります。

もしあなたが余暇をたくさん持て余しているなら、あれやこれやと開発を始めることができますが、得られるのはほんのわずかな時間短縮に過ぎず、それらはラボテストでのみ測定可能なものです。

チームやプラグイン/テーマ開発者に彼らの仕事を任せましょう。それで十分です。

WordPressやDrupalなどの「本物の」Webプラットフォームがあれば、さまざまな工夫ができます。しかし、Discourseのソリューションは根本的に異なります。

もちろん、私は単なる素人の管理者/ウェブマスターであり、間違っていれば訂正されます。しかし、私は間違っていません🤣

「いいね!」 1

はい、わかりました。コンポーネントが何も入っていない、まったく新しいデフォルトのテーマで同じテストを実行したところ、以下の結果になりました。

ブロック時間が常に最優先事項のようです(少なくとも私がテストを実行したときはそうです)。では、Discourseの開発者はこれをさらに最適化する必要があるのでしょうか?悪意はなく、純粋に質問しています。

これは人間が見ているものではありません。もう一度言いますが、Discourse は、まず必要なファイルを移動し、その後は(ほぼ)すべて JSON テキストになる Web アプリです。WordPress のように、Web サイトがサーバーレベルでページを生成し、クライアントに読み取り可能な HTML を送信する場合、そのテストは(なんとか)機能します。

そして、その時間はまったく悪くありません。

あなたが今提案しているのは、Discourse をブラウザ経由では使用できないフルアプリにすることです。