David、素晴らしい出来栄えですね！一つ提案なのですが、応答を待っている間でも、中央で一時停止するのではなく、バーを（少し速度を落として）進め続けることは可能でしょうか？例えば、40%から70%まではゆっくり進め、その後応答がない場合に一時停止するといった具合です。
その短い一時停止を隠すことで、より応答性が良く、即座に反応しているように感じられると思います 
「いいね！」 1
現在、80% 幅で停止するまで 5 秒間ゆっくり進んでいるようです。
ここでは、非常に非常に遅いインターネット接続をシミュレートしました：
現在の SCSS:
.loading-indicator-container {
--loading-duration: 5s;
--loading-function: cubic-bezier(0, 0, 0, 1);
--done-duration: 0.4s;
--done-function: ease;
--fade-out-duration: 0.4s;
position: fixed;
top: 0;
left: 0;
z-index: 1001;
height: 3px;
width: 100%;
opacity: 0;
transition: opacity var(--fade-out-duration) ease var(--done-duration);
background-color: var(--primary-low);
}
.loading-indicator-container .loading-indicator {
height: 100%;
width: 100%;
width: 0%;
background-color: var(--tertiary);
}
.loading-indicator-container.loading {
opacity: 1;
transition: opacity 0s;
}
.loading-indicator-container.loading .loading-indicator {
transition: width var(--loading-duration) var(--loading-function);
width: 80%;
}
.loading-indicator-container.done .loading-indicator {
transition: width var(--done-duration) var(--done-function);
width: 100%;
}
body.discourse-hub-webview .loading-indicator-container {
top: 1px;
}
body.footer-nav-ipad .loading-indicator-container {
top: 49px;
}
body.loading #main-outlet {
opacity: 0.2;
transition: opacity 0.2s ease;
}
「いいね！」 3
私の環境では約40%で止まってしまうのですが、たとえ遅くても動くバーの方が一時停止より良いと思います。
また、フェードに関連して、コンテンツをフェードアウトさせ、新しいコンテンツをフェードインさせることで、より速く表示されるようにできるかもしれません（読み込みルートのアウトレットをターゲットにできる場合ですが）。
「いいね！」 3
2つの現象が起きています…
@Canapin が指摘している通り、初期アニメーションは 5 秒後に 80% で終了します。そのため、接続が遅い場合、その状態で停止し、次のページに移動するまで完了しません。
@P16 のケースは、より高速な接続環境で私が経験する現象です。現在のページからの遷移が発生すると、アニメーションはたまたま進行していた位置で一時的に停止します。そして 1 秒ほど経ってから新しいページで再開されます（ここではバーの高さを誇張して表示しています）。
動きを継続させることが理想であるには同意しますが、実装方法を根本から変えない限り実現できないかもしれません…
フェードインではあまり効果がないと思います… コンテンツが存在するまでフェードインできないため、その分だけ表示が遅れてしまいます。速度の錯覚を生む可能性はありますが、技術的にはフェードインアニメーションの長さ分だけ遅くなります！
ふと気づいたのですが、目次コンポーネント（投稿をフェードインするため）でフェードインを（ある程度）テストできます。例えばこちらをご覧ください: https://meta.discourse.org/t/postgresql-13-update/172563。特に速いとは感じませんが、確かに「滑らか」です。
「いいね！」 11
おお、それはコンテンツが実際に読み込まれたことで発生しているのだと思います。HTML のパース、スタイルの連鎖、レイアウト、レンダリングに大きな遅延が発生しており、その間にアニメーションが動かなくなっているのでしょう。
「いいね！」 3
.loading-indicator-container .loading-indicator, .loading-indicator-container {
background-color:#FFCC00;
}
テーマの CSS で色を変更しようとしましたが、青色のままです。ご助力をお願いします。
「いいね！」 1
その通りです。JS と DOM レンダリングがシングルスレッドであるため、トピックのレンダリング中にフレームが大量にドロップしてしまいます 
。スライダーは常に「移動」していますが、フレームがレンダリングされていないだけなのです。
ありがとうございます。その点は コア で修正済みですので、まもなく Meta でも修正が適用されるはずです。
今日は Meta でもフェードインを実装して、その感触を確認できるようにします。もちろん、そうすれば TOC コンポーネントのような他のフェードインも削除する必要があります。
編集：完了しました。Meta でフェードインを有効にしました。
テーマやコンポーネントが読み込まれる順序によっては、うまくいかない可能性があります。ローディングスライダーコンポーネントの CSS よりもセレクターの「 specificity（重要度）」を高める必要があります。最も簡単な方法は、background-color に !important を追加することです。また、コンテナセレクターを削除する必要があります。そうしないと、背景色が前景色と同じになってしまいます。
.loading-indicator-container .loading-indicator {
background-color:#FFCC00 !important;
}
「いいね！」 7
ありがとう、David。素晴らしいですね！
「いいね！」 1
現在、直近の5回分のページ読み込み時間の平均値を計算し、その値に基づいてバーの表示速度を設定します。
「いいね！」 18
こんにちは、Davidさん。
このローダーはますます良くなってきていますね 素晴らしい仕事を続けてください。
この新しいアップデートにより、よりダイナミックに見えるようになりました
カテゴリに関する一点だけ気づいたことがあります。「トピック作成」ボタンをリネームして使用する際、ローディングスライダーがボタンのテキストを更新しないようです。これは他のスクリプトとの競合を引き起こす可能性があるため、注意が必要かもしれません。
デモ（この動画では、異なる「トピック作成」テキストを持つカテゴリをクリックし、デフォルトの「トピック作成」ボタンを持つ他のカテゴリに移動しています）ページ全体をリフレッシュすると、正しいテキストが表示されます。
「いいね！」 3
フェードイン/アウトの導入は改善点ですが、スライダーが依然として気が散る要素だと感じています。ついスライダーを見てしまい、ページが読み込まれた際にすぐに読む準備ができるのが遅れてしまいます。一方、スピナーは一定の位置にあり、目を向けずに済むため、突然現れることで速度を連想させます（誤解かもしれませんが）。
低速の接続環境では、スライダーの方がページの読み込み速度の遅さや速さを実感できるため、むしろ良いかもしれません。ただ、その点については確信が持てません。
「いいね！」 4
私にとって、モバイル端末を使用する際のスライダーは画面の上部に位置していますが、以前のものは画面の中央付近、上から約30%の位置にありました。
そのため、スマホの中心に視線を固定するのではなく、上下に視線を動かす必要があります。あくまで個人的な意見ですが。
「いいね！」 5
これに賛成です。ローディングスライダーはデスクトップのみで動作し、モバイルではスピナーを維持するのが最善だと思います。スピナーの方がアプリを利用しているような感覚があり、モバイルでは良いですよね。YouTube がローダーを使用しているのと同じです。
「いいね！」 4
はい、iPhone で使用していましたので、私のコメントは特にモバイル端末に関連するものでした。
「いいね！」 4
コンセプトが素晴らしいですね。スライダーはスピンナーよりずっと気に入っています。
Dark、Alien、Vincent、Star Wars など、多くのテーマで有効化し、27 インチと 34 インチの ROG モニターの両方でテストしました。しかし、読み込み中のスライダーがほとんど見えませんでした。非常に細いようです。「Dark」系のテーマでは、細い線の色が柔らかすぎて、はっきりと認識できませんでした。
モバイル（iPhone 6s と iPhone 6+）でも試しましたが、同様の感想です。ほとんど目立ちません。
社交的な雰囲気を壊したくないのですが、客観的に言えば、スライダーは有望ですが（私見ですが）追加の CSS 調整が必要です。そのため、当サイトでは現在、はっきりと目立ち「再読み込みの状況を明確に伝える」スピンナーに戻しています。時間ができたら、もう一度有効にして当サイトの CSS を調整するつもりです。非常に有望に見えます！
とても有望です！
ありがとうございます。これからも頑張ってください！
追伸：速度に問題はありません。当社は国内のファイバーバックボーン（すぐそば）に接続しており、メインバックボーンへの専用ファイバー回線を利用しています。
「いいね！」 5
カテゴリやトピックの選択時などの新しい UX の挙動について一言触れさせてください。新しいページが読み込まれる前に現在の表示が薄くなる現象ですが、私はあまり好んでいません。空白のページにローディングスピナーを表示する旧来のアプローチの方が、はるかに心地よい体験だったと思います。
どちらの方式でもページが 2 回切り替わる点は同じです。しかし、スピナーは普遍的な要素であるため、実際には「ページが 2 回切り替わった」という感覚はあまりありませんでした。「切り替わる準備をして、その後 1 回切り替わる」という印象だったのです。一方、現在の方式では、2 つの遷移のあいだにどちらもコンテンツが存在するため（1 回は薄くなった状態、もう 1 回は新しいページの内容）、2 回切り替わっているように感じられます。
なぜ気に入らないのかを正確に言語化するのは難しいのですが、おそらく「普遍的なローディング表示」がなくなったことが原因ではないでしょうか。現在では事実上無数の異なるローディング表示が存在することになり、特に「フェード後に読み込み」という表示は気が散ると感じます。なぜなら、新しいページへ遷移するたびに背景のコンテンツが異なってしまうからです。
「いいね！」 4
didInsertElement フックを使用しているいくつかの部分は、更新が必要になるでしょう。以前のスピナーでは、ページ上のすべての要素が破棄されて再作成されていました。しかし、この新しいシステムでは、Ember が可能な限り要素を再利用します。これにより、レンダリングが少し速くなる可能性がありますが、カスタマイズが通常の Ember パターンに従っていない場合、バグが発生する可能性があります。気づいた次第に、それらを特定して修正していく必要があります。
カスタマイズのコードを共有できる Git リポジトリはありますか？
これが、この機能をコアに移動させる前に、しばらくテーマコンポーネントとして実験したい主な理由です。そうすることで、できるだけ多くの問題を検出できるようになります。
「いいね！」 6
はい、リポジトリはこちらです。ありがとうございます
「いいね！」 4
この新機能には、少なくとも iPhone 上でモバイルのバグがあると思います。「ナビゲーションのドロップダウン」から「最新」を選択すると、ページ読み込み時にドロップダウンは正常に消えます。しかし、「新着」や「未読」（他の項目も同様かもしれません）を選択すると、ドロップダウンがまだ表示されたままになります。常に発生するわけではありませんが、頻繁に起こるため、再現は容易であるはずです。なお、この現象は旧バージョンでも時々発生していましたが、「最新」でのみ起こり、「新着」や「未読」では発生したことはありませんでした。
「いいね！」 5
@Don さん、ありがとうございます。これについて少し試してみましたが、新しいスライダーでも動作する、より良い方法だと思います：https://github.com/VaperinaDEV/category-btn-name/pull/1（ハンガリー語の修正にミスがあったらすみません）。このようなパターンは、他の人がコンポーネントを更新する際にも役立つはずです（`didInsertElement` や jQuery の代わりに、computed プロパティを使用する）。
調査リストに追加しました。ありがとう。
「いいね！」 8