Pertanyaan Apakah rekomendasi untuk menyertakan CSS sebelum JavaScript tidak valid?


Di banyak tempat online, saya telah melihat rekomendasi untuk memasukkan CSS sebelum JavaScript. Alasannya umumnya, dari formulir ini:

Ketika datang untuk memesan CSS dan JavaScript, Anda menginginkan CSS Anda   untuk datang lebih dulu. Alasannya adalah bahwa render thread memiliki semua   informasi gaya yang dibutuhkan untuk merender laman. Jika JavaScript   termasuk datang pertama, mesin JavaScript harus menguraikan semuanya sebelumnya   melanjutkan ke rangkaian sumber daya berikutnya. Ini berarti render   utas tidak dapat benar-benar menampilkan halaman, karena tidak memiliki semua   gaya yang dibutuhkan.

Pengujian saya yang sebenarnya mengungkapkan sesuatu yang sangat berbeda:

Alat uji saya

Saya menggunakan skrip Ruby berikut untuk menghasilkan penundaan tertentu untuk berbagai sumber daya:

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..."
}

Server mini di atas memungkinkan saya untuk menetapkan penundaan acak untuk file JavaScript (baik server dan klien) dan penundaan CSS acak. Sebagai contoh, http://10.0.0.50:8081/test.css?delay=500 memberi saya penundaan 500 ms mentransfer CSS.

Saya menggunakan halaman berikut untuk menguji.

<!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>

Saat saya memasukkan CSS lebih dulu, halaman membutuhkan 1,5 detik untuk dirender:

CSS first

Saat saya memasukkan JavaScript terlebih dahulu, halaman membutuhkan waktu 1,4 detik untuk dirender:

JavaScript first

Saya mendapatkan hasil serupa di Chrome, Firefox, dan Internet Explorer. Namun di Opera, pemesanan itu tidak masalah.

Apa yang tampaknya terjadi adalah interpreter JavaScript menolak untuk memulai hingga semua CSS diunduh. Jadi, sepertinya JavaScript memiliki yang pertama lebih efisien karena thread JavaScript lebih banyak dijalankan.

Apakah saya kehilangan sesuatu, apakah rekomendasi untuk menempatkan CSS termasuk sebelum JavaScript termasuk tidak benar?

Jelas bahwa kita dapat menambahkan async atau menggunakan setTimeout untuk membebaskan render thread atau menempatkan kode JavaScript di footer, atau menggunakan pemuat JavaScript. Intinya di sini adalah tentang pemesanan bit JavaScript penting dan bit CSS di kepala.


827
2018-02-14 03:24


asal


Jawaban:


Ini pertanyaan yang sangat menarik. Saya selalu menaruh CSS saya <link href="...">s sebelum JS saya <script src="...">karena "Saya membaca satu kali bahwa itu lebih baik." Jadi, Anda benar; Sudah saatnya kita melakukan penelitian yang sebenarnya!

Saya mengatur harness pengujian saya sendiri di Node (kode di bawah). Pada dasarnya, saya:

  • Pastikan tidak ada cache HTTP sehingga peramban harus melakukan unduhan penuh setiap kali halaman dimuat.
  • Untuk mensimulasikan realitas, saya menyertakan jQuery dan H5BP CSS (jadi ada jumlah script / CSS yang layak untuk mengurai)
  • Siapkan dua halaman - satu dengan CSS sebelum skrip, satu dengan CSS setelah skrip.
  • Direkam berapa lama untuk skrip eksternal di <head> untuk mengeksekusi
  • Direkam berapa lama untuk skrip sebaris di <body> untuk melaksanakan, yang analog dengan DOMReady.
  • Tertunda mengirim CSS dan / atau skrip ke browser sebesar 500ms.
  • Lakukan tes 20 kali di 3 browser utama.

Hasil

Pertama, dengan file CSS tertunda 500ms:

     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

Selanjutnya, saya menetapkan jQuery untuk menunda hingga 500ms daripada CSS:

     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

Akhirnya, saya mengatur kedua jQuery dan CSS untuk menunda hingga 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

Kesimpulan

Pertama, penting untuk dicatat bahwa saya beroperasi di bawah asumsi bahwa Anda memiliki skrip yang terletak di <head> dokumen Anda (sebagai lawan dari akhir <body>). Ada berbagai argumen mengenai mengapa Anda mungkin menautkan ke skrip Anda di <head> versus akhir dokumen, tetapi itu di luar lingkup jawaban ini. Ini benar-benar tentang apakah itu <script>s harus pergi sebelumnya <link>di dalam <head>.

Di browser DESKTOP modern, sepertinya menautkan ke CSS terlebih dahulu tak pernah memberikan peningkatan kinerja. Menempatkan CSS setelah skrip memberi Anda jumlah keuntungan yang kecil ketika CSS dan skrip ditunda, tetapi memberi Anda keuntungan besar ketika CSS tertunda. (Ditampilkan oleh last kolom di set pertama hasil.)

Mengingat bahwa menghubungkan ke CSS terakhir tampaknya tidak merusak kinerja tetapi bisa memberikan keuntungan dalam keadaan tertentu, Anda harus menautkan ke stylesheet eksternal setelah Anda menautkan ke skrip eksternal hanya di browser desktop jika kinerja browser lama tidak menjadi perhatian. Baca terus untuk situasi seluler.

Mengapa?

Secara historis, saat browser menemukan <script> tag yang menunjuk ke sumber daya eksternal, browser akan berhenti menguraikan HTML, mengambil skrip, menjalankannya, lalu melanjutkan penguraian HTML. Sebaliknya, jika browser menemui a <link> untuk stylesheet eksternal, itu akan terus menguraikan HTML saat mengambil file CSS (secara paralel).

Oleh karena itu, saran yang banyak diulang untuk menempatkan stylesheet terlebih dahulu - mereka akan mengunduh terlebih dahulu, dan skrip pertama untuk mengunduh dapat dimuat secara paralel.

Namun, peramban modern (termasuk semua peramban yang saya uji di atas) telah diterapkan spekulatif parsing, di mana browser "melihat ke depan" dalam HTML dan mulai mengunduh sumber daya sebelum skrip unduh dan eksekusi.

Di browser lama tanpa parsing spekulatif, menempatkan skrip terlebih dahulu akan mempengaruhi kinerja karena tidak akan diunduh secara paralel.

Dukungan Browser

Penguraian spekulatif pertama kali diterapkan di: (bersama dengan persentase pengguna browser desktop di seluruh dunia yang menggunakan versi ini atau lebih besar pada Januari 2012)

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

Secara total, sekitar 85% dari browser desktop yang digunakan saat ini mendukung pemuatan spekulatif. Menempatkan skrip sebelum CSS akan memiliki penalti kinerja pada 15% pengguna secara global; YMMV berdasarkan audiens spesifik situs Anda. (Dan ingat jumlah itu menyusut.)

Pada peramban seluler, sedikit lebih sulit untuk mendapatkan angka yang pasti hanya karena betapa heterogennya peramban seluler dan lanskap OS. Sejak rendering spekulatif diimplementasikan di WebKit 525 (dirilis pada Maret 2008), dan hampir setiap browser seluler yang bermanfaat didasarkan pada WebKit, kita dapat menyimpulkan bahwa "sebagian besar" peramban seluler harus dukung itu. Menurut quirksmode, iOS 2.2 / Android 1.0 menggunakan WebKit 525. Saya tidak tahu seperti apa Windows Phone itu.

Namun, Saya menjalankan pengujian pada perangkat Android 4 saya, dan ketika saya melihat angka yang mirip dengan hasil desktop, saya menghubungkannya dengan yang baru dan fantastis. debugger jarak jauh di Chrome untuk Android, dan tab Jaringan menunjukkan bahwa browser benar-benar menunggu untuk mengunduh CSS hingga JavaScript sepenuhnya dimuat - dengan kata lain, bahkan versi terbaru WebKit untuk Android tampaknya tidak mendukung parsing spekulatif.  Saya menduga itu mungkin dimatikan karena CPU, memori, dan / atau kendala jaringan yang melekat pada perangkat seluler.

Kode

Maafkan kecerobohan - ini adalah 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 adalah jquery-1.7.1.min.js


671
2018-02-14 06:37



Ada dua alasan utama untuk meletakkan CSS sebelum JavaScript.

  1. Browser lama (Internet Explorer 6-7, Firefox 2, dll.) Akan memblokir semua unduhan berikutnya ketika mereka mulai mengunduh skrip. Jadi, jika Anda punya a.js diikuti oleh b.css mereka diunduh secara berurutan: pertama a lalu b. Jika Anda memiliki b.css diikuti oleh a.js mereka diunduh secara paralel sehingga laman memuat lebih cepat.

  2. Tidak ada yang dirender sampai semua stylesheet diunduh - ini berlaku di semua browser. Skrip berbeda - mereka memblokir perenderan semua elemen DOM yang ada di bawah tag skrip di halaman. Jika Anda meletakkan skrip Anda di HEAD maka itu berarti seluruh halaman diblokir dari render sampai semua stylesheet dan semua skrip diunduh. Meskipun masuk akal untuk memblokir semua render untuk stylesheet (sehingga Anda mendapatkan gaya yang benar saat pertama kali dan menghindari flash konten yang tidak dipermasalahkan FOUC), tidak masuk akal untuk memblokir render seluruh halaman untuk skrip. Seringkali skrip tidak memengaruhi elemen DOM atau hanya sebagian dari elemen DOM. Lebih baik memuat skrip serendah mungkin di laman, atau bahkan memuatnya dengan lebih baik secara asinkron.

Sangat menyenangkan untuk membuat contoh dengan Cuzillion. Sebagai contoh, halaman ini memiliki skrip di HEAD sehingga seluruh halaman kosong hingga selesai diunduh. Namun, jika kita memindahkan skrip ke akhir BODY, blokkan header halaman karena elemen DOM tersebut muncul di atas tag SCRIPT, seperti yang dapat Anda lihat di halaman ini.


293
2018-02-14 06:27



Saya tidak akan terlalu menekankan pada hasil yang Anda dapatkan, saya percaya bahwa itu subyektif, tetapi saya memiliki alasan untuk menjelaskan kepada Anda bahwa lebih baik untuk memasukkan CSS sebelum js.

Selama pemuatan situs web Anda, ada dua skenario yang akan Anda lihat:

KASUS 1: layar putih> situs web tanpa cela> situs web bergambar> interaksi> situs web bergaya dan interaktif

KASUS 2: layar putih> situs web tidak terganggu> interaksi> situs web bergaya> situs web bergaya dan interaktif


Sejujurnya saya tidak dapat membayangkan siapa pun yang memilih Kasus 2. Ini berarti bahwa pengunjung yang menggunakan koneksi internet lambat akan dihadapkan dengan situs web yang tidak ditata, yang memungkinkan mereka untuk berinteraksi dengannya menggunakan Javascript (karena itu sudah dimuat). Selanjutnya, jumlah waktu yang dihabiskan untuk mencari situs web yang tidak ditata akan dimaksimalkan dengan cara ini. Kenapa ada yang mau itu?

Ini juga berfungsi lebih baik sebagai jQuery menyatakan 

"Saat menggunakan skrip yang bergantung pada nilai properti gaya CSS,   penting untuk mereferensikan stylesheet eksternal atau gaya penyematan   elemen sebelum referensi skrip ".

Ketika file dimuat dalam urutan yang salah (JS pertama, lalu CSS), kode Javascript yang bergantung pada properti yang diatur dalam file CSS (misalnya lebar atau tinggi dari div) tidak akan dimuat dengan benar. Tampaknya dengan urutan pemuatan yang salah, properti yang benar adalah 'kadang-kadang' dikenal dengan Javascript (mungkin ini disebabkan oleh kondisi balapan?). Efek ini tampak lebih besar atau lebih kecil tergantung pada browser yang digunakan.


40
2018-02-14 07:55



Apakah tes Anda dilakukan di komputer pribadi Anda, atau di server web? Ini adalah halaman kosong, atau apakah itu sistem online yang kompleks dengan gambar, database, dll? Apakah skrip Anda melakukan tindakan peristiwa sederhana yang melayang-layang, atau apakah itu komponen inti untuk bagaimana situs web Anda merender dan berinteraksi dengan pengguna? Ada beberapa hal yang perlu dipertimbangkan di sini, dan relevansi rekomendasi ini hampir selalu menjadi aturan ketika Anda menjelajah ke pengembangan web berkaliber tinggi.

Tujuan dari aturan "pasang stylesheet di bagian atas dan skrip di bagian bawah" adalah bahwa, secara umum, ini adalah cara terbaik untuk mencapai optimal render progresif, yang sangat penting bagi pengalaman pengguna.

Selain itu: mengasumsikan tes Anda valid, dan Anda benar-benar menghasilkan hasil yang bertentangan dengan aturan populer, itu tidak mengherankan, sungguh. Setiap situs web (dan semua yang diperlukan untuk membuat semuanya muncul di layar pengguna) berbeda dan Internet terus berkembang.


25
2018-02-14 13:31



Saya menyertakan file CSS sebelum Javascript karena alasan yang berbeda.

Jika Javascript saya perlu melakukan ukuran dinamis dari beberapa elemen halaman (untuk kasus-kasus sudut di mana CSS benar-benar utama di belakang) kemudian memuat CSS setelah JS russing dapat menyebabkan kondisi balapan, di mana elemen diubah ukurannya sebelum gaya CSS diterapkan dan dengan demikian terlihat aneh ketika gaya akhirnya menendang. Jika saya memuat CSS sebelumnya saya dapat menjamin bahwa hal-hal berjalan dalam urutan yang dimaksudkan dan bahwa tata letak akhir adalah apa yang saya inginkan.


21
2018-05-25 20:00



Apakah rekomendasi untuk menyertakan CSS sebelum JavaScript tidak valid?

Tidak jika Anda memperlakukannya hanya sebagai rekomendasi. Tetapi jika Anda memperlakukannya sebagai aturan yang keras dan cepat ?, ya, itu tidak valid.

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

Stylesheet memuat skrip eksekusi skrip, jadi jika Anda memiliki <script>   setelah <link rel="stylesheet" ...> halaman tidak akan selesai melakukan parsing   - dan DOMContentLoaded tidak akan menyala - hingga stylesheet dimuat.

Tampaknya Anda perlu tahu apa yang setiap skrip bergantung dan memastikan bahwa eksekusi skrip ditunda hingga setelah acara penyelesaian yang tepat. Jika skrip hanya bergantung pada DOM, itu dapat dilanjutkan di ondomready / domcontentloaded, jika itu bergantung pada gambar yang akan dimuat atau stylesheet yang akan diterapkan, maka jika saya membaca referensi di atas dengan benar, kode itu harus ditunda sampai acara onload.

Saya tidak berpikir bahwa satu ukuran kaus kaki cocok untuk semua, meskipun itulah cara mereka dijual dan saya tahu bahwa satu ukuran sepatu tidak cocok untuk semua. Saya tidak berpikir bahwa ada jawaban pasti untuk memuat pertama, gaya atau skrip. Ini lebih merupakan kasus per kasus keputusan apa yang harus dimuat dalam urutan apa dan apa yang dapat ditunda sampai nanti karena tidak berada di "jalur kritis".

Untuk berbicara dengan pengamat yang berkomentar bahwa lebih baik untuk menunda kemampuan pengguna untuk berinteraksi sampai lembarannya cantik. Ada banyak dari Anda di luar sana dan Anda mengganggu rekan-rekan Anda yang merasakan sebaliknya. Mereka datang ke sebuah situs untuk mencapai tujuan dan penundaan kemampuan mereka untuk berinteraksi dengan situs sambil menunggu hal-hal yang tidak penting untuk menyelesaikan pemuatan sangat membuat frustasi. Saya tidak mengatakan bahwa Anda salah, hanya saja Anda harus sadar bahwa ada faksi lain yang ada yang tidak berbagi prioritas Anda.

Pertanyaan ini terutama berlaku untuk semua iklan yang ditempatkan di situs web. Saya akan senang jika penulis situs hanya memberikan placeholder div untuk konten iklan dan memastikan bahwa situs mereka dimuat dan interaktif sebelum menyuntikkan iklan dalam acara onload. Bahkan kemudian saya ingin melihat iklan yang dimuat secara serial bukan sekaligus karena mereka memengaruhi kemampuan saya untuk bahkan menggulir konten situs saat iklan yang membengkak sedang dimuat. Tapi itu hanya satu sudut pandang orang.

  • Ketahui pengguna Anda dan apa yang mereka hargai.
  • Ketahui pengguna Anda dan lingkungan penelusuran apa yang mereka gunakan.
  • Ketahuilah apa yang setiap file lakukan, dan apa pra-syaratnya. Membuat semuanya bekerja akan lebih diutamakan daripada kecepatan dan cantik.
  • Gunakan alat yang menunjukkan kepada Anda garis waktu jaringan ketika berkembang.
  • Uji di setiap lingkungan yang digunakan pengguna Anda. Ini mungkin diperlukan untuk secara dinamis (sisi server, saat membuat halaman) mengubah urutan pemuatan berdasarkan lingkungan pengguna.
  • Jika ragu, ubah urutan dan ukur lagi.
  • Ada kemungkinan bahwa gaya dan skrip antarmasing dalam urutan pembebanan akan optimal; tidak semuanya satu dari yang lain.
  • Eksperimen bukan hanya apa untuk memuat file tetapi di mana. Kepala? In Body? Setelah Tubuh? DOM Ready / Loaded? Sarat?
  • Pertimbangkan async dan tangguhkan opsi bila sesuai untuk mengurangi penundaan bersih yang akan dialami pengguna sebelum dapat berinteraksi dengan halaman. Uji untuk menentukan apakah mereka membantu atau melukai.
  • Selalu ada trade off yang perlu dipertimbangkan ketika mengevaluasi urutan pemuatan yang optimal. Cukup vs Responsif hanya menjadi satu.

10
2018-04-27 12:16



Diperbarui 2017-12-16

Saya tidak yakin tentang tes di OP. Saya memutuskan untuk bereksperimen sedikit dan akhirnya menghancurkan beberapa mitos.

Sinkronis <script src...> akan memblokir pengunduhan sumber daya   di bawahnya sampai diunduh dan dijalankan

Ini tidak lagi benar. Lihatlah air terjun yang dihasilkan oleh 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 net inspector -> waterfall

<link rel=stylesheet> tidak akan memblokir unduhan dan eksekusi   skrip di bawahnya

Ini tidak benar. Stylesheet tidak akan memblokir unduhan tetapi akan blokir eksekusi skrip (sedikit penjelasan di sini). Lihatlah grafik kinerja yang dibuat oleh 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 dev tools -> performance


Menjaga di atas dalam pikiran, hasil dalam OP dapat dijelaskan sebagai berikut:

CSS Pertama:

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

JS Pertama:

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

6
2018-02-14 22:33



Saya tidak tahu pasti bagaimana waktu pengujian Anda 'render' saat Anda menggunakan skrip java. Namun pertimbangkan ini

Satu halaman di situs Anda adalah 50k yang tidak masuk akal. Pengguna berada di pantai timur sementara server Anda berada di barat. MTU pasti bukan 10k jadi akan ada beberapa perjalanan bolak-balik. Mungkin butuh waktu 1/2 detik untuk menerima halaman dan stylesheet Anda. Biasanya (untuk saya) javascript (melalui jquery plugin dan semacamnya) jauh lebih dari CSS. Ada juga yang terjadi ketika koneksi internet Anda tersendat di tengah halaman tetapi mari kita abaikan itu (itu terjadi pada saya sesekali dan saya percaya css membuat tetapi saya tidak yakin 100%).

Karena css ada di kepala, mungkin ada koneksi tambahan untuk mendapatkannya, yang berarti berpotensi untuk selesai sebelum halaman itu. Anyways selama jenis sisa halaman mengambil dan file javascript (yang lebih banyak byte) halaman tidak ditata yang membuat situs / koneksi tampak lambat.

BAHKAN JIKA penerjemah JS menolak untuk memulai sampai CSS selesai waktu yang dibutuhkan untuk mengunduh kode javascript terutama ketika jauh dari server memotong ke waktu css yang akan membuat situs terlihat tidak cantik.

Ini adalah optimasi kecil tapi itulah alasannya.


4
2018-04-20 22:42



Ini dia RINGKASAN dari semua jawaban utama di atas (atau mungkin di bawah nanti :)

Untuk browser modern, letakkan css di mana pun Anda menyukainya. Mereka akan menganalisis file html Anda (yang mereka sebut spekulatif parsing) dan mulai mengunduh css secara paralel dengan penguraian html.

Untuk peramban lama, letakkan css di atas (jika Anda tidak ingin menampilkan halaman yang telanjang tetapi interaktif terlebih dahulu).

Untuk semua browser, letakkan javascript lebih jauh di bawah halaman, karena itu akan menghentikan penguraian html Anda. Sebaiknya, unduh secara asinkron (mis., Panggilan ajax)

Ada juga, beberapa hasil eksperimental untuk kasus tertentu yang mengklaim menempatkan javascript pertama (yang bertentangan dengan kearifan tradisional menempatkan CSS pertama) memberikan kinerja yang lebih baik tetapi tidak ada alasan logis yang diberikan untuk itu, dan tidak memiliki validasi terkait penerapan yang luas, sehingga Anda dapat abaikan saja untuk saat ini.

Jadi, untuk menjawab pertanyaan: Ya. Rekomendasi untuk memasukkan CSS sebelum JS tidak valid untuk browser modern. Letakkan CSS di mana pun Anda suka, dan letakkan JS menjelang akhir, sebanyak mungkin.


2
2018-03-12 20:46



Steve Souders sudah memberikan jawaban pasti tapi ...

Saya bertanya-tanya apakah ada masalah dengan tes asli Sam dan pengulangan Josh.

Kedua tes tampaknya telah dilakukan pada koneksi latensi rendah di mana pengaturan koneksi TCP akan memiliki biaya yang sepele.

Bagaimana ini mempengaruhi hasil tes saya tidak yakin dan saya ingin melihat air terjun untuk tes melalui koneksi latency 'normal' tetapi ...

File pertama diunduh harus dapatkan koneksi yang digunakan untuk halaman html, dan file kedua yang diunduh akan mendapatkan koneksi baru. (Membilas alter awal yang dinamis, tetapi tidak dilakukan di sini)

Di browser yang lebih baru, koneksi TCP kedua dibuka secara spekulatif sehingga overhead koneksi dikurangi / hilang, di browser yang lebih lama ini tidak benar dan koneksi kedua akan memiliki overhead dibuka.

Cukup bagaimana / jika ini mempengaruhi hasil tes saya tidak yakin.


1
2017-08-23 08:33



Saya pikir ini tidak akan berlaku untuk semua kasus. Karena css akan mengunduh paralel tetapi tidak bisa. Pertimbangkan untuk kasus yang sama,

Daripada memiliki css tunggal, ambil 2 atau 3 file css dan cobalah cara-cara ini,

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

Saya yakin css..css..js akan memberikan hasil yang lebih baik daripada yang lain.


1
2018-02-14 14:29