CSSは常にJavascriptに先行する必要がありますか?


897

オンラインの数え切れないほどの場所で、JavaScriptの前にCSSを組み込むことを推奨しています。推論は一般に、この形式のものです:

CSSとJavaScriptの注文に関しては、CSSが最初に来るようにします。その理由は、レンダリングスレッドには、ページのレンダリングに必要なすべてのスタイル情報があるためです。JavaScriptのインクルードが最初に来る場合、JavaScriptエンジンはそれをすべて解析してから次のリソースセットに進む必要があります。つまり、必要なスタイルがすべて揃っていないため、レンダリングスレッドはページを完全には表示できません。

私の実際のテストでは、まったく異なるものが明らかになりました。

私のテストハーネス

次のRubyスクリプトを使用して、さまざまなリソースに特定の遅延を生成します。

require 'rubygems'
require 'eventmachine'
require 'evma_httpserver'
require 'date'

class Handler  < EventMachine::Connection
  include EventMachine::HttpServer

  def process_http_request
    resp = EventMachine::DelegatedHttpResponse.new( self )

    return unless @http_query_string

    path = @http_path_info
    array = @http_query_string.split("&").map{|s| s.split("=")}.flatten
    parsed = Hash[*array]

    delay = parsed["delay"].to_i / 1000.0
    jsdelay = parsed["jsdelay"].to_i

    delay = 5 if (delay > 5)
    jsdelay = 5000 if (jsdelay > 5000)

    delay = 0 if (delay < 0) 
    jsdelay = 0 if (jsdelay < 0)

    # Block which fulfills the request
    operation = proc do
      sleep delay 

      if path.match(/.js$/)
        resp.status = 200
        resp.headers["Content-Type"] = "text/javascript"
        resp.content = "(function(){
            var start = new Date();
            while(new Date() - start < #{jsdelay}){}
          })();"
      end
      if path.match(/.css$/)
        resp.status = 200
        resp.headers["Content-Type"] = "text/css"
        resp.content = "body {font-size: 50px;}"
      end
    end

    # Callback block to execute once the request is fulfilled
    callback = proc do |res|
        resp.send_response
    end

    # Let the thread pool (20 Ruby threads) handle request
    EM.defer(operation, callback)
  end
end

EventMachine::run {
  EventMachine::start_server("0.0.0.0", 8081, Handler)
  puts "Listening..."
}

上記のミニサーバーを使用すると、JavaScriptファイル(サーバーとクライアントの両方)に任意の遅延と任意のCSS遅延を設定できます。例えば、http://10.0.0.50:8081/test.css?delay=500、CSSの転送に500 msの遅延が発生します。

次のページを使用してテストします。

<!DOCTYPE html>
<html>
  <head>
      <title>test</title>
      <script type='text/javascript'>
          var startTime = new Date();
      </script>
      <link href="http://10.0.0.50:8081/test.css?delay=500" type="text/css" rel="stylesheet">
      <script type="text/javascript" src="http://10.0.0.50:8081/test2.js?delay=400&amp;jsdelay=1000"></script> 
  </head>
  <body>
    <p>
      Elapsed time is: 
      <script type='text/javascript'>
        document.write(new Date() - startTime);
      </script>
    </p>    
  </body>
</html>

最初にCSSを含めると、ページのレンダリングに1.5秒かかります。

CSSが最初

最初にJavaScriptを含めると、ページのレンダリングに1.4秒かかります。

最初にJavaScript

Chrome、Firefox、Internet Explorerでも同様の結果が得られます。ただし、Operaでは、順序は重要ではありません。

すべてのCSSがダウンロードされるまで、JavaScriptインタープリターは開始を拒否しているようです。したがって、JavaScriptスレッドの実行時間が長くなるほど、JavaScriptを最初にインクルードする方が効率的であるようです。

何か不足していますか?JavaScriptインクルードの前にCSSインクルードを配置するという推奨は正しくありませんか?

非同期を追加したり、setTimeoutを使用してレンダリングスレッドを解放したり、JavaScriptコードをフッターに挿入したり、JavaScriptローダーを使用したりできることは明らかです。ここで重要なのは、主要なJavaScriptビットとCSSビットをヘッドで順序付けることです。


120
1511対1422は統計的に有意な違いですか?それは6パーセントです。注目すべき人と平均的な人のパフォーマンスの差の一般的なしきい値は、約20%です。
Jeff Atwood、

15
重要なのは、並べ替えによってこの任意の遅延が解消されるため、遅延を任意の値に設定でき、問題のデモにすぎません。
Sam Saffron、2012

3
あなたの遅延は100ミリ秒でしたか?スクリーンショットの違いは89ミリ秒です。あなたのURLではdelay=400&amp;jsdelay=1000delay=500それは100ミリ秒または89ミリ秒の近くではありません。あなたがどの番号を参照しているかはわかりません。
Jeff Atwood、

4
「JavaScriptのインクルードが最初に来る場合、JavaScriptエンジンは次のリソースのセットに進む前にすべてを解析する必要があります。これは、必要なスタイルがすべてないため、レンダリングスレッドがページを完全に表示できないことを意味します」-JSインクルードが先頭にある場合、CSSインクルードが前か後かに関係なく、ページがレンダリングされる前にJSが実行されます。
nnnnnn

162
これを検討したかどうかはわかりませんが、読み込み時間の認識も重要です。したがって、たとえば、CSSを最初にロードすると、ページの背景の色やテクスチャだけが表示される場合は、より高速に見えます。絶対ロード時間はこれを示していない場合があります。
Rakesh Pai

回答:


712

これは非常に興味深い質問です。私は常にCSSを<link href="...">JSの前に置いてい<script src="...">ます。だから、あなたは正しいです。実際の調査を行う時間です。

Nodeに独自のテストハーネスをセットアップします(以下のコード)。基本的に、私は:

  • HTTPキャッシュがないことを確認したため、ページが読み込まれるたびにブラウザが完全ダウンロードを実行する必要がありました。
  • 現実をシミュレートするために、jQueryとH5BPを含めました CSS(そのため、解析するスクリプト/ CSSは適切な量になっています)
  • 2つのページを設定します。1つはスクリプトの前にCSSを使用し、もう1つはスクリプトの後にCSSを使用します。
  • 外部スクリプトにかかった時間を <head>実行
  • のインラインスクリプトの<body>実行にかかった時間を記録します。これは、DOMReady。ます。
  • CSSやスクリプトのブラウザへの送信が500ミリ秒遅れる。
  • 3つの主要なブラウザでテストを20回実行しました。

結果

まず、CSSファイルを500ミリ秒遅延させます。

     Browser: Chrome 18    | IE 9         | Firefox 9
         CSS: first  last  | first  last  | first last
=======================================================
Header Exec |              |              |
Average     | 583ms  36ms  | 559ms  42ms  | 565ms 49ms
St Dev      | 15ms   12ms  | 9ms    7ms   | 13ms  6ms
------------|--------------|--------------|------------
Body Exec   |              |              |
Average     | 584ms  521ms | 559ms  513ms | 565ms 519ms
St Dev      | 15ms   9ms   | 9ms    5ms   | 13ms  7ms

次に、CSSではなくjQueryを500ミリ秒遅延するように設定します。

     Browser: Chrome 18    | IE 9         | Firefox 9
         CSS: first  last  | first  last  | first last
=======================================================
Header Exec |              |              |
Average     | 597ms  556ms | 562ms  559ms | 564ms 564ms
St Dev      | 14ms   12ms  | 11ms   7ms   | 8ms   8ms
------------|--------------|--------------|------------
Body Exec   |              |              |
Average     | 598ms  557ms | 563ms  560ms | 564ms 565ms
St Dev      | 14ms   12ms  | 10ms   7ms   | 8ms   8ms

最後に、jQueryとCSSの両方を500ms遅延するように設定しました。

     Browser: Chrome 18    | IE 9         | Firefox 9
         CSS: first  last  | first  last  | first last
=======================================================
Header Exec |              |              |
Average     | 620ms  560ms | 577ms  577ms | 571ms 567ms
St Dev      | 16ms   11ms  | 19ms   9ms   | 9ms   10ms
------------|--------------|--------------|------------
Body Exec   |              |              |
Average     | 623ms  561ms | 578ms  580ms | 571ms 568ms
St Dev      | 18ms   11ms  | 19ms   9ms   | 9ms   10ms

結論

まず、私は<head>、ドキュメントの(の最後ではなく<body>)にスクリプトが配置されているという前提の下で動作していることに注意することが重要です。<head>ドキュメントの最後と最後にスクリプトにリンクする理由についてはさまざまな議論がありますが、それはこの回答の範囲外です。これは、が内のの<script>前にくるべきかどうかを厳密<link>に示してい<head>ます。

最近のデスクトップブラウザーでは、CSSにリンクすると、パフォーマンスが向上しないように見えます。スクリプトの後にCSSを配置すると、CSSとスクリプトの両方が遅延している場合は取るに足らない量の効果が得られますが、CSSが遅延している場合は効果が大きくなります。(last最初の結果セットの列にます。)

CSS lastへのリンクはパフォーマンスを低下させないように見えますが、特定の状況下で利益もたらす可能性があるため、古いブラウザーのパフォーマンスが問題にならない場合は、デスクトップブラウザーでのみ外部スクリプトにリンクした後で外部スタイルシートリンクする必要がありますモバイルの状況について読んでください。

どうして?

従来、ブラウザが<script>外部リソースを指すタグに遭遇すると、ブラウザはHTMLの解析を停止し、スクリプトを取得して実行し、HTMLの解析を続行していました。対照的に、ブラウザーが<link>外部スタイルシートのを検出した場合、CSSファイルを(並行して)フェッチしながら、HTMLの解析を続行します。

したがって、スタイルシートを最初に置くという広く繰り返されるアドバイス–最初にダウンロードし、ダウンロードする最初のスクリプトを並行してロードすることができます。

ただし、最近のブラウザー(上記でテストしたすべてのブラウザーを含む)は投機的解析を実装しており、ブラウザーはHTMLを「先読み」し、スクリプトのダウンロードと実行の前にリソースのダウンロードを開始します。

投機的解析を行わない古いブラウザでは、スクリプトを並列にダウンロードしないため、スクリプトを最初に配置するとパフォーマンスに影響します。

ブラウザのサポート

投機的解析は最初に実装されました:(2012年1月現在、このバージョン以上を使用している世界中のデスクトップブラウザーユーザーの割合とともに)

  • Chrome 1(WebKit 525)(100%)
  • IE 8(75%)
  • Firefox 3.5(96%)
  • Safari 4(99%)
  • Opera 11.60(85%)

合計で、現在使用されているデスクトップブラウザの約85%が投機的な読み込みをサポートしています。CSSの前にスクリプトを配置すると、世界中のユーザーの15%がパフォーマンスを低下させます。YMMVは、サイトの特定のオーディエンスに基づいています。(そして、数が減少していることを思い出してください。)

モバイルブラウザーでは、モバイルブラウザーとOSランドスケープが異種混合であるため、明確な数値を取得するのが少し難しくなります。投機的レンダリングはWebKit 525(2008年3月リリース)に実装されており、モバイルブラウザーのほとんどすべてがWebKitに基づいているため、「ほとんどの」モバイルブラウザーサポートする必要があると結論付けることができます。quirksmodeによると、iOS 2.2 / Android 1.0はWebKit 525を使用しています。WindowsPhoneがどのように見えるか私にはわかりません。

しかし、私はAndroid 4デバイスでテストを実行し、デスクトップの結果と同様の数値を確認しながら、Chrome for Android の素晴らしい新しいリモートデバッガーに接続しました。[ネットワーク]タブには、ブラウザーが実際にダウンロードを待機していることが示されましたJavaScriptが完全に読み込まれるまでのCSS –言い換えれば、Android向けのWebKitの最新バージョンでさえ、投機的な解析をサポートしていないようです。 CPU、メモリ、および/またはモバイルデバイスに固有のネットワークの制約が原因でオフになっているのではないかと思います。

コード

だらしない–これはQ&Dでした。

app.js

var express = require('express')
, app = express.createServer()
, fs = require('fs');

app.listen(90);

var file={};
fs.readdirSync('.').forEach(function(f) {
    console.log(f)
    file[f] = fs.readFileSync(f);
    if (f != 'jquery.js' && f != 'style.css') app.get('/' + f, function(req,res) {
        res.contentType(f);
        res.send(file[f]);
    });
});


app.get('/jquery.js', function(req,res) {
    setTimeout(function() {
        res.contentType('text/javascript');
        res.send(file['jquery.js']);
    }, 500);
});

app.get('/style.css', function(req,res) {
    setTimeout(function() {
        res.contentType('text/css');
        res.send(file['style.css']);
    }, 500);
});


var headresults={
    css: [],
    js: []
}, bodyresults={
    css: [],
    js: []
}
app.post('/result/:type/:time/:exec', function(req,res) {
    headresults[req.params.type].push(parseInt(req.params.time, 10));
    bodyresults[req.params.type].push(parseInt(req.params.exec, 10));
    res.end();
});

app.get('/result/:type', function(req,res) {
    var o = '';
    headresults[req.params.type].forEach(function(i) {
        o+='\n' + i;
    });
    o+='\n';
    bodyresults[req.params.type].forEach(function(i) {
        o+='\n' + i;
    });
    res.send(o);
});

css.html

<!DOCTYPE html>
<html>
    <head>
        <title>CSS first</title>
        <script>var start = Date.now();</script>
        <link rel="stylesheet" href="style.css">
        <script src="jquery.js"></script>
        <script src="test.js"></script>
    </head>
    <body>
        <script>document.write(jsload - start);bodyexec=Date.now()</script>
    </body>
</html>

js.html

<!DOCTYPE html>
<html>
    <head>
        <title>CSS first</title>
        <script>var start = Date.now();</script>
        <script src="jquery.js"></script>
        <script src="test.js"></script>
        <link rel="stylesheet" href="style.css">
    </head>
    <body>
        <script>document.write(jsload - start);bodyexec=Date.now()</script>
    </body>
</html>

test.js

var jsload = Date.now();


$(function() {
    $.post('/result' + location.pathname.replace('.html','') + '/' + (jsload - start) + '/' + (bodyexec - start));
});

jquery.jsはjquery-1.7.1.min.jsでした


137
これは素晴らしい答えです。科学使用していただきありがとうございます。あなたの結果によれば、「最新のブラウザでは、CSSにリンクすると最初にパフォーマンスが向上することはないようです」という質問のタイトルに対する答えは「はい」であり、CSSファーストの古いアドバイスは明らかに無効です。
Jeff Atwood、

@ josh3736のモバイルでの逆に関する更新について...これは、この重要な変更で銃を飛び越えないようにするのに適した事例です。多くの場合、モバイルでのパフォーマンスがより重要であるため、他のモバイルブラウザーの動作(webkit、gecko、presto、tridentなど)に興味があります。
scunliffe 2012

1
遅いサーバーの速度をシミュレートするために、css / jsの印刷に若干の遅延を加えることも試してください。
Kirb

1
「最初に、私はあなたが<head>(の終わりではなく<body>)ドキュメントのにスクリプトが配置されているという前提の下で動作していることに注意することが重要です。」冒頭のように、回答の早い段階でその点を強調しおきます。外部ファイルを参照するscriptin headを含めることは、ほとんどどのような観点からも(確かにパフォーマンスの観点からは)正確ではありません。実生活でそれをしなければならなかったことを思い出しません。インラインスクリプトの奇数行または2行かもしれませんが、それだけです。デフォルトでは、なしで非常に良い反対の理由、本体の端でなければなりません。
TJクラウダー2018

1
反対投票されたjQueryはJavaScriptではなく、ページをさらに膨らませるだけなので、それを使用した結果は客観的ではありません。
ジョン

303

CSSをJavaScriptの前に置く主な理由は2つあります。

  1. 古いブラウザ(Internet Explorer 6-7、Firefox 2など)では、スクリプトのダウンロードを開始すると、以降のすべてのダウンロードがブロックされていました。したがって、それらがa.js続いてb.cssいる場合、それらは順番にダウンロードされます:最初にa、次にb。あなたがb.css続いてa.jsいる場合、それらは並行してダウンロードされ、ページがより速くロードされます。

  2. すべてのスタイルシートがダウンロードされるまで何もレンダリングされません-これはすべてのブラウザーに当てはまります。スクリプトは異なります-スクリプトは、ページのスクリプトタグの下にあるすべてのDOM要素のレンダリングをブロックします。スクリプトをHEADに配置すると、すべてのスタイルシートとすべてのスクリプトがダウンロードされるまで、ページ全体のレンダリングがブロックされます。スタイルシートのすべてのレンダリングをブロックすることは理にかなっています(そのため、最初に正しいスタイルを取得し、スタイルのないコンテンツFOUCのフラッシュを回避します)、スクリプトのページ全体のレンダリングをブロックすることは意味がありません。多くの場合、スクリプトはDOM要素またはDOM要素の一部にのみ影響します。ページ内のできるだけ低い場所にスクリプトをロードするか、非同期でスクリプトをロードすることをお勧めします。

Cuzillionで例を作成するのは楽しいです。たとえば、このページのHEADにはスクリプトが含まれているため、ダウンロードが完了するまでページ全体が空白になります。ただし、スクリプトをBODYブロックの最後に移動すると、これらのDOM要素がSCRIPTタグの上にあるため、ページヘッダーがレンダリングされますこのページをご覧ください


10
受賞スティーブは答えに私を打つが、私は彼が言及するものに関連する記事を追加します:stevesouders.com/blog/2009/04/27/...
ファン・パブロ・Buritica

4
どのブラウザがasync属性をサポートするかを確認してください。スティーブが「非同期でさらに読み込む」と言ったときにここでお勧めします-stackoverflow.com/questions/1834077/…–
Jeff Atwood

CSSファイルを@importディレクティブにリンクする理由を教えていただけませんか。
Josh Stodola、2012

6
2)のソースは何ですか?それが真実である場合、ページがコンテンツのロードを終了することがあり、CSSが1、2秒後に適用される理由を説明できますか?(これはまれに、CSSが<head>タグにある自分のページで発生しました)
Izkata

2
それで、ページの最後にjQuery+ jQuery UI+ $(document).ready(function () { });を置くべきですか?それはウィル常に期待通りに動作しますか?
Olivier Pons

42

私はあなたが得た結果をあまり強調しませんが、それは主観的であると信じていますが、jsの前にCSSを入れる方が良いことを説明する理由があります。

Webサイトのロード中に、次の2つのシナリオが表示されます。

ケース1:白い画面>スタイルのないウェブサイト>スタイルのあるウェブサイト>インタラクション>スタイルのあるインタラクティブなウェブサイト

ケース2:白い画面>スタイルのないウェブサイト>インタラクション>スタイルのあるウェブサイト>スタイルのあるインタラクティブなウェブサイト


ケース2を選択する人は誰も想像できない。低速のインターネット接続を使用している訪問者は、スタイルが設定されていないWebサイトに直面し、JavaScriptを使用してそれを操作できるようになります(すでにロードされているため)。さらに、スタイルのないWebサイトの閲覧に費やす時間は、この方法で最大化されます。なぜ誰もがそれを望みますか?

jQueryの状態としてもうまく機能します

「CSSスタイルプロパティの値に依存するスクリプトを使用する場合、スクリプトを参照する前に、外部スタイルシートを参照するか、スタイル要素を埋め込むことが重要です。」

ファイルが間違った順序で読み込まれると(最初にJS、次にCSS)、CSSファイルで設定されたプロパティ(divの幅や高さなど)に依存するJavascriptコードが正しく読み込まれません。読み込み順序が間違っていると、正しいプロパティがJavascriptに「ときどき」認識されるようです(おそらく、これは競合状態が原因ですか?)。この効果は、使用するブラウザに応じて大きくなったり小さくなったりします。


2
JavaScriptが実行される前にすべてのCSSがロードされていることをどのように保証しますか?あなたはできる?または、JavaScriptが十分に堅牢で、スタイルが必ずしもロードされない場合がある状況に対処する必要があります。
ジョニオ

@Jonnio JSに依存関係がある場合は、その依存関係を明示的にする必要があります。そうしないと、常にまれなタイミングの問題が発生します。ES6モジュールはそれを実現する良い方法ですが、同様に使用できる多くのライブラリがあります。
kmkemp

26

テストは、パーソナルコンピュータまたはWebサーバーで実行されましたか?空白のページですか、それとも画像やデータベースなどを備えた複雑なオンラインシステムですか?スクリプトは単純なホバーイベントアクションを実行していますか、それともWebサイトがどのようにレンダリングされ、ユーザーと対話するためのコアコンポーネントですか?ここで考慮すべき点がいくつかあり、これらの推奨事項の関連性は、ほとんどの場合、高品質のWeb開発に取り組むときにルールになります。

ルール「下部にトップとスクリプトに入れたスタイルシート」の目的は、それは、一般的には、それが最適な達成するための最善の方法だあるプログレッシブレンダリングユーザーエクスペリエンスに重要です。

それ以外はすべて、テストが有効であり、一般的なルールに反する結果を実際に生成していると想定すると、それは当然のことです。すべてのWebサイト(およびすべてをユーザーの画面に表示するために必要なすべてのもの)は異なり、インターネットは常に進化しています。


1
あなたが太字で書いている点に感謝しますが、OPは、両方を上にして、両方を下にしないで順序を変えるとどうなるかについて話しています。
nnnnnn

1
したがって、「[彼の]テストが有効であると仮定します。」
skippr

21

別の理由でJavaScriptの前にCSSファイルを含めています。

JavaScriptがいくつかのページ要素の動的サイズ変更を行う必要がある場合(CSSが実際にメインであるこれらのコーナーの場合)、JSが実行された後にCSSをロードすると、要素がCSSスタイルの前にサイズ変更される競合状態が発生する可能性がありますCSSを事前にロードしておけば、意図した順序で実行され、最終的なレイアウトが希望どおりになることが保証されます。


2
これはあるブラウザでいつか壊れるでしょう。私は推測していません。
jcolebrand

1
jcolebrand:はい、これを書いたとき、私は十分なコーヒーを飲んでいなかったと思います。(振り返ってみると、重要なことは、CSSの動的なロードを回避し、動的なサイズ変更を行う必要がある場合は、JSをdomReadyイベント内に配置することだけです)
hugomg

スクリプトで表示を変更しないでください。それがCSSの仕事です。HTML =コンテンツ、CSS =コンテンツの表示方法、JavaScriptはコンテンツを動的に変更します。また、jsは、DOMContentLoadedが起動された後(またはしばらくの間)にのみ動作する必要があります。
brunoais 2012

@brunoais:ただし、一部のレイアウトはJavaScriptでしか作成できません。たとえば、動的にサイズを変更する必要があるものはすべてJavascriptを介して作成する必要があり、一部のこと(サイズが100%から20pxになるなど)は、古いブラウザで移植可能にJavaScriptを実行する必要があります。
hugomg

@missingnoこれらの場合、とにかくDOMContentLoadedイベントを使用します。しかし、私はあなたの意味を理解しています。(愚かなIE!)
brunoais

10

JavaScriptの前にCSSを含めることの推奨は無効ですか?

それを単に推奨事項として扱うのではありません。しかし、あなたがそれを厳格な規則として扱うなら、はい、それは無効です。

https://developer.mozilla.org/en-US/docs/Web/Reference/Events/DOMContentLoadedから

スタイルシートはブロックスクリプトの実行をロードするため、<script> 後の場合<link rel="stylesheet" ...>、ページは解析を完了せず、DOMContentLoadedはスタイルシートがロードされるまで起動しません。

各スクリプトが何に依存しているかを把握し、スクリプトの実行が正しい完了イベントの後まで遅れることを確認する必要があるようです。スクリプトがDOMのみに依存している場合は、ondomready / domcontentloadedで再開できます。ロードする画像または適用するスタイルシートに依存している場合は、上記の参照を正しく読んだ場合、onloadイベントまでコードを延期する必要があります。

靴下のサイズ1つですべてが収まるとは思いませんが、靴のサイズ1つですべてが収まるわけではないことはわかっています。スタイルやスクリプトを最初にロードする決定的な答えはないと思います。これは、何をどの順序でロードする必要があるか、何が「クリティカルパス」にないとして後で延期できるかというケースバイケースの決定です。

シートがきれいになるまで、ユーザーが対話する能力を遅らせる方が良いとコメントしたオブザーバーに話しかける。世の中にはたくさんの人がいて、反対を感じている相手を困らせています。彼らは目的を達成するためにサイトにやって来て、読み込みの完了に関係のないことを待っている間にサイトと対話する能力が遅れることは非常にイライラします。私はあなたが間違っていると言っているのではなく、あなたの優先順位を共有していない別の派閥が存在していることを知っている必要があるだけです。

この質問は、Webサイトに掲載されるすべての広告に特に当てはまります。サイトの作成者が広告コンテンツのプレースホルダーdivのみをレンダリングし、onloadイベントに広告を挿入する前にサイトが読み込まれ、インタラクティブであることを確認した場合、私はそれを気に入っています。それでも、膨らんだ広告の読み込み中にサイトのコンテンツをスクロールする機能にも影響を与えるため、一度にすべてではなく連続して読み込まれる広告を見たいと思います。しかし、それは一人の視点に過ぎません。

  • ユーザーとその価値を理解します。
  • ユーザーと、ユーザーが使用しているブラウジング環境を把握します。
  • 各ファイルの機能とその前提条件を理解します。すべてを機能させることは、速度と美しさの両方よりも優先されます。
  • 開発時にネットワークのタイムラインを示すツールを使用します。
  • ユーザーが使用する各環境でテストします。ユーザー環境に基づいて、動的に(ページを作成するときにサーバー側で)ロードの順序を変更する必要がある場合があります。
  • 疑問がある場合は、順序を変更して再度測定します。
  • ロード順序でスタイルとスクリプトを混在させることが最適になる可能性があります。すべてではなく、他のすべてではありません。
  • ファイルをロードする順序だけでなく、場所も試してください。頭?体に?体の後?DOM Ready / Loaded?読み込まれましたか?
  • ページを操作する前にユーザーが経験する最終的な遅延を減らすために、適切な場合は非同期オプションと遅延オプションを検討してください。彼らが助けたり傷つけたりするかどうかを決定するためにテストします。
  • 最適なロード順序を評価する際には、常に考慮すべきトレードオフがあります。Pretty vs. Responsiveは1つだけです。

1
リンクされた記事は、「スタイルシートがブロックスクリプトの実行をロードする」とはもはや主張していません。それはもう本当ですか?
グレッグ

@グレッグ-それはまだ本当です。スクリプトはDOM .style属性をクエリできる必要があるため、スタイルシートは依然としてスクリプトの実行をブロックします。彼らは可能性があるスクリプトブロックではないロードを、彼らは賢いしている場合、彼らはscript.onLoadイベントをブロックします。
Jimmy Breck-McKye 2017年

10

2017年12月16日更新

OPでのテストについてはわかりませんでした。私は少し実験することに決めて、いくつかの神話を破りました。

同期<script src...>は、ダウンロードされて実行されるまで、その下のリソースのダウンロードをブロックします

これはもはや本当ではありません。Chrome 63によって生成された滝をご覧ください。

<head>
<script src="//alias-0.redacted.com/payload.php?type=js&amp;delay=333&amp;rand=1"></script>
<script src="//alias-1.redacted.com/payload.php?type=js&amp;delay=333&amp;rand=2"></script>
<script src="//alias-2.redacted.com/payload.php?type=js&amp;delay=333&amp;rand=3"></script>
</head>

Chromeネットインスペクタ->ウォーターフォール

<link rel=stylesheet> その下のスクリプトのダウンロードと実行をブロックしません

これは誤りです。スタイルシートは、ダウンロードをブロックしませんが、それはします(スクリプトの実行ブロックし、ここで少し説明を)。Chrome 63によって生成されたパフォーマンスチャートをご覧ください。

<link href="//alias-0.redacted.com/payload.php?type=css&amp;delay=666" rel="stylesheet">
<script src="//alias-1.redacted.com/payload.php?type=js&amp;delay=333&amp;block=1000"></script>

Chrome開発ツール->パフォーマンス


上記を念頭に置いて、OPの結果は次のように説明できます。

CSSファースト:

CSS Download  500ms:<------------------------------------------------>
JS Download   400ms:<-------------------------------------->
JS Execution 1000ms:                                                  <-------------------------------------------------------------------------------------------------->
DOM Ready   @1500ms:                                                                                                                                                      

JSファースト:

JS Download   400ms:<-------------------------------------->
CSS Download  500ms:<------------------------------------------------>
JS Execution 1000ms:                                        <-------------------------------------------------------------------------------------------------->
DOM Ready   @1400ms:                                                                                                                                            

また、それがdocument.write()がHTMLDOMに対してこれまでに作成された中で最悪のアイデアの1つである理由でもあります。
brunoais

1
The reason is that the script may want to get coordinates and other style-dependent properties of elements, like in the example above. Naturally, it has to wait for styles to load. javascript.info/…JSの場合、最初に同じ仮定が適用されないのはなぜですか?私にはあまり意味がありません。実行されたJSの順序は、その目的について何も伝えていません。
ThorstenSchöning2018

4

私はあなたのテストがあなたのJavaスクリプトをどのように「レンダリング」するのか正確にわかりません。しかしこれを考慮

サイトの1ページは50kであり、不当ではありません。サーバーが西側にある間、ユーザーは東海岸にいます。MTUは間違いなく10kではないので、往復が数回あります。ページとスタイルシートを受け取るまでに、1/2秒かかる場合があります。通常(私にとって)JavaScriptは(jqueryプラグインなどを介して)CSSをはるかに超えています。あなたのインターネット接続がページの途中で途切れたが、それを無視させたときにも何が起こるかもあります(たまに起こり、CSSがレンダリングすると思いますが、100%確実ではありません)。

CSSが先頭にあるため、それを取得するための追加の接続が存在する可能性があります。つまり、ページが完了する前に終了する可能性があります。とにかく、タイプの間、ページの残りの部分が使用され、JavaScriptファイル(より多くのバイト)はページのスタイルが解除されるため、サイト/接続が遅く見えるようになります。

JSインタープリターがCSSが完了するまで開始を拒否した場合でも、特にサーバーから遠く離れている場合にJavaScriptのコードをダウンロードするのにかかる時間がサイトの見栄えを悪くします。

小さな最適化ですが、それが理由です。


1
サーバーは東海岸にあります。また、彼らがCDNを使用するようになったことにも気づいていないようです。
jcolebrand

3

ここに概要があります以上(または多分以下以降のすべての主要な回答が:)

最新のブラウザでは、cssを好きな場所に配置します。彼らはあなたのhtmlファイルを分析します(これは投機的解析と呼ばれます))をし、html解析と並行してcssのダウンロードを開始します。

古いブラウザの場合、CSSを最上位に置き続けます(最初にネイキッドでインタラクティブなページを表示したくない場合)。

すべてのブラウザで、HTMLの解析が停止するため、JavaScriptをページのできるだけ下に配置します。非同期でダウンロードする(つまり、ajax呼び出し)

また、(CSSを最初に置くという従来の知識とは対照的に)javascriptを最初に置くと主張する特定のケースのいくつかの実験結果は、より良いパフォーマンスを提供しますが、論理的な理由はなく、広範な適用性に関する検証が不足しているため、今は無視してください。

だから、質問に答えるために:はい。JSが最新のブラウザーでは無効になる前にCSSを組み込むことをお勧めします。CSSを好きな場所に配置し、JSをできるだけ最後に配置します。


1

スティーブ・スーダーズはすでに決定的な答えを出していますが...

サムの元のテストとジョシュのそれの繰り返しの両方に問題があるのだろうか。

どちらのテストも、TCP接続のセットアップにわずかなコストがかかる低遅延接続で実行されたようです。

これがテストの結果にどのように影響するかはわかりません。「通常の」レイテンシ接続を介したテストのウォーターフォールを確認したいのですが...

最初にダウンロードされたファイルはhtmlページに使用された接続取得し、2番目にダウンロードされたファイルは新しい接続を取得します。(初期のフラッシュは動的を変更しますが、ここでは行われません)

新しいブラウザーでは、2番目のTCP接続が投機的に開かれるため、接続オーバーヘッドが削減または解消されます。古いブラウザーでは、これは当てはまりません。2番目の接続では、オーバーヘッドが開かれます。

これがテストの結果にどのように/どのように影響するかはわかりません。


フォローしないでください、信じられないほどまれなパイプライン処理がない限り、接続設定を減らす可能性はほとんどありません...低遅延でテストを繰り返す必要があることに同意してください
Sam Saffron

あなたはこの滝を見れば、あなたはそれが必要なの前にクロムが投機的に2番目の接続を開く場所を確認することができますwebpagetest.org/result/...は(IE9は、同じことを)...私はむしろ低いよりTCPのために、通常の遅延を考えていた-どのようテストはどの環境で行われましたか?
アンディデイヴィス

2
Re: "Steve Soudersはすでに決定的な答えを出していますが..." Webの進化の問題は、決定的な答えがないということです。:)スクリプトをロードする方法は3つから4つあります。スティーブは、「同期のJavaScriptの前に入れCSS」言うの実際の正しいセマンティックが実際に...それ以外の人々は、それはすべてのスクリプトのルールとして一般化することによって、間違ったそれを取得されている必要があります
hexalys

はい、しかしほとんどの人はスクリプトを同期的にインクルードするだけなので、スティーブのアドバイスは初心者には良いです。
Andy Davies

1

これはすべての場合に当てはまるとは思いません。cssは並行してダウンロードしますが、jsはできません。同じケースを考えて、

単一のCSSを持つ代わりに、2つまたは3つのCSSファイルを取り、これらの方法を試してください、

1)css..css..js 2)css..js..css 3)js..css..css

私はcss..css..jsが他のすべてのものより良い結果を与えると確信しています。


0

新しいブラウザはJavascriptエンジンやパーサーなどで動作し、一般的なコードとマークアップの問題を最適化し、<= IE8などの古代のブラウザで発生した問題が、マークアップに関してだけでなく、JavaScript変数、要素セレクターの使用についても同様です。それほど遠くない将来、テクノロジーがもはやパフォーマンスにそれほど問題にならない状態に達した状況を見ることができます。


パフォーマンスは常に問題です。仕様に従わないブラウザが存在することはほとんど無視します。仕様に従うコードが全速力で機能するようにコードを準備し、その他のコードはそれが機能するように実行します。したがって、たとえば、IE8でのみ機能する場合は、すべて問題ありません。
brunoais

-5

個人的には、そのような「民俗の知恵」をあまり重視しません。昔は真実だったかもしれないが、今は真実ではないかもしれない。Webページの解釈とレンダリングに関連するすべての操作は完全に非同期であると想定します(「フェッチ」と「アクション」は2つのまったく異なるものであり、異なるスレッドで処理される可能性があります)いずれにしても、完全にあなたの制御または懸念を超えています。

私は、CSS参照を、外部スクリプトへの参照と一緒に、文書の「ヘッド」部分に配置します。(一部のスクリプトは本文に配置するように要求する場合があり、そうする場合はそれらを義務付けます。)

それを超えて...「これは、この/そのブラウザでは、それよりも速い/遅いようです」と気づいた場合、この観察を興味深いが無関係な好奇心として扱い、設計の決定に影響を与えないようにします。あまりにも多くのものが変化が速すぎます。 (誰もがどのように多くの上の任意の賭け敷設したいん Firefoxチームは、彼らの製品のさらに別の暫定リリースに出てくる前になりますが?うん、私どちらも。)

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.