kyle: " @paul_irish, я не согласен. http://bit.ly/9IfMMN кэшируемость (внешние CDN), параллельная загрузка, изменчивость скрипта ..."

Джеймс Берк: " @paul_irish @fearphage @getify В RequireJS есть инструмент сборки для объединения / минимизации скриптов, поэтому он может иметь лучшее из обоих: динамический и предварительно собранный"

Самый простой способ для разработчиков начать загрузку скрипта - это, вероятно, использовать $ Lab.js, потому что он уже использует синтаксис цепочки, с которым пользователи jQuery уже знакомы.

Если они создают большие корпоративные приложения, они всегда могут перейти на require.js при необходимости.

в настоящее время существует три основных метода загрузки скриптов:

1. HeadJS
2. ControlJS
3. LABjs

использовать это или нет, вопрос о том, какой использовать, довольно спорен: http://blog.getify.com/2010/12/on-script-loaders/

Также есть requireJS и EnhanceJS, чтобы вы знали об альтернативах HeadJS ControlJS и LabJS . Даже Yahoo и Google предлагают нечто подобное.

С выпуском jQuery 1.5 и deferreds - http://www.erichynds.com/jquery/using-deferreds-in-jquery/ , Борис Мур использует их в DeferJS, новом проекте загрузчика скриптов: https: // github. ru / BorisMoore / DeferJS

По умолчанию загрузка скрипта останавливает все остальные загрузки, поэтому загрузка modernizr в шапке - это плохо. Встраивание загрузчика имеет смысл, потому что загрузчики могут загружать скрипт параллельно и без блокировки. Например, если вам не нужны все функции modernizr, вы можете встроить head.min.js размером всего 6 КБ или пользовательскую сборку modernizr (http://modernizr.github.com/Modernizr/2.0-beta/). Иногда имеет смысл встраивание CSS. Google использует встраивание, они встраивают css, js и пустые гифки 1x1 через datauri.

LabJS становится довольно широко используемым и является хорошим решением - также он может быть включен асинхронно, поэтому его не нужно блокировать.

http://blog.getify.com/2010/12/on-script-loaders/ принадлежит автору

http://yepnopejs.com/ только что перешел на 1.0 и не ломается в новом webkit, в отличие от LAB и head.js. Загрузка скрипта затруднена.

yepnope также интегрирован в Modernizr как Modernizr.load .. http://modernizr.github.com/Modernizr/2.0-beta/

Так что, вероятно, очень скоро у нас будет загрузчик скриптов в h5bp в виде Modernizr.load.

Я не думаю, что это будет 1.0, но как только я подниму Modernizr до 1.8, мы добавим его в h5bp 1.1. Ага

Привет, Пол

Я портировал существующий сайт для использования вашего H5BP и хочу использовать загрузчик скриптов yepnope.js. Действительно приятно видеть, как все биты и боты собраны вместе, как это сделали вы.

Что бы вы порекомендовали использовать на данный момент?

1. Включите yepnope.js вместе с modernizer.js вверху страницы.
2. Включите его внизу страницы для загрузки после завершения загрузки HTML.
3. Используйте бета-версию modernizer.js
4. Я мог бы объединить yepnope.js с modernizer.js в один include.

Независимо от того, как лучше всего его включить, как вы рекомендуете загружать скрипты с помощью yepnope, js?

Я полагаю, мы должны делать это здесь: https://github.com/paulirish/html5-boilerplate/blob/master/index.html#L52 и использовать yepnope для загрузки CDN / локальной копии jQuery и других наших скриптов.

Но как вы думаете, лучше всего использовать внешний сценарий, включающий или отображающий блок сценария в html, который затем загружает сценарии через yepnope.js?

Большое спасибо.

Энди

Ну и еще кое-что.

Поскольку yepnope может загружать css через, я бы сказал, что лучше всего включить основной css, как обычно, и использовать yepnope только для включения css для определенных исправлений.

Например, включая некоторые CSS, которые применяются только к более старым версиям IE.

хокапока

Используйте бета-версию modernizr .. просто включите то, что вам нужно (и включите Modernizr.load() ), а затем поместите это вверху страницы.

фактический код для резервной копии jquery с yepnope находится на http://yepnopejs.com/

И да, мне нравится ваше представление об условной загрузке IE css.

tbh слишком много слепой веры в загрузчики скриптов в отношении производительности, и я не думаю, что мы готовы сказать, что ЭТО ПРАВИЛЬНЫЙ ПУТЬ.

нам нужно больше исследований размеров файлов, пропускной способности и состояния сети, которые указывают на разумные рекомендации по загрузке скриптов, но сейчас эта область только зарождается, и было бы наивно рекомендовать общее решение для загрузки скриптов.

так.

закрыть этот тикет и попросить всех, кто неравнодушен, провести всестороннее исследование и опубликовать, чтобы упростить разработчикам возможность сделать разумный выбор в отношении этого.

Я провел довольно много исследований о concat и параллельной загрузке. Я по-прежнему, без оговорок, рекомендую сначала объединить все js в один файл, затем разбить его на 2–3 части одинакового размера и загрузить их параллельно.

Я бы хотел иметь возможность взять свое исследование и сделать его широким и масштабным, чтобы оно было жизнеспособным как «факт» в этой области. Проблема в том, что я пытался и пытался найти пропускную способность хостинга, где мне не нужно было бы много $, чтобы фактически запустить тесты в масштабе, и пока не смог найти это предоставление хостинга.

Если я / мы сможем решить проблему пропускной способности для тестирования, у меня будут тесты, которые можно запустить, чтобы выяснить, действительно ли теория параллельной загрузки жизнеспособна (как я считаю).

@getify, что вам нужно в

Я могу обрабатывать на моем личном сервере примерно на 1,5 ТБ больше данных, чем использую сейчас. У меня установлен Nginx, который может обрабатывать около 4 триллионов квадриллионов обращений за микросекунду. Я не чувствую, что технологии являются здесь препятствием.

Если нас беспокоит местоположение, мы можем обмануть более высокую задержку и / или найти пару других людей, у которых есть немного лишнего места на своих ящиках.

Между прочим, у меня есть небольшая проблема со «слепой верой».

Легко, доказуемо и почти без сомнений верно, что если у вас есть существующий сайт, загружающий множество скриптов с тегами скриптов, использование параллельного загрузчика скриптов (без других изменений) улучшает производительность. Это правда, потому что даже новейшие браузеры не могут (и никогда, я не думаю) открепить загрузку скрипта от блокировки DOM-ready. Таким образом, даже при загрузке браузера в лучшем случае, если нет других преимуществ, резкое ускорение DOM-ready на сайте почти всегда является преимуществом (для пользователей и UX).

Ваше утверждение является немного ложным, поскольку предполагает, что мы пытаемся сравнить для каждого сайта параллельную загрузку со скриптом-concat. Большинство веб-сайтов в действительности не используют / не могут использовать script-concat, поэтому на самом деле сравнение (для них, большинство) не так тонко и сложно, как вы думаете. Если они не используют / не могут использовать script-concat (по какой-либо причине), сравнение простое: параллельная загрузка почти всегда дает преимущество над тегами script.

Если они открыты для script-concat (или уже используют его), тогда да, становится немного более тонким / сложным, чтобы решить, может ли параллельная загрузка помочь или нет. Но script-concat также не является универсальным решением, поэтому существует множество сайтов, для которых параллельная загрузка останется предпочтительным и лучшим подходом.

Тот факт, что некоторые сайты имеют дело с нюансами / сложностями выбора между параллельной загрузкой и объединением сценариев, не означает, что более серьезное (более эффективное) обсуждение тегов параллельной загрузки и тегов сценария должно быть потеряно в смеси. Первое трудно доказать, но второе на данный момент почти само собой разумеющееся.

Все это означает, что, учитывая все обстоятельства, ИМХО шаблонный шаблон должен поощрять шаблон, который имеет наибольшее влияние в положительном направлении. Если сегодня 80% сайтов в Интернете используют теги сценариев, большинство из которых выиграют от перехода от тегов сценариев к параллельной загрузке, то параллельная загрузка - это очень полезная вещь, которую можно предложить в качестве отправной точки для шаблона.

Это гораздо меньшая (но важная) часть тех сайтов, которые потенциально могут получить еще большую выгоду от изучения объединения сценариев по сравнению с параллельной загрузкой. Но вариант использования меньшинства - это не то, для чего следует оптимизировать шаблон.

Всего несколько центов.

@paulirish @slexaxton -

Что касается потребностей в полосе пропускания, я подсчитал, что для того, чтобы заставить 10000 человек (что, по моему мнению, было необходимо для точной выборки) запустить тест один раз (и я уверен, что многие люди будут запускать его несколько раз), это будет примерно Израсходовано 200 ГБ полосы пропускания. Для некоторых это капля в море. Для меня 200 ГБ полосы пропускания за несколько дней были бы непосильными для моих затрат на хостинг сервера. Итак, я не стал проводить масштабирование тестов только по этой причине.

Более того, у меня есть более десятка вариантов этого теста, которые, я думаю, нам нужно изучить. Таким образом, десятки раз использования 100-200 ГБ полосы пропускания для меня были бы непозволительно дорогостоящими для меня. Я не хотел идти по этому пути, если не был уверен, что у меня достаточно пропускной способности для выполнения задачи.

Это просто статические файлы, и тесты не требуют большого количества одновременных пользователей, поэтому нет серьезных опасений по поводу традиционных проблем масштабирования, таких как ЦП и т. Д. Просто пропускная способность, и все.

Мы можем отложить обсуждение тестов в автономном режиме и продолжить его по электронной почте или в мгновенных сообщениях. Очень хотелось бы наконец масштабировать тесты и «уладить» этот вопрос. Это крутилось у меня в голове большую часть года.

Я могу использовать неограниченное количество TB на моем VPS Dreamhost, так что это не будет проблемой. прямо сейчас я делаю 72 ГБ в день и могу справиться с гораздо большим. :)

Я согласен с Полом и думаю, что существует довольно много дезинформации о том, как и когда загрузчики сценариев будут кому-либо полезны.

В вашем первом абзаце сказано, что загрузчики скриптов повышают производительность «легко», «доказуемо» и «без вопросов».

Некоторое время назад я сделал подобное постулату для

https://github.com/SlexAxton/AssetRace

Код есть. Очевидно, что не было большой тестовой аудитории, но результаты в лучшем случае показали, что этот загрузчик сценариев имел примерно такую ​​же скорость, что и метод concat (при соблюдении ваших рекомендаций по параллельной загрузке из трех файлов аналогичного размера), а в худшем случае показали, что сценарий- Загрузчики различались гораздо больше и, как правило, были медленнее в пределах погрешности. Не стесняйтесь форкнуть и найти решение, которое превосходит наши или оба, даже если оно находится на вашем компьютере в одном браузере.

Что касается «ложной предпосылки», потому что h5bp предполагает, что люди конкатируют свои js. Этот аргумент полностью недействителен, потому что h5bp предлагает инструмент для сборки скриптов с объединением и минификацией. Таким образом, аргумент о том, что параллельная загрузка почти всегда дает преимущество над несколькими тегами сценария, может быть верным, но он не лучше, чем то, что предлагает в настоящее время h5bp. Это контекст нашего обсуждения.

Я думаю, что в худшем случае люди берут что-то вроде yepnope или lab.js и используют его в качестве полифилла тега скрипта. Это обязательно приведет к более медленной загрузке (их 19 JS и 34 файлов CSS), а также к появлению множества проблем обратной и прямой совместимости, о которых они даже не подозревают.

Я думаю, что в духе предоставления людям наиболее разумного, производительного и совместимого по умолчанию для _boilerplate_ инструмент сборки идет намного дальше, чтобы обеспечить все три.

@slexaxton

... результаты в лучшем случае показали, что этот загрузчик сценариев имел примерно такую ​​же скорость, что и метод concat (с учетом ваших рекомендаций по параллельной загрузке из 3 файлов аналогичного размера) ...

Я с радостью найду время, чтобы взглянуть на тесты, которые вы составили. Я уверен, что вы, ребята, знаете, что делаете, поэтому я уверен, что ваши тесты верны и верны.

OTOH, у меня много противоречивых доказательств. Если бы я когда-либо видел что-нибудь убедительное, что параллельная загрузка скриптов была пустой тратой или бесполезной для большинства сайтов, я бы давно отказался от безумного приемника времени, которым является LABjs.

Я могу сказать со 100% уверенностью, что я ни разу за 2 года помощи в выпуске LABjs для людей не встречал ситуации, когда LABjs был медленнее, чем альтернатива тегу скрипта. Ноль раз такое случалось со мной. Несколько раз люди говорили, что не видят особой пользы. Было несколько раз, когда люди загружали более 100 файлов, и поэтому сумасшедшие накладные расходы, связанные с таким количеством подключений, свели на нет все преимущества, которые они могли бы увидеть в противном случае. Но я ни разу не слышал, чтобы кто-нибудь сказал мне, что LABjs сделали их сайт медленнее.

Я буквально сам помог более чем 50 различным сайтам перейти от тегов сценариев к LABjs, и в обязательном порядке сайты сразу же улучшили производительность. На начальном этапе я взял выборку из 7 или 8 сайтов, которым помог, и они в совокупности наблюдали в среднем около 15% улучшения скорости загрузки. Для 4 или 5 сайтов, которыми я управляю, я, конечно, реализовал LABjs, и сразу увидел 3-кратную скорость загрузки.

Конечно, когда LABjs был впервые выпущен, браузеры могли загружать скрипты параллельно (лишь немногие так делали). Так что тогда успехи были огромными и заметными. Теперь у нас есть почти все браузеры, выполняющие параллельную загрузку, так что выигрыш уже не такой значительный.

Но неоспоримо одно: все браузеры блокируют событие DOM-ready для загрузки тегов скрипта. Они _ должны_ из-за возможности найти document.write() . Параллельная загрузка скрипта, по сути, означает «браузер, я обещаю, что вам не придется иметь дело с document.write, так что продолжайте и двигайтесь вперед со страницей».

Взгляните на две диаграммы на слайде 10 этой колоды:

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

Сравните размещение синей линии (готово для модели DOM). Это резкое улучшение воспринимаемой производительности (UX), даже если общее время загрузки страницы (или время, необходимое для завершения загрузки всех ресурсов) ничуть не лучше.

... h5bp предлагает инструмент для сборки скриптов ...

Ошибочное предположение состоит в том, что только потому, что h5bp предлагает этот инструмент, все (или даже большинство) пользователей h5bp могут его использовать. Даже если 100% пользователей h5bp _do_ используют его, это не означает, что если h5bp будет развернут в «длинном хвосте» Интернета, все они будут использовать этот инструмент concat. Есть множество других факторов, которые могут легко помешать кому-то использовать это. Есть очень мало_ причин, по которым кто-то не может перейти от использования тегов сценария к использованию параллельного загрузчика сценариев.

Таким образом, параллельная загрузка скриптов по-прежнему более привлекательна для «длинного хвоста» Интернета. Большинству сайтов, которые не используют оптимизацию загрузки скриптов, по-прежнему легче перейти от ничего к чему-то, и что-то предлагает им выигрыш в производительности. Немногие из этих длиннохвостых сайтов когда-либо потратят усилия (или будут иметь навыки экспериментировать с) автоматизированными инструментами создания скриптов в своих недорогих 6 долларов в месяц, массовом виртуальном хостинге, в средах веб-хостинга без CDN.

Я думаю, что в худшем случае люди берут что-то вроде yepnope или lab.js и используют его в качестве полифилла тега скрипта. Это обязательно приведет к более медленной загрузке ...

Я не мог больше не согласиться с этим утверждением. LABjs специально разработан как полифил тегов скрипта. И улучшения LABjs по сравнению с обычными тегами сценариев (пока игнорируем concat сценариев) хорошо известны и никогда серьезно не опровергались. Если у вас есть доказательство того, что большинству (или даже большому количеству) сайтов, использующих LABjs, было бы лучше вернуться к тегам скриптов, поделитесь, пожалуйста.

Нет абсолютно никаких причин, по которым параллельная загрузка сценария будет приводить к более медленной загрузке, чем то, что браузер мог бы выполнить с помощью тегов сценария. Это бессмысленно. И, как я установил выше, теги сценария всегда будут блокировать готовность к DOM, а при параллельной загрузке сценария - нет.

представляют множество проблем обратной и прямой совместимости, о которых они даже не подозревают.

О каких проблемах совместимости вы говорите? Матрица поддержки браузеров LABjs охватывает подавляющее большинство всех браузеров на планете. Сумасшедшая небольшая часть браузеров, в которую он взламывает, намного перевешивается большим количеством браузеров, в которых он имеет явные преимущества.

В LABjs 1.x было множество сумасшедших хаков, таких как предварительная загрузка кеша, которые действительно были серьезной проблемой для сбоев в работе браузеров. LABjs 2.x полностью перевернул это положение и теперь использует надежные и стандартизованные подходы для параллельной загрузки во всех случаях, возвращаясь только к взлому для более старого браузера webkit. Кроме того, в LABjs 2.x уже есть проверки для функциональных тестов техник загрузки сценариев, которые скоро появятся (надеюсь, вскоре будут стандартизированы), таких как «настоящая предварительная загрузка».

Я не могу однозначно говорить о каких-либо других загрузчиках скриптов - я знаю, что многие до сих пор используют хаки, - но что касается LABjs, меня сбивает с толку заявление о том, что он вводит проблемы прямой или обратной совместимости, поскольку я думаю, что это явно вводит в заблуждение требовать.

чтобы немного пояснить, почему я намереваюсь сделать LABjs полифилом тегов сценария ...

1. старые браузеры явно уступают в обработке загрузки тегов скрипта, которую может обрабатывать параллельная загрузка. именно в этих «старых браузерах» (которые были последними / лучшими, когда LABjs был запущен 2 года назад) мы увидели ~ 3-кратное улучшение времени загрузки страницы. почти по определению, это делает LABjs лучшим полифилом тегов сценария, поскольку он дает возможность (например, производительность параллельной загрузки) браузерам, которые сами ее не поддерживают.
2. новые браузеры, очевидно, намного лучше. но они не полностью отказались от преимуществ загрузчиков сценариев. Chrome еще в версии 12 (я думаю, они, кажется, наконец-то исправлены в версии 13) все еще блокировал загрузку изображений, пока теги скрипта завершили загрузку. даже с последними версиями IE, Firefox и Chrome, все они по-прежнему блокируют готовность к DOM, пока скрипты динамически загружаются, потому что им все еще приходится псевдопредполагать, что document.write() может скрываться.

Таким образом, для новых браузеров LABjs является «полифилом» в том смысле, что он передает браузеру «загрузку сценария, не готового к DOM-блокировке», чего не могут сделать теги сценария. Единственный возможный способ сделать это в современных браузерах без параллельного загрузчика сценариев - использовать теги сценария с defer ( async очевидно, не будет работать, поскольку он не сохраняет порядок) . Однако у defer есть ряд причуд, и его поддержка недостаточно широко распространена, чтобы быть жизнеспособным решением (резервное решение для non-defer - плохая производительность). Таким образом, можно сказать, что в самом простом случае LABjs представляет собой полифил для характеристик производительности тега сценария defer (хотя и не совсем).

Честно говоря, я все еще считаю, что мы должны подавать прошение о стандартах для объекта загрузки скрипта. Необходимость создания тега сценария другого типа, чем текст / javascript, для запуска кеша (или, что еще хуже, использовать тег объекта или объект изображения или что-то еще, что потребует новая версия популярного браузера) - значит прыгать много обручей напрасно и производительность будет варьироваться в зависимости от слишком большого количества переменных. Я понимаю, что мы все еще загружаем таблицы стилей, используя вставку dom node (но это только из-за порядка), но когда дело доходит до скрипта, я думаю, что это больше не имеет смысла (я бы хотел, чтобы Google перестал использовать document.write в большинстве случаев их сценарии, но это совсем другая история).

Кроме того, я думаю, что здесь мы упускаем самый важный момент, касающийся загрузчиков скриптов: возможность загружать js-код по запросу, а не загружать все заранее (даже если все в кеше, синтаксический анализ и инициализация требуют времени, и это может стать довольно приятным). некрасиво с нетривиальным количеством конкатенированных скриптов). Некоторое время ожидания после взаимодействия с пользовательским интерфейсом - гораздо меньшая проблема, чем то, что браузер "зависает" даже при запуске (DOM может быть готов, но что хорошего в том, если код для улучшения страницы и добавить итерацию еще не было: когда-нибудь замечали, как некоторые сайты загружаются сразу, а потом происходит что-то неуклюжее?).

Столь строгое измерение производительности - это прекрасно и изящно, но я по-прежнему считаю, что конечной целью является воспринимаемая производительность ... и, к сожалению, ее гораздо труднее оценить / оптимизировать / вычислить.

Это интенсивно.

@ jaubourg--

Честно говоря, я все еще считаю, что мы должны подавать прошение о стандартах для объекта загрузки скрипта.

Сейчас много ходатайств о том, как стандарты / спецификации и браузеры могут дать нам лучшую технологию загрузки скриптов. Первой крупной победой в этой категории за многие годы стал «упорядоченный асинхронный режим» ( async=false ), который был принят еще в феврале и теперь присутствует во всех основных браузерах текущей версии (исключение: очень скоро появится Opera, а в IE10p2 он есть. ).

Следующее обсуждение, которое я сейчас веду с Яном Хиксоном, - это то, что я называю «настоящей предварительной загрузкой». На мой взгляд, «настоящая предварительная загрузка» (которую IE уже поддерживает с v4, кстати) была бы ближайшим к «серебряной пуле», которая решила бы почти все сценарии загрузки скриптов довольно тривиально. Я все еще весьма оптимистичен, что мы увидим нечто подобное стандартизированному.

См. Эту вики для получения дополнительной информации: http://wiki.whatwg.org/wiki/Script_Execution_Control

Необходимость создания тега сценария другого типа, чем текст / javascript для запуска кеша (или, что еще хуже, использовать тег объекта или объект изображения или что-то еще, что потребует новая версия популярного браузера)

Это называется «предварительная загрузка кеша», и это, по общему признанию, уродливый и ужасный взлом. LABjs не уделяет этому больше внимания, начиная с версии 2 (использует его только как запасной вариант для более старого webkit). К сожалению, другие загрузчики скриптов все еще используют его в качестве основного механизма загрузки. Но 90% потребности в «предварительной загрузке кеша» можно решить с помощью «упорядоченного асинхронного режима», который стандартизирован и не является хакерским, поэтому хорошо работающие загрузчики скриптов теперь должны предпочесть это «предварительной загрузке кеша».

Итак, я согласен с тем, что «предварительная загрузка кеша» - отстой, но есть гораздо лучшие способы использовать document.createElement("script") которые не связаны с такими взломами, поэтому я не согласен с тем, что это аргумент против того, чтобы продолжать полагаться на элемент Script браузера для загрузка скрипта. Если мы сможем получить «настоящую предварительную загрузку», элемент Script будет всем, что нам нужно. Я искренне верю в это.

Я думаю, здесь мы упускаем самый важный момент, касающийся загрузчиков скриптов: возможность загружать js-код по запросу.

Совершенно согласен, что это важное преимущество, которое приносят загрузчики скриптов. Но это своего рода спорный аргумент в _этом_ потоке, потому что люди, занимающиеся "объединением сценариев", просто не могут без загрузки сценария решить вариант использования, поэтому нет смысла "сравнивать" их. Вы можете сказать, как сторонник «конкатенации сценариев»: «Хорошо, нам наплевать на этот вариант использования», но вы не можете сказать «мы можем лучше обслуживать этот вариант использования, используя XYZ».

Я согласен, что воспринимаемая производительность огромна и важна. Загрузка по запросу - огромная часть этого. Загрузка по требованию также улучшит реальную фактическую производительность (а не только восприятие), поскольку она имеет тенденцию приводить к меньшему количеству фактических загрузок, если вы загружаете только то, что необходимо (для нескольких посещений страниц требуется 100% написанного вами кода).

Воспринимаемая производительность - это также причина, по которой я выступаю за приведенный выше аргумент о готовности DOM. Потому что то, насколько быстро пользователь «чувствует», что он может взаимодействовать со страницей, _ очень_ важно, насколько быстрой, по его мнению, является страница (независимо от того, насколько быстро она действительно загружается). Это факт, установленный множеством пользовательских исследований.

Обожаю страстные длинные комментарии @getify.
Кайл ...

Если бы я мог внести свой вклад в исследование, я бы _любил_.
Пропускная способность (затраты), похоже, не проблема, поэтому @getify , что вы предлагаете в дальнейшем?
Не стесняйтесь обращаться ко мне по электронной почте (aaron [at] aaronpeters [точка] или twitter (@aaronpeters)

@kyle

Да, я следил за обсуждением «улучшений» тега сценария относительно предварительной загрузки, и я просто не считаю подход «добавить еще один атрибут в тег сценария» как жизнеспособный подход. Я видел, что он сделал со спецификацией xhr: большая сложность в отношении той небольшой выгоды, которую мы получаем в итоге.

Ясно то, что нам в значительной степени нужно только поведение предварительной загрузки при динамической вставке (то есть уже в javascript), так почему, черт возьми, мы все еще должны использовать инъекцию тегов сценария? Это не значит, что мы храним там тег или используем его в качестве узла DOM: это просто средство для достижения цели, не имеющей ничего общего со структурой документа.

Мне было бы намного удобнее что-нибудь в этом роде:

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

Это могло бы творить чудеса. Достаточно просто «присоединиться» к нескольким событиям загрузки сценария, а затем запустить эти сценарии в любом необходимом порядке. Это также не подразумевает наличия DOM, что делает его еще более универсальным. Я бы хотел, чтобы мы как можно скорее отказались от внедрения тегов сценария. Кроме того, его достаточно легко заполнить полифилом, используя известные нам уловки. Это также гораздо менее обременительно, чем полная система требований (но может быть кирпичиком для построения системы требований, которая в таком случае не ограничивается браузерами).

При этом я на 100% согласен с вами в отношении воспринимаемой производительности, я просто хотел указать на это, потому что мантра «давайте объединим все вместе» быстро становится своего рода убеждением, которое слишком сильно размывает, на мой вкус;)

fwiw, defer поддерживается в IE4 +, Chrome, Safari и FF 3.5+. Не поддерживается в Opera.

Это означает .... 98,5% пользователей уже имеют поддержку script@defer .

@getify

Однако у defer есть ряд причуд,

подробности плз? я ничего не видел об этом

Выполняются ли сценарии с отложенным запуском до или после срабатывания события готовности DOM?

Сохраняется ли порядок выполнения во всех браузерах?

Как насчет порядка выполнения и связывания внешнего со встроенными скриптами?

@ paulirish--

... 98,5% пользователей уже имеют поддержку script @ defer .

поддержка может быть в таком большом количестве браузеров, но это не значит, что она надежна в таком количестве браузеров. это то, что я имел в виду. (см. ниже)

Однако у defer есть ряд особенностей.

подробности плз? я ничего не видел об этом

Дай мне посмотреть ... IIRC:

1. поддержка отсрочки для динамических элементов скрипта не определена и не поддерживается ни в одном браузере ... работает только для тегов скрипта в разметке. это означает, что он совершенно бесполезен для техник и сценариев использования «по запросу» или «ленивой загрузки».
2. Я считаю, что был случай, когда в некоторых браузерах скрипты defer'd начинали выполняться непосредственно перед запуском DOM-ready, а в других - сразу после запуска DOM-ready. Чтобы получить больше подробностей, нужно будет покопаться дальше.
3. defer используемый в теге сценария, ссылающийся на внешний ресурс, ведет себя иначе, чем defer указанный в теге сценария со встроенным кодом в нем. То есть нельзя гарантировать, что оба типа скриптов будут работать, и они будут работать в правильном порядке.
4. defer в теге сценария, записанном оператором document.write() отличается от тега сценария в разметке с помощью defer .

У меня нет готовой тонны деталей по этим вопросам. Я вспоминаю, как около 2 лет назад (до LABjs) пытался использовать defer , и столкнулся с достаточным их количеством при кроссбраузерном тестировании, поэтому я в основном отложил его в сторону и с тех пор особо не посещал его.

Я также должен отметить, что defer самом деле не то же самое, что LABjs (и другие параллельные загрузчики). Я сказал это выше с оговоркой, что это вроде как так. Фактически, то, что обеспечивает параллельная загрузка скриптов (по крайней мере, для части LABjs), - это «упорядоченная асинхронность», которая не может быть достигнута только с помощью разметки.

Разница между «упорядоченным асинхронным» и «отложенным» состоит в том, что «упорядоченный асинхронный режим» все равно начнет выполняться, как только первый запрошенный скрипт завершит загрузку, тогда как «отложенный» будет ждать, пока «DOM-ready» не начнет выполнение. Для простой страницы с небольшой разметкой и без других вызовов блокирующей разметки (например, других тегов скрипта) эта разница невелика. Но для страницы с большим количеством ресурсов, когда скриптам разрешено начать выполнение, может быть совсем другое.

Так что, честно говоря, я бы не хотел слишком сильно расстраиваться по касательной к defer , потому что на самом деле это не лучшее сравнение с тем, что дает параллельная загрузка скриптов. Это был самый близкий пример в разметке, который я мог использовать для описания упорядоченного поведения, к которому я пришел. Мне, наверное, не стоило даже приносить defer - просто запутывает обсуждение.

Позвольте мне просто перефразировать сказанное выше: «Для современных браузеров LABjs - это своего рода« полифил »для« упорядоченного асинхронного »поведения, которое невозможно выбрать только для разметки в любом браузере».

Мне нравится «заказанный асинхронный режим», это хорошая фраза.

Kyle> аффаик, скрипты с defer будут выполняться _before_ onload, даже до domready.
Сценарии с атрибутом async будут выполняться как можно скорее и _всегда_ _перед_ загрузкой, но не обязательно до готовности

@ aaronpeters--
Я думаю, ты немного сбился с пути. Вот как я это понимаю:

async скрипты (будь то в разметке или динамически созданные) будут выполняться как можно скорее, то есть в любое время до или после готовности DOM. Другими словами, скрипты async должны ждать ничего (кроме доступности самого JS-движка). Однако, если они запрашиваются до window.onload , то почти во всех браузерах они будут «задерживать» событие window.onload до тех пор, пока они не загрузятся и не выполнятся. Я думаю, что был задокументированный случай, когда скрипты async не выдерживали window.onload , просто не помня точных деталей.

defer с другой стороны, конкретно означает: ждать, пока не станет DOM-ready. Более того, существует «очередь» всех скриптов с установленным для них defer , так что очередь не обрабатывается до тех пор, пока не будет готов DOM. Это означает, что все они должны выполняться строго после того, как DOM-ready (или, скорее, после DOM готов, а точнее закончил парсинг). Но они могут задерживаться и дальше (если загрузка идет медленно). Но они должны держать window.onload . Я просто припоминаю из смутной памяти прошлого, что в некоторых версиях IE реальная практика этой теории была немного нечеткой.

@getify

Не хотелось даже больше сорвать эту тему, поэтому я разместил свою мысль о предварительной загрузке скрипта и ваше предложение на странице WHATWG здесь: http://jaubourg.net/driving-a-nail-with-a-screwdriver-the-way -web

async скрипты (будь то в разметке или динамически созданные) будут выполняться как можно скорее, то есть в любое время до или после готовности DOM. Другими словами, скрипты async должны ждать ничего (кроме доступности самого JS-движка). Однако, если они запрашиваются до window.onload , то почти во всех браузерах они будут «задерживать» событие window.onload до тех пор, пока они не загрузятся и не выполнятся.

Это, вероятно, будет легче понять, если вы поймете, что JavaScript является однопоточным. (Я знаю, это заняло у меня время ...)

Точно так же, если вы используете setTimeout(fn, 0) для загрузки ресурсов, и они попадают в очередь загрузки до того, как сработает onload , то загрузка этих ресурсов (по-прежнему) задержит onload .

Я думаю, что был задокументированный случай, когда скрипты async не выдерживали window.onload , просто не помня точных деталей.

Я хотел бы получить больше информации по этому поводу. Пожалуйста, помните! :)

Ура загрузчики скриптов!

Проблема, с которой я столкнулся при их внедрении в сети сайтов AOL, связана с условиями гонки. Например, асинхронно загружая jQuery в голову, а затем произнесите плагин jQuery на полпути в документе, асинхронно доставленном внутри сообщения в блоге.

Таким образом, я начал свой собственный научный проект загрузчика скриптов (Boot.getJS), чтобы справиться с этим. Идея состоит в том, чтобы загрузить все скрипты параллельно и выполнить их по порядку, несмотря ни на что, как можно скорее. Он также поддерживает откладывание на готовность или загрузку и кеширование скриптов. Большинство идей заимствованы (украдены) людьми в этой ветке, спасибо, ребята. :)

Поскольку вы обсуждали тесты производительности, я решил поделиться тестовой страницей, которую я создал, чтобы понять различия в производительности, синтаксисе и поведении различных загрузчиков скриптов, проверьте это здесь:

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

Чтобы увидеть, как ведут себя различные загрузчики, очистите кеш и просмотрите сетевые запросы и последнее время, а также порядок, в котором выполняются скрипты.

Дэйв (@artzstudio), спасибо за то, что поделился своими мыслями и за ссылку на вашу тестовую страницу.

Вопрос: почему вы загружаете LABjs на странице '<script> в заголовке'? Это кажется неправильным.

@artzstudio также, вы используете старую версию LABjs. Это намеренно? Если да, то почему?

@aaronpeters В AOL у нас есть скрипты, такие как Omniture, рекламный код (и другие), которые необходимо

Это не было намеренно, этому тесту пару месяцев. Я обновлю библиотеки, когда у меня будет возможность.

К вашему сведению (надеюсь, это несколько интересно / актуально), я провел несколько тестов на Webpagetest.org, чтобы увидеть, что происходит в IE8 при загрузке некоторых тестовых страниц @artzstudio .
Теги скрипта: http://www.webpagetest.org/result/110810_C7_752b756180e132f50a3ef065e9e059ca/
Yepnope: http://www.webpagetest.org/result/110810_8S_a53f4ed2e16179c328fc57c572e71076/
LABjs: http://www.webpagetest.org/result/110810_ZV_1ece92044799e52ed5199aed6b407133/
RequireJS: http://www.webpagetest.org/result/110810_Z3_a1537e41a0b0570286151859973d0cfa/

Видео, сравнивающее Yepnope и LABjs: http://www.webpagetest.org/video/view.php?id=110810_074cb94c1b04a7ac9bd6538ec3fdd8d3c07f842d

Некоторые примечания:

• Gzip отключен на сервере, поэтому больший размер файла RequireJS влияет
• Как упоминалось ранее, страница тегов сценария загружает LABjs в HEAD (не имеет смысла), и это, конечно, влияет

По этим двум причинам я создал видео, в котором показаны только Yepnope и LABjs.

Что мне интересно, так это то, что время начала рендеринга намного лучше для LABjs. Это почему? Хотелось бы лучше понять.

Заключительное замечание: я публикую это не с целью отдать предпочтение LABjs, а не Yepnope или чему-то в этом роде. Просто делюсь данными ...

Извините, я понимаю, что вы имели в виду о LABjs в тесте <script>. Исправлено сейчас вместе с обновлением до LABjs.

@ artzstudio--

Таким образом, я начал свой собственный научный проект загрузчика скриптов (Boot.getJS), чтобы справиться с этим. Идея состоит в том, чтобы загрузить все скрипты параллельно и выполнить их по порядку, несмотря ни на что, как можно скорее.

Знаете ли вы, что именно для этого LABjs разработан и работает очень хорошо (если я сам так говорю)? Я имею в виду, вам просто нужен был другой API, или как насчет функциональности загрузки параллельного скрипта было недостаточно?

В любом случае, как бы я ни любил хвастаться LABjs, я не думаю, что эффективно увязать в этой теме обсуждения типа «посмотрите, мой загрузчик сценариев лучше справляется с X». Эти обсуждения полезны, но в другом месте.

В конце концов, вся технология загрузчика скриптов сводится к нескольким простым идеям. Независимо от того, какой модный API вы накладываете поверх него или какие варианты использования вы обслуживаете, технология остается неизменной. В наши дни должно быть 50 различных загрузчиков скриптов, и на самом деле ни один из них не предлагает ничего особенного с точки зрения технологий, только разные API. Так что сравнение API-интерфейсов на самом деле неуместное обсуждение.

Нам следует сосредоточиться на том, можно ли использовать базовую технологию загрузки скриптов, которая в настоящее время доступна в браузерах, для повышения производительности загрузки страниц по сравнению с простым использованием тегов скрипта в разметке. Это моя давняя посылка о том, что это абсолютно верно, но эта посылка подвергалась сомнению в этой беседе. Итак, задача №1 - ответить на этот вопрос.

Если мы обнаружим, что теги сценария просто лучше, чем загрузка сценария, тогда мы можем просто остановить все это безумие и закрыть все наши проекты. Но я подозреваю, что это не так. ;-)

Задача №2 - раз и навсегда выяснить, всегда ли объединение сценариев лучше, чем параллельная загрузка. Опять же, мое предположение (и мое тестирование) показывают, что объединение всех файлов в один - это хорошо, но тогда вам нужно разбить этот большой файл на 2-3 примерно равных части и параллельно загрузить эти фрагменты. Так что нам действительно нужно проверить и эту теорию.

Если мы обнаружим, что script-concat всегда лучше, то опять же, загрузчики сценариев по-прежнему полезны, если учесть, что большинство сайтов загружают сценарии из более чем одного места (jquery из Google CDN, Google Analytics из Google, кнопки facebook / twitter / g + , так далее). Итак, в качестве задачи № 3 нам нужно будет определить, настолько ли лучше concat, что вы должны размещать свои собственные копии всех этих файлов, объединяя их вместе с вашим собственным кодом.

Кайл, не могли бы вы просмотреть исходный код моего примера и сообщить мне, как я могу настроить LabJS для выполнения всех скриптов на странице по порядку (даже вне цепочки)? Я вполне мог неверно истолковать API (как сказал Пол, загрузчики скриптов сложны,% -).

10 августа 2011 г. в 9:09 [email protected] написал:

@ artzstudio--

Таким образом, я начал свой собственный научный проект загрузчика скриптов (Boot.getJS), чтобы справиться с этим. Идея состоит в том, чтобы загрузить все скрипты параллельно и выполнить их по порядку, несмотря ни на что, как можно скорее.

Знаете ли вы, что именно для этого LABjs разработан и работает очень хорошо (если я сам так говорю)? Я имею в виду, вам просто нужен был другой API, или как насчет функциональности загрузки параллельного скрипта было недостаточно?

---

В любом случае, как бы я ни любил хвастаться LABjs, я не думаю, что эффективно увязать в этой теме обсуждения типа «посмотрите, мой загрузчик сценариев лучше справляется с X». Эти обсуждения полезны, но в другом месте.

В конце концов, вся технология загрузчика скриптов сводится к нескольким простым идеям. Независимо от того, какой модный API вы накладываете поверх него или какие варианты использования вы обслуживаете, технология остается неизменной. В наши дни должно быть 50 различных загрузчиков скриптов, и на самом деле ни один из них не предлагает ничего особенного с точки зрения технологий, только разные API. Так что сравнение API-интерфейсов на самом деле неуместное обсуждение.

Нам следует сосредоточиться на том, можно ли использовать базовую технологию загрузки скриптов, которая в настоящее время доступна в браузерах, для повышения производительности загрузки страниц по сравнению с простым использованием тегов скрипта в разметке. Это моя давняя посылка о том, что это абсолютно верно, но эта посылка подвергалась сомнению в этой беседе. Итак, задача №1 - ответить на этот вопрос.

Если мы обнаружим, что теги сценария просто лучше, чем загрузка сценария, тогда мы можем просто остановить все это безумие и закрыть все наши проекты. Но я подозреваю, что это не так. ;-)

Задача №2 - раз и навсегда выяснить, всегда ли объединение сценариев лучше, чем параллельная загрузка. Опять же, мое предположение (и мое тестирование) показывают, что объединение всех файлов в один - это хорошо, но тогда вам нужно разбить этот большой файл на 2-3 примерно равных части и параллельно загрузить эти фрагменты. Так что нам действительно нужно проверить и эту теорию.

Если мы обнаружим, что script-concat всегда лучше, то опять же, загрузчики сценариев по-прежнему полезны, если учесть, что большинство сайтов загружают сценарии из более чем одного места (jquery из Google CDN, Google Analytics из Google, кнопки facebook / twitter / g + , так далее). Итак, в качестве задачи № 3 нам нужно будет определить, настолько ли лучше concat, что вы должны размещать свои собственные копии всех этих файлов, объединяя их вместе с вашим собственным кодом.

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment -1772315

Можно было бы подумать, что Physics считает concat лучшим. Каждое новое HTTP-соединение - это еще один медленный старт + налог в 100 мс в худшем случае от CDN.

Однако правда о документах заключается в том, что они могут быть очень длинными. Таким образом, загрузка одного файла BFJS в голову может излишне замедлить инициализацию модулей. Загрузка в конце может вызвать раздражающий FOUC. Большие файлы могут иметь последствия для мобильных устройств: http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

Я думаю, что это мотив, стоящий за правилом Содерса «разделить полезную нагрузку» (http://oreilly.com/server-administration/excerpts/9780596522315/splitting-the-initial-payload.html). Нам также нужно делать то, что ощутимо быстрее.

И, к сожалению, это сводится к ответу типа «зависит от обстоятельств», что делает эту проблему достаточно интересной, чтобы развлекать всех нас.

Я играю с гибридным подходом, когда вызовы getJS ставятся в очередь и периодически объединяются с заданным интервалом времени, а также объединяются на уровне зависимости модуля (например, объединение зависимостей RequireJS вместо загрузки по одному), все на лету на фронтэнде.

Это научный эксперимент, который, как вы отметили, скоро будет бессмысленным, но тем не менее интересным.

@getify : Я знаю, что на данный момент это просто насмешка на параде, но все же.

Если мы обнаружим, что теги сценария просто лучше, чем загрузка сценария,
тогда мы сможем просто остановить все это безумие и закрыть все наши проекты.
Но я подозреваю, что это не так. ;-)

Я мог бы много чего сказать о змеином масле, но демонстрация тоже подойдет:

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

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

Это страница со 100 КБ текста, 10 изображениями и 171 КБ JavaScript. В оригинальной версии используется один минифицированный файл, который включает jQuery, jQuery-UI, Underscore и Backbone, а также файл timer.js который записывает результаты времени загрузки. Версия LABjs загружает каждый из 5 (отдельно минифицированных) файлов JavaScript с помощью LABjs.

Вы обнаружите, что не только в версии LAB нет никаких преимуществ, но и что дополнительные HTTP-запросы только ухудшают производительность загрузки и должны конкурировать с другими активами на странице, такими как изображения. Но все это уже много раз говорилось раньше ...

Я могу предвидеть контраргумент о загрузке ваших скриптов по частям ... но это полностью ортогонально методике загрузки скриптов, поэтому, пожалуйста, оставьте его вне обсуждения.

Во что бы то ни стало остановите безумие.

@jashkenas Полный, 100% акк. Загрузчики скриптов просто добавляют накладные расходы, усложнение и точки отказа. Один файл, объединенный с сервером, загружается быстро (расчетная оценка), как с точки зрения чистого времени передачи, так и с точки зрения эффективности интерпретаторов JavaScript, и в качестве бонуса gzip-сжатие работает лучше, если у вас есть только один файл.

Я должен сказать, что версия LABjs _ иногда_ загружается быстрее в моем браузере (по сравнению с ванильной страницей), но не постоянно. Также onload не всегда срабатывает, что кажется ... странным.

Да, сжатие дает вам еще больший выигрыш с меньшим количеством HTTP-запросов.

И речь идет не о догме, это не обязательно должен быть _single_ JS-файл для всего приложения - два или три с defer подходят для более детального кеширования, так как они загружаются позже.

Некоторые исследования команды Google Page Speed:

http://pagespeed-velocity2011.appspot.com/#8 см. слайды 8–14, что делает обсуждение более неубедительным.

Мне все еще нравится атрибут @defer скрипта, и я считаю, что это разумное базовое значение по умолчанию, если только вы не планируете потратить много часов / дней на тестирование производительности ваших собственных вариантов.

@miketaylr : Да, пожалуйста,

Labjs всегда загружается быстрее всего в моем браузере (Safari 5.1) даже с обновлением сдвигом или когда элементы кэшируются.

Конечно, использование загрузчика скрипта без конкатенации будет медленнее, чем тэг конкатенированного скрипта. Вот почему люди (YUI, requireJS) создали загрузчики сценариев, которые загружают объединенные файлы и службы, которые объединяют их по запросу (https://github.com/rgrove/combohandler).

Давай, это обсуждение бессмысленно. Загрузчики сценариев предназначены для загрузки сценариев по запросу, особенно после взаимодействия с пользователем, например, загрузки логики за диалоговым окном и проверки формы при нажатии кнопки «войти в систему».

У меня есть скрытое подозрение, что @madrobby слишком упрощают ситуацию.
Стив предполагает, что параллельная загрузка имеет несколько преимуществ для ряда проблем с блокировкой и браузеров _ (да, это означает, что это не WebKit) _. Он также упоминает стратегию загрузки самого минимума JS, необходимого для задач внутренней загрузки, а затем, при необходимости, загрузки остальных позже. Поскольку ситуации и потребности разработчиков различаются, я не знаю, входит ли загрузчик скриптов в шаблон _ (включен по умолчанию) _, но я бы пока не стал выкидывать ребенка с водой в ванне.

Если это не было ясно в моем исходном посте. Я склонен согласиться (с jdalton), что у загрузчиков сценариев есть немало преимуществ в тщательно протестированных и специфических средах, требующих особого внимания. Я не думаю, что это подходящее значение по умолчанию.

Я согласен с @jdalton : нет загрузчика для всех размеров. Я лично использую разные загрузчики скриптов в зависимости от моих реальных потребностей и проектов. Иногда подойдет что-то простое, например yepnope или LabJS, для других RequireJS - находка. Я не уверен, что шаблон должен заставить его войти. Это сложно, потому что идея заключалась бы в том, чтобы шаблон упростил переключение на загрузчик сценариев ... чтобы я не выбрасывал ребенка с водой из ванны просто пока тоже нет.

Кроме того, @getify , притворяться, что все загрузчики скриптов на самом деле используют одну и ту же технологию, является очень неинформированным заявлением.

Чего стоит ...
это

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

лучше, чем это

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

по той причине, что он неблокирующий. Таким образом, последующие изображения и файлы CSS должны будут подождать, пока этот файл не будет загружен с последней версией. Первый - асинхронный - это должен знать каждый, независимо от того, решите ли вы использовать загрузчик скриптов или нет.

re: «притворяться, что все загрузчики скриптов на самом деле используют одну и ту же технологию, - это очень неосведомленное утверждение».

Если они делают это не так, значит, они делают это неправильно.

Честно говоря, использование appendChild вышло из употребления ...: D

Однако я добавил этот тестовый пример в AssetRace.

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

Это ускоряет стрельбу на загрузке, поэтому _может быть_ какая-то ощутимая выгода. Но время финиша примерно такое же ...

@ded : Мы не говорим о некомпетентной большой блокировке <script> в <head> здесь ... мы говорим о тегах скрипта с defer или async Атрибут <body> , где нечего блокировать.

@ jaubourg--

Кроме того, @getify , притворяться, что все загрузчики скриптов на самом деле используют одну и ту же технологию, является очень неинформированным заявлением.

Это полное неверное представление о том, что я имел в виду. Фактически, большинство загрузчиков скриптов НЕ делают то, что, как я думаю, им следует делать (и что LABjs сейчас делает) с точки зрения использования лучших технологий. Моя точка зрения заключалась в том, что даже если все они использовали лучшие технологии, все еще есть конечный предел тому, что мы можем делать с технической точки зрения. Я почти уверен, что нет загрузчиков, которые используют какую-то волшебную серебряную пулю, о которой LABjs не знает или не использует. Вы не можете заставить свет двигаться быстрее скорости света, независимо от того, что вы делаете или как возитесь с числами.

Спорить о технологии внизу (просто сказать «эй, посмотри на мой крутой и лучший API») бессмысленно. Лучшая технология загрузки скриптов - это известное конечное количество (даже если многие загрузчики безответственны и не используют его). Мы можем настаивать на улучшении технологий (как и я), но споры о том, у кого лучше API в загрузчике, ничего не делают для этой цели.

Этот поток действительно, кажется, имеет наибольший смысл в попытке определить, достаточно ли хороши теги сценария сами по себе (с задержкой или без нее) или помогают ли загрузчики сценариев повысить производительность. Во-вторых, нам нужно выяснить, действительно ли concat является конечной целью загрузки скрипта.

Это также спорный вопрос (для этого потока), что у загрузчиков сценариев есть все эти другие варианты использования, которые они могут выполнять, которые теги сценария разметки не могут выполнять (например, по запросу / ленивая загрузка). Опять же, на данный момент это в основном данность, поэтому попытки восстановить этот факт бессмысленны.

NO U

ЗАГРУЗИТЕ ГНЕВ!

Посмотреть исходное сообщение можно здесь.

Также, любые люди, оскорбленные мультяшным пенисом: добро пожаловать в Интернет! Я очень рекомендую вам начать свое путешествие здесь .

Хорошо, я создал 3 теста, чтобы проиллюстрировать некоторые моменты. Во-первых, ручные теги сценария (в качестве основы):

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

Обратите внимание, что DOMContentLoaded (также известный как «DOM-ready») появляется намного позже, после завершения скриптов. Это плохо. Хотя фактическое время загрузки страницы может быть таким же, как и в более поздних тестах, воспринимаемое время загрузки страницы всегда будет намного медленнее, если DOM-ready блокируется (поэтому многие сайты ждут, пока DOM-ready присоединяется к поведению кликов, применять к контенту улучшения на основе JS и т. д.).

Теперь происходит то, что мы используем defer в наших тегах скрипта:

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

Что ж, это хорошо, мы исправили проблему задержки DOMContentLoaded, но теперь у нас есть другая проблема. Встроенный блок скрипта не работает с defer . Он выполняется немедленно. Ой. Кстати, это не ошибка, это конкретно диктуется спецификацией.

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

Тест LABjs имеет в основном те же (или лучшие) показатели производительности по сравнению с тестом defer , но он не пропускает встроенный код для запуска после завершения скриптов.

Попробуйте эти тесты несколько раз в современных браузерах (Chrome 13, FF5 и т. Д.). На мой взгляд, LABjs всегда работал примерно так же или лучше с тестом defer . За все свои попытки я никогда не видел, чтобы LABjs работал хуже, чем тест defer . Попробуйте эти тесты в старых браузерах (например, FF3.5 или IE7), и вы увидите, что загрузчик скриптов начинает заметно превосходить другие тесты.

Несмотря на то, что тест LABjs имеет те же числа, что и тест defer в новейших браузерах, это нарушает условия сделки, если defer нельзя использовать с кодом defer ALL (работает только для кода, загружаемого через внешний файл). МНОГО сайтов загружают скрипты, а затем имеют встроенный код для активации / инициализации кода, который они только что загрузили. defer предлагает нам решения этой проблемы.

Следовательно, defer не подходит в качестве технологии «общей загрузки скриптов». Следующий лучший вариант - загрузчик скриптов.

@getify

Дело не только в микрооптимизациях ... и, ДА, API важен и, как правило, является хорошим индикатором ограничений, присущих базовой технологии, в основном из-за упомянутых микро (или даже макро) оптимизаций. Дело не только в загрузке скриптов. Сложное управление зависимостями, правильная песочница и настоящая, настоящая модульность - это не то, что нужно вымывать только потому, что это вас не интересует. Угадай, что? Это на самом деле то, что нужно людям, и производительность загрузки страницы может быть достигнута на достаточно хорошем уровне с помощью статических тегов скрипта.

В конечном итоге все сводится к тому, что внедрение тегов сценария не является подходящим инструментом для этой задачи: на самом деле этого никогда не было. Это просто очень уродливый хакер. В этом смысле вы на самом деле не настаиваете на лучшей технологии: вы настаиваете на том же с новыми видами предостережений, которые никто из нас еще не может сделать. Пожалуйста, подумайте всего на секунду и посмотрите, щелкнет ли он, наконец.

Что действительно бесит, так это то, что вы отказываетесь приводить единственный аргумент в пользу внедрения тега сценария в отличие от правильного, нативного API javascript для загрузки сценария. Вы просто игнорируете все это. Я избавлю вас от неприятностей: здесь нет аргументов . Но, хех, у всех нас может быть какая-то мысленная мастурбация по поводу тонкостей defer и async и мы чувствуем себя богами javascript, верно? Или обсудите оптимизацию 50 мс, как если бы она действительно помогала кому-то в этой отрасли.

Если вы, наконец, решите, что я достаточно достоин разумного ответа (в отличие от еще одной рекламы LabJS), сделайте это в моем блоге и оставьте эту ветку в покое. Спасибо.

@jaubourg -
Я прочитал ваш пост в последнюю ночь. В ответ я планировал написать сообщение в блоге, в котором по большей части хвалил и хвалил вас за хорошие мысли, которые вы там изложили. К сожалению, то, что вы предлагаете, уже ДОЛГО разглашалось участниками обсуждения на W3C и WHATWG. Вы довольно опоздали на вечеринку.

Было несколько человек, которые поддержали совершенно новый API загрузчика, и было несколько важных контраргументов, почему это, вероятно, не лучший вариант. Опять же, я планировал написать вам ответ в осторожном и аргументированном сообщении в блоге, чтобы помочь все это объяснить.

Жаль, что тебе нужно пойти и быть здесь таким придурком. Теперь мне кажется, что этот аргументированный пост в блоге будет пустой тратой времени. Вы, очевидно, думаете, что я идиот, и никогда не задумывались о том, о чем пытаетесь рассказать. Потому что я не потратил большую часть прошлого года на то, чтобы быть полностью одержимым технологией загрузчика сценариев и тем, как получить спецификацию и браузеры, чтобы сделать ее лучше. Ага, я идиот. Я явно никогда раньше не думал ни о чем, кроме тега скрипта.

Вы, очевидно, не слушали 15 раз, когда я говорил, что эта ветка имеет лучшую цель - сосредоточиться на конкретных вопросах, которые подняли Пол Айриш и Алекс Секстон: достаточно ли defer ? script-concat лучше, чем параллельная загрузка?

Это более важные вопросы.

Не то, какая основная технология "загрузчика" используется. Есть другой, лучший форум для обсуждения того, что такое основная технология загрузчика. Я понимаю, тебе не нравится тег скрипта. Отлично. Проведите десятки часов в списке W3C / WHATWG, пытаясь убедить Иэна и других вас выслушать. Они, вероятно, все просто зевнут и скажут: «Мы уже это обсудили, уходите».

@getify : Создание нелепых тестов не

Если вы проведете тестирование, чтобы подтвердить предварительное заблуждение ... ваши тесты всегда подтвердят это заблуждение. Никогда не спорили о 20 тегах сценария против 20 загрузок сценария LABjs. Речь идет об интеллектуальном обрезании, объединении, уменьшении, сжатии и загрузке вашего JavaScript в как можно меньшем количестве HTTP-запросов, а затем его кэшировании.

С одной стороны, у нас есть надежный, проверенный временем подход, поддерживаемый браузером, который заметно лучше работает на реальных страницах; и, с другой стороны, у нас есть взломанная «технология», которая в прошлом фактически ломала каждый сайт, который ее использовал после обновления браузера, которая в среднем работает явно хуже и с гораздо большим разбросом медленности.

Это простой выбор.

@ jashkenas--

Мы также знаем, что запуск блоков встроенных скриптов перед «отложенными» скриптами ни в коей мере не является проблемой для реальных сайтов.

Эээ ... Я думаю, вы не сделали view-source примерно на 98% всех сайтов в Интернете, которые на самом деле используют встроенные блоки сценариев в разметке для выполнения / инициализации кода, который они загрузили ранее (блокировка) вызов тега скрипта.

Если @paulirish предполагает, что defer достаточно хорош и что загрузчики скриптов не нужны, тогда я считаю важным указать, почему на самом деле defer НЕ достаточно хорош.

ВАС могут интересовать только несколько контролируемых вами узкоспециализированных сайтов, на которых у вас есть полная возможность оптимизировать процессы сборки и т. Д. Я, с другой стороны, забочусь о помощи в повышении производительности на сайтах с длинным хвостом в Интернете, а именно о тех, с полдюжиной тегов сценария (некоторые из них являются встроенными блоками сценария!), где использование полдюжины вызовов $LAB.script() на самом деле, вероятно, повысит производительность. Это то, чем всегда была компания LABjs. То, что это не то, что вас волнует, не означает, что это не актуально.

Никогда не спорили о 20 тегах сценария против 20 загрузок сценария LABjs.

В этой ветке обсуждается вопрос о том, работают ли 3-4 тега сценария (с defer или без него) хуже, одинаково или лучше, чем 3-4 сценария, динамически загружаемых с помощью параллельного загрузчика сценариев. Мои «нелепые тесты соломенного человека» на самом деле предназначены для проверки именно этого.

По моему опыту, загрузчики скриптов сокращают время загрузки страницы на многие миллисекунды. Но я думаю, что мы все упустили суть. У JavaScript есть несколько более серьезных проблем:

• Отсутствие операторов импорта затрудняет модульную организацию кода.
• Глобальные переменные сталкиваются, если не уделять много внимания тщательному размещению имен всех элементов.
• Невозможно четко увидеть, какие зависимости скрипта

Я не использую RequireJS, потому что он загружается быстрее, хотя это хороший побочный эффект. Я использую его, чтобы организовать свое JS-приложение в виде небольших модулей, как в NodeJS. Каждый модуль четко перечисляет свои зависимости и использует шаблон песочницы для поддержания чистоты глобального пространства имен. Модули (и их зависимости) могут быть загружены заранее или загружены по запросу (например, по щелчку пользователя) или загружены лениво. С помощью этих приемов вы действительно можете отточить свое исполнение. И RequireJS также поставляется с инструментом сборки, который объединяет и минимизирует все зависимости в один (или несколько) готовый файл (ы) gzip для развертывания. Решение этих трех проблем - огромная победа для меня.

Я понимаю, почему люди спорят об использовании загрузчика сценариев, который не решает эти проблемы. Если производительность - это единственный вопрос, и это спорно, тогда конечно. Но используйте загрузчик модулей AMD, например RequireJS, и дискуссия становится неактуальной. Модули - это будущее JavaScript. Дэйв Херман из Mozilla работает с членами совета директоров из Apple и Google над добавлением собственных модулей к самому языку . А пока мы можем получить все преимущества, используя загрузчик модулей AMD. Дело не только в производительности.

@getify

Вы не можете ожидать, что люди будут относиться к вам иначе, чем вы относитесь к другим. Покровительство - не лучший способ получить достойную реакцию (и, боже, вы покровительствуете), и, как я сказал в своем сообщении в блоге, я не думаю, что вы идиот, я просто думаю, что вы одержимы (как вы говорите себя, кстати), и это серьезно ухудшает ваше суждение. Как я уже сказал в своем сообщении в блоге, решать эту проблему должны не W3C или WHATWG, а сам EcmaScript: это не проблема браузера, это проблема языка. Так вот, не отвечайте, если не хотите, это ваша прерогатива.

Может, я поступил так же жестко, но я просто защищаю то, во что верю.

Я откажусь от подписки на эту ветку и больше буду ее комментировать. Извините, что сорвал материал @paulirish и @SlexAxton.

@getify

ВАС могут интересовать только несколько контролируемых вами нишевых сайтов, которые у вас есть
полная возможность оптимизировать процессы сборки и т. д.
С другой стороны, забота о повышении производительности на сайтах с длинным хвостом
Интернет, те, у которых есть полдюжины тегов сценария (некоторые из них встроенные сценарии
блоков!), где использование полдюжины вызовов $ LAB.script () на самом деле скорее всего
улучшить производительность. Это то, чем всегда была компания LABjs. Просто так
это не то, что вас волнует, не означает, что это не актуально.

Если LABjs помогает посредственным сайтам загружаться немного менее плохо ... я думаю, это благородная цель. Но если вы серьезно относитесь к медленно загружающемуся веб-сайту и загружаете его как можно быстрее - потенциально буквально на секунды быстрее, чем позволяет LABjs, тогда вам следует сохранять непредвзятость и признать, что более простой и менее хрупкий техника также более производительна.

В этой ветке обсуждается вопрос о том, нужно ли использовать 3-4 тега скрипта (с отсрочкой или без нее)
работает хуже, так же или лучше, чем 3-4 скрипта, динамически загружаемых с использованием
загрузчик параллельных скриптов. Мои "нелепые тесты соломенного человека" на самом деле предназначены для
проверить именно это.

Дискуссия в этой ветке идет о том, как создать веб-сайт, чтобы загружать и выполнять свой JavaScript как можно быстрее. Продажа змеиного масла клиентам и продвижение его среди веб-разработчиков - это медвежья услуга для обоих.

Задержка существует в Интернете. Объедините, минимизируйте и заархивируйте свой JS и загрузите его внизу страницы с помощью как можно меньшего количества HTTP-запросов. Достаточно.

@ jashkenas--

Если LABjs помогает посредственным сайтам загружаться немного менее плохо ... это благородная цель, я думаю

Есть сотни сайтов, о которых я лично знаю за последние 2 года, которые ничего не делали, кроме как заменяли свои теги скриптов вызовами $LAB.script() , и по всем направлениям все они показали лучшую производительность (некоторые резко, некоторые лишь скромно).

Были написаны статьи (полностью независимые от меня и не связанные со мной), направленные на то, чтобы помочь сайтам в различных отраслях (например, электронная коммерция, недвижимость и т. Д.) Повысить производительность (поскольку более высокая производительность означает больше конверсий), где эти статьи рекомендуются сайтам, которые они заменяют теги сценария вызовами $ LAB, и многие люди в этих обсуждениях ответили утвердительно, что это им помогло.

Если бы в этих статьях говорилось: «Хорошо, что вам нужно сделать для повышения производительности, это нанять администратора сервера, который понимает gzip и может установить ruby ​​или node.js, чтобы вы могли выполнять некоторые автоматизированные процессы сборки .......» эти люди Прочитав эти статьи, я бы остекленел и ушел, даже не задумываясь. Но мне нравится верить, что сообщение «Эй, замените <script> на script ()» было для них довольно простым, чтобы понять и понять.

Что я хотел для LABjs, так это простое решение, которое кто-то может легко заменить, не задумываясь, и заменить свои теги скрипта. Я понимаю, что если вы можете лично проконсультироваться с сайтом и выяснить, как лучше всего оптимизировать, вы можете выжать намного больше производительности из множества сайтов. Но я также понимаю, что это далеко за пределами моих возможностей как одного человека сделать для длинного хвоста Интернета, и точно так же сказать всем этим сайтам мам и пап: «Эй, идите, получите автоматизированную систему сборки и убедитесь, что она использует gzip» - это все равно что говорить с ними на чужом языке. OTOH, было довольно успешно сказать: «Эй, возьми эти 3 тега скрипта и сделай из них 3 вызова скрипта (). Видишь, как легко это было?»

В итоге, мой подход к LABjs заключался в том, чтобы поразить низко висящие плоды.

Ничто из этого не означает, что более сложные подходы к оптимизации невозможны - они явно возможны, и когда у меня появляется возможность проконсультироваться, я определенно их исследую. Просто хочу сказать, что для многих веб-сайтов это более сложно / сложно, чем они хотят или могут себе позволить. И я просто пытаюсь помочь этим сайтам улучшить их так, чтобы им было легче понять.

@ jashkenas--

потенциально буквально на секунды быстрее, чем позволяет LABjs, тогда вам следует сохранять непредвзятость и признать, что более легкая и менее хрупкая техника также более эффективна.

Не было никаких доказательств того, что LABjs значительно замедляет работу каких-либо сайтов. Есть МНОГО подтвержденных доказательств того, что это помогает многим сайтам. Поэтому я не верю в это - то, о чем вы говорите, является ложной предпосылкой, предполагающей, что факты не являются доказательствами.

@paulirish нашел сообщение, в котором указаны проблемы с атрибутом defer :
http://hacks.mozilla.org/2009/06/defer/

Исходя из перспективы производительности мобильных устройств - как сказал @jashkenas , всегда лучше

Проводится много исследований по использованию методов встраивания, при которых вы кодируете изображения в base64 в строки, а затем сохраняете их как пары ключ: значение в localStorage, просто чтобы уменьшить количество HTTP-запросов и использовать «кеширование»: http://channel9.msdn.com/Events / MIX / MIX11 / RES04 - отличная презентация Джеймса Миккенса из Microsoft Research.

Вот довольно хорошая подборка по производительности мобильных устройств с HTTP-запросами и их влиянию на взаимодействие с пользователем: http://davidbcalhoun.com/present/mobile-performance/

Я работаю над RequireJS и хочу прояснить, что стремится сделать RequireJS:

1) Показать способ модульного кода в JS, который хорошо работает везде, где выполняется JS.
2) Загрузите скрипты.

Часть «скрипты загрузки» - необходимая часть достижения первой цели. В dev не рекомендуется просто объединять все ваши скрипты, потому что это усложняет отладку, номера строк не совпадают. Загрузчики скриптов также упрощают использование JS API для загрузки кода по запросу. Для приложений размером с веб-почту это необходимая часть истории производительности. Однако объединение сценариев в один или небольшое количество запросов обычно является лучшим вариантом развертывания.

Но цель requirejs - быть прокладкой / полифилом / чем угодно, чтобы показать, как создавать и ссылаться на модульные блоки кода, которые могут использоваться совместно с другими таким образом, чтобы препятствовать глобальным переменным и поощрять явные зависимости.

Он использует AMD API, который был разработан с другими людьми, создающими модульные загрузчики скриптов (включая тесты на соответствие ), с целью помочь информировать любые обсуждения для формата модуля в JS. Такой подход, заключающийся в реализации реальных реализаций и достижении соглашения с другими по API, является способом достижения прогресса.

В частности, учитывая сетевой характер JS и его связь с веб-документами / приложениями, API плагина загрузчика - это то, что должно каким-то образом поддерживаться модулями ES Harmony, и я работаю над прототипированием модулей гармонии ES через requirejs loader , чтобы я мог лучше понять предложение гармонии и

Для исполнителей :

• Есть несколько вариантов загрузчиков, поддерживающих AMD ( curl , Dojo 1.7 , loadrunner , requirejs), даже очень маленький, который можно использовать для оптимизации «все сценарии в одном JS-файле», выполняемой для развертывания. Таким образом, можно добиться отличной производительности, поощряя лучшие практики кодирования - упрощая совместное использование кода, избегая глобальных переменных, используя явные зависимости.
• Оптимизатор requirejs работает очень быстро в Node и может работать в Rhino. Это инструмент командной строки, но последний основной код ветки экспортирует его как модуль, который можно использовать в Node, поэтому, например, его можно запускать через HTTP-сервер на основе Node, который может выполнять сборку на лету . Таким образом, вы всегда можете разрабатывать в режиме «всегда загружается один скрипт», если хотите, но затем вы можете исключить один или два модуля из этого оптимизированного файла, чтобы вы могли легко их отлаживать.

В контексте этого билета : выбор AMD-совместимого загрузчика (не обязательно requirejs) соответствует целям шаблона HTML: указать путь к лучшим практикам как в коде, так и в производительности. Тем не менее, я понимаю, что попытка разработать шаблон HTML - это очень сложная задача, поскольку существуют конкурирующие интересы, некоторые стилистические аспекты, поэтому я признателен за то, что сейчас не хочу давать рекомендации в этой области.

Я просто хочу прояснить, что цель requirejs и загрузчиков, реализующих AMD API, дает больше преимуществ, чем просто загрузка некоторых скриптов, которые сбрасывают глобальные объекты и заставляют разработчика разработать полное, иногда неявное, дерево зависимостей. Эти цели достигаются с помощью решений с надежными характеристиками.

Чтобы переориентироваться с более раннего ... сравнивая тест defer тестом LABjs ... (и игнорируя тот факт, что defer не работает со встроенными блоками сценария), кто-нибудь видит, что Тест LABjs работает хуже, чем тест defer ? Я пробовал его в нескольких браузерах и даже на своем мобильном устройстве, но до сих пор вижу примерно равные числа.

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

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

@getify

Я понятия не имею, почему и как вы можете это оптимизировать, но у меня на моем 3+-летнем MacBook есть постоянная разница в 3000 между ними, что благоприятствует @defer .

Однако я тестировал только с Firefox.

@ espadrine - довольно странно. хотел бы разобраться в этом. с какой версией Firefox вы тестируете? можешь прислать мне скриншот с результатами?

Просто объедините и минимизируйте все свои JS и CSS, встроите их прямо в свою HTML-страницу и покончите с этим. Единый HTTP-запрос FTW! :П

Если серьезно, существует так много более серьезных проблем, на которых мы должны сосредоточиться в этом сообществе, а не только на том, как ваше приложение будет загружаться. Скорее всего, самый простой метод (теги сценария внизу), вероятно, будет достаточно быстрым. Просто напишите отличные приложения и в конце разберитесь с производительностью загрузки. Делать что-либо еще - это преждевременная оптимизация.

Есть ли общее мнение участников этой темы о том, что AMD должна быть золотым стандартом для организации кода JS? На самом деле не видел других вариантов, но я согласен, что Boilerplate был бы отличным началом для настройки людей прямо при организации кода.

Канал обновления Firefox UX 8.0a1 (07.08.2011).

Опять же, не знаю почему, и это, вероятно, очень конкретно. LABjs, вероятно, очень хорош с устаревшими браузерами.

Пожалуйста, не используйте тестовую страницу @getify ни для чего, кроме смеха. Цитировать:

<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 , если вы хотите провести настоящий тест, не стесняйтесь форкнуть репозиторий AssetRace @SlexAxton и добавить версию LABjs ... или создать тестовую страницу, которая использует _real_ файлов JavaScript с реальными задержками.

Кроме того, убедитесь, что вы действительно объединяете JS для одного тега скрипта - defer или нет. Дело в том, что один и тот же контент, обслуживаемый одним HTTP-запросом, превосходит тот же контент, обслуживаемый 10 HTTP-запросами.

Никогда не было доказательств того, что LABjs значительно
замедление любых сайтов. Есть МНОГО подтвержденных доказательств того, что это очень помогает
сайтов. Так что я не куплюсь на это - то, о чем вы говорите, является ложной предпосылкой, предполагающей
факты, не подтверждаемые доказательствами.

Выше было продемонстрировано, что LABjs действительно значительно замедляет работу сайтов, заставляя их JS конкурировать во многих HTTP-запросах с их изображениями, CSS и другими ресурсами. @getify : Мне бы хотелось увидеть ссылку на сайт, который, по вашему мнению, значительно продемонстрировал ваше преобразование в LABjs. Возможно, мы сможем загрузить копию и использовать ее в качестве тестового примера, который вы будете уважать.

Для записи, я думаю, было бы разумно получить еще несколько изображений на тестовой странице репозитория AssetRace. Но сейчас это определенно хорошая база.

@artzstudio, организующая ваш JS с помощью загрузчика AMD, действительно является золотым стандартом, по крайней мере, до тех пор, пока модули Harmony не будут закончены и широко поддерживаются. Тогда будет четкий путь миграции с модулей AMD на модули Native.

Модули AMD, являющиеся золотым стандартом, - это, безусловно, мнение (которое я могу разделить). Однако есть много умных людей (на ум приходят Иегуда Кац и Дэн Уэбб), которым это не нравится и которые предлагают другие решения.

Загрузчик @danwrong может делать и то, и другое, если это тоже ваша сумка: https://github.com/danwrong/loadrunner

Там есть довольно хорошие вещи. Потенциально немного более практично для людей, не использующих JS. Мне нравятся модули AMD для моих вещей, но не все хотят тратить время на преобразование каждой версии библиотек, которые они используют, в модули.

Я знаю, что @strobecorp работает над своим собственным решением, которое не требует большого количества дополнительного кода, необходимого для модулей AMD.

Хотя я бы хотел, чтобы AMD использовалась по умолчанию, это, вероятно, неразумно с точки зрения нескольких библиотек / newb, как бы мне этого ни хотелось.

@ jashkenas--

Пожалуйста, не используйте тестовую страницу @getify ни для чего, кроме смеха.

Если вы не можете вести себя вежливо, у меня нет желания обсуждать с вами что-либо еще. Я действую добросовестно. Буду признателен за небольшую общую порядочность.

@getify , если хочешь провести настоящий тест

Я обязательно прошу вас объяснить, почему то, что я делаю, настолько безумно, смешно и недействительно. Я воспользовался подходом непосредственно от Стива Содерса, который (благодаря своему огромному опыту и мудрости) предлагал во всех своих тестах использовать серверное время для управления скриптами, уменьшая количество вариаций в ваших тестах. Именно этим я и занимаюсь.

Более контролируемый тест - это действительный базовый тест. Это устоявшаяся научная практика. Это не означает, что тесты в реальном мире также бесполезны, но это также не значит, что вы можете стрелять в меня и сказать: «Смейтесь над ним, какой идиот, потому что он проводит свои тесты иначе, чем я думаю. должно быть сделано."

не стесняйтесь форкнуть репозиторий AssetRace @SlexAxton и добавить версию LABjs

Я с радостью сделаю это. Но не потому, что я согласен с тем, что другие мои тесты недействительны. Если у вас есть аргументированные и уравновешенные аргументы в пользу того, почему моя тестовая установка недействительна, поделитесь, пожалуйста. Но перестань быть таким идиотом.

@ jashkenas--

Дело в том, что один и тот же контент, обслуживаемый одним HTTP-запросом, превосходит тот же контент, обслуживаемый 10 HTTP-запросами.

Я знаю, что вы (и другие) продолжаете разглагольствовать здесь о том, как это обсуждение должно быть посвящено конкатенированию и отсутствию конкатенации. Если вы читали намного раньше в этой ветке, я признал, что есть два вопроса, которые необходимо решить. Насколько я понимаю, эти два вопроса являются ортагональными. Во-первых, если теги сценария в разметке могут быть такими же хорошими (или лучше), чем динамические элементы сценария, используемые в параллельном загрузчике сценариев. ЭТОТ ВОПРОС я все еще пытаюсь решить с помощью своих тестов.

Второй вопрос, на который мы еще не ответили, - всегда ли лучше с помощью скрипт-конкатенации. Я знаю, что вы уже в этом убедились, но у меня есть контрдоказательства, позволяющие предположить, что это не так просто. Этот вопрос также требует тщательной проверки. Но это не то, о чем я сейчас пытаюсь разобраться в этой теме.

Продолжая настаивать на том, что ваш путь лучше, вы просто делаете дискуссию менее приятной для себя. Все, что я пытаюсь сделать, это методично собрать доказательства по каждому из этих двух основных вопросов, чтобы мы могли перестать гадать и быть более информированными. Почему ты не можешь помочь с этим, вместо того, чтобы пытаться быть для меня придурком из-за того, что ты со мной не согласен?

Что касается теста defer сравнению с тестом LABjs, я только что сделал быстрый снимок экрана, на котором тестировались два теста лицом к лицу в IE9, FF8 (ночью) и Chrome15 (канарейка).

http://www.screenr.com/icxs

Чтобы ответить на предыдущий вопрос причудах defer , посмотрите, как "DOMContentLoaded" ведет себя в IE, Chrome и Firefox в тесте defer .

В IE9 и Chrome15 событие DOMContentLoaded задерживается (блокируется) и не запускается до тех пор, пока не будут запущены скрипты. Однако в FF событие DOMContentLoaded не задерживается, оно запускается сразу, а скрипты начинают выполняться после него. Это гигантское несоответствие между современными браузерами и одна из причин, почему я не думаю, что defer достаточно.

Насколько я могу судить по спецификации, я не уверен, какое поведение является правильным. Но я знаю, что это явно странно и несовместимо между браузерами.

@getify Я не пытаюсь быть придурком. Я искренне извиняюсь за то, что обидел ваши чувства.

Естественно, то, что вы считаете разглагольствованием, я считаю предметом обсуждения ... а то, что я считаю змеиным маслом, вы рассматриваете как полезный шаг вперед.

Эти две проблемы действительно ортогональны (язык, который я использовал в своем исходном посте).

Во-первых, если теги сценария в разметке могут быть не хуже (или лучше), чем
динамические элементы сценария, используемые в загрузчике параллельных сценариев.

Мы полностью согласны по этому поводу - это не имеет значения. Конечно, параллельная загрузка будет быстрее, чем последовательная загрузка более чем одного скрипта. И, конечно же, сделать это неблокирующим образом, либо в конце тега <body> , или с помощью defer , или с помощью загрузчика сценария, это будет лучше, чем блокирование в <head> .

Но это упускает суть. Включение последовательных тегов сценария - соломинка для сравнения, потому что никто, кого не волнует производительность своего JavaScript, не будет использовать этот подход. Угадайте, что еще быстрее, чем последовательные теги сценария? _Что-нибудь_.

Второй вопрос, на который мы еще не ответили, заключается в том,
script-concat всегда лучше.

Мы «добрались» до этого вопроса. Фактически, это вопрос @paulirish вверху этой страницы. Если вы не пытаетесь разобраться в этом в этой теме, вам нужно это сделать. Это затрагивает самую суть всех ваших заявлений о том, чем занимается LABjs, не только в этой ветке, но и на протяжении многих лет.

Этот вопрос также требует тщательной проверки.

Повторюсь, вот (честный) тестовый пример. Те же 5 реальных скриптов, загружающихся на страницу среднего размера с другими присутствующими активами, один использует лучшие практики LABj для обеспечения порядка загрузки, а другой использует один объединенный скрипт:

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

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

Если у вас есть другой тестовый пример, который вы хотели бы изучить, или реальный веб-сайт, использующий LABjs, с которым вы хотите поэкспериментировать, поделитесь им.

@SlexAxton Спасибо. Мне было бы любопытно услышать мнение Иегуды по этому поводу и другие твердые мнения (кроме того, что его слишком сложно реорганизовать). Я нашел это, но не разговоры.

Чтобы прояснить комментарий @geddesign : на сегодняшний день похоже, что модули AMD можно довольно легко преобразовать в модули гармонии, но это предложение модулей гармонии, которое я считаю, все еще находится в стадии разработки, оно может измениться позже. Он еще не прошел тщательного тестирования реализации, но начинает кое-что делать. С другой стороны, плагины AMD loaders + loader могут дать солидную обратную связь при опробовании некоторых идей гармонии.

К комментарию @SlexAxton :

Для loadrunner: мне не ясно, синтаксис лучше, просто другой. Он поддерживает AMD, так что все еще работает.

Для стробоскопа: я еще не видел на нем кода от них. Они кажутся достаточно сосредоточенными на внутреннем мире, хотя я ценю работу, которую Иегуда проделал, чтобы сделать это развитие более открытым. Алекс, если у вас есть указания на то, что они думают, я был бы признателен за их получение.

Если подход будет разрешать вложенные зависимости (что необходимо для широкого совместного использования кода), вам понадобится синтаксис, который:

• дает имя единице кода
• способ указать зависимости
• оболочка функции вокруг этого кода, чтобы гарантировать, что он не будет выполняться, пока не будут готовы зависимости. Или всегда требуйте сборку или доступ к XHR, который не масштабируется по всему спектру JS-разработки.

Это то, что предлагает AMD, и синтаксис максимально упрощен. Все остальное - это просто борьба за имена и, возможно, некоторые типы пунктуации. В какой-то момент просто нужно что-то выбрать, и до сих пор я не слышал от Дэна Уэбба или Иегуды о структурных недостатках, которые делают AMD несостоятельной. Некоторые загрузчики AMD, такие как requirejs, могут загружать только обычные скрипты, они не обязательно должны быть модулями.

Придумать синтаксис кода очень легко, особенно для модулей, и я понимаю, что у каждого есть свои личные предпочтения. Однако AMD имеет довольно глубокую историю выполнения тяжелой работы по достижению какого-то соглашения и, что более важно, реального кода и развертывания для его резервного копирования. Я чувствую, что теперь ответственность ложится на других, чтобы они действительно были очень четкими и ясными в отношении того, почему AMD не подходит (этот билет не место для этого, не стесняйтесь связаться со мной вне списка или используйте список amd-implementation ) .

Но я ценю точку зрения

@SlexAxton Я с тобой. Мой собственный код - полностью AMD. Хотя я хочу, чтобы все писали модули вместо скриптов, к счастью, RequireJS может загружать как простые скрипты, так и модули.

Если вы имеете в виду шаблон Иегуды handlebars.js, он отлично работает с RequireJS. Особенно, если вы пишете плагин, который компилирует / кэширует шаблон и возвращает его функцию шаблона.

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

Однако я не согласен с этим утверждением:

Хотя я бы хотел, чтобы AMD использовалась по умолчанию, это, вероятно, неразумно с точки зрения нескольких библиотек / newb, как бы мне этого ни хотелось.

Ньюбсу нужна чистая структура, которую AMD предоставляет даже больше, чем опытному разработчику, поскольку они более склонны к конфликтам глобальных переменных, ужасной организации кода, которая приводит к огромным беспорядочным файлам JS, к которым никто не хочет прикасаться из-за страха столкнуться с конфликтами слияния, Библиотеки получают огромную выгоду от модулей, поэтому будущие Dojo 1.7 и Mootools 2.0 переходят на AMD. Я надеюсь, что jQuery попадает на борт - одна из самых больших жалоб - это то, что он «все или ничего». Вы не можете использовать его отличные манипуляции с DOM, не загрузив на страницу его анимацию, ajax, события и т. Д. Так что да, AMD беспроигрышный вариант. Если HTML5 Boilerplate хочет указать людям на передовой опыт, было бы стыдно не учитывать AMD. Он элегантно решает многие проблемы JavaScript.

Чтобы было ясно. Я согласен. Я бы хотел, чтобы они использовали все необходимое.

Я просто не думаю, что они это сделают.

Я не думаю, что люди еще понимают, что AMD - это модное слово, «вещь», о которой должен знать каждый серьезный разработчик. Как только они это сделают, они захотят сказать своим начальникам и в будущих интервью, что они знают об этом и используют это.

Если мы все сделаем свой вклад и скажем «смотри, это легко, лучше и важно» и сделаем это модным словом, стада последуют за нами ради своей карьеры.

@ jashkenas--

Во-первых, если теги сценария в разметке могут быть такими же хорошими (или лучше), чем динамические элементы сценария, используемые в параллельном загрузчике сценариев.

Мы полностью согласны по этому поводу - это не имеет значения.

Собственно, я начал свое участие в этом потоке, предполагая, что все согласны с тем, что динамическая загрузка элементов скрипта приведет к более высокой производительности, чем теги скрипта. Но и @paulirish, и @slexaxton поставили это предположение под сомнение в _this_ ветке.

@paulirish предположил, что defer - это достаточный способ сделать простой тег скрипта таким же хорошим (или лучше), чем альтернатива загрузки динамического элемента скрипта. Я не согласен с тем, что defer достаточно, и теперь установил несколько причин, почему.

Итак, я думаю, что мы ДОЛЖНЫ изучить первый вопрос и выяснить, лучше ли defer чем загрузчики скриптов. Может быть несколько ограниченных случаев, когда вы можете обойтись с defer , но что касается обобщенного случая, загрузчики скриптов обрабатывают / нормализуют все причуды, тогда как defer подвергает вас этим проблемам.

Я до сих пор не уверен, что все видят или соглашаются с тем, почему defer недостаточно.

Повторюсь, вот (честный) тестовый пример. Те же 5 реальных скриптов, загружающихся на страницу среднего размера с другими присутствующими активами, один использует лучшие практики LABj для обеспечения порядка загрузки, а другой использует один объединенный скрипт:

Это ваша (и чужая) ложная предпосылка тестирования. Я никогда не утверждал, что загрузка 5 скриптов вместо 1 будет быстрее. Никогда. Всегда. Могу я быть более ясным? Предпосылка никогда не была 5 против 1.

Первый тест заключался в тестировании 3 тегов скрипта против 3 вызовов script() , потому что это честный тест. И я думаю, что видео и тесты показывают, что загрузка скрипта в ЭТОМ сценарии полезна.

Второй и гораздо более сложный для проверки вопрос - есть ли способ улучшить производительность сайта, который уже загружает весь свой JS в один файл. Большинство людей говорят, что это невозможно улучшить. Я не согласен.

ПРИМЕЧАНИЕ. Причина, по которой этот вопрос является ортогональным, заключается в том, что вы можете загрузить этот единственный файл concat либо с помощью тега сценария, либо с помощью динамической загрузки document.createElement("script") type. В любом случае вопрос об одном файле concat является допустимым, но независимо от того, лучше ли теги сценария или динамическая загрузка сценария.

То, что вы слышали от меня несколько раз в этой теме, а также во многих других контекстах (включая все мои выступления на конференции по этой теме, сообщения в блогах и т. Д.), Заключается в том, что я думаю, что вы могли бы улучшить конкатенацию одного файла JS. подход путем «разбиения на фрагменты» (то есть разбиения большого файла concat) на 2 или 3 фрагмента (самое большее). Если блоки имеют ~ равный размер и загружаются параллельно, то возможно, что страница будет загружаться быстрее, даже с дополнительными накладными расходами HTTP из-за соединения «Keep-Alive», эффекта параллельной загрузки и т. Д.

На самом деле я писал на эту тему ДОЛГО время назад, еще в ноябре 2009 года, вскоре после первого выпуска LABjs: http://blog.getify.com/2009/11/labjs-why-not-just-concat/

В том сообщении в блоге и с тех пор я сказал, что ЕСЛИ у вас есть возможность (не все ... на самом деле, большая часть Интернета нет) использовать процессы сборки для объединения, вам следует сделать так. Период. Всегда. Всегда объединяйте файлы из 10-20 локальных файлов в гораздо меньшее количество.

НО, я также говорю, что если у вас есть этот единственный файл concat, также может быть полезно попытаться загрузить ваш единственный файл в 2-3 куска, загружаемых параллельно (с использованием загрузчика сценариев).

Почему это могло быть лучше? Я изложил это в том сообщении в блоге, но вкратце:

1. эффект параллельной нагрузки реален. спросите об этом пользователей bit-torrent. накладные расходы HTTP также реальны и действуют, чтобы противодействовать и устранять это преимущество. Но это не значит, что извлечь выгоду невозможно. Используя соединение Keep-Alive, вы можете получить 2 или 3 одновременных подключения (без 2-3 полных штрафов за накладные расходы) и загрузить свой код за более короткий промежуток времени. Будет ли это в 1/3 раза быстрее (на 60-70% быстрее), если вы загрузите его тремя частями? Нет. Абсолютно нет. Но может быть на 20-30% быстрее.
2. Обслуживание всего вашего кода в одном файле не позволяет вам делать разные заголовки кеша для разного жизненного кода. Например, jquery очень стабилен, и его не нужно повторно загружать. но ваш UX-ориентированный код на вашем сайте может быть очень нестабильным (вы можете настраивать его раз в неделю или чаще). Делать короткие заголовки кэширования в одном файле concat глупо, потому что это приводит к более частым повторным загрузкам стабильного кода без надобности. Делать длинные заголовки кеширования в одном файле concat также глупо, потому что это заставляет вас аннулировать кешированный файл (параметр перебора кеша и т. Д.) И принудительно выполнять полную повторную загрузку всего файла, когда вы просто настраиваете один байт вашего более изменчивый код. Итак, разделение вашего большого файла concat на 2 части, один для стабильного кода, другой для изменчивого кода, позволяет вам иметь разные заголовки кеширования для каждого фрагмента. Это делает использование кеша более эффективным и приводит к потенциально более высокой производительности в течение определенного периода времени, поскольку пользователи повторно посещают ваш сайт.
3. Исследования показали, что в среднем одно представление страницы использует гораздо меньше, чем 100% JS, загружаемого на страницу (по некоторым оценкам, это около 20-30% кода). Загрузка всего вашего кода за один раз, сразу, в начале загрузки страницы, излишне перегружает строку, чтобы протолкнуть 70-80% файла, который тогда не нужен (и может «никогда» не понадобиться). Если ваш код разбит на 2 части (один является более важным кодом, а другой - менее критическим), и вы загружаете первый фрагмент сразу, а второй фрагмент загружаете через несколько секунд после загрузки страницы, вы можете освободить канал для гораздо более важных изображений / CSS и контента. По сути, разбиение на части позволяет вам расставить приоритеты для вашего кода.

Итог ... по теме concat vs. parallel ... Я всегда говорю людям: и то, и другое.

@getify хорошо сказано.

Я поддерживаю LABjs Кайла.
Как консультант, помогающий сайтам повышать производительность, я много раз видел, как LABj работают хорошо.
Это не только значительно улучшило производительность (не только 100 мс, но и более 1 секунды), но и понравилось разработчикам.
Легко понять, легко реализовать.

И я воспользуюсь этой возможностью, чтобы публично сказать: «Спасибо, Кайл, за огромную поддержку LABjs. Вы в несколько раз превзошли мои ожидания».

Используя соединение Keep-Alive, вы можете получить 2 или 3 одновременных подключения (без 2-3 полных штрафов за накладные расходы на подключение)

HTTP не мультиплексирует / не чередует ответы, поэтому вы не можете иметь параллельные загрузки без предварительного открытия нескольких соединений. Идеальный случай постоянного и конвейерного соединения - это непрерывная загрузка одного файла (+ несколько заголовков).

@ pornel--

Я воочию убедился и подтвердил, что браузеры могут открывать несколько подключений параллельно одному серверу, при этом с включенным Connection Keep-Alive накладные расходы для второго и третьего подключений значительно меньше, чем для первого. Я говорю об этом эффекте.

@getify Fantastic, я думаю, мы достигли какого-то консенсуса. Чтобы освежить память:

Я могу предвидеть контраргумент о загрузке ваших скриптов по частям ...
но это полностью ортогонально методике загрузки скрипта, поэтому, пожалуйста, оставьте его
обсуждения.

Да, я согласен с тем, что загрузка ваших изменчивых скриптов в файл JS, отличный от ваших постоянных скриптов, - это здорово. Загрузка скрипта, который нужен только для определенной страницы, только на этой конкретной странице, также хороша.

Итак, если я веб-разработчик и у меня есть страница с кучей сценариев JavaScripts, что мне делать? Используйте LABjs или объедините мои постоянные скрипты в один файл, а мои изменчивые скрипты в другой и загрузите оба в нижней части тега тела с помощью <script defer="true"> ?

Почему я должен подвергать свое приложение проблемам с кешированием, несовместимости браузеров, гонке с изображениями на странице и прочим проблемам, которые приносит с собой загрузчик скриптов?

Если вся предпосылка использования загрузчика сценариев для повышения производительности заключается в том, что это проще и проще, чем использование двух тегов сценария ... У меня есть мост в Бруклине, чтобы продать вам.

@getify реализовал веб-сервер более одного раза: keep-alive никоим образом не влияет на параллельные запросы и только снижает затраты на последующие запросы. Разделение тела с двумя последующими запросами с сохранением активности по-прежнему дороже, чем один запрос. Наличие двух одновременных запросов для двух частей тела, вероятно, будет работать лучше, но имейте в виду, что браузер будет открывать только ограниченное количество одновременных запросов (в зависимости от браузера и конфигурации примерно 5, я думаю), что нормально, если все вы загружаете свои три файла js, но это, как неоднократно указывал

@ jashkenas-

Итак, если я веб-разработчик и у меня есть страница с кучей сценариев JavaScripts, что мне делать? Использовать LABjs или объединить мои постоянные скрипты в один файл, а мои изменчивые скрипты в другой и загрузить оба внизу тега body с помощью <script defer = "true">?

TL; DR: оба

Во-первых, многие сайты в Интернете собираются с помощью CMS, а это означает, что наличие встроенных блоков сценариев, разбросанных по всей странице, является обычным явлением, и ОЧЕНЬ сложно решить с точки зрения обслуживания, просто сказав «переместите весь этот код в один файл». Итак, я думаю, что предположение о том, что _most_ сайтов может обойтись без какого-либо «встроенного кода» для запуска после загрузки и выполнения другого внешнего скрипта, в лучшем случае маловероятно.

Во-вторых, я доказал, что defer разному действует по отношению к DOMContentLoaded в разных браузерах. В некоторых браузерах скрипты идут до DOM-ready, в других браузерах они идут после DOM-ready. Если у вас есть код в ваших скриптах, который зависит от того, что происходит до или после DOM-ready, использование defer может быть проблемой. Особенно верно то, что это чувствительная область с большим количеством недоразумений и путаницы, поэтому быстро становится «это не простое прямое решение». Это требует гораздо больше размышлений.

В-третьих, я думаю, что для многих сайтов изменение разметки для использования $LAB.script() вместо <script> намного проще, чем объяснять им, как установить некоторый автоматический (или ручной) процесс Bulid на их сервер. Особенно, если этот сайт находится на общем хостинге (большая часть Интернета), и они на самом деле не контролируют большую часть своего сервера, просить их выяснить процессы сборки, чтобы их код не был потерян, - это ... ну. .. нетривиально.

Можно ли это преодолеть? Ага. Конечно могут. Но они требуют много работы. В некоторых случаях (например, в случае с DOM-ready) им может потребоваться кропотливая корректировка вашего кода. Чтобы разобраться во всем этом, нужен человек, обладающий самоотверженными усилиями, большим опытом и страстью в этой области.

Напротив, они могут получить «быстрый выигрыш», выбрасывая LABjs вместо тега <script> . Им не о чем думать (кроме document.write() ). В большинстве случаев «это просто работает». И в большинстве случаев они видят немедленное увеличение скорости загрузки страницы. Для большинства сайтов это большая победа.

Итак, чтобы ответить на ваш вопрос, я бы сказал, как я сказал ранее, делайте и то , defer .

Кроме того, наличие LABjs уже делает для вас глупо простым выполнение шага 3, который заключается в том, чтобы начать выяснять, какой код вы можете «отложить / загружать по требованию» позже. Вы не можете этого сделать без загрузчика скриптов. Наличие и знакомство с LABjs означает, что вам вообще не нужно беспокоиться о том, как загрузить этот сценарий по запросу - это уже выяснено.

@ rkh--

Я продемонстрировал мне (особенно в Apache, с переключением настройки Keep-Alive), как были затронуты несколько параллельных запросов (положительно, когда Keep-Alive был там). Я не эксперт в этой области, поэтому я не могу спорить о точных деталях того, как это работает или нет. Я могу сказать, что время запроса №2 было меньше времени запроса №1, когда там был Keep-Alive. Каким образом браузер и сервер сделали это, я могу делать лишь частично обоснованные предположения.

Разделение тела с двумя последующими запросами с сохранением активности по-прежнему дороже, чем один запрос.

Я никогда не утверждал, что второй запрос бесплатный. Я утверждал, что второй запрос не такой дорогой, как первый. Итак, если мы предположим, что должен быть сделан хотя бы один запрос, параллельный второй запрос НЕ то же самое, что наличие двух полностью независимых соединений с одним и тем же сервером, с точки зрения накладных расходов или временных затрат.

Для оценки, похоже, что запрос №1 был X для обслуживания, а №2, параллельно с присутствием Keep-Alive, был 0,7X. Мне объяснили, что сервер смог использовать часть существующих накладных расходов на соединение при обслуживании второго запроса, что сделало его немного дешевле. При выключенном Keep-Alive второй запрос не имел такого ощутимого снижения.

Однако все эти разговоры - очень глубокая кроличья нора. Я не эксперт по серверам. Мне не обязательно быть. Я могу только объяснить, что я действительно видел (и создавал тесты) по этой конкретной теме ... могу ли я проверить это время загрузки одного файла 100k по сравнению с загрузкой двух половин того же файла параллельно, и будет ли второй тест измеримым сумма быстрее. Как я уже сказал, я видел, что где-то на 15-25% быстрее при параллельном тестировании. Как он это сделал и каким-то образом смог преодолеть ужасный эффект «OMG HTTP RESPONSE OVERHEAD IS TERRIBLE» и по-прежнему получать выгоду от двух параллельных нагрузок, я полагаю, я не квалифицирован, чтобы научно доказывать. Но это определенно произошло при наблюдении.

Господи, вы, люди, быстро набираете текст. Я заканчиваю читать, перезагружаю страницу и получаю еще девять комментариев.

Мне нужна помощь. Я попытался точно указать, где в этой беседе мы перешли от обсуждения _ того, что лучше всего работает для шаблонного файла HTML_, к обсуждению _ того, являются ли загрузчики сценариев во всех случаях змеиным маслом.

@getify , вы, безусловно, должны защищать LABjs и отвечать на конкретные критические замечания, сделанные другими участниками обсуждения, но (за исключением @jashkenas) я думаю, что те, кто критикует LABjs, делают это, чтобы продемонстрировать, что это не лучшее решение для шаблона. Вы утверждаете, что легче преобразовать устаревшие страницы в LABjs, чем в script[defer] , и это может быть правдой, но как это применимо к шаблонному HTML-файлу (который, по определению, начинается с нуля)?

Вы говорите, что он разработан для людей, у которых нет причудливых процессов сборки, но вы также, кажется, отстаиваете объединение, разделение на блоки равного размера и параллельную загрузку. Разве это не задача сценария сборки? Опять же, это кажется неправильным выбором для шаблона, разработанного для предоставления пользователю разумных значений по умолчанию. Если пользователь хочет увеличить скорость на 20-30%, он может выбрать обновление позже, чем предлагает шаблон, но это нетривиальная задача.

Сказав все это, если вы, ребята, хотите продолжить общую тему («Загрузчики сценариев: ценный инструмент или змеиное масло?»), Я с радостью буду торчать и приготовить попкорн.

@getify : Я могу согласиться с тем, что 2-е и 3-е соединения могут открываться быстрее, чем первое - первое ожидает DNS и, возможно, маршрутизация самого первого пакета на сервер немного медленнее, чем маршрутизация остальных по тому же пути. В HTTPS кеш сеанса SSL очень помогает при последующих подключениях.

Однако я не вижу актуальности Keep-Alive в этой ситуации. Последующие _requests_ на том же соединении запускаются быстрее с Keep-Alive, но эти запросы являются последовательными внутри соединения.

Я почти закончил - я только что дошел до своего «чертовски безумного» момента в отношении загрузчиков скриптов.

Тем не менее, я думаю, что эта беседа для фестиваля пламени на самом деле была довольно продуктивной. Если LABjs хочет заявить о своих правах на несчастные и некомпетентные веб-сайты и оставить в покое людей, которые действительно хотят, чтобы их сайты загружались быстро, это большой шаг вперед.

чувак, расслабься

@ savetheclocktower--

Справедливые вопросы.

Я не начинал свое участие в этой теме, решительно выступая за включение LABjs (или любого загрузчика скриптов) в h5bp. Я думаю, что это полезно (см. Ниже), но меня не сильно беспокоило то, что я теряю сон. Ясно, что этот поток превратился в тотальную атаку на все, что является «загрузкой сценария». Это, очевидно, то, что меня волнует немного больше.

Вы говорите, что он разработан для людей, у которых нет причудливых процессов сборки, но вы также, кажется, отстаиваете объединение, разделение на блоки равного размера и параллельную загрузку. Разве это не задача сценария сборки?

Я рекомендую сначала переместить все ваши десятки тегов сценария в параллельный загрузчик сценариев, такой как LABjs. Это не требует ничего, кроме возможности корректировать разметку. Это гораздо более простой / менее пугающий шаг, чем, например, указание сайту для родителей использовать автоматизированную систему сборки на основе node.js.

А для тех, кто МОЖЕТ делать сборки своих файлов, я рекомендую LABjs по-прежнему иметь преимущество, потому что он может помочь вам загружать эти фрагменты параллельно. Если вы категорически не согласны с тем, что чанки хоть как-то полезны, то вы не увидите причин использовать LABjs вместо defer . Но если вы понимаете, почему разбиение на фрагменты _ может быть_ полезно, из этого следует, что загрузчик сценариев _ также может помочь_ в этом процессе.

Опять же, это кажется неправильным выбором для шаблона, разработанного для предоставления пользователю разумных значений по умолчанию.

Единственная причина, по которой я думаю, что загрузчик сценария (в частности тот, который разработан, как LABjs, чтобы иметь однозначное сопоставление между тегами сценария и вызовами script() ) имеет преимущество в шаблоне, заключается в том, что в шаблоне , вы часто видите один экземпляр чего-то (например, тега), и ваша тенденция при создании своей страницы состоит в том, чтобы просто копировать и вставлять дубликаты столько раз, сколько вам нужно. Итак, если у вас есть плохо работающий шаблон (тег скрипта) в шаблоне, люди будут склонны дублировать тег скрипта десятки раз. Я думаю, что в среднем, если бы они вместо этого дублировали вызов $LAB.script() несколько раз, есть большая вероятность, что их производительность будет не такой плохой, как могла бы быть.

Это единственная причина, по которой я начал участвовать в этой теме. Это единственная причина, по которой я не согласился с комментарием @paulirish о "слепой вере" ПУТЬ выше здесь, в ветке.

Тааааааааааааааааааааааааааааааааааааааааааааааааааааоо

Я думаю, что ясно, что это обсуждение ушло в прошлое, подходит ли загрузчик скриптов для проекта h5bp. Но это хорошо, поскольку эту тему стоит изучить.

Тем не менее, я очень заинтересован в воспроизводимых тестовых примерах наряду с результатами тестов.

Также кажется, что спецификация для @defer была написана, чтобы защитить некоторые из неустойчивых поведений, которые браузеры предоставляют вместе с ней. Такое поведение следует задокументировать. Я могу помочь перенести его в MDC, когда он будет готов.

Нам нужна прямая документация по этому поведению, охватывающая все браузеры, различные типы подключения и сетевые эффекты. Я не уверен, должен ли тестовый стенд использовать cuzillion или Assetrace, но это можно определить.

Я создал билет, чтобы заинтересоваться этим https://github.com/paulirish/lazyweb-requests/issues/42

Присоединяйтесь ко мне, если вам нравятся _superfun_ задачи исследования webperf и документирования доказательств.

Будем считать эту ветку закрытой, господа.

Ленивая загрузка не является основным преимуществом модулей AMD, как описал @jrburke в своих комментариях. Основная причина, по которой я предпочитаю использовать модули AMD, насколько это возможно, заключается в том, что она улучшает структуру кода. Он сохраняет исходные файлы небольшими и краткими - их легче разрабатывать и поддерживать - так же, как использование css @import во время разработки и запуск автоматической сборки для объединения таблиц стилей также рекомендуется для больших проектов ...

Я чувствую, что этот пост, который я написал в прошлом году, подходит к теме: догма производительности - это не только производительность, и убедитесь, что вы не _ тратите время_ на «оптимизацию» чего-то, что не имеет _реального_ значения ...

И я с @SlexAxton , я хочу AMD, но простых тегов сценария, вероятно, достаточно для большинства людей. Возможно, правильным подходом было бы добавить новый параметр для выбора проекта AMD и запуска оптимизатора RequireJS вместо задач _concat_ (

Будем считать эту ветку закрытой, господа.

@paulirish А как насчет включения поддержки AMD? Где мы должны это обсудить?

@benatkin открой новый билет, братан.

@paulirish ОК, спасибо. @jrburke, не

Развлекательно и познавательно. Спасибо ребята.

Я думаю, что кому-то нужно запустить новый проект загрузчика скриптов и назвать его «Issue28». :)

Для максимальной совместимости можно добиться высокой производительности, поместив скрипт внизу, minify, gzip, но не откладывая. По крайней мере, до тех пор, пока совместимость браузеров не станет стабильной в течение нескольких лет подряд.

Узкие места могут возникать из-за рекламы, слишком большого количества javascript, раздутого HTML, слишком большого количества CSS, слишком большого количества фреймов, слишком большого количества запросов, задержки сервера, неэффективного javascript. Приложения, которые используют множество сторонних библиотек, имеют проблемы, вызванные не только слишком большим количеством javascript, но, более того, они, как правило, также имеют много других проблем, в основном раздутый HTML, недопустимый HTML, слишком много css и неэффективный javascript. На ум приходит Твиттер с двумя версиями jQuery и двумя обработчиками onscroll, которые вызывают подпрыгивающий правый столбец при прокрутке.

Самое интересное в том, что если вы знаете, что делаете, вы можете избежать этих проблем. Вам не нужны такие вещи, как jQuery или подчеркивание, поэтому ваши скрипты намного меньше. Вы пишете чистый, простой, корректный HTML и CSS. Как следствие, ваши страницы загружаются быстрее, приложение становится более гибким с точки зрения изменений, а SEO улучшается. Таким образом, использование загрузчика скриптов просто добавляет неоправданной сложности и накладных расходов.

https://github.com/BroDotJS/AssetRage

БУМ! Я закрываю клубы и закрываю нити.

Какая нить ... вау.

Imo, обсуждение началось в контексте h5bp, который должен стать отправной точкой для веб-разработчиков.
Таким образом, вы можете заявить, что веб-разработчик, использующий h5bp, на самом деле будет иметь чистый HTML, чистый CSS, хороший .htaccess и т. Д. И _могут_ даже _не_ страдать от слишком большого количества изображений, неэффективного JS, большого количества дрянных сторонних JS и т. Д. Вы знаете, потому что веб-разработчик, решивший использовать высокопроизводительный h5bp, обеспокоен производительностью и будет обращать внимание на материалы, не относящиеся к h5bp, которые попадают на страницы.

Из темы, и в этом контексте, я думаю, что, к сожалению, недостаточно доказательств, чтобы сделать окончательный вывод.
Я вместе с Полом занимаюсь проведением исследования и документированием того, что необходимо задокументировать.
Считайте меня Павлом.

Примечание. Я не очень хорошо знаком с AMD, и на первый взгляд это кажется мне пугающим или, по крайней мере, не тем, что я могу легко понять. Я думаю, что большинство «обычных» веб-разработчиков согласятся.
То, что вы видите в h5bp, должно иметь низкий входной барьер, иначе он не будет использоваться, а потребление h5bp может быть медленнее, чем могло бы быть без него.
Я сомневаюсь, что AMD принадлежит к h5bp.
Будь проще.

И еще один комментарий ....
«Размещение скриптов внизу» и «Объединение файлов JS в один файл» уже много лет занимают первые места в списке лучших практик Web Perf. Так почему же более 90% обычных сайтов, созданных собственными разработчиками и ведущими агентствами брендов, по-прежнему имеют несколько тегов скриптов в HEAD? Действительно, почему?

А у остальных 9% есть один объединенный JS-файл ... в ГОЛОВКЕ.
Я редко вижу «нормальный» сайт, который _не_ создан каким-нибудь ведущим разработчиком веб-перфоманса с одним скриптом внизу.

Разработчики продолжают создавать сайты, как в течение многих лет.
Владельцы сайтов больше всего заботятся о дизайне и функциях, поэтому разработчики тратят на это свое время.

Изменение способа работы, системы сборки, кода ... это должно быть легко, очень легко, иначе этого не произойдет.

Я работал на многих сайтах, где объединение JS в HEAD в один файл и его загрузка в нижнюю часть BODY приводило к поломке страниц сайта. И что потом? В большинстве случаев это не просто час работы. Необходим серьезный рефакторинг ... и этого не происходит из-за недостатка знаний и, особенно, нехватки времени.

(да ладно, нить закрыта ...)

Мы говорим о библиотеке, построенной на основе jQuery и Modernizr. Говорит все, правда. Кто этим пользуется? О, черт, я забыл, Twitter.com, который использует два jQuerys, а также имеет в исходном коде следующее:

 Строка 352, столбец 6: Конечный тег div виден, но есть открытые элементы.
 Строка ошибки 350, столбец 6: Незакрытый элемент ul.
 Строка ошибки 330, столбец 6: Незакрытый элемент ul.

И проблема с ожиданием, что браузер исправит ошибку, заключается в том, что HTML4 не определил механизмы исправления ошибок, и поэтому вы получите неизвестно что, кто знает где. Конечно, HTML5 определяет обработку ошибок, но это не имеет обратной силы - есть еще много «старых» браузеров.

И, говоря о дерьме, кто-нибудь здесь смотрел на прокладки jQuery ES5?

Кстати, есть ли у вас что-нибудь добавить к вашему заявлению «что веб-разработчик, использующий h5bp, на самом деле будет иметь чистый HTML», aaronpeters?

@GarrettS хорошо, хорошо, я должен был написать "будет _ вероятно_ чистый HTML"

:-D на нас всегда можно надеяться!

Бить дохлую лошадь, я знаю ... но оказалось, что в то время, когда мы вели эту блестящую дискуссию, в текущей версии LABjs действительно была ошибка, из-за которой JavaScript выполнялся в неправильном порядке в некоторых браузерах: https: //github.com/getify/LABjs/issues/36

О, ирония.

должен. оказывать сопротивление. размещение. полностью. [неприличный. изображение. для. предыдущий. заявление .... агггх! АГОНИЯ!

Мне больше всего понравилось, когда чувак, который сделал полностью испорченный ), начал говорить об ошибках разметки.

Этот сайт был передан Пауло Фрагомени. Да, я сделал это и горжусь тем, что написал там, как здесь. Сделай скриншот своего слабого аватара, болван.

... и после того, как вы закончите с этим, попробуйте вытащить голову из своей задницы и понять разницу между моим старым личным веб-сайтом (который больше не поддерживается мной) и тем, который разработан командой и финансируется прибыльная компания с многомиллионным оборотом (хотя Twitter может стоить миллиарды AFAIK).

Рад, что мы сохраняем этот классный вид и _ по теме_, ребята.

jashkenas получил необходимую информацию в начале этого обсуждения.

Но потом была обратная реакция. Нет! Этого не должно быть! Содерс сказал сделать это! И был плохой совет использовать defer, не заботясь о том, как он дает сбой, когда дает сбой.

А потом, по иронии судьбы, из ниоткуда пришло заявление, что пользователи h5bp будут делать все правильно. И это очень иронично, потому что этот комментарий последовал за комментариями его сторонников, которые, очевидно, создают недопустимую разметку и используют множество сторонних слоев абстракции (и ужасных). И после комментария об использовании defer.

Итак, какое отношение все это имеет к тому, что dhtmlkitchen.com не работает? Совершенно очевидно, что ничего. Это был всего лишь слабый джеб форкера h5bp, который терпеть не может критику.

Bros.
Чувак.
Bros.

Эта тема закрыта. Помнить? Тебе не обязательно идти домой, но ты не можешь здесь греться.

Привет, вы помните тот случай, когда мы сделали эпическую ветку, где было несколько дебатов, личные пламенные войны, люди повсюду злятся, несколько непристойных изображений и всестороннее хорошее времяпрепровождение? Не могу поверить, что это было бесплатно. Мы должны сделать это снова когда-нибудь.