11.7から本日までに、ユーザーのブラウザでページをレンダリングするために必要なCPU時間が増加しました。
これは新しいCSSによってブロックされているようです。こちら側では何も調整していませんが、定期的に(ほぼ毎日)更新を行っています。
問題の理解を深めるためのデータを以下に示します。左側は11.7です。
![]()
しかし、セルフホストのDiscourseに関して最近Dockerのアップデートが多数あったため、問題は別の場所にある可能性があります。
11.7から本日までに、ユーザーのブラウザでページをレンダリングするために必要なCPU時間が増加しました。
これは新しいCSSによってブロックされているようです。こちら側では何も調整していませんが、定期的に(ほぼ毎日)更新を行っています。
問題の理解を深めるためのデータを以下に示します。左側は11.7です。
![]()
しかし、セルフホストのDiscourseに関して最近Dockerのアップデートが多数あったため、問題は別の場所にある可能性があります。
他に同じ問題を抱えている人はいますか?
Discourse のバージョン 11.7 はどれで、どのバージョンから問題が発生し始めましたか?
残念ながら、お答えできません。Discourseコミュニティでは、そのような詳細なログは保持していません。
しかし、私が掘り起こすことができたログから、この <meta name="generator" content="Discourse 3.3.0.beta4-dev - https://github.com/discourse/discourse version 39187d98149e9822a8c9c21da9c1dc6a7aff4e49"> が見つかりました。
これが正常に動作していた最後の状態です。
これは、必要であれば、生の投稿コンテンツから取得した「<meta name="generator" content="Discourse 3.3.0.beta4-dev - https://github.com/discourse/discourse version 39187d98149e9822a8c9c21da9c1dc6a7aff4e49">」であるはずです。
これらの指標はどのように収集されていますか?
LCP測定のスクリーンショットでは、「以前」のスクリーンショットはbasic-htmlクローラービューを示しているように見えますが、「現在」のスクリーンショットはユーザーに提示される完全なJSアプリを示しています。
完全なJSアプリの方がCPU時間とページ重量が高いのは理にかなっています。
したがって、これは監視システムの変更、またはおそらくDiscourseが監視システムに応答する方法の変更である可能性が高いと思います。![]()
すべての画像は、常に同じものを測定する単一のシステムからのものです。測定値のみが異なる日に取得されました。したがって、Discourse側の条件は変更された可能性が高いです。
DebugBearの測定方法の詳細については、こちらをご覧ください。A Guide to Website Monitoring | DebugBear