最近、Webサイトでテキストがすぐに表示されないのはなぜですか。
最近多くのWebサイトではテキストの表示が遅くなっていることに気付きました。通常、背景、画像などが読み込まれますが、テキストは読み込まれません。しばらくするとテキストがあちこちに表示され始めます（必ずしもすべてが同時に表示されるとは限りません）。
それは基本的にはテキストが最初に表示されたとき、それから画像と残りがその後ロードされていたときに使用していたときとは逆に機能します。この問題を引き起こしている新しい技術は何ですか？何か案が？
私は遅い接続をしていることに注意してください、それはおそらく問題を強調します。
例については以下を参照してください - すべてがロードされましたが、テキストが最終的に表示されるまでにさらに数秒かかります。
その理由は、あなたがまだ読めないテキストが ウェブフォント でレンダリングされているからです。
また、お使いのブラウザはページをレンダリングするためにWebKitを使用するGoogle Chromeなので 、テキストを表示しないのが最良の方法です （WebKit）。 Webフォントがダウンロードされるまでのすべて。しかし、代わりに適切な代替システムフォントでテキストを読みやすくすることを望む開発者であれば、 GoogleのWebFont Loader のようなものを使用することができます。この。
いくつかの原因があるWebサイトがあります"テキストの表示が遅い"。 portableapps.com の遅さはWOFFフォントのダウンロードが原因です。ただし、"テキストはあちこちに表示されるようになります"と説明するものは、AJAXが原因であることが多くなります。
Webサイトは多くの部分で構成されています。これらのパーツがどのようにダウンロードされ組み立てられるかは、ウェブデザイナーの管理下にあるデザインの選択です。この遅さは、開発者が次の構成要素を組み立てる方法を選択したために発生します。
- 最初のHTMLページ
- CSS
- JS
- 画像
- WOFFフォント
- AJAXリクエスト
- DOM操作
従来のWebサイト：
従来、開発者は、テキストコンテンツを初期HTMLページに入れて表示するのが一般的でした利用可能になり次第。 HTMLは、ダウンロードされるいくつかのリソースを参照します。ブラウザはprogressively redraw画面を使用可能になり、スタイルと画像が含まれるようになります。 AJAXおよびWOFFは使用できませんでした。
WOFF Websites：
WOFFフォントを使用すると、Webサイトでフォントをダウンロードするを使用して、Webサイトで通常ブラウザで使用できないフォントを使用できます。一部の開発者は、すべてのWOFFフォントがダウンロードされるまで、テキストコンテンツを表示しないようにブラウザーに指示します。私の経験では、このアプローチはまだあまり使用されていません。
AJAX Websites：
一部の開発者は、最初のHTMLページにテキストコンテンツを含めないことを選択します。代わりに、AJAXを使用してテキストコンテンツをダウンロードすることを選択します。これは基本ページがロードされた後で発生します。私の経験では、この方法はWOFFフォントよりもはるかに多くの広く採用されているを得ており、ほとんどの場合、あなたが説明する速度の低下の原因です。
原因の特定
特定のサイトの原因を特定するには、 Firebug または Chrome Developer Tools などのツールを使用した分析が必要です。または、 Internet Explorer 8 を使用してサイトを開くことができます。これは、AJAXをサポートしますが、WOFFはサポートしません。それでもサイトが遅い場合、問題はAJAXであり、WOFFではありません。
私はしばしば、「スタイルのないコンテンツのフラッシュ」を回避することを意図的に選択することがあります。 CSSがロードされる前にテキストが表示された場合は、テキストがそのまま表示されてからしばらくすると表示され、その後ブラウザとしてフラッシュされると再描画されます。実際のスタイルシートでオーバーライドされるコンテンツを最初に隠すためにいくつかの基本的なインラインスタイルを入れることによって、またはJSを使用することによって、開発者はこのフラッシュを避けます。
他の人が指摘したように、カスタムフォントはおそらく遅延の一因となっています。
もう少し背景を説明するために、ブラウザはページの内容を画面にレンダリングする前に、おおよそ次のことを行っています。
- hTMLを取得する（DNS、TCP、リクエスト/レスポンスの数往復）
- hTMLの解析を開始し、外部のCSSやJSなどの外部リソースを見つけます。 CSSはレイアウトをブロックし、JSは解析をブロックします。そのため、CSSやJSなどの外部リソースが文書の最初の部分（頭の中など）にロードされると、ページにコンテンツが表示されるまでの時間が遅くなります。
- 外部のCSSとJSを取得する（いくつかのラウンドトリップ：DNSとTCPこれらのリソースがCDNなどの異なるドメインにある場合、およびリクエスト/レスポンスのRTT）
- 外部CSSとJSのロードが完了したら、JSを解析/実行し、スタイルを解析/適用します。
- cSSがカスタムフォントを参照している場合は、それらのフォントもダウンロードする必要があるため、カスタムフォントに依存するページの一部をレンダリングするために追加の往復遅延が発生します。
それは特にカスタムフォントによって引き起こされる遅れについてではありませんが、私は最近レンダリングの遅れの原因についての追加情報を与えるブログ投稿を書きました。それはあなたのページのために最初にペイントする時間を最小にするためにいくつかの提案を与えます。カスタムフォントを使用したいページを含め、自分のページでコンテンツをより速く表示させることに興味を持っている読者にはこれが便利なことです。 モバイルページの1秒以内のレンダリング/
短い答え：開発者。
外部文書を参照するリンクタグやスクリプトタグ（.cssファイルや.jsファイルなど）が文書の先頭（本文、およびその要素よりもフロー内で高い位置）に配置されると、それらが最初に読み込まれます。 JavaScriptはそれを参照するマークアップから実行されます。処理するコードがたくさんあるか、コードが面倒な場合、あるいは一般的に、表示されるテキストがサーバー上でレンダリングされ、ロード時に文書に取り込まれる場合、そしてそのサーバーサイドコードも面倒です。大量の、または複数の同時要求の処理が原因でI/Oがブロックされている場合は、HTMLがレンダリングされる可能性がある前にダウンタイムに気付くことがあります。一部の開発者は、マークアップやスタイルの後に（本体の最後に）ビューに関連しないJavaScriptをロードすることを選択します。そのため、実装時にテクノロジの決定が全体のユーザーエクスペリエンスに与える影響を意識してください。
インターネット接続速度は、明らかにデータの低速ダウンロードに重要な役割を果たしていますが、動的なコンテンツの低速ロードでは、ネットワーク接続が高速になるにつれて、Webサイトの種類に応じたコードの書き方やデザインの不備が生じます。ユビキタス.
一言で言えば、ページを表示する前に別々のHTTP GETからロードする必要があるロード可能なオブジェクトが多すぎ、サイトの健全性の尺度として平均待ち時間に過度に依存しています。
1つ目は、ページがロードするすべての.css、.js、およびWebフォントを参照します。多くのサイトでもXHR要求を介してJSONオブジェクトを取得してから、ある種のテンプレートを使用してそれらからHTMLを生成する必要があります。
しかし、なぜ彼らはサイトが遅いことに気付かないのですか？
おそらく彼らは物事をスピードアップするために（あるいは単にファイルシステムのキャッシュに頼るために）どこかにmemecacheを持っていて、平均待ち時間を使って彼らのサイトの健全性を測定しているからです。したがって、キャッシュされたオブジェクトは6ミリ秒の待ち時間で返され、多くのGET要求が完了するまでに5000ミリ秒かかるという事実を隠します。平均は死ぬ必要があります。許容可能な最大しきい値を超えてRTTのカウントを長持ちさせます。その数は0であるべきです、または、定義上、RTTは受け入れられません。