遅いホームページは読み込みバーよりも優れていますか？
ホームページに表示するために大量のデータをロードする必要がある小さなサイトで作業しています。
ページコンテナーの読み込みは高速（約1秒）ですが、データベースからデータを取得して計算を実行し、テーブルに表示する必要があります。
私はAjax呼び出しを介してこれを行いますが、これが完了するまでページの使用を遅くします。スクロールすると、スクロールがびくびくします。
1秒後にユーザーにページへのフルアクセスを許可する必要がありますが、次の10秒間は、ページを使用するのが非常に遅く、時間がかかりますか？
または、読み込みバー付きのポップアップを表示し、ページが完全に準備ができて応答するまで、ページを使用してポップアップをブロックする必要がありますか？
ホームページが読み込まれると、サイトは非常に高速に実行され、すべてが良好です。
確かに後者。ユーザーは前者のユーザーエクスペリエンスが低下します。
この質問について興味深いのは、「システム状態の可視性」または「何が起こっているのかを知っている限り、私が制御していると感じている」という概念を引き起こし、それがまさにロードバーが行うことです。
より重要な質問は、このステータスバーが表示される場所だと思います。ロードが完了するまでページ上のライトボックスは1つのオプションです。ページの先頭にあるバーは別のものです。
編集：ページの下のジェーンの解決策はより良い方法です。
編集2：ジェーンのアイデアには、それに夢中にならない人がいるかもしれません「Facebookでの動作が信じられないほど愚かだと思います」
この場合、外に出てユーザーが自分のアイデアをテストする必要があります。スケルトンページ、ページロードインジケーター、および直接のやり取りをテストし、どれがテストに最適かを確認します。それが本当の解決策です！
スケルトンのuiパターンまたはプレースホールドパターンを調べることをお勧めします。現在非常に人気があり、Facebookなどで使用されています。
私はそれについて語っているメディアでニース 短い記事 を見つけましたが、あなたはそれをウェブ上でたくさん見つけることができると確信しています。作家を引用するには：
コンテンツのレイアウトを強化するため、これは読み込み状態の良い代替手段のように思われます。したがって、ユーザーが実際にコンテンツのレイアウトを模倣している場合、すぐに物事がどこにあるかを予想できます。
プレースホルダーは基本的にダミーコンテンツの形式でバーを読み込んでいます。それはユーザーに奇妙なジャンプを引き起こすことなく何かが来ていることを知らせます。
Medium自体も非常に優れています プログレッシブな画像の読み込み これは優れたプレースホルダーとしても機能しますが、表示しようとしているコンテンツの種類の例は示していません。
このアプリケーションをhomeページに配置しないでください。ホームページはサイトへのエントリページとして機能し、ユーザーはナビゲーションにすばやくアクセスする必要があります。私はそれのために〜1秒のロード時間も長すぎると考えます。
それでもフロントページにアプリケーションを表示したい場合は、ユーザーが意識的にロードを開始できるボタンの後ろにアプリケーションを非表示にします。また、その間はスクロールしないようにすることもできます。関連するすべてのものを画面に合わせ、アプリケーションの準備ができたらページを下に拡大します。また、ユーザーがボタンを押す前に、データをバックグラウンドでプリロードすることもできます。重いデータ処理がsnappinessに影響を与えないようにするには、それを バックグラウンドプロセス で実行します。
あなたの最善の策は、ページの手続きと構造を1〜2秒でレンダリングすることです（イーサネット時間、セルデータ時間は異なります）。そして、データが出てきたら、データを埋め戻します。
宇宙船エンタープライズを再起動すると想像してみてください。何十ものディスプレイがあります。彼らはすべて同時に起きるのではなく、彼らが自分のことをするのにかかる時間に応じて、一度に1つずつ飛びつきます。それは正常だと考えています。また、ワークステーションが起動時に他のワークステーションの間にハリーポッタースタイルを挿入するため、エンタープライズブリッジが突発的に大きくなることはありません。ワークステーションは常にそこにあり、（固定サイズの）画面だけがデータで満たされ始めます。それがデザインのコンセプトです。
どうして？
ユーザーはそのデータさえ欲しくないかもしれません
飛行士が言うように、トンネル視力や「ゲット・ザ・イア・イティス」に苦しむのは簡単です。あなたは、ホームページにアクセスしたすべての人が、すべての作業を行ったコンテンツを望んでいると想定しています。チャンスはありません。
- 「会社概要」ページや「このビジネス/サイトのしくみ」ページを求めている人もいます-それらは変換する準備ができておらず、商品を提示するための大きな計算負荷が無駄になっています。
- 他の人はあなたのサイトへの方向を望んでいます（音楽劇場を考えてください、彼らはこのショーに遅れており、他のショーのチケットの入手可能性を気にしません。）
- 他に質問があり、あなたに連絡する方法を見つけたいと思っています。
- などなど。それらのユーザーは重要ではありません。
彼らを待たせるのは失礼だ。遅らせることも自殺です。ビッグDBクランチが終了しない場合、それはサイトがダウンしていることを意味します。 同じビッグDBのクランチに7秒かかるが、6秒で放棄される場合。
あなたはスペースを予約することを想定しています
コンテンツをロードするためのスペースを予約する「スケルトンUI」と呼ばれるこの新しいトレンドは、新しいものではありません。それは非常に古いものであり、非常に義務的なものです。
ほとんどの人が33.6kbpsモデムを持っていた1995年に、ウェブは非常に勢いを増していました。 imgタグとそのheight=およびwidth=属性？スケーリング用ではありません。 インターネットが存続または死亡したそれが、サイトを苦しむ量の中で使用可能にした理由です。時間。それはあなたのコンテンツが行くところに小さな「画像」アイコンが付いた灰色のボックスを置くものです。人々はこれに慣れ、本当に感謝しています。多くの人がブラウザを「画像を自動ロードしない」に設定し、クリックして希望の画像を表示しました。
これは（まだ）レンダリングされませんでしたか？どんなに。ページがレンダリングされ、ジャンプしません。
1995年のことですが、失敗する可能性がありましたheight=およびwidth=パラメータを使用すると、VPUを使用しない486（CPUチップ）で可能だった悲しいバージョンのスクロールジャンプが発生します。これは、最も安っぽいアマチュア自家製のWebサイトでのみ発生しました。 友人の個人的な旅行情報サイトをロードし、彼の100枚の画像がぎくしゃくとロードされている間にコーヒーを飲まなければならなかったことを覚えている人はいますか？
したがって、この「スクロールジャンプを引き起こさない」という概念は新しいものではありません。 normalizeコンテンツをロードするためのスペースの予約に失敗しないでください。これは常にコードを書くのが面倒でずさんな方法でした。
そして、そうです、それは動的に読み込まれるコンテンツの設計課題を提示します。実際、そのようにしてサイズが決まっていないラクダがテントの中に鼻を取り戻しました。怠惰なサイトは、「このツイートの大きさがわからない」と表示されます（たぶん、140文字未満です）...良いデザインがこれをうまくやっています。
昔は、このような問題は iframe で解決していました。したがって、それは間違いなく可能です。
どちらでもない。これはホームページであるため、ユーザーが頻繁にアクセスすると想定できます。事前にすべてを計算してキャッシュしてください。
ロードまたはリフレッシュされるたびに最新のデータを提供する必要がある「ライブ」ページの場合、前のリクエストの結果をキャッシュし、これを次のリクエストの初期ページとして使用します（ページが「最終更新」フィールドがあり、キャッシュされたデータが最初に生成された時刻が含まれます）。次に、ページはロードされた後、AJAXを使用してデータを更新できます。その結果、ユーザーはページのロードをすぐに確認でき、データはおそらく数分以内の古さで、その後数分以内に表示されます。ページのデータ読み込みの秒数が最新のデータに置き換えられます。ユーザーが更新ボタンをマッシュしても、以前のクエリからのデータがキャッシュされて次回に返されるため、ユーザーが古いデータを受け取ることはありません。
また、実行中のAJAXリクエストの数を制限し、サーバー上でほとんどの計算を実行します。これにより、クライアントは1つのAJAXリクエストを作成できます。 AJAXリクエストと多くの計算でユーザーのコンピューターとネットワーク接続に負荷をかけるのではなく、数秒後にデータ全体を返します。さらに、サーバー側で計算を実行すると、キャッシュすることができます結果（前の段落を参照）。
これに対する一般的な解決策は、不完全なページレイアウトを表示することです。このレイアウトは、情報が利用可能になると徐々に満たされます。クライアントマシンがデータ自体を処理する必要がある場合を除いて、バックグラウンドスレッドでデータを読み込むとUIの速度が低下する理由はありません。
経験豊富なユーザーが必要とするすべてのボタンに最初からアクセスできるようにして、生産性を向上させます。