最近、ウェブサイトがすぐにテキストを表示しないのはなぜですか？

最近、多くのWebサイトでテキストの表示が遅いことに気付きました。通常、背景、画像などが読み込まれますが、テキストは読み込まれません。しばらくすると、テキストがあちこちに表示され始めます（常にすべてが同時に表示されるとは限りません）。

それは基本的に、テキストが最初に表示されたとき、イメージと残りの部分がその後読み込まれていたとき、以前とは逆に機能します。この問題を引き起こしている新しいテクノロジーは何ですか？何か案が？

接続速度が遅いことに注意してください。これはおそらく問題を際立たせます。

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

その理由の1つは、今日のWebデザイナーは、Webフォント（通常はWOFF形式）を使用することを好みます。たとえば、Google Webフォントなどです。

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

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

ここで、最初のフォントがシステム上で見つからなかった場合、ブラウザは2番目のフォントを探し、最後にフォールバック「サンセリフ」フォントを探します。

これで、ブラウザにフォントをダウンロードさせるCSSルールとしてフォントURLを与えることができます。

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

次に、たとえば次のようにして特定の要素のフォントをロードします。

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

これは、カスタムフォントを使用できることが非常に一般的ですが、ブラウザによってリソースがロードされるまでテキストが表示されないという問題にもつながります。これには、ダウンロード時間、フォントのロード時間、レンダリング時間が含まれます。これはあなたが経験しているアーティファクトだと思います。

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

（また、デザイナーは最近どこでも絶対にJavaScriptを振りかけているので、誰かがテキストで何か巧妙なことをしようとしているのかもしれません。それが遅れる理由です。それは非常にサイト特有です。時間は上記のウェブフォントの問題だと思います。）

添加

この答えは非常に支持されましたが、私はあまり詳しく説明しませんでしたが、おそらくこのためです。質問スレッドには多くのコメントがあったので、少し拡大してみます（トピックが保護された後、多くのコメントが消えたようです-一部のモデレーターはおそらく手動で削除しました）。また、これらはすべて独自の方法で展開されるため、このスレッドの他の回答をお読みください。

この現象は、一般に「スタイルなしコンテンツのフラッシュ」、特に「スタイルなしテキストのフラッシュ」として知られています。「FOUC」と「FOUT」を検索すると、詳細情報が表示されます。

Webフォントに関連して、FOUTに関するWebデザイナーのPaul Irishの投稿をお勧めします。

注目できることは、異なるブラウザはこれを異なる方法で処理するということです。上記で書いたように、OperaとChromeはどちらも同じように動作します。すべてのWebKitベースのもの（Chrome、Safariなど）は、Webフォントの読み込み期間中にフォールバックフォントでWebフォントテキストをレンダリングしないことにより、FOUTを回避することを選択します。場合でも、ウェブフォントがキャッシュされ、そこになりますレンダリング遅延すること。この質問スレッドには多くのコメントがあり、キャッシュされたフォントがこのように振る舞うのは間違っていますが、たとえば上記のリンクから：

どのような場合にFOUTを取得しますか

• Will：リモートttf / otf / woffのダウンロードと表示
• Will：キャッシュされたttf / otf / woffの表示
• Will： data-uri ttf / otf / woffのダウンロードと表示
• Will：キャッシュされたデータの表示uri ttf / otf / woff
• しない：従来のフォントスタックで既にインストールされ、名前が付けられているフォントを表示する
• しない： local（）の場所を使用してインストールされ、名前が付けられたフォントを表示する

Chromeは、レンダリングの前にFOUTリスクがなくなるまで待機するため、遅延が発生します。効果がどの程度見えるか（特にキャッシュからロードする場合）は、レンダリングする必要のあるテキストの量とおそらく他の要因に依存しているようですが、キャッシュは効果を完全には削除しません。

アイルランド語では、2011年4月14日の時点でブラウザの動作に関する更新が投稿の下部にあります。

• Firefox（FFb11およびFF4 Final以降）にはFOUTがありません！すごい！http://bugzil.la/499292基本的に、テキストは3秒間非表示になり、その後、代替フォントが表示されます。ただし、おそらく3秒以内にウェブフォントが読み込まれます。
• IE9は、WOFFとTTFおよびOTFをサポートしています（ただし、ビット セットを埋め込む必要があります-WOFFを使用する場合はほとんど意味がありません）。しかしながら！！！IE9にはFOUTがあります。:(
• Webkitには、 0.5秒後にフォールバックテキストを表示するために着陸するのを待っているパッチがあります。FFと同じ動作ですが、3秒ではなく0.5秒です。
• 追加：Blinkにもこれに関するバグが登録されていますが、それをどう処理するかについては最終的な合意に達していないようです-現在はWebKitと同じ実装です。

これがデザイナー向けの質問である場合、のようなこれらの種類の問題を回避する方法に進むことができますwebfontloaderが、それは別の質問です。ポール・アイリッシュのリンクでは、この問題についてさらに詳しく説明しています。

この理由は、まだ読めないテキストが、ブラウザへのパイプをたどる途中のWebフォントでレンダリングされているためです。

また、ブラウザーはWebKitを使用してページをレンダリングするGoogle Chromeであるため、Webフォントがダウンロードされるまではテキストをまったく表示しないのが最善であると判断しました（WebKit）。ただし、代わりに適切なフォールバックシステムフォントでテキストを読み上げたい開発者であれば、GoogleのWebFont Loaderなどを使用してこれを実現できます。

短い答え：AJAXまたはWOFF

ウェブサイトが「テキストの表示に時間がかかる」原因はいくつかあります。上の遅さportableapps.comをダウンロードすることにより引き起こされWOFFのフォントを。ただし、「テキストはあちこちに表示されるようになります」と説明することは、AJAXが原因であることが多くなります。

Webサイトは多くの部分で構成されています。これらの部品をダウンロードして組み立てる方法は、Webデザイナーの管理下で設計を選択します。この遅さは、開発者が次の構成要素を組み立てる方法を選択したために発生します。

• 最初のHTMLページ
• CSS
• JS
• 画像
• WOFFフォント
• AJAXリクエスト
• DOM操作

従来のウェブサイト：

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

WOFF Webサイト：

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

AJAX Webサイト：

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

原因の特定

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

「スタイル設定されていないコンテンツのフラッシュ」を避けるのは、しばしば意図的な選択かもしれません。CSSがロードされる前にテキストが表示された場合、テキストは生のまま表示され、ブラウザが再描画するときにフラッシュが表示されます。実際のスタイルシートでオーバーライドされるコンテンツを最初に隠すためにいくつかの基本的なインラインスタイルを配置するか、JSを使用することにより、開発者はこのフラッシュを回避します。

他の人が指摘したように、カスタムフォントが遅延の原因である可能性があります。

もう少し背景を説明するために、ブラウザはページコンテンツを画面にレンダリングする前に、おおよそ次のことを行っています。

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 -一秒/

短い答え：開発者。

外部ドキュメント（.cssや.jsファイルなど）を参照するリンクおよびスクリプトタグがドキュメントのヘッドに配置されている場合（本文およびその要素よりもフロー内で高い）、それらは最初にロードされます。JavaScriptは、それを参照するマークアップから実行されます。処理するコードが大量にあるか、面倒なコードである場合、またはより一般的には、見たいテキストがサーバー上でレンダリングされ、ロード時にドキュメントに取り込まれる場合-そしてそのサーバー側のコードも面倒です、大規模な、または複数の同時リクエストの処理によるI / Oのブロックが発生している場合、HTMLがレンダリングされる前にダウンタイムに気付くことがあります。一部の開発者は、マークアップとスタイルの後に（本文の最後に）ビューに関連しないJavaScriptを読み込むことを選択します。

インターネット接続速度は、データの遅いダウンロードで重要な役割を果たしますが、ネットワーク接続が高速であるため、コードの記述が不十分であるか、Webサイトの種類に応じて技術スタックが適切に設計されていないため、動的コンテンツの読み込みがますます重要になりますユビキタスにアプローチします。

一言で言えば、ページを表示する前に個別のHTTP GETからロードする必要があるロード可能なオブジェクトが多すぎ、サイトの状態の尺度として平均レイテンシに過度に依存しています。

1つ目は、多くのサイトがXHRリクエストを介してJSONオブジェクトを取得し、何らかのテンプレートを使用してHTMLオブジェクトを生成する必要があることは言うまでもなく、ページが読み込むすべての.css、.js、およびwebfontsを指します。

しかし、なぜ彼らはサイトが遅いことに気付かないのでしょうか？

おそらく、どこかに高速化するためにmemecacheがあり（またはファイルシステムキャッシュに依存している）、平均レイテンシを使用してサイトの状態を測定しているためでしょう。したがって、キャッシュされたオブジェクトは6ミリ秒のレイテンシで返され、多くのGET要求が完了するのに5000ミリ秒かかるという事実を隠します。平均は死ななければなりません。許容可能な最大しきい値を超えるRTTのカウントを長期間実行します。その数は0でなければなりません。または、定義により、RTTは受け入れられません。

それにはいくつかの理由があります。理由の1つは、背景を定義するコマンド、またはhtmlページの上部にあるコマンドが頻繁に、または最初に読み込まれる別のCSSで取得されることです。テキストを含むドキュメントの本文がロードされる前。

もう1つの原因は、ほとんどの場合、画像のサイズを入力することは可能ですが、Webデザイナーはそれを使用しないことです。そのため、ブラウザは最初に画像全体をページにロードして、テキストをどのように折り返すかを知る必要があります。

一部のデザイナーは、最初の写真と次のテキストも表示したいので、JavaScriptを使用してそれを実現します。たとえば、単純なページでは最初にバナーを表示し、次に他のすべてを表示します。

しかし、なぜニュースを読みたいだけなのに、なぜ私のページに大量のスパム商品があるのか​​不思議に思うなら、解決策があります。Firefoxを使用している場合は、スパムブロッカーを使用できます。このようなアドオンを使用すると、webrowserはスパムを提供するサイトを認識し、単にそれらをブロックするだけで、ページの読み込みがはるかに高速になりますが、読んだ記事に関連する重要な画像を表示できます。

fidlerを試すには、ページの読み込みが遅いことに対処するすべての人にお勧めします。fidlerは、IEexplorerまたはFireFox（プロキシ機能を使用）で使用できます。Fidlerは、実際にかかる時間とWebページの一部がロードされるタイミングを実際に示します。これはHTMLデバッグツールです。