こんにちは 
UX: improve touch, swipe, panning performance on mobile menus by featheredtoast · Pull Request #23775 · discourse/discourse · GitHub のアップデート以降、メニューパネル（ユーザーとサイドバー）の移動が、古いモバイル Android デバイスでは以前よりもはるかに遅く感じるようになりました。これは、これらのデバイスの CPU パフォーマンスがスムーズな移動には十分ではないためかもしれません。
私のデバイスは Huawei P20 Pro です。
しかし、iPhone X でもテストしたところ、非常にスムーズで高速でしたので、問題は CPU だと思います。古いデバイスのパフォーマンスを改善する可能性はありますか？
ありがとうございます 
@Donありがとうございます。確認します！
ドンさん、フィードバックありがとうございます！
これはすぐにテストします。古いデバイスでは、メニューの項目数を20に減らす（少しハックな）パフォーマンス最適化が必要になる可能性があると疑っています。これはすぐに確認します。
@Don - さらに詳しく調べて、何をテストすべきかを知るために、メニューのタップ（メニューのオン/オフ）、またはスワイプ（長押ししてジェスチャーでスワイプ）のどちらでこの問題が発生しているか確認していますか？
メニューを開いた直後はスムーズに動作しているように見えます。これは、パネル要素がまだ読み込まれていないためだと思います。最初にスピナーローダーが一番上に表示されます。これは良い動作だと思いますし、常にスピナーローダーを開くときに使用するのはクールかもしれません。
この後の開閉はアニメーションなしで行われます。閉じる動作はランダムです（時々スムーズで、時々カクつきます）。
開いて、外側をクリックすると通常、パネルメニューのボタンが遅延します。しかし、それらは最初にスライドアウトします🤔これは、メニューパネル全体がreverse-rowにあり、閉じるときに完全にスライドアウトする前にクラスが削除され、rowに戻るために発生するのでしょうか？
編集：それはメニューパネルのボタン（タブ）ではなく、通知前のアイコンだけのようです。しかし、その行には通常遅延が発生します。
ジェスチャーでメニューを閉じると、スムーズに動作するように見えます。
更新：Firefoxブラウザではメニューの移動がスムーズなようです。Chromeと同様にEdgeでもテストしました。
Firefox
私の知る限り、ここの「遅延」はアニメーション自体によるものではなく、ヘッダーの再レンダリングによるものです。
私が導入したことで、新しさによる遅さの認識が生じる可能性があることの1つは、スライドアウトアニメーションです（このアニメーションは、新しいヘッダーのリファクタリング時に誤って削除されていました）。
アニメーションとウィジェットメニューが行っている再レンダリング処理の間にsetTimeoutで余裕を持たせることで、物事がずっとスムーズに進むようになるようです。つまり、アニメーション自体が遅いのではなく、開閉時にサイトヘッダーを再レンダリングする際に行われている処理が原因であると疑っています。
Firefoxのアニメーション終了プロミス（animation end promise）の処理が、アニメーションが完全にペイントされた後（元の変更をコーディングした際にそう仮定していました）に発生しているのではないかと疑問に思っています。これが、Chromeよりもスムーズに見える理由かもしれません。一方、Chromeは、アニメーション終了がペイントされる前に、アニメーション計算が完了した後で再計算処理を開始することを許可しています。
編集：runloopを使用して一時停止を追加し、アニメーションの前に必要な余裕を持たせるようにしました。これにより、アニメーションがはるかにスムーズに感じられるはずです。UX: call discourseLater on menu animations by featheredtoast · Pull Request #24168 · discourse/discourse · GitHub
ありがとうございます！よく見つけましたね！