Jika Anda hanya peduli dengan kinerja, sebagian besar saran di utas ini benar-benar salah, dan menjadi semakin salah di era SPA, di mana kita dapat menganggap bahwa halaman tersebut tidak berguna tanpa kode JS. Saya telah menghabiskan banyak waktu untuk mengoptimalkan waktu pemuatan halaman SPA, dan memverifikasi hasil ini dengan browser yang berbeda. Di seluruh papan, peningkatan kinerja dengan mengatur ulang html Anda, bisa sangat dramatis.
Untuk mendapatkan kinerja terbaik, Anda harus menganggap halaman sebagai roket dua tahap. Kedua tahap ini secara kasar berhubungan dengan <head>dan <body>fase, tetapi menganggapnya sebagai <static>dan <dynamic>. Bagian statis pada dasarnya adalah konstanta string yang Anda sorong ke bawah pipa respon secepat mungkin. Ini bisa sedikit rumit jika Anda menggunakan banyak middleware yang mengatur cookie (ini perlu diatur sebelum mengirim konten http), tetapi pada prinsipnya itu hanya menyiram buffer respon, mudah-mudahan sebelum beralih ke beberapa kode templating (razor, php, dll) di server. Ini mungkin terdengar sulit, tetapi kemudian saya hanya menjelaskannya salah, karena hampir sepele. Seperti yang mungkin sudah Anda duga, bagian statis ini harus berisi semua javascript yang digarisbawahi dan diperkecil. Itu akan terlihat seperti
<!DOCTYPE html>
<html>
<head>
<script>/*...inlined jquery, angular, your code*/</script>
<style>/* ditto css */</style>
</head>
<body>
<!-- inline all your templates, if applicable -->
<script type='template-mime' id='1'></script>
<script type='template-mime' id='2'></script>
<script type='template-mime' id='3'></script>
Karena hampir tidak ada biaya untuk mengirimkan bagian ini, Anda dapat berharap bahwa klien akan mulai menerima ini sekitar 5 ms + latensi setelah tersambung ke server Anda. Dengan asumsi server cukup dekat, latensi ini bisa antara 20 ms hingga 60 ms. Browser akan mulai memproses bagian ini segera setelah mereka mendapatkannya, dan waktu pemrosesan biasanya akan mendominasi waktu transfer dengan faktor 20 atau lebih, yang sekarang menjadi jendela diamortisasi Anda untuk pemrosesan <dynamic>bagian sisi server .
Dibutuhkan sekitar 50 ms untuk browser (chrome, sisanya mungkin 20% lebih lambat) untuk memproses jquery inline + signalr + angular + ng animasi + ng sentuh + ng rute + lodash. Itu cukup luar biasa dalam dan dari dirinya sendiri. Sebagian besar aplikasi web memiliki kode lebih sedikit daripada semua perpustakaan populer yang disatukan, tetapi katakanlah Anda memiliki jumlah yang sama, jadi kami akan memenangkan latensi + 100ms pemrosesan pada klien (kemenangan latensi ini berasal dari potongan transfer kedua). Pada saat chunk kedua tiba, kami telah memproses semua kode js dan templat dan kami dapat mulai menjalankan transformasi dom.
Anda mungkin keberatan bahwa metode ini ortogonal dengan konsep inlining, tetapi tidak. Jika Anda, alih-alih meluruskan, menautkan ke cdns atau server Anda sendiri, browser harus membuka koneksi lain dan menunda eksekusi. Karena eksekusi ini pada dasarnya gratis (karena sisi server sedang berbicara ke database), harus jelas bahwa semua lompatan ini akan lebih mahal daripada tidak melompat sama sekali. Jika ada kekhasan browser yang mengatakan js eksternal mengeksekusi lebih cepat kita bisa mengukur faktor mana yang mendominasi. Pengukuran saya menunjukkan bahwa permintaan tambahan membunuh kinerja pada tahap ini.
Saya banyak bekerja dengan optimalisasi aplikasi SPA. Sudah umum bagi orang untuk berpikir bahwa volume data adalah masalah besar, sementara dalam latensi kebenaran, dan eksekusi sering mendominasi. Pustaka yang diperkecil yang saya daftarkan menambahkan hingga 300kb data, dan itu hanya 68 kb di-gzip, atau 200ms diunduh pada telepon 2mbit 3g / 4g, yang merupakan latensi yang diperlukan pada telepon yang sama untuk memeriksa JIKA ada data yang sama dalam cache sudah, bahkan jika itu adalah proxy di-cache, karena pajak latensi seluler (telepon-ke-menara-latensi) masih berlaku. Sementara itu, koneksi desktop yang memiliki latensi first-hop lebih rendah biasanya memiliki bandwidth yang lebih tinggi pula.
Singkatnya, sekarang (2014), yang terbaik adalah inline semua skrip, gaya, dan templat.
EDIT (MEI 2016)
Ketika aplikasi JS terus tumbuh, dan beberapa muatan saya sekarang menumpuk hingga 3+ megabyte kode minified, menjadi jelas bahwa paling tidak perpustakaan umum seharusnya tidak lagi digariskan.