パフォーマンス – なぜ最近のウェブサイトはすぐにテキストを表示しないのですか?

browser display performance webkit

最近、テキストの表示が遅いサイトが多いことに気がつきました。通常、背景や画像などは読み込まれようとしていますが、テキストは表示されません。しばらくすると、あちこちにテキストが表示されるようになります(一度に全部が表示されるわけではありません)

基本的には、テキストが先に表示され、次に画像が表示され、残りの部分が後からロードされるという、以前とは逆の動作をしています。何か新しい技術がこの問題を引き起こしているのでしょうか?何かアイデアはありますか?

遅い接続にいることに注意してください、それがおそらく問題を強調しています

以下の例を参照してください – すべてが読み込まれていますが、最終的にテキストが表示されるまでに数秒かかります

enter image description here

  444  None  2013-02-07


ベストアンサー

理由の一つは、ウェブデザイナーが最近ではウェブフォント(通常は WOFF 形式)、例えば Google ウェブフォント などを好んで使用しているからです

以前は、サイトに表示できるフォントは、ユーザーがローカルにインストールしたものだけでした。例えば、MacとWindowsのユーザーは必ずしも同じフォントを持っていなかったので、デザイナーは本能的に常にルールとして定義されています

font-family: Arial, Helvetica, sans-serif;

最初のフォントがシステム上で見つからなかった場合、ブラウザは2番目のフォントを探し、最後に代替の “sans-serif “フォントを探します

これで、ブラウザにフォントをダウンロードさせるためのCSSルールとして、フォントのURLを与えることができるようになりました

@import url(http://fonts.googleapis.com/css?family=Droid+Serif:400,700);

で特定の要素のフォントを読み込みます

font-family: 'Droid Serif',sans-serif;

カスタムフォントが使えるというのは非常に好評ですが、ブラウザがリソースを読み込むまでテキストが表示されないという問題にもつながり、ダウンロード時間、フォントの読み込み時間、レンダリング時間などがかかってしまいます。これが皆さんが経験しているアーティファクトではないかと期待しています

例として、私の全国紙の一つである Dagens Nyheter は、見出しにはウェブフォントを使用していますが、リードには使用していませんので、そのサイトが読み込まれると、通常はリードが最初に表示され、半秒後には上記のすべての空白スペースが見出しで埋め尽くされます(これは少なくともChromeとOperaでは当てはまります。 他のものは試したことがありません)

(また、最近はデザイナーがJavaScriptをいたるところに散りばめているので、もしかしたら誰かがテキストに何か気の利いたことをしようとしているのかもしれませんが、それが遅延の原因になっているのかもしれません。これはサイト固有の問題だと思いますが、この時代にテキストが遅れてしまう一般的な傾向は、上述のウェブフォントの問題だと思います)


Addition

この回答は、あまり詳しく書いていないのに、そのせいか、非常にupvotedされるようになりました。質問スレッドには多くのコメントがあったので、少し拡大してみます(トピックが保護された後、しばらくしてから多くのコメントが消えてしまったようです – おそらくどこかのモデレーターが手動で削除したのでしょう)。また、このスレッドの他の回答も読んでみてください

この現象は、一般的には「フラッシュ・オブ・アンスタイル・コンテンツ」、特に「フラッシュ・オブ・アンスタイル・テキスト」と呼ばれているようです。FOUC」や「FOUT」で検索すると詳細な情報が得られます

私はウェブデザイナーのポール・アイリッシュ氏の記事をウェブフォントに関連してFOUTに推薦することができます

注意すべきことは、ブラウザによってこれを扱う方法が異なるということです。上にも書きましたが、OperaとChromeをテストしましたが、どちらも似たような動作をしていました。すべての WebKit ベースのもの (Chrome, Safari など) は、Web フォントの読み込み期間中、フォールバックフォントを使って Web フォントのテキストをレンダリングしないことで FOUT を回避することを選択しています。ウェブフォントがキャッシュされていても、レンダリングの遅延が発生します。この質問スレッドでは、そうではないことや、キャッシュされたフォントがこのような振る舞いをするのは全くの間違いだというコメントがたくさんありますが、例えば上のリンクを参照してください

どのような場合にFOUTが出るのでしょうか

  • ウィル。リモートの ttf/otf/woff をダウンロードして表示します
  • Will.キャッシュされた ttf/otf/woff を表示しています
  • ウィルです。データuri ttf/otf/woffをダウンロードして表示します
  • Will.Will.Will.Will.Will.Will.キャッシュされたデータuri ttf/otf/woffを表示しています
  • しません。従来のフォントスタックに既にインストールされ、名前が付けられているフォントを表示します
  • しません。インストールされているフォントを表示し、local()の場所を使用して名前を付けたフォントを表示します

Chrome は FOUT のリスクがなくなるまで待ってからレンダリングを行うため、遅延が発生します。この効果がどの程度見えるか(特にキャッシュからの読み込みの場合)は、特にレンダリングする必要のあるテキストの量やその他の要因に依存しているようですが、キャッシュによって効果が完全になくなるわけではありません

また、Irishでは、投稿の一番下に2011-04-14時点でのブラウザの動作に関する更新情報を掲載しています

  • Firefox(FFb11とFF4 Finalの時点で)のFOUTがなくなった!うわぁーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーhttp://bugzil.la/499292 基本的にテキストが3秒間見えなくなり、その後フォールバックフォントが復活します。ウェブフォントはおそらくこの3秒以内に読み込まれるでしょう…願わくば
  • IE9 は WOFF と TTF と OTF をサポートしています (ただし、埋め込みビット set thing– WOFF を使用している場合はほとんど意味がありません)。しかし、IE9 には FOUT があります。IE9 には FOUT があります
  • Webkit には a patch waiting to land があり、0.5 秒後にフォールバック テキストを表示するようになっています。FF と同じ動作ですが、3 秒ではなく 0.5 秒です
  • 追加。Blink には これもバグ登録されていますが、これをどうするかについては最終的なコンセンサスが得られていないようです – 現在のところ WebKit と同じ実装です

これが設計者向けの質問であれば、webfontloaderのようなこの種の問題を回避する方法に踏み込むことができますが、それは別の質問になります。この問題については、ポール・アイリッシュのリンクがさらに詳しく説明しています

482  Daniel Andersson  2013-02-07


その理由は、まだ読めないテキストがa ウェブフォントでレンダリングされているからです

また、ブラウザは Google Chrome で、WebKit を使ってページをレンダリングしているので、it was decided by them (WebKit ということです) によって、Web フォントがダウンロードされるまではテキストを全く表示しないのがベストだと決定されました。しかし、もしあなたが開発者で、代わりに適切なフォールバックシステムフォントでテキストを読めるようにしたいのであれば、Google の WebFont Loader のようなものを使って、これを実現することができます

117  Marcel  2013-02-07


短い答えです。AJAX または WOFF です

Webサイトが「文字の表示が遅くなる」原因はいくつかあります。portableapps.comの遅さは、WOFFフォントをダウンロードしたことが原因です。しかし、「あちこちにテキストが表示されるようになった」と記述されているものは、AJAXが原因であることが多いです

ウェブサイトは多くのパーツで構成されています。これらのパーツをどのようにダウンロードして組み立てるかは、ウェブデザイナーのコントロール下での設計上の選択です。遅さの原因は、開発者が以下のビルディングブロックをどのように組み立てるかを選択することにあります

  • 初期HTMLページ
  • CSS
  • JS
  • Images
  • WOFF fonts
  • AJAX requests
  • DOM manipulation

Traditionally websites:

従来、開発者は最初のHTMLページにテキストコンテンツを入れて、それが利用可能になるとすぐに表示するのが一般的でした。HTML は、ダウンロードされるいくつかのリソースを参照します。ブラウザは利用可能になると、スタイルや画像を含むように画面を徐々に再描画します。AJAXとWOFFは利用できませんでした


WOFF Websites:

WOFFフォントを利用することで、Webサイトでは、Webサイトと一緒にフォントをダウンロードすることで、通常はブラウザで利用できないフォントを利用することができるようになります。開発者の中には、WOFF フォントがすべてダウンロードされるまで、ブラウザにテキストコンテンツを表示しないように指示する人もいます。私の経験上、この方法はまだあまり普及していません


AJAX Websites:

開発者の中には、最初のHTMLページにテキストコンテンツを含まないことを選択する人もいます。代わりに、AJAXを使ってテキストコンテンツをダウンロードすることを選択します。これは基本的なページがロードされた後に行われます。私の経験では、この方法はWOFFフォントよりもはるかに広く採用されており、あなたが説明した遅さの原因となっていることがほとんどです


原因の特定

特定のサイトの原因を特定するには、FirebugChrome Developer Tools などのツールを使って分析する必要があります。あるいは、Internet Explorer 8を使用してサイトを開くこともできますが、AJAXはサポートしていますがWOFFはサポートしていません。サイトがまだ遅い場合、問題はAJAXであり、WOFFではありません

19  KevSheedy  2013-02-08


私はしばしば、「スタイル化されていないコンテンツのフラッシュ」を避けるために意図的に選択しているのかもしれません。CSS が読み込まれる前に表示されたテキストは、生の状態で表示され、ブラウザが再描画するとフラッシュが表示されます。コンテンツを最初に非表示にするために基本的なインラインスタイルを入れるか、実際のスタイルシートでオーバーライドするか、JS を使用することで、開発者はこのフラッシュを回避することができます

14  Greg H  2013-02-07


他の人が指摘しているように、カスタムフォントが遅延の一因になっている可能性が高いです

もう少し背景を説明すると、ブラウザはページの内容を画面にレンダリングする前に大まかに次のようなことをしています

  1. HTMLを取得します(DNS、TCP、リクエスト/レスポンスのための数回のラウンドトリップ)
  2. HTML の解析を開始し、外部 CSS や JS などの外部リソースを発見します。CSS はレイアウトをブロックし、JS はパースをブロックすることに注意してください。そのため、CSS や JS のような外部リソースをドキュメントの早い段階で読み込むと (ヘッド部などで読み込むと)、ページが画面にコンテンツを表示するまでの時間が遅くなります
  3. 外部のCSSとJSをフェッチする(数回のラウンドトリップ。これらのリソースがCDNのような別のドメインにある場合はDNSとTCP、リクエスト/レスポンスのRTT)。)
  4. 外部CSSとJSの読み込みが終わったら、JSのパース/実行、スタイルのパース/適用を行います
  5. CSS がカスタム フォントを参照している場合、それらのフォントもダウンロードしなければならないため、カスタム フォントに依存するページのあらゆる部分をレンダリングするために、さらに往復の遅延が発生します

カスタムフォントによる遅延についてではありませんが、最近、レンダリング遅延の原因についての追加情報を提供するブログ記事を書きました。それは、あなたのページの最初のペイントにかかる時間を最小限に抑えるためのいくつかの提案を提供しています。カスタムフォントを使用したいページを含め、ページのコンテンツ表示を高速化したいと考えている読者にとって、この記事が役に立つことを願っています。http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/

8  Bryan McQuade  2013-02-07


簡単な答えだ開発者です

外部ドキュメント(.css や .js ファイルなど)を参照しているリンクタグやスクリプトタグがドキュメントの先頭(本文やその要素よりもフローの上位)に配置されている場合、それらが最初に読み込まれます。JavaScript は、それを参照するマークアップから実行されます。処理するコードが多い場合、あるいは面倒なコードである場合、あるいはより一般的には、表示されると期待されるテキストがサーバー上でレンダリングされ、ロード時にドキュメントに入力されている場合、サーバー側のコードもまた面倒であったり、大きかったり、複数の同時リクエストの処理のために I/O がブロックされていたりする場合、HTML がレンダリングされる前にダウンタイムに気づくかもしれません。開発者の中には、マークアップやスタイルの後に (本文の最後に) ビューに関連しない JavaScript をロードすることを選択する人もいますが、最高の開発者は、その技術的な決定が実装されたときに全体的なユーザーエクスペリエンスにどのような影響を与えるかをより意識しようとします

インターネット接続の速度は、データのダウンロードが遅くなるのは明らかですが、コードの書き方が悪かったり、(ウェブサイトの種類に合わせて)設計が悪かったりすることが、より高速なネットワーク接続が一般的になるにつれて、動的コンテンツの読み込みが遅くなることで、ますます中心的な役割を果たすようになっています

4  Benny  2013-02-07


一言で言えば、ページを表示する前に別のHTTP GETからロードする必要があるロード可能なオブジェクトが多すぎて、サイトの健全性の指標として平均的な待ち時間に過度に依存していることです

最初のものは、ページが読み込まれるすべての .css、.js、および Web フォントを指し、多くのサイトが JSON オブジェクトを取得する必要があることは言うまでもありませんが、XHR リクエストを受けて、それらからテンプレートを使って HTML を生成する必要があります

しかし、なぜサイトが遅いことに気づかないのでしょうか?

おそらく、高速化のためにどこかに memecache を入れていて (あるいはファイルシステムキャッシュに頼っている)、平均的なレイテンシを使ってサイトの健全性を測定しているからでしょう。そのため、キャッシュされたオブジェクトは6ミリ秒のレイテンシで返され、多くの GET リクエストが完了するのに5000ミリ秒かかるという事実を覆い隠しています。平均は死ななければなりません。許容可能な最大閾値を超えたRTTのカウントは万歳です!この数値は 0 でなければなりません

3  Michael Dillon  2013-02-13


まあ、複数の理由があります。1つの理由はまた、背景を定義するためのコマンドやHTMLページの上にしばしばまたは最初にロードされる別のCSSで取得されます

もう一つの原因は、画像のサイズを入力することは可能ですが、ほとんどの場合、ウェブデザイナーはそれを利用していません。そのため、ブラウザはページ上で最初に画像全体を読み込まなければならず、テキストをどのように折り返すかを知る必要があります

デザイナーの中には、最初に写真を表示して次のテキストを表示したいと考えている人もいますが、彼らはそれをjavascriptで実現しています

しかし、私は唯一のニュースを読みたいのに、なぜ私のページには多くのスパム商業的なものがあるのか疑問に思っている場合は、あなたのための解決策があります。firefoxを使用している場合は、スパムブロッカーを使用することができます。このようなアドオンを使用すると、ウェブブラウザはスパムを提供するサイトを知っていて、単にそれらをブロックするだけで、ページの読み込みが格段に速くなる一方で、あなたが読む記事に関連する重要な画像を見ることができます

fidlerはIEexplorerやFireFox(プロキシ機能を使用)で使用することができます。これは HTML デバッグツールです

-1  user613326  2013-02-07


タイトルとURLをコピーしました