kyle: " @paul_irish saya tidak setuju. http://bit.ly/9IfMMN cacheability (CDN eksternal), unduhan paralel, perubahan skrip-volatilitas..."

james burke: " @paul_irish @fearphage @getify RequireJS memiliki alat build untuk melakukan bundling/minifying skrip, sehingga dapat memiliki yang terbaik dari keduanya: dinamis dan prebuilt"

Cara termudah bagi pengembang untuk memulai pemuatan skrip mungkin menggunakan $Lab.js, karena sudah menggunakan sintaks rantai yang sudah dikenal oleh banyak pengguna jQuery.

Jika mereka membuat aplikasi perusahaan besar, mereka selalu dapat bermigrasi ke require.js jika diperlukan.

saat ini ada tiga teknik pemuatan skrip utama:

1. HeadJS
2. KontrolJS
3. LABjs

gunakan atau tidak, yang mana yang akan digunakan agak bisa diperdebatkan: http://blog.getify.com/2010/12/on-script-loaders/

Ada juga requireJS dan EnhanceJS hanya untuk memberi tahu Anda alternatif dari HeadJS ControlJS dan LabJS . Bahkan Yahoo dan google menawarkan hal serupa.

Dengan dirilisnya jQuery 1.5 dan ditangguhkan -- http://www.erichynds.com/jquery/using-deferreds-in-jquery/ , Boris Moore menggunakannya di DeferJS, proyek pemuat skrip baru: https://github. com/BorisMoore/DeferJS

Secara default, pemuatan skrip menghentikan semua unduhan lainnya, jadi mengunduh modernizr di header itu buruk. Pemuat sebaris masuk akal, karena pemuat dapat mengunduh skrip secara paralel dan dalam mode tidak memblokir. Misalnya jika Anda tidak memerlukan semua fitur modernizr, Anda dapat inline head.min.js yang hanya 6kb atau custom build modernizr (http://modernizr.github.com/Modernizr/2.0-beta/). Menyisipkan CSS terkadang masuk akal juga. Google menggunakan inlining, mereka inline css, js dan gifs 1x1 kosong melalui datauri.

LabJS menjadi cukup banyak digunakan dan merupakan solusi yang baik - juga dapat dimasukkan secara tidak sinkron sehingga tidak perlu diblokir.

http://blog.getify.com/2010/12/on-script-loaders/ adalah oleh penulisnya

http://yepnopejs.com/ baru saja menggunakan 1.0 dan tidak merusak webkit baru, tidak seperti LAB dan head.js. Memuat skrip sulit.

yepnope juga terintegrasi ke Modernizr sebagai Modernizr.load .. http://modernizr.github.com/Modernizr/2.0-beta/

Jadi kita mungkin akan segera memiliki pemuat skrip di h5bp melalui Modernizr.load.

Saya tidak berpikir itu akan menghasilkan 1.0 tetapi begitu saya menggunakan Modernizr hingga 1.8, kami akan memasukkannya ke dalam h5bp 1.1. Yeeeah

hai paul

Saya telah mem-porting situs yang ada untuk menggunakan H5BP Anda dan saya ingin menggunakan pemuat skrip yepnope.js. Sangat menyenangkan melihat semua bit dan bot disatukan seperti yang telah Anda lakukan.

Apa yang akan Anda rekomendasikan untuk digunakan saat ini?

1. Sertakan yepnope.js bersama dengan modernizer.js di bagian atas halaman
2. Sertakan di bagian bawah halaman, untuk memuat setelah HTML selesai dimuat.
3. Gunakan versi beta dari modernizer.js
4. Saya dapat menggabungkan yepnope.js dengan modernizer.js menjadi satu include.

Terlepas dari cara terbaik untuk memasukkannya, bagaimana Anda merekomendasikan memuat skrip dengan yepnope,js?

Saya pikir kita harus melakukannya di sini: https://github.com/paulirish/html5-boilerplate/blob/master/index.html#L52 dan gunakan yepnope untuk memuat CDN / salinan lokal jQuery dan skrip kami yang lain.

Namun, apakah menurut Anda yang terbaik adalah menggunakan skrip eksternal yang menyertakan atau merender blok skrip di dalam html, yang kemudian memuat skrip melalui yepnope.js?

Terimakasih banyak.

andy

Oh dan hal lain.

Karena yepnope dapat memuat css melalui, saya akan mengatakan yang terbaik untuk memasukkan css utama seperti biasanya dan menggunakan yepnope untuk hanya menyertakan css untuk perbaikan tertentu.

Misalnya termasuk beberapa css yang hanya diterapkan pada versi IE yang lebih lama.

hokapoka,

Gunakan versi beta modernizr.. cukup sertakan apa yang Anda butuhkan (dan sertakan Modernizr.load() ) lalu letakkan di bagian atas halaman.

kode aktual untuk fallback jquery dengan yepnope ada di http://yepnopejs.com/

Dan ya saya suka ide Anda tentang beban bersyarat IE css.

tbh ada terlalu banyak kepercayaan buta di sekitar kinerja script loader wrt dan saya tidak berpikir kami siap untuk mengatakan INI ADALAH CARA YANG BENAR.

kami membutuhkan lebih banyak penelitian seputar ukuran file, bandwidth, dan kondisi jaringan yang menunjukkan rekomendasi cerdas tentang pemuatan skrip, tetapi saat ini bidangnya baru lahir dan kami akan naif untuk merekomendasikan solusi menyeluruh untuk pemuatan skrip.

jadi.

menutup tiket ini dan meminta siapa saja yang peduli untuk melakukan penelitian dan penerbitan komprehensif yang diperlukan untuk memudahkan pengembang membuat pilihan cerdas tentang yang satu ini

saya telah melakukan sedikit penelitian tentang beban concat vs paralel. saya masih, tanpa syarat, membuat rekomendasi untuk menggabungkan semua js menjadi satu file terlebih dahulu, lalu potong menjadi 2-3 ~ potongan berukuran sama, dan muat secara paralel.

Saya ingin sekali dapat melakukan penelitian saya dan menyebarkannya secara luas dan berskala, sehingga layak sebagai "fakta" di bidang ini. Masalahnya adalah saya telah mencoba dan mencoba menemukan bandwidth hosting yang tidak akan menghabiskan banyak $$ untuk benar-benar menjalankan tes dalam skala besar, dan gagal menemukan penyediaan hosting itu.

Jika saya/kami dapat memecahkan masalah bandwidth untuk pengujian, saya memiliki tes yang dapat dijalankan untuk mengetahui apakah teori pemuatan paralel sebenarnya layak (seperti yang saya yakini).

@getify apa yang Anda butuhkan sejauh rig pengujian?

Saya dapat melakukan sekitar 1,5TB lebih banyak data dari server pribadi saya daripada yang saya gunakan saat ini. Saya telah menginstal Nginx dan itu dapat menangani sekitar 4 triliun kuadriliun hit per mikrodetik. Saya tidak merasa teknologi adalah penghalang di sini.

Jika kami khawatir tentang lokasi, kami dapat memalsukan latensi yang lebih tinggi, dan/atau menemukan beberapa orang lain dengan sedikit ruang ekstra di kotak mereka.

BTW, saya mengambil sedikit masalah dengan "iman buta".

Mudah, dapat dibuktikan, dan hampir tanpa pertanyaan benar bahwa jika Anda memiliki situs yang memuat banyak skrip dengan tag-skrip, menggunakan pemuat skrip paralel (tanpa perubahan lain) meningkatkan kinerja. Ini benar karena bahkan peramban terbaru tidak dapat (dan saya rasa tidak akan pernah) melepas pin pemuatan skrip dari pemblokiran yang siap-DOM. Jadi, bahkan dalam kasus terbaik pemuatan browser, jika tidak ada manfaat lain, mempercepat DOM-siap secara drastis di situs hampir selalu merupakan kemenangan (untuk pengguna dan UX).

Pernyataan Anda sedikit mengandung premis yang salah karena mengasumsikan bahwa kami mencoba membandingkan, untuk setiap situs, pemuatan paralel ke script-concat. Sebagian besar situs di web sebenarnya tidak/tidak dapat menggunakan script-concat, jadi sebenarnya perbandingan (bagi mereka, mayoritas) tidak begitu bernuansa dan serumit yang Anda bayangkan. Jika mereka tidak/tidak dapat menggunakan script-concat (untuk alasan apa pun), perbandingannya sederhana: pemuatan paralel hampir selalu merupakan kemenangan atas tag skrip.

Jika mereka terbuka untuk script-concat (atau sudah menggunakannya), maka ya, itu menjadi sedikit lebih bernuansa/rumit untuk memutuskan apakah pemuatan paralel dapat membantu atau tidak. Tetapi script-concat juga bukan solusi peluru perak satu ukuran untuk semua, jadi ada banyak situs yang memuat paralel akan tetap menjadi pendekatan yang disukai dan terbaik.

Hanya karena beberapa situs berurusan dengan nuansa/kompleksitas dalam memutuskan antara pemuatan paralel vs. script-concat tidak berarti bahwa diskusi yang lebih besar (lebih berdampak) tentang pemuatan paralel vs. tag skrip harus hilang dalam campuran. Yang pertama sulit dibuktikan, tetapi yang terakhir hampir diberikan pada saat ini.

Semua ini untuk mengatakan bahwa, semua hal dipertimbangkan, IMHO boilerplate harus mendorong pola yang memiliki dampak terbesar ke arah yang positif. Jika 80% situs di internet saat ini menggunakan tag skrip, yang sebagian besar akan mendapat manfaat dari perpindahan dari tag skrip ke pemuatan paralel, maka pemuatan paralel adalah hal yang sangat sehat untuk disarankan sebagai titik awal untuk boilerplate.

Ini adalah subbagian yang jauh lebih kecil (tetapi penting) dari situs-situs yang berpotensi mendapatkan lebih banyak manfaat dari menjelajahi skrip-concat vs pemuatan paralel. Tetapi kasus penggunaan minoritas bukanlah yang harus dioptimalkan dalam boilerplate.

Hanya beberapa sen saya.

@paulirish @slexaxton --

Sejauh kebutuhan bandwidth, saya memperkirakan bahwa untuk mendapatkan 10.000 orang (apa yang saya rasa diperlukan untuk menjadi pengambilan sampel yang akurat) untuk menjalankan tes sekali (dan banyak orang akan menjalankannya beberapa kali, saya yakin), itu akan menjadi sekitar 200GB bandwidth yang dihabiskan. Bagi sebagian orang, itu adalah setetes air dalam ember. Bagi saya, bandwidth 200GB dalam beberapa hari akan membebani biaya hosting server saya. Jadi, saya tidak mengejar penskalaan tes dengan alasan itu saja.

Selain itu, saya memiliki lebih dari selusin variasi tes ini yang menurut saya perlu kita jelajahi. Jadi, puluhan kali menggunakan bandwidth masing-masing 100-200GB akan sangat mahal bagi saya untuk membayar tagihan. Saya tidak ingin memulai jalan itu kecuali saya yakin bahwa saya memiliki cukup bandwidth untuk menyelesaikan tugas.

Itu hanya file statis, dan pengujiannya tidak memerlukan banyak pengguna secara bersamaan, jadi tidak ada masalah nyata tentang masalah penskalaan tradisional seperti CPU, dll. Hanya bandwidth, itu saja.

Kami dapat mengambil sisa diskusi tentang tes secara offline dan melanjutkannya melalui email atau IM. Saya sangat ingin akhirnya menskalakan tes dan "menyelesaikan" masalah ini. Sudah berkeliaran di bagian belakang otak saya selama lebih dari satu tahun sekarang.

Saya dapat melakukan TB tanpa batas di VPS dreamhost saya jadi ini tidak akan menjadi masalah. sekarang saya melakukan 72gb/hari dan dapat menangani lebih banyak. :)

Saya setuju dengan paul, dan berpikir ada sedikit informasi yang salah tentang bagaimana dan kapan pemuat skrip akan bermanfaat bagi siapa pun.

Paragraf pertama Anda mengatakan itu 'mudah', 'dapat dibuktikan' dan 'tanpa pertanyaan' bahwa pemuat skrip meningkatkan kinerja.

Saya membuat postulat serupa dengan @jashkenas beberapa waktu lalu, dan dia dan saya mengumpulkan beberapa halaman identik sebaik mungkin untuk mencoba dan mengukur kinerja teknik _best_ kami. Dia penggemar 100% concat, dan saya mencoba 2 teknik pemuatan skrip yang berbeda.

https://github.com/SlexAxton/AssetRace

Kode semua ada. Jelas tidak ada audiens pengujian yang besar, tetapi hasil terbaik menunjukkan bahwa pemuat skrip ini memiliki kecepatan yang hampir sama dengan metode concat (dengan mengikuti pedoman pemuatan paralel 3 file berukuran serupa), dan paling buruk menunjukkan bahwa skrip- loader lebih bervariasi dan umumnya lebih lambat dalam batas kesalahan. Jangan ragu untuk melakukan fork dan menemukan solusi yang lebih baik dari kami atau keduanya, meskipun itu hanya di komputer Anda dalam satu browser.

Adapun "premis palsu" karena h5bp mengasumsikan bahwa orang menggabungkan js mereka. Argumen ini sepenuhnya tidak valid karena h5bp menawarkan alat pembuatan skrip, lengkap dengan concat dan minification. Jadi argumen bahwa pemuatan paralel hampir selalu merupakan kemenangan atas beberapa tag skrip mungkin benar, tetapi itu tidak lebih baik dari apa yang ditawarkan h5bp saat ini. Itulah konteks diskusi ini.

Saya pikir skenario terburuk adalah orang-orang mengambil sesuatu seperti yepnope atau lab.js dan menggunakannya sebagai polyfill tag skrip. Itu benar-benar akan menghasilkan pemuatan yang lebih lambat (dari 19 file JS dan 34 CSS mereka), serta memperkenalkan banyak masalah kompatibilitas mundur dan maju yang sama sekali tidak mereka sadari.

Saya pikir dalam semangat memberi orang standar yang paling masuk akal dan berkinerja dan kompatibel untuk _boilerplate_, alat build melangkah lebih jauh untuk memastikan ketiganya.

@slexaxton

... hasil terbaik menunjukkan bahwa pemuat skrip ini memiliki kecepatan yang hampir sama dengan metode concat (dengan mengikuti pedoman pemuatan paralel 3 file berukuran serupa)...

Saya akan dengan senang hati mencari waktu untuk melihat tes yang Anda buat. Saya yakin kalian tahu apa yang Anda lakukan, jadi saya yakin tes Anda valid dan benar.

OTOH, saya punya banyak bukti yang kontradiktif. Jika saya pernah melihat sesuatu yang menarik untuk menyarankan bahwa pemuatan skrip paralel adalah pemborosan atau tidak membantu sebagian besar situs, saya sudah lama meninggalkan wastafel waktu gila yaitu LABjs.

Saya dapat mengatakan dengan kepastian 100% bahwa saya tidak pernah, dalam 2 tahun membantu mengeluarkan LABjs untuk orang-orang, menemukan situasi di mana LABjs lebih lambat daripada alternatif tag skrip. Nol kali yang pernah terjadi _untuk saya_. Sudah beberapa kali orang mengatakan bahwa mereka tidak melihat banyak manfaat. Ada beberapa kali di mana orang memuat 100+ file dan overhead gila dari banyak koneksi menghapus semua manfaat yang mungkin mereka lihat. Tapi saya tidak pernah sekalipun memiliki seseorang yang memberi tahu saya bahwa LABjs membuat situs mereka lebih lambat.

Saya sendiri telah membantu 50+ situs berbeda berpindah dari tag skrip ke LABjs, dan tanpa gagal situs langsung melihat peningkatan kinerja. Pada awal upaya, saya mengambil sampel dari mungkin 7 atau 8 situs yang telah saya bantu, dan mereka secara kolektif melihat peningkatan rata-rata sekitar 15% dalam kecepatan pemuatan. Untuk 4 atau 5 situs yang saya kelola, tentu saja saya menerapkan LABjs, dan langsung melihat kecepatan loading sebanyak 3x.

Tentu saja, ketika LABjs pertama kali diluncurkan, browser memuat skrip secara paralel (hanya sedikit yang melakukannya). Jadi keuntungannya sangat besar dan terlihat saat itu. Sekarang, kami memiliki hampir semua browser melakukan pemuatan paralel, jadi keuntungannya tidak begitu drastis lagi.

Tetapi satu hal yang tidak dapat disangkal adalah bahwa semua browser memblokir acara DOM-siap untuk memuat tag skrip. Mereka _harus_ karena kemungkinan menemukan document.write() . Pemuatan skrip paralel pada dasarnya mengatakan "browser, saya berjanji Anda tidak perlu berurusan dengan document.write, jadi lanjutkan dan lanjutkan dengan halaman".

Perhatikan dua diagram pada slide 10 dari dek ini:

http://www.slideshare.net/shadedecho/the-once-and-future-script-loader-v2

Bandingkan penempatan garis biru (DOM-ready). Itu adalah peningkatan drastis dalam kinerja yang dirasakan (UX), meskipun waktu pemuatan halaman secara keseluruhan (atau waktu untuk menyelesaikan semua pemuatan aset) tidak lebih baik.

...h5bp menawarkan alat pembuatan skrip...

Asumsi yang salah di sini adalah bahwa hanya karena h5bp menawarkan alat ini, semua (atau bahkan sebagian besar) pengguna h5bp dapat menggunakannya. Bahkan jika 100% pengguna h5bp _do_ menggunakannya, itu tidak berarti bahwa jika h5bp diluncurkan ke ujung panjang internet, mereka semua akan menggunakan alat concat itu. Ada banyak faktor lain yang dapat dengan mudah mencegah seseorang menggunakannya. Ada _sangat sedikit_ alasan mengapa seseorang tidak dapat beralih dari menggunakan tag skrip ke menggunakan pemuat skrip paralel.

Dengan demikian, pemuatan skrip paralel masih menawarkan daya tarik yang lebih luas ke ekor panjang internet. Masih lebih mudah bagi sebagian besar situs yang tidak menggunakan optimasi pemuatan skrip, untuk berpindah dari tidak ada ke sesuatu, dan sesuatu yang menawarkan kinerja menang. Beberapa dari situs berekor panjang itu akan pernah menghabiskan upaya (atau memiliki keterampilan untuk bereksperimen dengan) alat pembuatan skrip otomatis di $6/bln murah, hosting bersama massal, lingkungan hosting web non-CDN.

Saya pikir skenario terburuk adalah orang-orang mengambil sesuatu seperti yepnope atau lab.js dan menggunakannya sebagai polyfill tag skrip. Itu benar-benar akan menghasilkan pemuatan yang lebih lambat ...

Saya sangat tidak setuju dengan pernyataan ini. LABjs dirancang khusus sebagai polyfill tag skrip. Dan peningkatan LABj atas tag skrip biasa (abaikan skrip concat untuk saat ini) sudah mapan dan tidak pernah dibantah secara serius. Jika Anda memiliki bukti bahwa sebagian besar (atau bahkan banyak) situs di luar sana yang menggunakan LABjs akan lebih baik kembali ke tag skrip, silakan bagikan.

Sama sekali tidak ada alasan mengapa pemuatan skrip paralel akan menghasilkan pemuatan yang lebih lambat daripada yang dapat dilakukan browser dengan tag skrip. Itu tidak masuk akal. Dan seperti yang saya tetapkan di atas, tag skrip akan selalu memblokir DOM-ready, di mana pemuatan skrip paralel tidak.

memperkenalkan banyak masalah kompatibilitas mundur dan maju yang sama sekali tidak mereka sadari.

Masalah kompatibilitas apa yang Anda bicarakan? Matriks dukungan browser LABjs benar-benar mencakup sebagian besar browser web di planet ini. Sepotong kecil browser yang dibobolnya jauh lebih besar daripada banyaknya browser yang memiliki manfaat jelas.

LABjs 1.x memiliki banyak peretasan gila di dalamnya, seperti cache-preloading, yang memang menjadi perhatian utama untuk kerusakan pada browser. LABjs 2.x telah membalikkannya sepenuhnya, dan sekarang menggunakan pendekatan yang andal dan standar untuk pemuatan paralel dalam semua kasus, hanya kembali ke peretasan untuk browser webkit yang lebih lama. Selain itu, LABjs 2.x sudah memiliki pemeriksaan di dalamnya untuk uji fitur teknik pemuatan skrip yang akan segera hadir (semoga segera distandarisasi) seperti "preloading nyata".

Saya tidak dapat berbicara secara pasti untuk pemuat skrip lainnya -- saya tahu banyak yang masih menggunakan peretasan -- tetapi untuk LABj, saya bingung dengan klaim bahwa ini memperkenalkan masalah kompatibilitas maju atau mundur, karena saya pikir ini jelas-jelas menyesatkan mengeklaim.

untuk menguraikan sedikit tentang mengapa saya bermaksud agar LABjs sebenarnya menjadi polyfill tag skrip ...

1. browser lama jelas JAUH lebih rendah dalam menangani tag skrip yang memuat yang dapat ditangani oleh pemuatan paralel. di "browser lama" tersebut (yang merupakan yang terbaru/terbaik ketika LABj diluncurkan 2 tahun lalu) kami melihat ~3x peningkatan waktu pemuatan halaman. hampir secara definisi, itu membuat LABjs menjadi polyfill tag skrip yang lebih baik, karena membawa fitur (yaitu, kinerja pemuatan paralel) ke browser yang tidak mendukungnya sendiri.
2. browser yang lebih baru jelas jauh lebih baik. tetapi mereka belum sepenuhnya menghilangkan manfaat pemuat skrip. chrome baru-baru ini seperti v12 (saya kira mereka akhirnya diperbaiki di v13 tampaknya) masih memblokir pemuatan gambar saat tag skrip selesai dimuat. bahkan dengan yang terbaru dari IE, Firefox dan Chrome, mereka semua masih memblokir DOM-siap saat skrip dimuat secara dinamis, karena mereka semua masih harus pesimis berasumsi bahwa document.write() mungkin mengintai.

Jadi, untuk browser yang lebih baru, LABjs adalah "polyfill" dalam arti membawa "pemuatan skrip non-DOM-ready-blocking" ke browser dengan cara yang tidak dapat dilakukan oleh tag skrip. Satu-satunya cara yang mungkin Anda lakukan untuk melakukan itu di browser modern tanpa pemuat skrip paralel adalah dengan menggunakan tag skrip dengan defer ( async jelas tidak akan berfungsi karena tidak mempertahankan urutan) . Namun, defer memiliki sejumlah keanehan, dan dukungannya tidak cukup luas untuk menjadi solusi yang layak (fallback untuk non-defer adalah kinerja yang buruk). Jadi Anda bisa mengatakan bahwa, dalam kasus yang paling dasar, LABjs adalah polyfill untuk karakteristik kinerja tag skrip defer (walaupun tidak persis).

Sejujurnya, saya masih berpikir kita harus mengajukan petisi standar untuk objek pemuatan skrip. Harus membuat tag skrip dari jenis yang berbeda dari teks/javascript untuk memicu cache (atau lebih buruk lagi, menggunakan tag objek atau objek gambar atau apa pun yang diperlukan versi baru dari browser populer) melompati banyak rintangan tanpa biaya dan kinerja akan bervariasi tergantung dari terlalu banyak variabel. Saya bisa mengerti kita masih memuat stylesheet menggunakan penyisipan simpul dom (tapi itu hanya karena pesanan) tetapi ketika menyangkut skrip, saya pikir itu tidak masuk akal sama sekali (saya berharap google akan berhenti menggunakan document.write di sebagian besar skrip mereka tapi itu cerita lain sepenuhnya).

Juga, saya pikir kami kehilangan poin terbesar tentang pemuat skrip di sini: untuk dapat memuat kode js sesuai permintaan daripada memuat semuanya di muka (bahkan dengan semua yang ada di cache, penguraian dan inisialisasi membutuhkan waktu dan itu bisa menjadi cantik jelek dengan jumlah skrip gabungan yang tidak sepele). Memiliki beberapa waktu tunggu setelah interaksi UI jauh lebih sedikit masalah daripada membuat browser "hang" bahkan sedikit saat start-up (DOM mungkin sudah siap baik-baik saja, tetapi apa gunanya jika kode untuk meningkatkan halaman dan tambahkan iterasi belum dieksekusi: pernahkah memperhatikan bagaimana beberapa situs segera memuat kemudian sesuatu yang kikuk terjadi?).

Jadi pengukuran kinerja yang ketat semuanya baik-baik saja dan keren, tetapi saya masih berpikir kinerja yang dirasakan adalah tujuan akhir ... dan sayangnya jauh lebih mudah untuk memperkirakan/mengoptimalkan/menghitung.

Ini intens.

@jaubourg--

Sejujurnya, saya masih berpikir kita harus mengajukan petisi standar untuk objek pemuatan skrip.

Ada banyak petisi yang terjadi mengenai bagaimana standar/spesifikasi dan browser dapat memberi kami teknologi pemuatan skrip yang lebih baik. Kemenangan besar pertama dalam kategori ini dalam beberapa tahun adalah "async yang dipesan" ( async=false ) yang diadopsi kembali pada bulan Februari dan sekarang ada di setiap browser rilis utama saat ini (pengecualian: Opera segera hadir, dan IE10p2 memilikinya ).

Debat berikutnya, yang saat ini sedang saya diskusikan dengan Ian Hickson, adalah apa yang saya sebut "preloading nyata". Menurut pendapat saya, "pramuat nyata" (yang sudah didukung IE sejak v4, btw) akan menjadi hal yang paling dekat dengan "peluru perak" yang akan menyelesaikan hampir semua skenario pemuatan skrip dengan agak sepele. Saya masih cukup optimis bahwa kita akan melihat standar seperti ini.

Lihat wiki ini untuk info lebih lanjut: http://wiki.whatwg.org/wiki/Script_Execution_Control

Harus membuat tag skrip dari jenis yang berbeda dari teks/javascript untuk memicu cache (atau lebih buruk lagi, gunakan tag objek atau objek gambar atau apa pun yang diperlukan versi baru dari browser populer)

Ini disebut "cache preloading", dan ini adalah peretasan yang buruk dan mengerikan. Cara LABjs tidak menekankan ini sekarang pada v2 (hanya menggunakannya sebagai cadangan untuk webkit yang lebih lama). Sayangnya, pemuat skrip lain masih menggunakannya sebagai mekanisme pemuatan utama mereka. Tetapi 90% dari kebutuhan untuk "memuat awal cache" dapat diselesaikan dengan "async yang dipesan", yang distandarisasi dan bukan merupakan peretasan, jadi pemuat skrip yang berperilaku baik harus lebih memilih daripada "memuat cache terlebih dahulu" sekarang.

Jadi, saya setuju bahwa "pramuat cache" menyebalkan, tetapi ada banyak cara yang lebih baik untuk menggunakan document.createElement("script") yang tidak melibatkan peretasan seperti itu, jadi saya tidak setuju bahwa ini adalah argumen untuk tidak terus mengandalkan elemen Skrip browser untuk pemuatan skrip. Jika kita bisa mendapatkan "preloading nyata", elemen Script akan menjadi semua yang kita butuhkan. Saya benar-benar percaya itu.

Saya pikir kami kehilangan poin terbesar tentang pemuat skrip di sini: untuk dapat memuat kode js sesuai permintaan

Sangat setuju bahwa itu adalah manfaat penting yang dibawa oleh pemuat skrip. Tapi itu semacam argumen yang bisa diperdebatkan di utas _this_, karena orang-orang "skrip concat" tidak bisa, tanpa memuat skrip, menyelesaikan kasus penggunaan, jadi tidak masuk akal untuk "membandingkan" keduanya. Anda dapat mengatakan sebagai pendukung "script concat" "baik, kami tidak peduli dengan use case itu", tetapi Anda tidak dapat mengatakan "kami dapat melayani use case itu dengan lebih baik menggunakan XYZ".

Kinerja yang dirasakan _is_ besar dan penting, saya setuju. Pemuatan sesuai permintaan adalah bagian besar untuk mewujudkannya. Pemuatan sesuai permintaan juga akan meningkatkan kinerja nyata yang sebenarnya (bukan hanya persepsi) karena cenderung menyebabkan lebih sedikit unduhan yang sebenarnya jika Anda hanya mengunduh apa yang diperlukan (beberapa kunjungan halaman memerlukan 100% dari kode yang Anda tulis).

Kinerja yang dirasakan juga mengapa saya menganjurkan argumen siap DOM di atas. Karena seberapa cepat "merasa" pengguna dapat berinteraksi dengan halaman adalah _sangat_ penting untuk seberapa cepat mereka menganggap halaman tersebut (terlepas dari seberapa cepat halaman tersebut benar-benar dimuat). Itu fakta yang ditetapkan oleh banyak penelitian pengguna.

Harus menyukai komentar panjang dan penuh gairah dari @getify
Kyle...

Jika saya dapat berkontribusi dengan cara apa pun untuk penelitian ini, saya akan _suka_.
Bandwidth (biaya) tampaknya tidak menjadi masalah, jadi @getify , apa yang Anda usulkan untuk maju?
Jangan ragu untuk menghubungi saya melalui email (aaron [at] aaronpeters [dot] atau twitter (@aaronpeters)

@kyle

Ya, saya mengikuti diskusi tag skrip "penyempurnaan" mengenai pramuat dan saya tidak membeli pendekatan "tambahkan atribut lain pada tag skrip" sebagai pendekatan yang layak. Saya telah melihat apa yang dilakukannya pada spesifikasi xhr: banyak kerumitan sehubungan dengan sedikit manfaat yang kita dapatkan pada akhirnya.

Yang jelas adalah bahwa kita hanya membutuhkan perilaku preloading saat melakukan penyisipan dinamis (yaitu sudah melakukannya dalam javascript) jadi mengapa kita masih harus menggunakan injeksi tag skrip? Ini tidak seperti kita menyimpan tag di sana atau menggunakannya sebagai simpul DOM: itu hanya sarana untuk mencapai tujuan yang tidak ada hubungannya dengan struktur dokumen.

Saya akan jauh lebih nyaman dengan sesuatu seperti itu:

window.loadScript( url, function( scriptObject ) {
    if ( !scriptObject.error ) {
        scriptObject.run();
    }
});

Ini akan membuat keajaiban. Cukup mudah untuk "bergabung" dengan beberapa acara pemuatan skrip dan kemudian menjalankan skrip tersebut dalam urutan apa pun yang diperlukan. Itu juga tidak menyiratkan kehadiran DOM yang membuatnya lebih umum. Saya berharap kita akan segera menjauh dari injeksi tag skrip. Selain itu, cukup mudah untuk melakukan polyfill menggunakan trik yang kita semua tahu. Ini juga jauh lebih ringan daripada sistem kebutuhan yang lengkap (tetapi bisa menjadi batu bata bangunan untuk sistem yang dibutuhkan yang kemudian tidak terbatas pada browser).

Meskipun demikian, saya setuju 100% dengan Anda tentang kinerja yang dirasakan, saya hanya ingin menunjukkannya karena mantra "mari kita padukan semuanya" dengan cepat menjadi semacam kepercayaan yang mengaburkan hal-hal terlalu banyak untuk selera saya;)

fwiw, defer didukung di IE4+, Chrome, Safari, dan FF 3.5+. Tidak didukung di Opera.

Jadi itu berarti.... 98,5% pengguna sudah memiliki dukungan script@defer .

@getify

Namun, defer memiliki sejumlah kebiasaan,

perincian? saya belum melihat apa-apa tentang ini

Apakah skrip dengan penangguhan dijalankan sebelum atau setelah peristiwa siap DOM diaktifkan?

Apakah perintah eksekusi dipertahankan di semua browser?

Bagaimana urutan exec dan kopling eksternal dengan skrip sebaris?

@paulirish--

...98,5% pengguna sudah memiliki dukungan script@defer .

dukungan mungkin ada di banyak browser, tetapi itu tidak berarti itu dapat diandalkan di banyak browser. itu yang saya maksud. (Lihat di bawah)

Namun, defer memiliki sejumlah kebiasaan,

perincian? saya belum melihat apa-apa tentang ini

Coba lihat... IIRC:

1. dukungan penangguhan pada elemen skrip dinamis tidak ditentukan atau didukung di browser mana pun... hanya berfungsi untuk tag skrip di markup. ini berarti sama sekali tidak berguna untuk teknik dan kasus penggunaan "sesuai permintaan" atau "pemuatan malas".
2. saya percaya ada kasus di mana di beberapa browser, skrip yang ditangguhkan akan mulai dieksekusi segera sebelum DOM-ready diaktifkan, dan di kasus lain, itu terjadi segera setelah DOM-ready diaktifkan. Perlu melakukan lebih banyak penggalian untuk lebih spesifik tentang itu.
3. defer digunakan pada tag skrip yang mereferensikan sumber daya eksternal berperilaku berbeda dari defer ditentukan pada tag skrip dengan kode sebaris di dalamnya. Artinya, itu tidak dapat dijamin berfungsi untuk menunda kedua jenis skrip dan membuatnya tetap berjalan dalam urutan yang benar.
4. defer pada tag skrip yang ditulis oleh pernyataan document.write() berbeda dari tag skrip dalam markup dengan defer .

Saya tidak memiliki banyak detail yang siap di ujung jari saya tentang masalah ini. Saya ingat sekitar 2 tahun yang lalu (sebelum LABjs) mencoba menggunakan defer , dan mengalami cukup banyak dari mereka dalam pengujian lintas-browser yang pada dasarnya saya kesampingkan dan belum pernah mengunjunginya kembali sejak itu.

Saya juga harus menunjukkan bahwa defer sebenarnya tidak sama dengan yang disediakan oleh LABjs (dan pemuat paralel lainnya). Saya mengatakan itu di atas dengan peringatan bahwa itu hanya agak seperti itu. Faktanya, apa yang disediakan oleh pemuatan skrip paralel (setidaknya, untuk bagian LABjs), adalah "async yang dipesan", yang sama sekali tidak dapat dicapai hanya melalui markup.

Perbedaan antara "ordered async" dan "defer" adalah bahwa "ordered async" masih akan mulai dieksekusi segera setelah skrip yang diminta pertama selesai dimuat, sedangkan "defer" akan menunggu hingga `DOM-ready sebelum memulai eksekusi. Untuk halaman sederhana dengan sedikit markup dan tidak ada panggilan markup pemblokiran lainnya (seperti tag skrip lainnya), perbedaan ini kecil. Tetapi untuk halaman dengan banyak sumber daya, saat skrip diizinkan untuk mulai dieksekusi bisa sangat berbeda.

Jadi, sejujurnya saya tidak ingin terlalu banyak menyinggung defer , karena pada kenyataannya itu bukan perbandingan yang bagus dengan apa yang disediakan oleh pemuatan skrip paralel. Itu hanya contoh terdekat dalam markup-only yang dapat saya gunakan untuk menggambarkan perilaku perintah eksekusi yang saya dapatkan. Saya mungkin seharusnya tidak membawa defer -- hanya memperkeruh diskusi.

Mari saya ulangi dari atas: "Untuk browser modern, LABjs adalah semacam 'polyfill' untuk perilaku 'ordered async', yang tidak mungkin untuk memilih hanya markup di browser mana pun."

Saya suka "memerintahkan async", itu ungkapan yang bagus.

Kyle > afaik, skrip dengan defer akan mengeksekusi _before_ onload, bahkan sebelum domready.
Skrip dengan atribut async akan dieksekusi secepatnya, dan _always_ _before_ onload, tetapi tidak harus sebelum domready

@aaronpeters--
Saya pikir Anda mungkin sedikit keluar jalur. Begini cara saya memahaminya:

Skrip async (baik dalam markup atau dibuat secara dinamis) akan dieksekusi ASAP, artinya kapan saja sebelum atau setelah DOM-ready. Dengan kata lain, skrip async boleh menunggu apa pun (kecuali ketersediaan mesin JS itu sendiri). Namun, jika diminta sebelum window.onload , maka di hampir semua browser mereka akan "menahan" acara window.onload hingga dimuat dan dijalankan. Saya pikir ada kasus yang terdokumentasi di mana skrip async tidak menyimpan window.onload , hanya saja tidak mengingat detail persisnya.

defer di sisi lain secara khusus berarti: tunggu sampai setelah DOM-siap. Selain itu, ada "antrian" dari semua skrip dengan defer disetel, sehingga antrean tidak diproses sampai setelah DOM-ready Ini berarti semuanya harus dijalankan secara ketat setelah DOM-ready (atau, lebih tepatnya, setelah DOM sudah siap dan selesai diurai, tepatnya). Tetapi mereka mungkin tertunda lebih jauh (jika pemuatan berjalan lambat). Mereka harus menahan window.onload sekalipun. Saya hanya ingat dari ingatan masa lalu yang samar-samar bahwa dalam beberapa versi IE, praktik sebenarnya dari teori ini agak kabur.

@getify

Tidak ingin menggagalkan utas ini lebih jauh, jadi saya memposting pemikiran saya tentang pramuat skrip dan proposal Anda di halaman WHATWG di sini: http://jaubourg.net/driving-a-nail-with-a-screwdriver-the-way -web

Skrip async (baik dalam markup atau dibuat secara dinamis) akan dieksekusi ASAP, artinya kapan saja sebelum atau setelah DOM-ready. Dengan kata lain, skrip async boleh menunggu apa pun (kecuali ketersediaan mesin JS itu sendiri). Namun, jika diminta sebelum window.onload , maka di hampir semua browser mereka akan "menahan" acara window.onload hingga dimuat dan dijalankan.

Ini mungkin lebih mudah dipahami setelah Anda menyadari bahwa JavaScript adalah utas tunggal. (Saya tahu saya butuh beberapa saat ...)

Demikian pula, jika Anda menggunakan setTimeout(fn, 0) untuk mengunduh sumber daya, dan mereka memasuki antrian unduhan sebelum onload diaktifkan, maka memuat sumber daya ini akan (masih) menunda onload .

Saya pikir ada kasus yang terdokumentasi di mana skrip async tidak menyimpan window.onload , hanya saja tidak mengingat detail persisnya.

Saya ingin mendapatkan info lebih lanjut tentang ini. Tolong ingat! :)

Yay pemuat skrip!

Masalah yang saya alami saat mengimplementasikannya di seluruh jaringan situs AOL adalah berurusan dengan kondisi balapan. Misalnya, memuat jQuery secara asinkron di kepala, lalu mengucapkan plugin jQuery di tengah-tengah dokumen yang dikirimkan secara asinkron di dalam entri blog.

Jadi, saya memulai proyek sains pemuat skrip saya sendiri (Boot.getJS) untuk menangani ini. Idenya adalah untuk mengunduh semua skrip secara paralel dan menjalankannya secara berurutan, apa pun yang terjadi, sesegera mungkin. Ini juga mendukung penangguhan untuk siap atau memuat, dan cache skrip. Sebagian besar ide dipinjam (dicuri) oleh orang-orang di utas ini, jadi terima kasih kawan. :)

Karena Anda mendiskusikan tolok ukur, saya pikir saya akan membagikan halaman pengujian yang saya buat untuk memahami perbedaan kinerja, sintaksis, dan perilaku berbagai pemuat skrip di luar sana, lihat di sini:

http://artzstudio.com/files/Boot/test/benchmarks/script.html

Untuk melihat bagaimana berbagai loader berperilaku, bersihkan cache, dan perhatikan permintaan jaringan dan waktu terakhir serta urutan eksekusi skrip.

Dave (@artzstudio), terima kasih telah membagikan pemikiran Anda dan tautan ke halaman pengujian Anda.

Pertanyaan: mengapa Anda memuat LABjs di halaman '<script> tag in head'? Itu sepertinya salah.

@artzstudio juga, Anda menggunakan LABjs versi lama. Apakah itu disengaja? Jika demikian, mengapa?

@aaronpeters Di AOL kami memiliki skrip seperti Omniture dan kode Iklan (dan lebih banyak lagi) yang harus ada di kepala, jadi di situlah perpustakaan pemuat masuk dalam kasus penggunaan kami. Juga ketika skrip berada di bagian bawah, ada masalah FOUC di beberapa widget kami sehingga semakin cepat dependensi dimuat (seperti jQuery) semakin baik.

Itu tidak disengaja, tes ini berumur beberapa bulan. Saya akan memperbarui perpustakaan ketika saya mendapat kesempatan.

FYI (semoga ini agak menarik/relevan), saya menjalankan beberapa tes di Webpagetest.org untuk melihat apa yang terjadi di IE8 saat memuat beberapa halaman pengujian @artzstudio .
Tag skrip: http://www.webpagetest.org/result/110810_C7_752b756180e132f50a3ef065e9e059ca/
Yapnope: http://www.webpagetest.org/result/110810_8S_a53f4ed2e16179c328fc57c572e71076/
LABjs: http://www.webpagetest.org/result/110810_ZV_1ece92044799e52ed5199aed6b407133/
MembutuhkanJS: http://www.webpagetest.org/result/110810_Z3_a1537e41a0b0570286151859973d0cfa/

Video membandingkan Yepnope dan LABjs: http://www.webpagetest.org/video/view.php?id=110810_074cb94c1b04a7ac9bd6538ec3fdd8d3c07f842d

Beberapa catatan:

• Gzip tidak aktif di server, jadi ukuran file RequireJS yang lebih besar berdampak
• Seperti yang disebutkan sebelumnya, halaman tag Script memuat LABjs di HEAD (tidak masuk akal) dan itu tentu saja berdampak

Untuk dua alasan ini saya membuat video yang hanya menampilkan Yepnope dan LABjs.

Yang menurut saya menarik adalah bahwa waktu Mulai Render jauh lebih baik untuk LABjs. Mengapa demikian? Akan senang untuk lebih memahami.

Catatan penutup: Saya tidak memposting ini dengan tujuan untuk mendukung LABjs daripada Yepnope atau semacamnya. Sekedar berbagi data...

Oh maaf saya mengerti apa yang Anda maksud tentang LABjs dalam tes <script>. Diperbaiki sekarang, bersama dengan peningkatan ke LABjs.

@artzstudio--

Jadi, saya memulai proyek sains pemuat skrip saya sendiri (Boot.getJS) untuk menangani ini. Idenya adalah mengunduh semua skrip secara paralel dan menjalankannya secara berurutan, apa pun yang terjadi, sesegera mungkin

Jadi, apakah Anda sadar bahwa ini adalah _persis_ yang dirancang dan berfungsi dengan baik oleh LABjs (jika saya sendiri yang mengatakannya)? Maksud saya, apakah Anda hanya menginginkan API yang berbeda, atau bagaimana dengan fungsionalitas pemuatan skrip paralel yang tidak mencukupi?

Bagaimanapun, sebanyak saya suka membual tentang LABjs, saya tidak berpikir itu efektif untuk menghentikan utas ini dengan jenis diskusi "lihat, pemuat skrip saya lebih baik di X". Diskusi-diskusi itu berguna, tetapi di tempat lain.

Pada akhirnya, semua teknologi pemuat skrip bermuara pada beberapa ide sederhana. Apa pun jenis API mewah yang Anda lapisi di atasnya, atau kasus penggunaan apa yang Anda layani, teknologinya tetap sama. Pasti ada 50 pemuat skrip yang berbeda hari ini, dan sungguh, tidak satupun dari mereka memberikan sesuatu yang berbeda dalam hal teknologi, hanya API yang berbeda. Jadi, membandingkan API sebenarnya adalah diskusi yang agak tidak relevan.

Yang harus kita fokuskan adalah, dapatkah teknologi pemuatan skrip dasar yang saat ini kami miliki di browser digunakan untuk meningkatkan kinerja pemuatan halaman dibandingkan dengan hanya menggunakan tag skrip di markup. Ini adalah premis saya yang sudah lama dipegang bahwa itu sepenuhnya benar, tetapi premis itu telah dipertanyakan di utas ini. Jadi tugas #1 adalah menjawab pertanyaan itu.

Jika kami mengetahui bahwa tag skrip hanya lebih baik daripada pemuatan skrip, maka kami dapat menghentikan semua kegilaan ini dan menutup semua proyek kami. Saya menduga itu tidak akan terjadi, meskipun. ;-)

Tugas # 2 adalah mencari tahu sekali dan untuk semua apakah script-concat selalu lebih baik daripada memuat paralel. Sekali lagi, premis saya (dan pengujian saya) menunjukkan bahwa menggabungkan semua file menjadi satu itu bagus, tetapi kemudian Anda harus memotong file besar itu menjadi 2-3 bagian yang kira-kira sama dan memuat potongan-potongan itu secara paralel. Jadi, kita benar-benar perlu menguji teori itu juga.

Jika kami menemukan bahwa script-concat selalu yang terbaik, sekali lagi, pemuat skrip masih berguna ketika Anda menganggap bahwa sebagian besar situs memuat skrip dari lebih dari satu lokasi (jquery dari Google CDN, google analytics dari google, tombol facebook/twitter/g+ , dll). Jadi kita perlu, sebagai tugas #3, menentukan apakah concat jauh lebih baik sehingga Anda harus meng-host salinan Anda sendiri dari semua file itu, menggabungkannya dengan kode Anda sendiri.

Kyle, dapatkah Anda melihat sumber contoh saya dan memberi tahu saya bagaimana saya akan menggunakan LabJS untuk mengeksekusi semua skrip pada halaman secara berurutan (bahkan di luar rantai)? Saya bisa saja salah membaca API (seperti yang dikatakan Paul, pemuat skrip sulit, %-).

Pada 10 Agustus 2011, pukul 09:09, [email protected] menulis:

@artzstudio--

Jadi, saya memulai proyek sains pemuat skrip saya sendiri (Boot.getJS) untuk menangani ini. Idenya adalah mengunduh semua skrip secara paralel dan menjalankannya secara berurutan, apa pun yang terjadi, sesegera mungkin

Jadi, apakah Anda sadar bahwa ini adalah _persis_ yang dirancang dan berfungsi dengan baik oleh LABjs (jika saya sendiri yang mengatakannya)? Maksud saya, apakah Anda hanya menginginkan API yang berbeda, atau bagaimana dengan fungsionalitas pemuatan skrip paralel yang tidak mencukupi?

---

Bagaimanapun, sebanyak saya suka membual tentang LABjs, saya tidak berpikir itu efektif untuk menghentikan utas ini dengan jenis diskusi "lihat, pemuat skrip saya lebih baik di X". Diskusi-diskusi itu berguna, tetapi di tempat lain.

Pada akhirnya, semua teknologi pemuat skrip bermuara pada beberapa ide sederhana. Apa pun jenis API mewah yang Anda lapisi di atasnya, atau kasus penggunaan apa yang Anda layani, teknologinya tetap sama. Pasti ada 50 pemuat skrip yang berbeda hari ini, dan sungguh, tidak satupun dari mereka memberikan sesuatu yang berbeda dalam hal teknologi, hanya API yang berbeda. Jadi, membandingkan API sebenarnya adalah diskusi yang agak tidak relevan.

Yang harus kita fokuskan adalah, dapatkah teknologi pemuatan skrip dasar yang saat ini kami miliki di browser digunakan untuk meningkatkan kinerja pemuatan halaman dibandingkan dengan hanya menggunakan tag skrip di markup. Ini adalah premis saya yang sudah lama dipegang bahwa itu sepenuhnya benar, tetapi premis itu telah dipertanyakan di utas ini. Jadi tugas #1 adalah menjawab pertanyaan itu.

Jika kami mengetahui bahwa tag skrip hanya lebih baik daripada pemuatan skrip, maka kami dapat menghentikan semua kegilaan ini dan menutup semua proyek kami. Saya menduga itu tidak akan terjadi, meskipun. ;-)

Tugas # 2 adalah mencari tahu sekali dan untuk semua apakah script-concat selalu lebih baik daripada memuat paralel. Sekali lagi, premis saya (dan pengujian saya) menunjukkan bahwa menggabungkan semua file menjadi satu itu bagus, tetapi kemudian Anda harus memotong file besar itu menjadi 2-3 bagian yang kira-kira sama dan memuat potongan-potongan itu secara paralel. Jadi, kita benar-benar perlu menguji teori itu juga.

Jika kami menemukan bahwa script-concat selalu yang terbaik, sekali lagi, pemuat skrip masih berguna ketika Anda menganggap bahwa sebagian besar situs memuat skrip dari lebih dari satu lokasi (jquery dari Google CDN, google analytics dari google, tombol facebook/twitter/g+ , dll). Jadi kita perlu, sebagai tugas #3, menentukan apakah concat jauh lebih baik sehingga Anda harus meng-host salinan Anda sendiri dari semua file itu, menggabungkannya dengan kode Anda sendiri.

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment -1772315

Orang akan berpikir Fisika mengatakan concat adalah yang terbaik. Setiap koneksi HTTP baru adalah awal yang lambat + pajak 100 ms dalam skenario kasus yang lebih buruk dari CDN.

Namun kebenaran tentang dokumen adalah bahwa mereka bisa sangat panjang. Jadi memuat satu file BFJS di kepala mungkin tidak perlu memperlambat inisialisasi modul. Memuatnya di akhir dapat menyebabkan FOUC yang mengganggu. Mungkin ada implikasi seluler untuk file besar: http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

Saya pikir ini adalah motif di balik aturan "membagi muatan" Souders ( http://oreilly.com/server-administration/excerpts/9780596522315/splitting-the-initial-payload.html). Kita juga perlu melakukan apa yang bisa terasa lebih cepat.

Dan sayangnya intinya adalah semacam jawaban "itu tergantung", yang membuat masalah ini cukup menarik untuk membuat kita semua terhibur.

Saya bermain-main dengan pendekatan hibrida di mana panggilan getJS diantrekan dan digabungkan secara berkala pada interval waktu yang ditentukan, serta menggabungkan pada tingkat ketergantungan modul (misalnya menggabungkan dependensi RequireJS alih-alih memuat satu per satu), semua dengan cepat di front-end.

Ini adalah eksperimen sains yang seperti yang Anda tunjukkan, mudah-mudahan akan segera menjadi sia-sia, tetapi tetap menarik.

@getify : Saya tahu bahwa ini cukup mengecewakan parade pada saat ini, tapi tetap saja.

Jika kami menemukan bahwa tag skrip lebih baik daripada pemuatan skrip,
maka kita bisa menghentikan semua kegilaan ini dan menutup semua proyek kita.
Saya menduga itu tidak akan terjadi, meskipun. ;-)

Saya dapat mengatakan banyak hal tentang minyak ular, tetapi demonstrasi juga akan berhasil:

http://jashkenas.s3.amazonaws.com/misc/snake-oil/labjs.html

http://jashkenas.s3.amazonaws.com/misc/snake-oil/vanilla.html

Itu adalah halaman dengan 100rb teks, 10 gambar, dan 171rb JavaScript. Versi vanilla menggunakan satu file yang diperkecil yang mencakup jQuery, jQuery-UI, Underscore, dan Backbone, serta file timer.js yang menuliskan hasil waktu buka. Versi LABjs memuat masing-masing dari 5 file JavaScript (diperkecil secara terpisah) menggunakan LABjs.

Anda akan menemukan bahwa tidak hanya tidak ada manfaat untuk versi LAB, tetapi permintaan HTTP tambahan hanya merusak kinerja pemuatan, dan harus bersaing dengan aset lain di halaman, seperti gambar. Tapi semua ini telah dikatakan berkali-kali sebelumnya...

Saya dapat mengantisipasi argumen balasan tentang memuat skrip Anda sedikit demi sedikit ... tapi itu sepenuhnya ortogonal dengan teknik memuat skrip, jadi tolong, tinggalkan dari diskusi.

Dengan segala cara, hentikan kegilaan itu.

@jashkenas Penuh, 100% ack. Pemuat skrip hanya menambahkan overhead dan komplikasi dan titik kegagalan. Satu file gabungan server dimuat dengan cepat, baik dalam hal waktu transfer murni dan dalam hal efisiensi penerjemah JavaScript, dan sebagai bonus, gzipping berfungsi lebih baik jika Anda hanya memiliki satu file.

Saya harus mengatakan, versi LABjs _sometimes_ memuat lebih cepat di browser saya (dibandingkan dengan halaman vanilla), tetapi tidak secara konsisten. Juga onload tidak selalu menyala, yang tampaknya... aneh.

Ya, gzipping memberi Anda lebih banyak kemenangan secara keseluruhan dengan lebih sedikit permintaan HTTP.

Dan ini bukan tentang dogma, ini tidak harus berupa _single_ file JS untuk seluruh aplikasi -- dua atau tiga dengan defer baik-baik saja untuk caching berbutir halus, seperti memuat lebih banyak nanti.

Beberapa penelitian oleh tim Google Page Speed:

http://pagespeed-velocity2011.appspot.com/#8 lihat slide 8-14, yang membuat diskusi lebih tidak meyakinkan

Saya masih tertarik pada atribut skrip @defer dan berpikir itu adalah default dasar yang bijaksana, kecuali jika Anda berencana untuk menghabiskan berjam-jam/hari dalam pengujian kinerja variasi Anda sendiri.

@miketylr : Ya, silakan geser-refresh setiap halaman berkali-kali untuk mendapatkan kesan keseluruhan. Latensi S3 dan pemuatan gambar akan membuat segalanya sedikit tidak terduga -- berperilaku lebih seperti aplikasi nyata.

Nah labjs _always_ memuat tercepat di browser saya (Safari 5.1) bahkan dengan shift-refresh atau ketika elemen di-cache.

Tentu saja menggunakan pemuat skrip tanpa penggabungan akan lebih lambat daripada tag skrip gabungan. Itu sebabnya orang (YUI, requireJS) membuat pemuat skrip yang memuat file dan layanan gabungan yang menggabungkannya berdasarkan permintaan (https://github.com/rgrove/combohandler).

Ayolah diskusi ini tidak masuk akal. Pemuat skrip adalah untuk memuat skrip sesuai permintaan, terutama setelah interaksi pengguna, misalnya memuat logika di balik dialog dan validasi formulir saat mengklik tombol "masuk".

Saya memiliki kecurigaan licik bahwa @jashkenas dan @madrobby terlalu menyederhanakan banyak hal.
Steve menyarankan pengunduhan paralel memiliki beberapa manfaat untuk berbagai masalah pemblokiran dan browser _(ya itu berarti non-WebKit)_. Dia juga menyebutkan strategi memuat JS minimum yang diperlukan untuk tugas-tugas dom-load dan kemudian memuat sisanya nanti sesuai kebutuhan. Karena situasi dan kebutuhan pengembang bervariasi, saya tidak tahu apakah pemuat skrip termasuk dalam boilerplate _(diaktifkan secara default)_ tetapi saya belum akan membuang bayi dengan air mandi dulu.

Jika tidak jelas di posting asli saya. Saya cenderung setuju (dengan jdalton) bahwa ada beberapa manfaat pemuat skrip di lingkungan yang sangat teruji dan spesifik yang memerlukan perhatian khusus. Saya tidak berpikir itu default yang sesuai.

Saya setuju dengan @jdalton : tidak ada loader size-fit-all. Saya pribadi menggunakan pemuat skrip yang berbeda tergantung pada kebutuhan dan proyek saya yang sebenarnya. Terkadang sesuatu yang sederhana seperti yepnope atau LabJS baik-baik saja, yang lain, RequireJS adalah anugerah. Saya tidak yakin boilerplate harus memaksanya masuk. Ini rumit karena idenya adalah boilerplate membuatnya mudah untuk beralih ke pemuat skrip... jadi saya tidak akan membuang bayi keluar dengan air mandi saja belum juga.

Juga, @getify , berpura-pura semua pemuat skrip benar-benar menggunakan teknologi yang sama di bawahnya adalah pernyataan yang sangat tidak tepat.

Untuk apa itu layak...
ini

var script = document.createElement('script')
script.src = 'foo.js'
document.getElementsByTagName('head')[0].appendChild(script)

lebih baik dari ini

<script src="foo.js"></script>

untuk satu alasan utama bahwa itu adalah non-blocking. Dengan demikian, gambar dan file CSS berikutnya perlu menunggu hingga file tersebut diunduh dengan versi terakhir. Yang pertama, adalah async — Ini, semua orang harus tahu terlepas dari apakah Anda memutuskan untuk menggunakan pemuat skrip atau tidak.

re: "berpura-pura semua pemuat skrip benar-benar menggunakan teknologi yang sama di bawahnya adalah pernyataan yang sangat tidak tepat."

Jika mereka tidak melakukannya dengan cara di atas, mereka melakukannya dengan salah

Agar adil, menggunakan appendChild tidak disukai... :D

Namun, saya menambahkan test case itu ke AssetRace

https://github.com/SlexAxton/AssetRace/blob/master/asyncconcat.html

Itu membuat onload api lebih cepat, jadi _bisa_ ada beberapa manfaat yang dirasakan. Tapi waktu finisnya hampir sama...

@ded : Kami tidak berbicara tentang pemblokiran besar yang tidak kompeten pada <script> di <head> sini ... kami berbicara tentang tag skrip dengan defer atau async atribut, dimuat di akhir <body> , di mana tidak ada yang tersisa untuk diblokir.

@jaubourg--

Juga, @getify , berpura-pura semua pemuat skrip benar-benar menggunakan teknologi yang sama di bawahnya adalah pernyataan yang sangat tidak tepat.

Ini adalah representasi yang salah dari apa yang saya maksud. Faktanya, sebagian besar pemuat skrip TIDAK melakukan hal-hal yang menurut saya seharusnya mereka lakukan (dan itulah LABj sekarang) dalam hal menggunakan teknologi terbaik. Maksud saya adalah, bahkan jika mereka semua menggunakan teknologi terbaik, masih ada batasan terbatas untuk apa yang dapat kita lakukan dari segi teknologi. Saya cukup yakin tidak ada pemuat di luar sana yang menggunakan peluru perak ajaib yang LABjs tidak sadari atau tidak gunakan. Anda tidak bisa membuat cahaya bergerak lebih cepat dari kecepatan cahaya, tidak peduli apa yang Anda lakukan atau bagaimana Anda mengutak-atik angka.

Berdebat tentang teknologi di bawahnya (dengan mengatakan "hei, lihat API saya yang keren dan lebih baik") tidak ada gunanya. Teknologi terbaik dalam pemuatan skrip adalah jumlah terbatas yang diketahui (bahkan jika banyak pemuat tidak bertanggung jawab dan tidak menggunakannya). Kami dapat mendorong untuk teknologi yang lebih baik (yang saya), tetapi memperdebatkan siapa yang memiliki API yang lebih baik pada pemuat mereka tidak menghasilkan apa-apa untuk tujuan itu.

Utas ini tampaknya benar-benar memiliki poin paling penting dalam mencoba menentukan apakah tag skrip cukup baik dengan sendirinya (dengan atau tanpa penundaan) atau jika pemuat skrip membantu mendapatkan kinerja yang lebih baik. Kedua, kita perlu mencari tahu apakah concat benar-benar akhir dari semua pemuatan skrip.

Ini juga merupakan poin diperdebatkan (untuk utas ini) bahwa pemuat skrip memiliki semua kasus penggunaan lain yang dapat mereka lakukan, yang tidak dapat dilakukan oleh tag skrip markup (seperti sesuai permintaan/pemuatan malas). Sekali lagi, itu pada dasarnya diberikan pada saat ini, jadi mencoba membangun kembali fakta itu tidak ada gunanya.

TIDAK U

BEBAN KEMARAHAN!

Lihat postingan asli di sini.

Juga, setiap ppl/orang yang tersinggung oleh penis kartun: selamat datang di internet! Saya sangat menyarankan Anda memulai perjalanan Anda di sini .

Oke, saya telah membuat 3 tes untuk mengilustrasikan beberapa poin. Pertama, tag skrip manual (sebagai garis dasar):

http://labjs.com/dev/test_suite/test-script-tags.php

Perhatikan bahwa DOMContentLoaded (alias, "DOM-ready") datang terlambat, setelah skrip selesai. Ini adalah yang buruk. Meskipun waktu muat halaman yang sebenarnya mungkin sama dengan pengujian selanjutnya, waktu muat halaman yang dirasakan akan selalu jauh lebih lambat jika DOM-ready diblokir (begitu banyak situs menunggu hingga DOM-ready untuk melampirkan perilaku klik, menerapkan peningkatan berbasis JS ke konten, dll).

Sekarang, yang terjadi adalah kita menggunakan defer pada tag skrip kita:

http://labjs.com/dev/test_suite/test-script-defer-tags.php

Yah, itu bagus, kami telah memperbaiki masalah penundaan DOMContentLoaded, tetapi sekarang kami memiliki masalah lain. Blok skrip sebaris tidak berfungsi dengan defer . Ini segera dieksekusi. Ups. BTW, ini bukan bug, spesifikasi secara khusus menentukan ini.

http://labjs.com/dev/test_suite/test-LABjs.php

Pengujian LABjs pada dasarnya mendapatkan angka kinerja yang sama (atau lebih baik) dibandingkan dengan pengujian defer , tetapi tidak gagal untuk menjalankan kode sebaris setelah skrip selesai.

Coba tes tersebut beberapa kali di browser modern (Chrome 13, FF5, dll). Bagi saya, LABjs selalu tampil hampir sama atau lebih baik untuk pengujian defer . Dalam semua upaya saya, saya belum pernah melihat LABj berkinerja lebih buruk daripada tes defer . Coba tes tersebut di browser lama (seperti FF3.5 atau IE7), dan Anda akan melihat bahwa pemuat skrip mulai mengungguli tes lain dengan jumlah yang nyata.

Meskipun tes LABjs memiliki angka yang mirip dengan tes defer di browser terbaru, itu adalah deal breaker jika defer tidak dapat digunakan untuk kode defer ALL (hanya berfungsi untuk kode yang dimuat melalui file eksternal). BANYAK situs memuat skrip dan kemudian memiliki kode sebaris untuk mengaktifkan/memulai kode yang baru saja mereka muat. defer memberi kami solusi untuk ini.

Oleh karena itu, defer tidak cocok sebagai teknologi "pemuatan skrip umum". Opsi terbaik berikutnya adalah pemuat skrip.

@getify

Ini tidak semua tentang optimasi mikro... dan, YA, API itu penting dan umumnya merupakan indikasi yang baik dari jenis keterbatasan yang dimiliki teknologi yang mendasarinya, terutama karena optimasi mikro (atau bahkan makro) tersebut. Ini tidak selalu hanya tentang memuat skrip. Manajemen ketergantungan yang kompleks, sandboxing yang tepat, dan modularitas aktual, nyata, bukanlah sesuatu yang harus dihapus hanya karena Anda tidak tertarik padanya. Tebak apa? Ini sebenarnya adalah hal-hal yang dibutuhkan orang dan kinerja pemuatan halaman dapat dicapai pada tingkat yang cukup baik dengan tag skrip statis.

Akhirnya semua bermuara pada injeksi tag skrip bukan alat yang tepat untuk tugas itu: sebenarnya tidak pernah ada. Ini hanya peretasan yang sangat jelek. Dalam hal itu, Anda sebenarnya tidak mendorong untuk teknologi yang lebih baik : Anda mendorong lebih banyak hal yang sama dengan jenis peringatan baru yang belum dapat kami simpulkan. Tolong, pikirkan sejenak dan lihat apakah itu akhirnya berbunyi klik.

Apa yang benar-benar menyebalkan adalah Anda menolak untuk mengeluarkan satu argumen yang mendukung injeksi tag skrip sebagai lawan dari API javascript asli yang tepat untuk pemuatan skrip. Anda hanya mengabaikan semuanya. Saya akan menyelamatkan Anda dari masalah: tidak ada argumen di sana. Tapi, heh, kita semua dapat melakukan masturbasi mental tentang seluk beluk defer dan async dan merasa seperti kita adalah dewa javascript, bukan? Atau berdebat tentang pengoptimalan 50 md seolah-olah itu benar-benar membantu siapa pun di industri ini.

Jika Anda akhirnya memutuskan bahwa saya cukup layak untuk mendapatkan balasan yang cerdas (sebagai lawan dari iklan LabJS lainnya), lakukanlah di blog saya dan biarkan utas ini saja. Terima kasih.

@jaubourg --
Saya membaca posting Anda secara mendalam tadi malam. Saya berencana untuk menulis posting blog sebagai tanggapan, sebagian besar memuji dan memuji Anda atas pemikiran bagus yang Anda sajikan di sana. Sayangnya, apa yang Anda sarankan telah di-hash oleh anggota utas diskusi di W3C dan WHATWG. Anda cukup terlambat ke pesta itu.

Ada beberapa orang yang mendukung API pemuat yang benar-benar baru, dan ada beberapa argumen tandingan yang penting mengapa itu bukan cara terbaik untuk dilakukan. Sekali lagi, saya berencana untuk menulis tanggapan kepada Anda dalam posting blog yang cermat dan masuk akal, untuk membantu menjelaskan semua itu.

Sayang sekali Anda harus pergi dan menjadi seperti orang brengsek di sini. Sekarang saya merasa bahwa posting blog yang beralasan itu hanya akan membuang-buang waktu. Anda jelas berpikir saya idiot dan tidak pernah mempertimbangkan hal-hal yang Anda coba kemukakan. Karena saya belum menghabiskan sebagian besar tahun lalu untuk benar-benar terobsesi dengan teknologi pemuat skrip dan cara mendapatkan spesifikasi dan browser untuk membuatnya lebih baik. Ya, aku idiot. Saya jelas tidak pernah memikirkan apa pun selain tag skrip sebelumnya.

Anda tampaknya tidak mendengarkan 15 kali saya mengatakan bahwa utas _this_ memiliki tujuan yang lebih baik untuk berfokus pada pertanyaan spesifik yang diajukan oleh Paul Irish dan Alex Sexton: apakah defer cukup baik? apakah script-concat lebih baik daripada memuat paralel?

Itu adalah pertanyaan-pertanyaan yang lebih penting.

Bukan apa yang mendasari teknologi "loader" yang digunakan. Ada forum yang berbeda dan lebih baik untuk membahas apa itu teknologi loader yang mendasarinya. Saya mengerti, Anda tidak suka tag skrip. Bagus. Habiskan puluhan jam di daftar W3C/WHATWG mencoba membuat Ian dan orang lain mendengarkan Anda. Mereka mungkin semua hanya akan menguap dan berkata, "Kami sudah membicarakannya, pergilah."

@getify : Membuat tes strawman yang konyol tidak akan memberimu poin, sobat. Kita semua tahu bahwa tag skrip berurutan memblokir halaman. Kami juga tahu bahwa menjalankan blok skrip sebaris sebelum skrip "ditunda" sama sekali bukan masalah untuk situs nyata.

Jika Anda menguji untuk mengkonfirmasi pra-kesalahpahaman ... tes Anda akan selalu mengkonfirmasi kesalahpahaman itu. Perdebatan tidak pernah tentang 20 tag skrip vs 20 beban skrip LABjs. Ini tentang memangkas, menggabungkan, mengecilkan, membuat gzip, dan memuat JavaScript Anda dalam permintaan HTTP sesedikit mungkin, dan kemudian menyimpannya dalam cache.

Di satu sisi, kami memiliki pendekatan yang andal, didukung browser, dan teruji waktu, yang berkinerja lebih baik di halaman dunia nyata; dan di sisi lain, kami memiliki "teknologi" yang diretas bersama yang di masa lalu benar-benar merusak setiap situs yang menggunakannya setelah pembaruan browser, yang kinerjanya rata-rata terbukti lebih buruk, dan dengan varian kelambatan yang jauh lebih besar.

Ini adalah pilihan tanpa otak.

@jashkenas--

Kami juga tahu bahwa menjalankan blok skrip sebaris sebelum skrip "ditunda" sama sekali bukan masalah untuk situs nyata.

Uhh... Saya kira Anda belum melakukan view-source di sekitar 98% dari semua situs di internet, yang sebenarnya menggunakan blok skrip inline di markup untuk mengeksekusi/menginisialisasi kode yang mereka muat sebelumnya (pemblokiran) panggilan tag skrip.

Jika @paulirish menyarankan bahwa defer cukup baik dan pemuat skrip tidak diperlukan, maka saya merasa penting untuk menunjukkan mengapa, pada kenyataannya, defer TIDAK cukup baik.

ANDA mungkin hanya peduli dengan beberapa situs niche yang Anda kendalikan, yang Anda memiliki kemampuan lengkap untuk sangat dioptimalkan tentang proses pembuatan, dll. Di sisi lain, saya peduli untuk membantu meningkatkan kinerja di situs-situs berekor panjang internet, yang dengan setengah lusin tag skrip (beberapa di antaranya adalah blok skrip sebaris!), di mana menggunakan setengah lusin panggilan $LAB.script() sebenarnya akan meningkatkan kinerja. Itulah yang selalu tentang LABjs. Hanya karena itu bukan yang Anda pedulikan bukan berarti itu tidak relevan.

Perdebatan tidak pernah tentang 20 tag skrip vs 20 beban skrip LABjs.

Perdebatan di utas ini adalah tentang apakah 3-4 tag skrip (dengan atau tanpa defer ) berkinerja lebih buruk, sama, atau lebih baik daripada 3-4 skrip yang dimuat secara dinamis menggunakan pemuat skrip paralel. "Tes strawman konyol" saya sebenarnya dimaksudkan untuk menguji hal itu.

Dalam pengalaman saya, pemuat skrip memangkas banyak milidetik dari waktu buka halaman. Tapi saya pikir kita semua kehilangan poin di sini. JavaScript memiliki beberapa masalah yang lebih besar:

• Kurangnya pernyataan impor membuat sulit untuk mengatur kode Anda secara modular
• Variabel global bertabrakan, kecuali jika banyak perhatian diberikan pada penspasian nama yang cermat dari semuanya.
• Tidak ada cara untuk melihat dengan jelas apa itu dependensi skrip

Saya tidak menggunakan RequireJS karena memuat lebih cepat, meskipun itu adalah efek samping yang bagus. Saya menggunakannya sehingga saya dapat mengatur aplikasi JS saya menjadi modul kecil seperti yang saya lakukan di NodeJS. Setiap modul dengan jelas mencantumkan dependensinya, dan menggunakan pola kotak pasir untuk menjaga namespace global tetap bersih. Modul (dan dependensinya) dapat dimuat di depan, atau dimuat sesuai permintaan (misalnya saat pengguna mengklik), atau dimuat lambat. Anda benar-benar dapat menyempurnakan kinerja Anda dengan teknik ini. Dan RequireJS juga dilengkapi dengan alat build yang menggabungkan dan memperkecil semua dependensi menjadi satu (atau beberapa) file siap pakai gzip untuk penerapan. Memecahkan tiga masalah ini adalah kemenangan besar bagi saya.

Saya dapat melihat mengapa orang berdebat tentang menggunakan pemuat skrip yang tidak menyelesaikan masalah ini. Jika kinerja adalah satu-satunya poin, dan itu bisa diperdebatkan, maka tentu saja. Tetapi gunakan pemuat modul AMD seperti RequireJS dan perdebatan menjadi tidak relevan. Modul adalah masa depan JavaScript. Dave Herman dari Mozilla bekerja dengan anggota dewan dari Apple dan Google untuk menambahkan modul asli ke bahasa itu sendiri . Tetapi sementara itu kita bisa mendapatkan semua manfaat dengan menggunakan pemuat modul AMD. Ini bukan hanya tentang kinerja.

@getify

Anda tidak dapat mengharapkan orang untuk memperlakukan Anda secara berbeda dari yang Anda lakukan pada orang lain. Menggurui bukanlah cara cerdas untuk mendapatkan reaksi yang layak (dan Tuhan apakah Anda menggurui) dan, seperti yang saya katakan di posting blog saya, saya tidak berpikir Anda idiot, saya hanya berpikir Anda terobsesi (yang Anda katakan diri sendiri btw) dan itu sangat merusak penilaian Anda. Seperti yang saya katakan di posting blog saya, bukan W3C atau WHATWG untuk menangani masalah ini tetapi EcmaScript sendiri: ini bukan masalah browser, ini masalah bahasa. Sekarang, jangan membuat balasan ini jika Anda tidak mau, itu hak prerogatif Anda.

Mungkin saya datang dengan kasar tetapi saya hanya mempertahankan apa yang saya yakini.

Saya akan berhenti berlangganan dari utas ini dan mengomentarinya lagi. Maaf telah menggagalkan hal-hal @paulirish dan @SlexAxton.

@getify

ANDA mungkin hanya peduli dengan beberapa situs niche yang Anda kendalikan, yang Anda miliki
kemampuan lengkap untuk sangat dioptimalkan tentang proses pembuatan, dll. Saya di
sisi lain peduli tentang membantu meningkatkan kinerja di situs ekor panjang
internet, yang memiliki setengah lusin tag skrip (beberapa di antaranya skrip sebaris
blok!), di mana menggunakan setengah lusin panggilan $LAB.script() sebenarnya mungkin
meningkatkan kinerja. Itulah yang selalu tentang LABjs. Hanya karena
bukan itu yang Anda pedulikan bukan berarti itu tidak relevan.

Jika LABjs adalah tentang membantu situs biasa-biasa saja memuat sedikit lebih buruk ... itu tujuan yang mulia, saya kira. Tetapi jika Anda serius ingin mengambil situs web yang memuat lambat, dan memuatnya secepat mungkin -- berpotensi secara harfiah beberapa detik lebih cepat daripada yang diizinkan LABjs, maka Anda harus tetap berpikiran terbuka dan mengakui bahwa semakin mudah dan tidak rapuh teknik juga lebih performan.

Perdebatan di utas ini adalah tentang apakah 3-4 tag skrip (dengan atau tanpa penundaan)
berkinerja lebih buruk, sama, atau lebih baik dari 3-4 skrip yang dimuat secara dinamis menggunakan
pemuat skrip paralel. "Tes manusia jerami yang konyol" sebenarnya dimaksudkan untuk
menguji persis itu.

Perdebatan di utas ini adalah tentang bagaimana membangun situs web untuk memuat dan menjalankan JavaScript-nya secepat mungkin. Menjual minyak ular ke klien, dan mempromosikannya ke pengembang web, merugikan keduanya.

Latensi ada di internet. Gabungkan, perkecil, dan gzip JS Anda, dan muat di bagian bawah halaman dalam permintaan HTTP sesedikit mungkin. kata Nuf.

@jashkenas--

Jika LABjs adalah tentang membantu situs biasa-biasa saja memuat sedikit lebih buruk ... itu tujuan yang mulia, saya kira

Ada ratusan situs yang saya ketahui secara pribadi dari 2 tahun terakhir yang tidak melakukan apa-apa selain mengganti tag skrip mereka dengan panggilan $LAB.script() , dan secara keseluruhan mereka semua melihat kinerja yang lebih baik (beberapa secara drastis, beberapa hanya sedikit).

Ada artikel yang ditulis (benar-benar independen dan tidak terhubung dengan saya) yang berfokus untuk membantu situs di berbagai industri (seperti e-niaga, real estat, dll.) mendapatkan kinerja yang lebih baik (karena kinerja yang lebih baik berarti lebih banyak konversi), di mana artikel tersebut direkomendasikan ke situs yang mereka mengganti tag skrip dengan panggilan $LAB, dan banyak orang di utas komentar tersebut telah menanggapi dengan setuju bahwa itu membantu mereka.

Seandainya artikel itu mengatakan "Oke, yang perlu Anda lakukan untuk mendapatkan kinerja lebih adalah menyewa admin server yang mengerti gzip dan dapat menginstal Ruby atau node.js sehingga Anda dapat melakukan beberapa proses pembuatan otomatis ......" orang-orang itu membaca artikel-artikel itu akan menjadi berkaca-kaca dan pergi tanpa memikirkannya lagi. Tapi saya suka percaya bahwa "Hei, ganti <script> dengan script()" adalah pesan yang cukup mudah untuk mereka pahami dan hubungkan.

Apa yang saya inginkan untuk LABjs adalah solusi sederhana dimana seseorang dapat dengan mudah masuk untuk mengganti tag skrip mereka tanpa terlalu banyak berpikir. Saya menyadari bahwa jika Anda secara pribadi dapat berkonsultasi dengan sebuah situs dan mencari tahu pengoptimalan terbaik, Anda dapat memeras lebih banyak kinerja dari banyak situs. Tetapi saya juga menyadari bahwa ini jauh di luar kemampuan saya sebagai satu orang yang harus dilakukan untuk ekor panjang internet, dan dengan cara yang sama memberi tahu semua situs ibu & pop itu "hei, dapatkan sistem pembuatan otomatis, dan pastikan itu menggunakan gzip" seperti berbicara bahasa asing kepada mereka. OTOH, sudah cukup berhasil untuk mengatakan "Hei, ambil 3 tag skrip itu, dan buat mereka 3 skrip() panggilan. Lihat betapa mudahnya itu?"

Intinya, pendekatan saya dengan LABjs adalah untuk mencapai hasil yang tergantung rendah.

Tidak satu pun dari itu yang menyarankan bahwa pendekatan yang lebih canggih untuk pengoptimalan tidak mungkin -- mereka jelas ada, dan ketika saya mendapat kesempatan untuk berkonsultasi, saya pasti menjelajahinya. Itu hanya untuk mengatakan bahwa untuk banyak web, itu lebih terlibat/rumit daripada yang mereka mau atau bisa dapatkan. Dan saya hanya mencoba membantu _situs_ itu berkembang dengan cara yang lebih mudah dipahami oleh mereka.

@jashkenas--

berpotensi secara harfiah beberapa detik lebih cepat daripada yang diizinkan LABj, maka Anda harus tetap berpikiran terbuka dan mengakui bahwa teknik yang lebih mudah dan tidak terlalu rapuh juga lebih berkinerja.

Tidak pernah ada bukti kuat yang menunjukkan bahwa LABjs secara signifikan memperlambat situs mana pun. Ada BANYAK bukti mapan bahwa itu membantu banyak situs. Jadi saya tidak percaya ini -- apa yang Anda bicarakan adalah premis yang salah dengan asumsi fakta bukan bukti.

@paulirish menemukan posting yang menunjukkan masalah dengan atribut defer :
http://hacks.mozilla.org/2009/06/defer/

Berasal dari perspektif kinerja seluler -- seperti yang dikatakan @jashkenas , selalu lebih baik untuk menggabungkan, gzip, dan mengirimkannya melalui jalur sebagai satu paket daripada memiliki beberapa permintaan http karena latensi yang ditimbulkan oleh koneksi jaringan 3g.

Ada banyak penelitian yang dilakukan dalam memanfaatkan teknik inlining di mana Anda base64 menyandikan gambar ke dalam string kemudian menyimpannya sebagai pasangan kunci:nilai di localStorage hanya untuk mengurangi permintaan http dan memanfaatkan 'caching': http://channel9.msdn.com/Events /MIX/MIX11/RES04 adalah presentasi yang bagus oleh James Mickens dari Microsoft Research.

Inilah dek yang cukup bagus tentang kinerja seluler dengan permintaan http dan pengaruhnya pada pengalaman pengguna: http://davidbcalhoun.com/present/mobile-performance/

Saya bekerja di RequireJS , dan saya ingin mengklarifikasi apa yang ingin dilakukan oleh RequireJS:

1) Tunjukkan cara untuk kode modular di JS yang berfungsi dengan baik di mana pun JS berjalan.
2) Memuat skrip.

Bagian "memuat skrip" adalah bagian penting untuk mencapai tujuan pertama. Di dev, bukan ide yang baik untuk hanya menggabungkan semua skrip Anda karena membuat debugging lebih sulit, nomor baris tidak cocok. Pemuat skrip juga memudahkan penggunaan JS API untuk memuat kode sesuai permintaan. Untuk aplikasi berukuran webmail, ini adalah bagian penting dari cerita kinerja. Namun, menggabungkan skrip menjadi satu atau sejumlah kecil permintaan biasanya merupakan opsi penerapan terbaik.

Tetapi tujuan dari requirejs adalah menjadi shim/polyfill/apa pun untuk menunjukkan cara membuat dan mereferensikan unit kode modular yang dapat dibagikan dengan orang lain dengan cara yang tidak mendorong global dan mendorong ketergantungan eksplisit.

Ini menggunakan API AMD yang telah dikerjakan dengan orang lain yang membuat pemuat skrip modular (termasuk tes kepatuhan ), dengan tujuan membantu menginformasikan diskusi apa pun untuk format modul di JS. Pendekatan ini, dengan membuat implementasi dunia nyata dan mencapai kesepakatan dengan orang lain di API adalah cara kemajuan dibuat.

Secara khusus, mengingat sifat jaringan JS dan hubungannya dengan dokumen/aplikasi web, API plugin pemuat adalah sesuatu yang harus didukung dalam beberapa cara dengan modul ES Harmony, dan saya sedang mengerjakan prototipe modul harmoni ES melalui a requirejs loader plugin , jadi saya bisa lebih memahami proposal harmoni dan memberikan umpan balik.

Untuk orang-orang kinerja :

• Ada beberapa pilihan untuk pemuat yang mendukung AMD ( curl , Dojo 1.7 , loadrunner , requirejs), bahkan yang sangat kecil yang dapat digunakan untuk pengoptimalan "semua skrip dalam satu file JS" yang dilakukan untuk penerapan. Jadi adalah mungkin untuk mendapatkan kinerja hebat sambil mendorong praktik pengkodean terbaik -- berbagi kode lebih mudah dengan menghindari global, menggunakan dependensi eksplisit.
• Pengoptimal requirejs berjalan sangat cepat di Node, dan dapat berjalan di Rhino. Ini adalah alat baris perintah, tetapi kode cabang master terbaru mengekspornya sebagai modul yang dapat digunakan di Node, jadi misalnya, dapat dijalankan melalui server http berbasis Node yang dapat melakukan build on the fly . Jadi Anda selalu dapat mengembangkan dalam mode "satu skrip unduh selalu" jika Anda mau, tetapi kemudian memilih untuk meninggalkan satu atau dua modul dari file yang dioptimalkan itu, sehingga Anda dapat dengan mudah men-debug mereka.

Dalam konteks tiket ini : memilih pemuat yang sesuai dengan AMD (tidak harus membutuhkan) sesuai dengan tujuan pelat boiler HTML: tunjukkan cara menuju praktik terbaik, baik dalam kode maupun dalam kinerja. Namun, saya menghargai mencoba mengerjakan boilerplate HTML adalah hal yang sangat sulit untuk dilakukan, ada minat yang bersaing, beberapa gaya, jadi saya menghargai tidak ingin membuat rekomendasi di area ini saat ini.

Saya hanya ingin memperjelas bahwa tujuan dari requirejs dan loader yang mengimplementasikan API AMD memberikan manfaat yang lebih besar daripada hanya memuat beberapa skrip yang membuang global dan memaksa pengembang untuk mengerjakan pohon ketergantungan yang lengkap, terkadang implisit. Tujuan tersebut dicapai dengan solusi yang memiliki profil kinerja yang solid.

Untuk memfokuskan kembali dari sebelumnya... membandingkan pengujian defer pengujian LABjs... (dan mengabaikan fakta bahwa defer tidak berfungsi pada blok skrip sebaris), apakah ada yang melihat bahwa Tes LABjs berkinerja lebih buruk daripada tes defer ? Saya sudah mencobanya di banyak browser, dan bahkan di perangkat seluler saya, dan masih melihat angka yang kira-kira sama.

http://labjs.com/dev/test_suite/test-script-defer-tags.php

http://labjs.com/dev/test_suite/test-LABjs.php

@getify

Saya tidak tahu mengapa atau bagaimana Anda dapat mengoptimalkan ini, tetapi saya memiliki, pada mesin MacBook saya yang berusia 3+ tahun, 3000 perbedaan yang konsisten antara keduanya, yang mendukung @defer .

Namun saya hanya menguji dengan Firefox.

@espadrine-- cukup aneh. akan senang untuk sampai ke bagian bawah itu. versi Firefox mana yang Anda uji? dapatkah Anda mengirim saya tangkapan layar hasilnya?

Cukup gabungkan dan perkecil semua JS dan CSS Anda dan sebariskan tepat di halaman HTML Anda dan selesaikan. Permintaan HTTP tunggal FTW! :P

Serius, ada begitu banyak masalah yang lebih besar yang harus kita fokuskan di komunitas ini daripada hanya bagaimana aplikasi Anda akan dimuat. Kemungkinannya, metode paling sederhana (tag skrip di bagian bawah) mungkin cukup cepat. Cukup tulis aplikasi hebat dan selesaikan kinerja pemuatan di akhir. Melakukan hal lain adalah pengoptimalan sebelum waktunya.

Apakah ada konsensus umum oleh orang-orang di utas ini bahwa AMD harus menjadi standar emas untuk organisasi kode JS? Belum benar-benar melihat opsi lain tetapi saya setuju Boilerplate akan menjadi awal yang baik untuk mengatur orang-orang dengan benar dalam mengatur kode.

Saluran pembaruan Firefox UX 8.0a1 (2011-08-07).

Sekali lagi, tidak tahu mengapa, dan ini mungkin sangat spesifik. LABjs mungkin sangat bagus dengan browser lawas.

Tolong jangan gunakan halaman pengujian @getify untuk hal lain selain tertawa. Kutipan:

<script defer src="http://labjs.xhr.me/dev/test_suite/testscript1.php?_=4911710&delay=5"> <script defer src="http://labjs.xhr.me/dev/test_suite /testscript2.php?_=6146431&delay=3"> <script defer src="http://labjs.xhr.me/dev/test_suite/testscript3.php?_=9499116&delay=1">

@getify, jika Anda ingin membuat tes yang sesungguhnya, jangan ragu untuk garpu @SlexAxton 's AssetRace repo dan menambahkan versi LABjs ... atau membuat halaman pengujian yang menggunakan _real_ file JavaScript, dengan latency nyata.

Juga, pastikan Anda benar-benar menggabungkan JS untuk satu tag skrip -- defer atau tidak. Intinya adalah bahwa konten yang sama yang disajikan melalui 1 permintaan HTTP mengalahkan konten yang sama yang disajikan di 10 permintaan HTTP.

Tidak pernah ada bukti kuat yang menunjukkan bahwa LABjs secara signifikan
memperlambat situs mana pun. Ada BANYAK bukti kuat bahwa itu banyak membantu
dari situs. Jadi saya tidak membeli ini -- apa yang Anda bicarakan adalah asumsi asumsi yang salah
fakta tidak dalam bukti.

Apa yang ditunjukkan di atas , adalah bahwa LABjs memang memperlambat situs secara signifikan, dengan membuat JS mereka bersaing di banyak permintaan HTTP dengan gambar, CSS, dan aset lainnya. @getify : Saya ingin melihat tautan ke situs yang menurut Anda sangat ditunjukkan dari konversi Anda ke LABjs. Mungkin kami dapat mengunduh salinannya, dan menggunakannya sebagai kasus uji yang akan Anda hormati.

Sebagai catatan, saya pikir akan lebih bijaksana untuk mendapatkan lebih banyak gambar di halaman pengujian repo AssetRace. Tapi itu pasti dasar yang bagus sekarang.

@artzstudio mengatur JS Anda dengan pemuat AMD memang merupakan standar emas, setidaknya sampai modul Harmony selesai dan didukung secara luas. Kemudian akan ada jalur migrasi yang jelas dari modul AMD ke modul Native.

Modul AMD menjadi standar emas tentu saja merupakan pendapat (yang mungkin saya bagikan). Namun, ada banyak orang pintar (Yehuda Katz dan Dan Webb muncul dalam pikiran) yang tidak menyukainya dan menawarkan solusi lain.

@danwrong 's loadrunner dapat melakukan keduanya, jika itu tas Anda juga: https://github.com/danwrong/loadrunner

Beberapa barang bagus di sana. Berpotensi sedikit lebih praktis untuk orang non-JS juga. Saya suka modul AMD untuk barang-barang saya, tetapi tidak semua orang ingin menghabiskan waktu untuk mengubah setiap versi perpustakaan yang mereka gunakan menjadi modul.

Saya tahu @strobecorp sedang mengerjakan solusi mereka sendiri yang tidak memerlukan banyak kode tambahan yang dibutuhkan modul AMD.

Meskipun saya ingin AMD menjadi default, itu mungkin tidak bijaksana dari sudut pandang multi-perpustakaan/newb, sebanyak yang saya inginkan.

@jashkenas--

Tolong jangan gunakan halaman pengujian @getify untuk hal lain selain tertawa.

Jika Anda tidak bisa bersikap sopan, saya tidak punya keinginan untuk membahas lebih lanjut dengan Anda. Saya bertindak dengan itikad baik. Saya akan menghargai sedikit kesopanan umum.

@getify , jika Anda ingin membuat tes nyata

Saya yakin ingin Anda menjelaskan mengapa apa yang saya lakukan sangat gila, menggelikan, dan tidak valid. Saya mengambil pendekatan langsung dari Steve Souders, yang (dalam pengalaman dan kebijaksanaannya yang luar biasa) menyarankan dalam semua pengujiannya agar Anda menggunakan waktu server untuk mengontrol skrip, mengurangi jumlah varians dalam pengujian Anda. Itulah yang saya lakukan.

Tes yang lebih terkontrol adalah tes dasar yang valid. Itu adalah praktik ilmiah yang mapan. Itu tidak berarti bahwa tes dunia nyata juga tidak berguna, tetapi itu juga tidak berarti bahwa Anda dapat menembak saya dan berkata "tertawakan dia, sungguh idiot karena dia melakukan tesnya secara berbeda dari yang saya pikir mereka lakukan. harus dilakukan."

merasa bebas untuk garpu @SlexAxton 's AssetRace repo dan menambahkan versi LABjs

Saya akan dengan senang hati melakukannya. Tetapi bukan karena saya setuju bahwa tes saya yang lain tidak valid. Jika Anda memiliki argumen yang masuk akal dan berkepala dingin tentang mengapa pengaturan pengujian saya tidak valid, silakan bagikan. Tapi berhenti menjadi seperti keledai tentang hal itu.

@jashkenas--

Intinya adalah bahwa konten yang sama yang disajikan melalui 1 permintaan HTTP mengalahkan konten yang sama yang disajikan di 10 permintaan HTTP.

Saya tahu Anda (dan yang lainnya) terus mengoceh di sini tentang bagaimana seharusnya diskusi ini tentang concat vs. non-concat. Jika Anda membaca lebih awal di utas, saya mengakui bahwa ada dua pertanyaan yang perlu ditangani. Kedua masalah itu, sejauh yang saya ketahui, orthagonal. Yang pertama adalah jika tag skrip di markup bisa sebagus (atau lebih baik) daripada elemen skrip dinamis yang digunakan dalam pemuat skrip paralel. PERTANYAAN ITU adalah apa yang saya masih coba atasi dengan tes saya.

Pertanyaan kedua, yang belum kita bahas, adalah apakah script-concat selalu lebih baik. Saya tahu Anda sudah yakin akan hal itu, tetapi saya memiliki bukti tandingan yang menunjukkan bahwa itu tidak sesederhana itu. Pertanyaan itu juga perlu diuji secara menyeluruh. Tapi bukan itu yang saya coba kerjakan sekarang di utas ini.

Dengan terus bersikeras bahwa cara Anda adalah cara yang lebih baik, Anda hanya membuat seluruh perdebatan menjadi kurang menyenangkan untuk menjadi bagiannya. Yang saya coba lakukan adalah secara metodis menetapkan beberapa bukti untuk masing-masing dari dua pertanyaan utama itu, sehingga kita dapat berhenti menebak dan menjadi lebih terinformasi. Mengapa itu bukan sesuatu yang bisa Anda bantu, daripada mencoba menjadi brengsek bagi saya karena Anda tidak setuju dengan saya?

Sehubungan dengan pengujian defer vs. pengujian LABjs, saya baru saja melakukan tangkapan layar cepat untuk menguji dua head-to-head di IE9, FF8(nightly), dan Chrome15(canary).

http://www.screenr.com/icxs

Untuk menjawab pertanyaan @paulirish sebelumnya (https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment-1765361) tentang kebiasaan defer , lihat bagaimana "DOMContentLoaded" berperilaku di IE, Chrome, dan Firefox dalam pengujian defer .

Di IE9 dan Chrome15, acara DOMContentLoaded ditahan (diblokir) dan tidak diaktifkan hingga skrip dijalankan. Namun, di FF, acara DOMContentLoaded tidak ditahan, langsung aktif, dan skrip mulai dijalankan setelahnya. Itu adalah inkonsistensi besar di seluruh browser modern, dan salah satu alasan mengapa menurut saya defer tidak cukup.

Sejauh yang saya tahu dari membaca spesifikasi, saya tidak yakin perilaku mana yang benar. Tapi saya tahu bahwa itu jelas aneh dan tidak konsisten di antara browser.

@getify Saya tidak mencoba menjadi brengsek. Saya dengan tulus meminta maaf karena telah menyakiti perasaan Anda.

Secara alami, apa yang Anda lihat sebagai ocehan, saya lihat sebagai titik diskusi ... dan apa yang saya lihat sebagai minyak ular, Anda lihat sebagai langkah maju yang bermanfaat.

Kedua masalah tersebut memang ortogonal (bahasa yang saya gunakan di posting asli saya).

Yang pertama adalah jika tag skrip di markup bisa sebagus (atau lebih baik) daripada
elemen skrip dinamis yang digunakan dalam pemuat skrip paralel.

Kami sepenuhnya sepakat tentang masalah ini -- tidak masalah. Tentu saja pemuatan paralel akan lebih cepat daripada pemuatan berurutan untuk lebih dari satu skrip. Dan tentu saja, melakukannya dengan cara yang tidak memblokir, baik di akhir tag <body> , atau dengan defer , atau dengan pemuat skrip, akan lebih baik daripada memblokir di <head> .

Tapi ini salah sasaran. Menempatkan tag skrip berurutan adalah hal yang sulit untuk dibandingkan, karena tidak ada orang yang peduli dengan kinerja JavaScript mereka yang akan menggunakan pendekatan itu. Tebak apa yang juga lebih cepat dari tag skrip berurutan? _Apa pun_.

Pertanyaan kedua, yang belum kita bahas, adalah tentang apakah
script-concat selalu lebih baik.

Kami telah "mendapat" pertanyaan ini. Faktanya, itu adalah pertanyaan @paulirish di bagian atas halaman ini. Jika Anda tidak mencoba menyelesaikannya di utas ini, Anda harus melakukannya. Itu menyerang inti dari semua klaim Anda tentang apa yang dilakukan LABjs, tidak hanya di utas ini, tetapi selama bertahun-tahun.

Pertanyaan itu juga perlu diuji secara menyeluruh.

Untuk mengulang sendiri, inilah kasus uji (adil). 5 skrip dunia nyata yang sama, memuat ke halaman berukuran sedang dengan aset lain yang ada, satu menggunakan praktik terbaik LABjs untuk memastikan urutan pemuatan, dan yang lainnya menggunakan satu skrip gabungan:

http://jashkenas.s3.amazonaws.com/misc/snake-oil/labjs.html

http://jashkenas.s3.amazonaws.com/misc/snake-oil/vanilla.html

Jika Anda memiliki kasus uji lain yang ingin Anda periksa, atau situs web dunia nyata yang menggunakan LABjs yang ingin Anda coba, silakan bagikan.

@SlexAxton Terima kasih. Saya ingin tahu mendengar pendapat Yehuda tentangnya dan pendapat kuat lainnya (selain terlalu sulit untuk diperbaiki). Saya menemukan ini tetapi bukan pembicaraan.

Untuk memperjelas komentar @geddesign : mulai hari ini sepertinya modul AMD dapat dikonversi dengan cukup mudah menjadi modul harmoni, tetapi proposal modul harmoni yang saya anggap masih dalam perubahan, itu bisa berubah nanti. Itu belum melalui pengujian implementasi yang ketat, tetapi mulai mendapatkan beberapa kaki di atasnya. Di sisi positifnya, AMD loader + plugin loader dapat memberikan umpan balik yang solid untuk mencoba beberapa ide harmoni.

Untuk komentar @SlexAxton :

Untuk loadrunner: tidak jelas bagi saya sintaksnya lebih baik, hanya berbeda. Ini mendukung AMD, jadi masih berfungsi.

Untuk strobo: Saya belum melihat kode dari mereka di atasnya. Mereka tampaknya cukup fokus ke dalam, meskipun saya menghargai pekerjaan yang telah dilakukan Yehuda untuk membuka perkembangan itu. Alex, jika Anda memiliki petunjuk tentang apa yang mereka pikirkan, saya akan menghargai untuk mendapatkannya.

Jika pendekatan akan memungkinkan dependensi bersarang (yang diperlukan untuk berbagi kode secara luas), Anda memerlukan sintaks yang:

• memberi nama pada unit kode
• cara untuk menentukan dependensi
• pembungkus fungsi di sekitar kode itu untuk memastikan itu tidak dijalankan sampai dependensi siap. Atau selalu mengamanatkan akses build atau XHR, yang tidak dapat diskalakan di seluruh spektrum pengembangan JS.

Inilah yang disediakan AMD, dan sintaksnya sangat tipis. Yang lainnya hanyalah memperebutkan nama dan mungkin beberapa jenis tanda baca. Pada titik tertentu sesuatu hanya perlu dipilih, dan sejauh ini saya belum mendengar dari Dan Webb atau Yehuda tentang kelemahan struktural yang membuat AMD tidak dapat dipertahankan. Beberapa pemuat AMD, seperti requirejs hanya dapat memuat skrip biasa, tidak harus berupa modul.

Sangat mudah untuk memikirkan sintaks kode, terutama untuk modul, dan saya dapat menghargai setiap orang memiliki preferensi pribadi mereka sendiri. Namun, AMD memiliki sejarah yang cukup dalam dalam melakukan kerja keras untuk mendapatkan semacam kesepakatan, dan yang lebih penting lagi, kode dan penerapan nyata untuk mendukungnya. Saya merasa tanggung jawab ada pada orang lain sekarang untuk benar-benar menjadi sangat jernih dan jelas mengapa AMD tidak cocok (tiket ini bukan tempatnya, jangan ragu untuk menghubungi saya di luar daftar, atau gunakan daftar implementasi amd ) .

Tapi saya menghargai pandangan @SlexAxton . Standarisasi pada pendekatan AMD untuk boilerplate HTML bisa jadi terlalu dini, dan saya setuju dengan itu. Jika proyek boilerplate memutuskan untuk memilih satu, AMD adalah pilihan kuat yang sesuai dengan spektrum pengembangan JS yang luas.

@SlexAxton aku bersamamu. Kode saya sendiri adalah AMD. Meskipun saya berharap semua orang menulis modul alih-alih skrip, untungnya RequireJS dapat memuat skrip biasa serta modul.

Jika Anda mengacu pada templating handlebars.js Yehuda, itu bekerja sangat baik dengan RequireJS. Terutama jika Anda menulis sebuah plugin yang mengkompilasi/men-cache template dan mengembalikan fungsi template-nya.

define(['tmpl!navigation.html'], function(nav){
   $('body').append(nav(data));
});

Namun saya tidak setuju dengan pernyataan ini:

Meskipun saya ingin AMD menjadi default, itu mungkin tidak bijaksana dari sudut pandang multi-perpustakaan/newb, sebanyak yang saya inginkan.

Pemula membutuhkan struktur bersih yang disediakan AMD bahkan lebih dari pengembang berpengalaman, karena mereka lebih rentan terhadap tabrakan variabel global, organisasi kode yang mengerikan yang mengarah ke file JS besar yang berantakan yang tidak ingin disentuh siapa pun karena takut harus berurusan dengan konflik gabungan, dll. Library sangat diuntungkan oleh modul, itulah sebabnya Dojo 1.7 dan Mootools 2.0 yang akan datang pindah ke AMD. Saya harap jQuery bergabung - salah satu keluhan terbesarnya adalah "semua atau tidak sama sekali". Anda tidak dapat menggunakan manipulasi DOM yang luar biasa tanpa juga memuat animasi, ajax, acara, dll. ke halaman juga. Jadi ya, AMD adalah win-win. Jika HTML5 Boilerplate ingin mengarahkan orang ke praktik terbaik, akan sangat disayangkan untuk mengabaikan AMD. Ini secara elegan memecahkan begitu banyak masalah JavaScript.

Untuk menjadi jelas. Saya setuju. Saya berharap mereka menggunakan membutuhkan sepanjang jalan.

Saya hanya tidak berpikir mereka akan melakukannya.

Saya rasa orang belum menyadari AMD adalah kata kunci, "hal" yang perlu diketahui oleh setiap pengembang serius. Begitu mereka melakukannya, mereka akan ingin mengatakan kepada bos mereka dan wawancara di masa depan bahwa mereka mengetahuinya dan menggunakannya.

Jika kita semua melakukan bagian kita dan berkata "lihat, itu mudah, dan lebih baik, dan penting" dan menjadikannya kata kunci, kawanan ternak akan mengikuti demi karier mereka.

@jashkenas--

Yang pertama adalah jika tag skrip di markup bisa sebagus (atau lebih baik) daripada elemen skrip dinamis yang digunakan dalam pemuat skrip paralel.

Kami sepenuhnya sepakat tentang masalah ini -- tidak masalah.

Sebenarnya, saya memulai partisipasi saya di utas ini dengan asumsi bahwa semua orang setuju bahwa pemuatan elemen skrip dinamis akan menghasilkan kinerja yang lebih baik daripada tag skrip. Tetapi baik @paulirish dan @slexaxton mempertanyakan asumsi itu di utas _this_.

@paulirish telah menyarankan bahwa defer adalah cara yang cukup untuk membuat tag skrip biasa sama baik (atau lebih baik) daripada alternatif pemuatan elemen skrip dinamis. Saya tidak setuju bahwa defer sudah cukup, dan sekarang saya telah menetapkan beberapa alasan mengapa.

Jadi, saya pikir itu sah bagi kita untuk memeriksa pertanyaan pertama, dan mengeksplorasi apakah defer lebih baik daripada pemuat skrip. Mungkin ada beberapa kasus terbatas di mana Anda dapat lolos dengan defer , tetapi sejauh kasus umum, pemuat skrip menangani/menormalkan semua kebiasaan, sedangkan defer menghadapkan Anda pada masalah tersebut.

Saya masih tidak yakin bahwa semua orang melihat atau setuju dengan mengapa defer tidak cukup.

Untuk mengulang sendiri, inilah kasus uji (adil). 5 skrip dunia nyata yang sama, memuat ke halaman berukuran sedang dengan aset lain yang ada, satu menggunakan praktik terbaik LABjs untuk memastikan urutan pemuatan, dan yang lainnya menggunakan satu skrip gabungan:

Ini adalah premis pengujian palsu Anda (dan orang lain). Saya tidak pernah mengklaim bahwa memuat 5 skrip alih-alih 1 akan lebih cepat. Tidak pernah. Pernah. Bisakah saya menjadi lebih jelas? Premisnya tidak pernah 5 vs 1.

Tes pertama adalah menguji 3 tag skrip vs 3 panggilan script() , karena itu adalah pengujian yang adil. Dan saya pikir video dan tes menggambarkan bahwa pemuatan skrip, dalam skenario ITU, bermanfaat.

Pertanyaan kedua, dan jauh lebih kompleks untuk diuji, adalah apakah ada cara untuk meningkatkan kinerja situs yang sudah memuat semua JS-nya dalam satu file. Kebanyakan orang mengatakan bahwa tidak mungkin untuk memperbaikinya. saya tidak setuju.

CATATAN: alasan pertanyaan ini ortagonal adalah karena Anda dapat memuat file concat tunggal ini dengan tag skrip, atau dengan menggunakan pemuatan dinamis tipe document.createElement("script") . Either way, pertanyaan tentang file concat tunggal adalah pertanyaan yang valid, tetapi terpisah dari apakah tag skrip atau pemuatan skrip dinamis lebih baik.

Apa yang Anda dengar saya katakan beberapa kali di utas ini, dan juga dalam banyak konteks lain (termasuk semua konferensi saya berbicara tentang topik, posting blog, dll), adalah bahwa saya pikir mungkin Anda dapat meningkatkan file JS tunggal concat pendekatan dengan "chunking" (yaitu membelah file concat besar) menjadi 2 atau 3 potongan (paling banyak). Jika potongan berukuran ~sama, dan dimuat secara paralel, maka mungkin halaman akan dimuat lebih cepat, bahkan dengan overhead HTTP tambahan, karena koneksi "Keep-Alive", efek pemuatan paralel, dll.

Sebenarnya saya sudah lama menulis tentang topik ini, jauh di bulan November 2009, tak lama setelah rilis pertama LABjs: http://blog.getify.com/2009/11/labjs-why-not-just-concat/

Dalam posting blog itu, dan sejak saat itu, saya telah mengatakan bahwa JIKA Anda berada dalam posisi (tidak semua orang ... sebenarnya, sebagian besar web tidak) menggunakan proses pembuatan untuk menyatukan, Anda harus melakukannya jadi. Periode. Selalu. Selalu gabungkan file dari 10-20 file lokal menjadi lebih sedikit.

TETAPI, saya juga mengatakan bahwa begitu Anda memiliki file concat tunggal itu, mungkin juga bermanfaat untuk mencoba dan memuat file tunggal Anda dalam 2-3 potongan, dimuat secara paralel (menggunakan pemuat skrip).

Mengapa ini bisa lebih baik? Saya menjelaskannya di posting blog itu, tetapi singkatnya:

1. efek pemuatan paralel adalah nyata. tanyakan kepada pengguna bit-torrent tentang hal ini. overhead HTTP juga nyata, dan bertindak untuk melawan, dan menghilangkan manfaat itu. Namun bukan berarti tidak mungkin mendapatkan keuntungan. Dengan menggunakan koneksi Keep-Alive, Anda mungkin bisa mendapatkan 2 atau 3 koneksi simultan (tanpa 2-3 penalti overhead koneksi penuh), dan memuat kode Anda dalam waktu yang lebih singkat. Apakah akan 1/3 waktu (60-70% lebih cepat) jika Anda memuatnya dalam 3 bagian? Tidak. Sama sekali tidak. Tapi mungkin 20-30% lebih cepat.
2. Menyajikan semua kode Anda dalam satu file mencegah Anda melakukan header cache yang berbeda untuk kode seumur hidup yang berbeda. Misalnya, jquery sangat stabil dan tidak perlu diunduh ulang. tetapi kode UX centric Anda di situs Anda mungkin sangat fluktuatif (Anda dapat mengubahnya sekali seminggu atau lebih). Melakukan header caching pendek pada file concat tunggal itu bodoh, karena memaksa pengunduhan ulang kode stabil yang lebih sering secara tidak perlu. Melakukan header caching panjang pada file concat tunggal juga bodoh, karena memaksa Anda untuk membatalkan file yang di-cache (param cache bust, dll) dan memaksa unduhan ulang penuh seluruh file, ketika Anda hanya men-tweak satu byte dari Anda kode yang lebih fluktuatif. Jadi, membagi file concat besar Anda menjadi 2 bagian, satu untuk kode stabil, satu untuk kode volatil, memungkinkan Anda memiliki header caching yang berbeda untuk setiap potongan. Hal ini membuat penggunaan cache menjadi lebih efektif, dan menghasilkan kinerja yang berpotensi lebih baik dari waktu ke waktu, karena pengguna berulang kali mengunjungi situs Anda.
3. Penelitian telah menunjukkan bahwa rata-rata, satu tampilan halaman menggunakan jauh lebih sedikit dari 100% JS yang dimuat di halaman (beberapa perkiraan menyebutkan sekitar 20-30% dari kode). Memuat semua kode Anda dalam satu kesempatan, sekaligus, pada awal pemuatan halaman, membuat baris menjadi padat untuk mendorong 70-80% file yang tidak diperlukan saat itu (dan mungkin "tidak pernah" diperlukan). Jika Anda memiliki kode dalam 2 bagian (satu yang merupakan kode yang lebih kritis dan yang lain kode yang kurang penting), dan Anda segera memuat potongan pertama, dan memuat potongan kedua beberapa detik setelah pemuatan halaman, Anda dapat mengosongkan pipa untuk gambar/css dan konten yang jauh lebih penting. Intinya, chunking memungkinkan Anda untuk memprioritaskan kode Anda.

Intinya... tentang topik concat vs. parallel... Saya _selalu_ memberi tahu orang-orang: keduanya.

@getify berkata dengan baik.

LABj Kyle mendapat dukungan saya.
Sebagai konsultan yang membantu situs meningkatkan kinerja, saya telah melihat LABj bekerja dengan baik berkali-kali.
Tidak hanya meningkatkan kinerja secara signifikan (tidak hanya 100 md, tetapi 1+ dtk), tetapi juga disukai oleh para pengembang.
Mudah dipahami, mudah diterapkan.

Dan saya akan mengambil kesempatan ini untuk secara terbuka mengatakan "Terima kasih Kyle, atas dukungan yang luar biasa di LABjs. Anda telah melampaui harapan saya beberapa kali."

Menggunakan koneksi Keep-Alive, Anda mungkin bisa mendapatkan 2 atau 3 koneksi simultan (tanpa 2-3 penalti overhead koneksi penuh)

HTTP tidak mux/interleave tanggapan, jadi Anda tidak dapat memiliki unduhan paralel tanpa membuka banyak koneksi terlebih dahulu. Kasus ideal koneksi persisten dan pipelined sama dengan pengunduhan satu file secara berurutan (+ beberapa header).

@pornel--

Saya telah melihat secara langsung dan memvalidasi bahwa browser dapat membuka banyak koneksi secara paralel ke satu server, di mana dengan Connection Keep-Alive sedang dimainkan, overhead untuk koneksi kedua dan ketiga secara drastis lebih sedikit daripada yang pertama. Itulah efek yang saya bicarakan.

@getify Fantastis, saya pikir kami telah mencapai semacam konsensus. Untuk menyegarkan ingatan Anda:

Saya dapat mengantisipasi argumen balasan tentang memuat skrip Anda sedikit demi sedikit ...
tapi itu sepenuhnya ortogonal dengan teknik pemuatan skrip, jadi tolong, tinggalkan saja
dari diskusi.

Ya, saya setuju bahwa memuat skrip volatil Anda dalam file JS yang berbeda dari skrip permanen Anda sangat bagus. Memuat skrip yang hanya diperlukan untuk halaman tertentu, hanya pada halaman tertentu itu, juga bagus.

Jadi jika saya seorang pengembang web dan saya memiliki halaman dengan sekumpulan JavaScript, apa yang harus saya lakukan? Gunakan LABjs, atau gabungkan skrip permanen saya ke dalam satu file, dan skrip volatil saya ke file lain, dan muat keduanya di bagian bawah tag tubuh dengan <script defer="true"> ?

Mengapa saya harus membuat aplikasi saya mengalami sakit kepala caching, browser yang tidak kompatibel, berpacu dengan gambar-di-halaman, dan masalah lainnya yang dibawa oleh pemuat skrip?

Jika seluruh premis menggunakan pemuat skrip untuk kinerja lebih mudah dan sederhana daripada menggunakan dua tag skrip ... Saya punya jembatan di Brooklyn untuk menjual Anda.

@getify telah mengimplementasikan server web lebih dari sekali: keep-alive tidak memengaruhi permintaan bersamaan dengan cara apa pun dan hanya mengurangi biaya permintaan berikutnya. Badan terpisah dengan dua permintaan berikutnya dengan keep-alive masih lebih mahal daripada satu permintaan. Memiliki dua permintaan bersamaan untuk dua bagian tubuh mungkin akan berkinerja lebih baik, tetapi perlu diingat bahwa browser hanya akan membuka sejumlah permintaan bersamaan (tergantung pada browser dan mengonfigurasi sekitar 5, saya pikir), yang baik-baik saja jika semua yang Anda lakukan adalah memuat tiga file js Anda, tetapi, seperti yang ditunjukkan @jashkenas lebih dari sekali, masalah jika Anda memiliki aset lain, seperti gambar atau file css.

@jashkenas-

Jadi jika saya seorang pengembang web dan saya memiliki halaman dengan sekumpulan JavaScript, apa yang harus saya lakukan? Gunakan LABjs, atau gabungkan skrip permanen saya ke dalam satu file, dan skrip volatil saya ke file lain, dan muat keduanya di bagian bawah tag body dengan <script defer="true">?

TL;DR: keduanya

Pertama, banyak situs di web yang dirakit oleh CMS, yang berarti bahwa blok skrip inline berserakan di seluruh halaman adalah hal biasa, dan SANGAT sulit untuk diselesaikan dari segi pemeliharaan dengan hanya mengatakan "pindahkan semua kode itu ke dalam satu file". Jadi, saya pikir premis bahwa _most_ situs dapat lolos tanpa memiliki "kode sebaris" untuk dijalankan setelah skrip eksternal lain memuat dan mengeksekusi tidak mungkin, paling banter.

Kedua, saya telah membuktikan bahwa defer bertindak berbeda sehubungan dengan DOMContentLoaded di berbagai browser. Di beberapa browser, skrip berjalan sebelum DOM-siap, di browser lain, mereka pergi setelah DOM-siap. Jika Anda memiliki kode dalam skrip yang bergantung pada kejadian sebelum atau setelah DOM-ready, menggunakan defer dapat menjadi masalah. Terutama benar bahwa ini adalah area sensitif dengan banyak kesalahpahaman dan kebingungan, sehingga dengan cepat menjadi "ini bukan solusi langsung yang sederhana". Dibutuhkan lebih banyak pemikiran.

Ketiga, saya pikir untuk banyak situs, mengubah markup mereka untuk menggunakan $LAB.script() daripada <script> jauh lebih mudah daripada menjelaskan kepada mereka cara menginstal beberapa proses bulid otomatis (atau manual) pada mereka server. Terutama jika situs itu menggunakan shared-hosting (sebagian besar web), dan mereka tidak benar-benar mengontrol banyak server mereka, meminta mereka untuk mencari tahu proses pembuatan sehingga pemeliharaan kode mereka tidak hilang adalah... yah. .. tidak sepele.

Apakah hal-hal tersebut dapat diatasi? Ya. Tentu saja mereka bisa. Tetapi mereka membutuhkan banyak pekerjaan. Dalam beberapa kasus (seperti hal yang DOM-siap) mereka mungkin benar-benar susah payah menyesuaikan kode Anda. Dibutuhkan seseorang dengan upaya berdedikasi dan banyak keahlian dan semangat di bidang ini untuk menyelesaikan semuanya.

Sebaliknya, mereka bisa mendapatkan "kemenangan cepat" di LABjs alih-alih tag <script> . Ada sedikit yang harus mereka pikirkan (kecuali document.write() ). Sebagian besar waktu, "itu hanya bekerja". Dan sebagian besar waktu, mereka melihat peningkatan kecepatan langsung dalam pemuatan halaman. Untuk sebagian besar situs, itu adalah kemenangan besar.

Jadi, untuk menjawab pertanyaan Anda, saya akan mengatakan, seperti yang saya katakan sebelumnya, lakukan keduanya ... Penurunan pertama di LABjs, lihat beberapa peningkatan kecepatan langsung. Sekarang, pertimbangkan dengan kuat manfaat menggunakan proses pembuatan untuk memindahkan Anda dari 15 file menjadi 2 file (1 file dipotong menjadi dua). Ketika Anda melakukan itu (jika Anda melakukan itu, yang seperti yang saya katakan, sebagian besar tidak), Anda dapat membuang LABjs jika Anda benar-benar menginginkannya. Tapi tidak ada salahnya (itu kecil dan cache dengan baik, bahkan di ponsel). Itu akan terus memuat dua potongan file Anda dengan baik, DAN itu akan melakukannya tanpa kebiasaan yang mungkin disebabkan oleh defer .

Selain itu, memiliki LABj yang sudah ada membuatnya sangat mudah bagi Anda untuk melakukan langkah 3, yaitu mulai mencari tahu kode apa yang dapat Anda "malas/beban sesuai permintaan" nanti. Anda tidak dapat melakukannya tanpa pemuat skrip. Memiliki LABj yang sudah ada dan familier berarti Anda tidak perlu khawatir tentang cara memuat skrip sesuai permintaan sama sekali -- ini sudah diketahui.

@rkh--

Saya telah menunjukkannya kepada saya (khususnya di Apache, dengan mengaktifkan pengaturan Keep-Alive) bagaimana beberapa permintaan paralel terpengaruh (secara positif ketika Keep-Alive ada di sana). Saya bukan ahli di bidang ini, jadi memperdebatkan detail pasti tentang cara kerjanya atau tidak adalah di luar jangkauan saya. Saya dapat mengatakan bahwa waktu permintaan # 2 lebih sedikit daripada waktu permintaan # 1, ketika Keep-Alive ada di sana. Bagaimana browser dan server melakukan itu, saya hanya bisa menebak-nebak.

Badan terpisah dengan dua permintaan berikutnya dengan keep-alive masih lebih mahal daripada satu permintaan.

Saya tidak pernah berargumen bahwa permintaan kedua itu gratis. Saya berpendapat bahwa permintaan kedua tidak semahal permintaan pertama. Jadi, jika kita berasumsi bahwa setidaknya satu permintaan harus dibuat, memiliki permintaan kedua secara paralel BUKAN hal yang sama dengan memiliki dua koneksi yang sepenuhnya independen ke server yang sama, dalam hal biaya overhead atau waktu.

Sebagai perkiraan, sepertinya Permintaan #1 adalah X untuk layanan, dan #2 secara paralel dengan hadiah Keep-Alive adalah 0,7X. Dijelaskan kepada saya bahwa server dapat memanfaatkan beberapa overhead koneksi yang ada dalam melayani permintaan kedua, sehingga membuatnya sedikit lebih murah. Dengan Keep-Alive dimatikan, permintaan kedua tidak memiliki penurunan yang terukur.

Semua diskusi ini adalah lubang kelinci yang sangat dalam. Saya bukan ahli server. Saya tidak harus. Saya hanya dapat menjelaskan bahwa saya telah benar-benar melihat (dan membuat tes) seputar topik yang tepat ini... dapatkah saya menguji waktu muat file 100k tunggal vs memuat dua bagian dari file yang sama secara paralel, dan apakah tes kedua dapat diukur jumlah lebih cepat. Seperti yang saya katakan, saya melihat, di suatu tempat antara 15-25% lebih cepat dengan tes chunked-in-parallel. Bagaimana melakukannya, dan entah bagaimana berhasil menyalip efek "OMG HTTP RESPONSE OVERHEAD IS TERRIBLE" yang mengerikan dan masih mendapat manfaat dari dua pemuatan paralel, saya kira saya tidak memenuhi syarat untuk membuktikan secara ilmiah. Tapi itu pasti dilakukan dengan observasi.

Astaga, kalian mengetik dengan cepat. Saya selesai membaca, memuat ulang halaman, dan ada sekitar sembilan komentar lagi.

Saya butuh bantuan. Saya telah mencoba untuk menunjukkan dengan tepat di mana di utas ini kita beralih dari membahas _apa yang terbaik untuk file HTML boilerplate_ untuk membahas _apakah pemuat skrip, dalam semua kasus, minyak ular_.

@getify , Anda tentu harus membela LABj dan menanggapi kritik khusus yang dibuat oleh orang lain di utas, tetapi (kecuali @jashkenas) saya pikir mereka yang mengkritik LABj melakukannya untuk menunjukkan bahwa itu bukan solusi terbaik untuk boilerplate. Anda berpendapat bahwa lebih mudah untuk mengonversi halaman lama ke LABjs daripada script[defer] , dan itu mungkin benar, tetapi bagaimana itu berlaku untuk file HTML boilerplate (yang, menurut definisi, mulai dari awal)?

Anda mengatakan bahwa itu dirancang untuk orang-orang yang tidak memiliki proses pembuatan yang mewah, tetapi Anda juga tampaknya menganjurkan penggabungan, pemisahan menjadi potongan berukuran sama, dan memuat secara paralel. Bukankah itu tugas untuk skrip build? Sekali lagi, sepertinya pilihan yang salah untuk boilerplate yang dirancang untuk memberikan default cerdas kepada pengguna. Jika pengguna menginginkan peningkatan kecepatan 20-30% yang diklaim, dia dapat memilih untuk memutakhirkan nanti atas apa yang ditawarkan boilerplate, tetapi itu bukan tugas yang sepele.

Setelah mengatakan semua itu, jika kalian ingin melanjutkan dengan topik umum ("Pemuat Skrip: Alat Berharga atau Minyak Ular?"), Saya akan dengan senang hati berkeliaran dan membuat popcorn.

@getify : Saya setuju bahwa koneksi ke-2 dan ke-3 mungkin dibuka lebih cepat daripada yang pertama - yang pertama menunggu DNS dan mungkin merutekan paket pertama ke server sedikit lebih lambat daripada merutekan sisanya di sepanjang jalur yang sama. Dalam cache sesi HTTPS SSL sangat membantu koneksi selanjutnya.

Namun, saya tidak melihat relevansi Keep-Alive dalam situasi ini. _permintaan_ berikutnya pada koneksi yang sama dimulai lebih cepat dengan Keep-Alive, tetapi permintaan tersebut serial dalam koneksi.

Saya hampir selesai di sini -- saya baru saja mencapai momen "gila dan tidak akan tahan lagi" sehubungan dengan pemuat skrip.

Yang mengatakan, saya pikir utas ini, untuk festival api, sebenarnya cukup produktif. Jika LABjs ingin mengintai klaim untuk situs web yang malang dan tidak kompeten, dan meninggalkan orang-orang yang benar-benar ingin situs mereka dimuat dengan cepat, itu adalah langkah maju yang bagus.

Bung, dinginkan

@savetheclocktower--

Pertanyaan yang adil.

Saya tidak memulai partisipasi saya di utas ini dengan sangat menganjurkan LABjs (atau pemuat skrip apa pun) untuk dimasukkan dalam h5bp. Saya pikir ini berguna (lihat di bawah), tetapi bukan masalah utama saya bahwa saya kurang tidur. Jelas, utas ini telah berubah menjadi serangan habis-habisan terhadap segala sesuatu yang "memuat skrip". Itu, jelas, sesuatu yang sedikit lebih saya pedulikan.

Anda mengatakan bahwa itu dirancang untuk orang-orang yang tidak memiliki proses pembuatan yang mewah, tetapi Anda juga tampaknya menganjurkan penggabungan, pemisahan menjadi potongan berukuran sama, dan memuat secara paralel. Bukankah itu tugas untuk skrip build?

Saya menganjurkan pertama untuk memindahkan semua lusinan tag skrip Anda ke pemuat skrip paralel seperti LABjs. Ini tidak lebih dari kemampuan untuk menyesuaikan markup Anda. Itu adalah langkah yang jauh lebih mudah/tidak terlalu mengintimidasi daripada memberi tahu situs ibu&pop untuk menggunakan sistem pembangunan berbasis node.js otomatis, misalnya.

Dan bagi mereka yang BISA membuat file mereka, saya menganjurkan bahwa LABjs masih memiliki manfaat, karena dapat membantu Anda memuat potongan-potongan itu secara paralel. Jika Anda benar-benar tidak setuju bahwa potongan berguna dengan cara apa pun, maka Anda tidak akan melihat alasan apa pun untuk menggunakan LABj lebih dari defer . Tetapi jika Anda dapat melihat mengapa chunking _mungkin_ membantu, maka harus diikuti bahwa pemuat skrip _mungkin juga membantu_ dalam proses itu.

Sekali lagi, sepertinya pilihan yang salah untuk boilerplate yang dirancang untuk memberikan default cerdas kepada pengguna.

Satu- satunya alasan saya pikir pemuat skrip (khususnya yang dirancang, seperti LABjs, untuk memiliki pemetaan satu-ke-satu antara tag skrip dan panggilan script() ) memiliki manfaat dalam boilerplate adalah bahwa dalam boilerplate , Anda sering melihat satu contoh dari sesuatu (seperti tag), dan kecenderungan Anda dalam membangun halaman Anda adalah dengan hanya menyalin-n-menempel duplikat itu sebanyak yang Anda butuhkan. Jadi, jika Anda memiliki pola (tag skrip) berkinerja buruk di boilerplate, kecenderungan orang adalah menduplikasi tag skrip belasan kali. Saya pikir, rata-rata, jika mereka malah menggandakan panggilan $LAB.script() beberapa kali, ada kemungkinan besar kinerja mereka tidak akan seburuk yang seharusnya.

Itulah satu-satunya alasan saya mulai berpartisipasi dalam utas ini. Itulah satu-satunya alasan saya mempermasalahkan komentar "iman buta" @paulirish WAY di atas di utas ini.

Iyaaaaaaaa.

Saya pikir sudah jelas diskusi ini telah bergerak melewati apakah pemuat skrip sesuai untuk proyek h5bp. Tapi itu bagus, karena topik ini layak untuk ditelusuri.

terlepas dari itu, saya sangat tertarik dengan kasus uji yang dapat direproduksi di samping hasil pengujian.

Tampaknya juga spesifikasi untuk @defer ditulis untuk melindungi beberapa perilaku tidak menentu yang diberikan browser bersamanya. Perilaku itu harus didokumentasikan. Saya dapat membantu memigrasikannya ke MDC jika sudah siap.

Kami membutuhkan dokumentasi langsung tentang perilaku ini yang menangkap semua browser, jenis koneksi yang berbeda, dan efek jaringan. Saya tidak yakin apakah rig uji harus menggunakan cuzillion atau assetrace, tapi itu bisa ditentukan.

Saya telah menyiapkan tiket untuk mengumpulkan minat pada https://github.com/paulirish/lazyweb-requests/issues/42

Bergabunglah dengan saya di sana jika Anda menyukai tugas _superfun_ penelitian webperf dan mendokumentasikan bukti.

Mari kita pertimbangkan utas ini ditutup, tuan-tuan.

Pemuatan yang lambat bukanlah manfaat inti dari modul AMD seperti yang dijelaskan @import selama pengembangan dan menjalankan build otomatis untuk menggabungkan stylesheet juga disarankan untuk proyek besar...

Saya merasa bahwa posting yang saya tulis tahun lalu ini sesuai dengan subjek: Dogma kinerja - Ini tidak semua tentang kinerja dan pastikan Anda tidak _membuang-buang waktu_ "mengoptimalkan" sesuatu yang tidak membuat _nyata_ perbedaan...

Dan saya dengan @SlexAxton , saya ingin AMD tetapi tag skrip sederhana mungkin cukup untuk kebanyakan orang. Mungkin pendekatan yang valid adalah menambahkan pengaturan baru untuk memilih proyek AMD dan menjalankan pengoptimal RequireJS alih-alih tugas _concat_ (

Mari kita pertimbangkan utas ini ditutup, tuan-tuan.

@paulirish Bagaimana dengan menyertakan dukungan AMD? Di mana kita harus membahas itu?

@benatkin buka tiket baru

@paulirish Oke, terima kasih. @jrburke, bisakah Anda membuka tiket baru untuk melanjutkan diskusi yang Anda mulai? Saya pikir saya akan menambahkan komentar, tetapi saya rasa saya tidak dapat menjelaskan kasus untuk dukungan AMD sebaik yang Anda bisa.

Menghibur dan informatif. Terima kasih teman-teman.

Saya pikir seseorang perlu memulai proyek pemuat skrip baru dan menyebutnya "Masalah28". :)

Untuk kompatibilitas terluas, kinerja cepat dapat diperoleh dengan meletakkan skrip di bagian bawah, perkecil, gzip, tetapi jangan ditunda. Setidaknya tidak sampai kompatibilitas browser konsisten selama beberapa tahun berturut-turut.

Hambatan dapat berasal dari iklan, terlalu banyak javascript, HTML yang membengkak, terlalu banyak CSS, terlalu banyak iframe, terlalu banyak permintaan, latensi server, javascript yang tidak efisien. Aplikasi yang banyak menggunakan lib pihak ketiga memiliki masalah yang disebabkan tidak hanya oleh terlalu banyak javascript, tetapi lebih dari itu, mereka cenderung juga memiliki banyak masalah lain, kebanyakan HTML kembung, HTML tidak valid, terlalu banyak css, dan javascript tidak efisien. Twitter datang langsung ke pikiran, dengan memiliki dua versi jQuery dan dua penangan onscroll yang menyebabkan onscroll kolom kanan memantul.

Penendangnya adalah jika Anda tahu apa yang Anda lakukan, Anda dapat menghindari masalah itu. Anda tidak memerlukan hal-hal seperti jQuery atau garis bawah, sehingga skrip Anda jauh lebih kecil. Anda menulis HTML dan CSS yang bersih, sederhana, valid. Akibatnya, halaman Anda dimuat lebih cepat, aplikasi lebih fleksibel dalam hal perubahan, dan SEO meningkat. Dan kemudian menggunakan pemuat skrip hanya menambah kompleksitas dan overhead yang tidak beralasan.

https://github.com/BroDotJS/AssetRage

LEDAKAN! Saya menutup klub dan saya menutup utasnya.

Apa benang ... wow.

Imo, diskusi dimulai dalam konteks h5bp, yang dimaksudkan sebagai titik awal untuk pengembang web.
Dengan demikian, Anda dapat menyatakan bahwa webdev yang menggunakan h5bp sebenarnya akan memiliki HTML yang bersih, CSS yang bersih, .htaccess dll yang baik dan _mungkin_ bahkan _tidak_ menderita terlalu banyak gambar, JS yang tidak efisien, banyak JS pihak ketiga yang jelek, dll. Anda tahu, karena pengembang web memilih untuk menggunakan h5bp kinerja tinggi dan dengan itu memperhatikan kinerja, dan akan memperhatikan hal-hal non-h5bp yang masuk ke halaman.

Dari utas, dan dalam konteks ini, saya pikir sayangnya tidak ada cukup bukti untuk menarik kesimpulan akhir.
Saya bersama Paul untuk memulai penelitian dan mendokumentasikan apa yang perlu didokumentasikan.
Hitung aku di Paul.

Catatan sampingan. Saya tidak begitu akrab dengan AMD dan dari pandangan pertama, tampaknya menakutkan bagi saya, atau setidaknya bukan sesuatu yang saya dapat mengambil dengan sangat mudah. Saya pikir sebagian besar pengembang web 'biasa' akan setuju.
Hal-hal yang Anda lihat di h5bp harus memiliki penghalang masuk yang rendah, atau itu tidak akan digunakan dan penyerapan h5bp mungkin lebih lambat daripada tanpanya.
Saya ragu sesuatu seperti AMD termasuk dalam h5bp.
Tetap sederhana.

Dan satu lagi komentar....
'Menempatkan skrip di bagian bawah' dan 'Menggabungkan file JS ke dalam satu file' telah menempati urutan teratas dalam daftar Praktik Terbaik Web Perf selama bertahun-tahun. Jadi mengapa >90% dari rata-rata situs di luar sana, yang dibangun oleh pengembang internal dan oleh agensi merek teratas masih memiliki beberapa tag skrip di HEAD? Sungguh, mengapa demikian?

Dan 9% lainnya memiliki satu file JS yang digabungkan ... di HEAD.
Jarang saya melihat situs 'normal' yang _not_ dibangun oleh beberapa pengembang web perf teratas dengan satu skrip di bawah.

Pengembang terus membangun situs seperti yang telah mereka lakukan selama bertahun-tahun.
Pemilik situs paling peduli dengan desain dan fitur, jadi untuk itulah para pengembang menghabiskan waktu mereka.

Mengubah cara kerja, sistem build, kode ... itu harus mudah, sangat mudah, atau itu tidak akan terjadi.

Saya telah bekerja di banyak situs di mana menggabungkan JS di HEAD menjadi satu file dan memuatnya di bagian bawah BODY memecahkan halaman di situs. Lalu apa? Dalam kebanyakan kasus, tidak hanya satu jam kerja untuk memperbaikinya. Refactoring yang serius perlu dilakukan ... dan ini tidak terjadi karena kurangnya pengetahuan dan, terutama, kurangnya waktu.

(oh ya, utasnya ditutup ...)

Kita berbicara tentang perpustakaan yang dibangun di atas jQuery dan Modernizr. Mengatakan itu semua, sungguh. Siapa yang menggunakan itu? Oh, sial, saya lupa, Twitter.com, yang menggunakan dua jQuery dan juga memiliki kode sumber, berikut ini:

 Baris 352, Kolom 6: Div tag akhir terlihat, tetapi ada elemen terbuka.
 Kesalahan Baris 350, Kolom 6: Elemen tidak tertutup ul.
 Kesalahan Baris 330, Kolom 6: Elemen tidak tertutup ul.

Dan masalah dengan mengharapkan browser untuk memperbaiki kesalahan yaitu bahwa HTML4 tidak mendefinisikan mekanisme koreksi kesalahan sehingga Anda akan berakhir dengan siapa-tahu-apa-siapa-tahu-di mana. Tentu, HTML5 mendefinisikan penanganan kesalahan, tetapi tidak berlaku surut -- masih banyak peramban "lama" di luar sana.

Dan omong-omong, adakah yang pernah melihat shim jQuery ES5?

BTW, apakah Anda memiliki sesuatu untuk ditambahkan ke pernyataan Anda "bahwa webdev yang menggunakan h5bp akan benar-benar memiliki HTML yang bersih," aaronpeters?

@GarrettS ok, ok, saya seharusnya menulis "akan _mungkin_ memiliki HTML yang bersih"

:-D kita selalu bisa berharap!

Mengalahkan kuda mati, saya tahu ... tetapi ternyata pada saat yang sama kami melakukan diskusi yang gemilang ini, versi LABjs saat ini sebenarnya memiliki bug yang menyebabkan JavaScript dijalankan dengan urutan yang salah di beberapa browser: https: //github.com/getify/LABjs/issues/36

Ah, ironi.

harus. melawan. posting. sama sekali. [tidak pantas. gambar. untuk. sebelumnya. pernyataan.... agggh! RASA SAKIT!

Bagian favorit saya adalah ketika pria yang membuat dhtmlkitchen.com (saat ini benar-benar kacau ) mulai berbicara tentang kesalahan markup.

Situs itu telah dipindahkan ke Paulo Fragomeni. Ya saya membuatnya dan bangga dengan apa yang saya tulis di sana, seperti di sini. Ambil screenshot avatar lemahmu, brengsek.

...dan setelah Anda selesai dengan itu, cobalah untuk mengeluarkan kepala Anda dari pantat Anda dan memahami perbedaan antara situs web pribadi lama saya (yang tidak lagi dikelola oleh saya) dan yang dikembangkan oleh tim dan dibiayai oleh perusahaan multi-juta dolar yang menguntungkan (meskipun Twitter mungkin bernilai miliaran AFAIK).

Senang kami menjaga ini tetap berkelas, dan _pada topik_, teman-teman.

jashkenas mendapatkan sedikit info yang relevan di awal diskusi ini.

Tapi kemudian ada reaksi balik. Tidak! Seharusnya tidak! Souders mengatakan untuk melakukannya! Dan ada saran buruk untuk menggunakan penangguhan, tidak peduli bagaimana gagal ketika gagal.

Dan kemudian ironisnya, entah dari mana, muncul klaim bahwa pengguna h5bp akan melakukan sesuatu dengan benar. Dan ini sangat ironis karena komentar ini datang _setelah_ komentar dari para pendukungnya yang ternyata menghasilkan markup yang tidak valid dan menggunakan banyak lapisan abstraksi pihak ketiga (dan yang mengerikan). Dan setelah komentar tentang menggunakan penangguhan.

Jadi apa hubungannya semua ini dengan dhtmlkitchen.com yang sedang down? Tidak ada sama sekali, jelas. Itu hanya jab lemah dari forker h5bp yang tidak tahan mendengar kritik.

saudara
Bung.
saudara

Utas ini ditutup. Ingat? Anda tidak harus pulang, tetapi Anda tidak bisa menyalakan api di sini.

Hei, kalian semua ingat bahwa suatu saat ketika kami membuat utas epik di mana ada banyak perdebatan, perang api pribadi, orang-orang marah di semua tempat, satu atau dua gambar cabul, dan waktu yang menyenangkan? Tidak percaya itu gratis. Kita harus melakukannya lagi kapan-kapan.