Якщо ви дбаєте лише про продуктивність, більшість порад у цій темі виправдовуються неправильно, і все частіше помиляються в епоху SPA, де можна припустити, що сторінка марна без коду JS. Я витратив незліченну кількість годин, оптимізуючи час завантаження SPA-сторінки та перевіряючи ці результати за допомогою різних браузерів. Повсюдно підвищення продуктивності шляхом повторного оркестрування вашого html може бути досить драматичним.
Щоб досягти найкращої продуктивності, ви повинні думати про сторінки як двоступеневі ракети. Ці два етапи приблизно відповідають фазам <head>і <body>фазам, але думайте про них замість як <static>і <dynamic>. Статична частина - це, по суті, струнна константа, яку ти збиваєш у відповідь так швидко, наскільки це можливо. Це може бути трохи складним, якщо ви використовуєте багато проміжного програмного забезпечення, яке встановлює файли cookie (їх потрібно встановити перед надсиланням http-вмісту), але в принципі це просто промивання буфера відповідей, сподіваємось, перш ніж перейти до якогось шаблонного коду (бритва, php, тощо) на сервері. Це може здатися важким, але тоді я просто пояснюю це неправильно, бо це майже тривіально. Як ви вже здогадалися, ця статична частина повинна містити всі вбудовані та мінімізовані JavaScript. Це виглядало б щось на кшталт
<!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>
Оскільки вам не доведеться нічого надсилати цю частину по проводу, ви можете розраховувати, що клієнт почне отримувати це десь близько 5 мс + затримки після підключення до вашого сервера. Якщо припустити, що сервер досить близький, ця затримка може бути від 20 до 60 мс. Веб-браузери почнуть обробляти цей розділ, як тільки вони його отримають, і час обробки зазвичай домінуватиме час передачі з коефіцієнтом 20 або більше, який тепер є вашим амортизованим вікном для обробки <dynamic>частини сервера на стороні .
Браузер займає близько 50 мс (хром, відпочинок, можливо, на 20% повільніше), щоб обробити вбудований jquery + сигналр + кутовий + нг анімований + дотик + нг маршрути + лодаш. Це досить дивовижно саме по собі. Більшість веб-додатків мають менше коду, ніж усі популярні бібліотеки разом, але, скажімо, у вас так само багато, тому ми виграємо затримку + 100 мс обробки на клієнті (ця виграш затримки походить від другої частини передачі). До приходу другого фрагменту ми обробили всі js-коди та шаблони, і ми можемо почати виконувати перетворення дому.
Ви можете заперечити, що цей метод є ортогональним для вбудованої концепції, але це не так. Якщо ви замість того, щоб вбудовувати посилання на cdns або власні сервери, браузеру доведеться відкрити інше з'єднання та затримати виконання. Оскільки це виконання в основному безкоштовне (так як сторона сервера спілкується з базою даних), повинно бути зрозуміло, що всі ці стрибки коштуватимуть дорожче, ніж взагалі не робити стрибків. Якби виникла думка браузера, яка сказала, що зовнішній js виконується швидше, ми могли б виміряти, який фактор домінує. Мої вимірювання показують, що додаткові запити вбивають ефективність на цьому етапі.
Я багато працюю з оптимізацією додатків SPA. Людям властиво думати, що обсяг даних - це велика справа, тоді як затримка правди і виконання часто домінують. Перераховані я перераховані бібліотеки містять до 300 кбіт даних, і це всього 68 кбіт gzipped, або 200 м завантаження на телефон 2mbit 3g / 4g, що є саме затримкою, яка знадобиться на тому ж телефоні, щоб перевірити, чи є у нього однакові дані у своєму кеші вже, навіть якщо він був кешований проксі-сервісом, оскільки податок на затримку мобільного зв'язку (затримка від телефону до башти) все ще діє. Тим часом підключення на робочому столі, які мають нижчу затримку першого переходу, як правило, мають більшу пропускну здатність.
Коротше кажучи, саме зараз (2014 р.) Найкраще вкладати всі сценарії, стилі та шаблони.
РЕДАКТУВАТИ (МАЙ 2016)
Оскільки додатки JS продовжують зростати, а деякі мої корисні навантаження тепер накопичують до 3+ мегабайт мінімізованого коду, стає очевидним, що принаймні загальні бібліотеки більше не повинні бути вказівними.