Как отложить синтаксический анализ кода javascript

Рано или поздно большинство веб-мастеров озадачивается вопросом оптимизации сайта для его быстрейшей загрузки.

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

Получив от плагина сообщение «При начальной загрузке страницы выполняется синтаксический анализ JavaScript в объеме 142.2Кб. Чтобы ускорить отображение страницы, отложите синтаксический анализ JavaScript», начинающие веб-мастера впадают в ступор: «как его отложить-то. «

На самом деле все несложно.

Можно запустить скрипт через какое-то время после загрузки документа, а не сразу:

script type=»text/javascript» >
function onLoadScript () var scri = document.createElement(‘script’);
scri.src = ‘ путь к файлу > ‘;
document.body.appendChild(scri);
>
window.onload = function () )>
/script >

в качестве примера:

script type=»text/javascript» >
function onLoadScript () var scri = document.createElement(‘script’);
scri.src = ‘chtoto.js’;
document.body.appendChild(scri);
>
window.onload = function ()
/script >

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

источник

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

К примеру, возьмем один из моих сайтов. Использую плагин JCH_Optimize.
Несмотря на то, что скорость загрузки по Google Speed — 90 из 100, немного напрягает результат теста, а именно строка:

При начальной загрузке страницы выполняется синтаксический анализ JavaScript в объеме 485.1Кб. Чтобы ускорить отображение страницы, отложите синтаксический анализ JavaScript.

Итак, начем разбираться. Погуглив, первое, на что наткнулся:

Обрадовался я, скрипт скопировал в head и добавил в его код путь:

Гугл тоже обрадовался моей находчивости и написал:

При начальной загрузке страницы выполняется синтаксический анализ JavaScript в объеме 485.1Кб. Чтобы ускорить отображение страницы, отложите синтаксический анализ JavaScript.

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

Скрипт «Defer loading of JavaScript»

Скрипт «Prefer asynchronous resources»

Есть умельцы, которые решали данную проблему?
UPD: умельцы-то точно есть, например, гиганты вроде read.ру и амазон.com решили данную задачу, странно, что озон не решил.

лично у меня мнение на этот счет совершенно противоположное — в топку.
объясню причину:
для чего всем нам нужен МТ или JQ? в большинстве случаев, для украшательств и всяких разных «прикольных примочек», ибо вызовы через AJAX и передачу данных формы можно реализовать и независимо, меньшим числом кода.
так вот теперь, собссно, вопрос — если «отложить» парсинг JS на «после» загрузки HTML кода, то что увидит пользователь? сначала непонятно отформатированную страницу, которая потом «вдруг» начнет во что-то «превращаться»?
никому не кажется это несколько . ненормальным?

я всегда ЗА оптимизацию, но она должна быть рациональной и обоснованной.

p.s. кстати, если кому интересно, рекомендую проанализировать startup latency самой джумлы (ядра). я уверен, что задержка при загрузке фреймворка (каждый раз, кстати) будет значительней, нежели парсинг JS в браузере (понятно, что с оговорками насчет быстродействия компьютера и т.д.)

p.s. а чтобы ускорить отображение страницы, лучше уберите с сайта нахрен скрипты от VK.com (он же «вконтакте»)

p.s.s.s. и почему получается так, что каунтер от рамблера грузится раньше «вконтактного» скрипта?

имхо, мусор на сайте, а вы занимаетесь оптимизацией не известно чего

Если бы ПС забили на соцсети — убрал бы =) Если честно, напрягает скрипт +1 от Google и периодически тупит твиттер.

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

А так я полностью согласен с первым комментарием: в топку. Но тема полезная, я, допустим, не согласен с:

если «отложить» парсинг JS на «после» загрузки HTML кода, то что увидит пользователь? сначала непонятно отформатированную страницу, которая потом «вдруг» начнет во что-то «превращаться»?

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

источник

В моей статье «Понимание критического пути рендеринга» (перевод статьи) я писала о том, какой эффект оказывают JavaScript-файлы на Критический Путь Рендеринга(CRP).

JavaScript является блокирующим ресурсом для парсера. Это означает, что JavaScript блокирует разбор самого HTML-документа. Когда парсер доходит до тега

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Еще интересен вариант сочетания http/2 и defer: загрузка скрипта и парсинг HTML — могут происходить одновременно, а запуск произойдет в момент, когда HTML будет готов, но раньше, чем это произошло бы при синхронном формировании запросов скриптов по ходу парсинга.

Когда парсер доходит до тега

Является ли блокирующим следующее объявление?

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

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

Тут нет ни загрузки сетевого ресурса, ни исполнения тяжелого кода, а потому вопрос является ли это объявление блокирующим — смысла не имеет.

Но парсер-то остановится, вопрос лишь в том, на долго ли (нет).

Нет. Парсер после полного чтения тэга сразу же пойдет дальше.

Нет, это не вы старый, это пост устарел 🙂 Сейчас как раз склеивание всех скриптов в один файл с его минификацией куда более распространено, чем раньше. requirejs, systemjs, webpack — все они обходят рассмотренную тут проблему, делая ее не такой существенной.

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

Да, но при использовании современных инструментов экосистемы javascript выделение критических ресурсов делается совсем другими методами, имеющими мало общего с атрибутами async и defer.

Хм. Простой пример. Вот есть скрипт гугловый, который подключает карту. Вот есть мой некий common.js , в котором, скажем, описан какой-нибудь полифилл. Сайт встречает заголовком, текстом, формой, кучей текста, картинками и лишь в конце картой. Так вот как раз-таки для скрипта карты и пригодится defer . Гугл, кстати, так и рекомендует подключать у себя в примере.

… и получаем скрипт, который полностью работоспособен только если на тут же самую страницу подключен другой скрипт? Ну, и еще пара десятков сторонних скриптов?

От этого и стараются уйти, в том числе перечисленными мною инструментами.

Мы ускоряем отрисовку, а не ждём пока у нас загрузятся все ресурсы, которые, возможно, нам и не понадобятся. Чанки о том же, по-сути. Можно собрать всё в единый файл и пусть грузится или же разбить на части и грузить первыми только важные ресурсы, а остальные оставить на потом. Как минимум пользователь уже начнёт взаимодействовать с сайтом, а не будет ждать со словами «сайт тормозной». А, может, и вовсе уйдёт.

Суть одна — но механизмы-то разные! Вы понимаете, что выделение чанков в вебпаке совсем не похоже на простановку атрибутов async или defer скриптам?

Можно прочитать хоть сотню постов про атрибуты async и defer — но когда понадобится разбить пакет на чанки — придется лезть в документацию. И обратное тоже верно.

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

Хотелось бы уточнить по поводу сохранения или не сохранения порядка выполнения нескольких скоиптов в случае с async и defer

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

Если внешний JavaScript-файл размещается непосредственно перед закрывающим тегом body, то использование async и defer становится менее уместным

Менее уместно, но всё же уместно? Например, если у нас 5 внешних скриптов в конце body то без defer , они будут загружаться один за другим (так как парсер соответственно поочередно будет переходить от одного тэга script к другому). А вот с defer у каждого тэга можно загрузку распараллелить. Я правильно понимаю?

Вот таким образом он забрал файлы.
А вот таким выполнил:

Уточните пожалуйста, из вашего примера, все 3 скрипта с defer атрибутом или без?

При этом в FF картина следующая:

defer влияет на порядок выполнения. Скрипты без атрибута будут выполняться строго один за другим, как написано.

При наличии атрибута defer порядок выполнения не определен. Кроме того, в defer скриптах нельзя выполнять document.write().

Скрипты без атрибута будут выполняться строго один за другим, как написано.

При открытом отладчике (или, особенно, Firebug’е) это на практике соблюдается не всегда.

браузер гарантирует, что относительный порядок скриптов с defer будет сохранён.

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

If the element has a src attribute, and the element has a defer attribute, and the element has been flagged as «parser-inserted», and the element does not have an async attribute
The element must be added to the end of the list of scripts that will execute when the document has finished parsing associated with the Document of the parser that created the element.

The task that the networking task source places on the task queue once the fetching algorithm has completed must set the element’s «ready to be parser-executed» flag. The parser will handle executing the script.

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

источник

В движках JavaScript для ускорения выполнения кода используется механизм, называемый ленивым синтаксическим анализом (lazy parsing).

В этой статье вы узнаете: что такое ленивый синтаксический анализ, чем он полезен и каковы потенциальные проблемы при его использовании.

V8 — это JavaScript-движок, который используется в Chrome и Node. Хотя эта статья посвящена V8, это не единственный JavaScript-движок, использующий ленивый синтаксический анализ.

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

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

Синтаксический анализ — это второй шаг, преобразование токенов в абстрактное синтаксическое дерево (AST). Вот пример исходного кода с соответствующим ему AST:

Если вы хотите попробовать поиграть с синтаксическими деревьями JavaScript, попробуйте AST Explorer.

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

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

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

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

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

Давайте посмотрим на пример такого поведения.

Node имеет специальный аргумент —trace_parse , при запуске с которым вам будет видно, как происходит синтаксический анализ скриптов или функции. Тем не менее, вывод может быть довольно большим из-за различного внутреннего кода, который Node запускает для начальной загрузки вашей программы. Поэтому вместо Node я буду использовать оболочку V8 под названием d8.

В отличие от Node, d8 не имеет функции console.log , поэтому я использую функцию с именем print :

Здесь у меня две функции sayHi и add , причём add никогда не вызывается.

Всё еще присутствует избыточный вывод, связанный с d8 , но гораздо меньший, чем если бы мы использовали Node ( при использовании d8 из последней сборки v8 избыточный вывод отсутствует, — прим. пер.). Важны три последние строчки.

Когда test.js первоначально анализируется, функции sayHi и add обрабатываются только предварительно, что ускоряет анализ исходного кода.

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

Важно: add никогда не анализируется полностью. Это позволяет экономить время синтаксического анализатора и уменьшает потребление памяти V8.

Если мы добавим add(1, 2) к нашему JavaScript-коду, функция add будет проанализирована во время вызова:

Давайте уберём неиспользуемую функцию add из кода ниже.

Вывод d8 —trace_parse test.js :

Сначала V8 предварительно обрабатывает sayHi , после чего следует полный синтаксический анализ. Тогда предварительный анализ не нужен и наша программа работает быстрее без попыток оптимизации V8!

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

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

Обратите внимание: здесь нет parsing function: constants .

Теперь предположим, что мы хотим, чтобы наш пример sayHi работал быстрее. Что мы можем сделать?

Во-первых, давайте сохраним sayHi как переменную вместо использования объявления функции:

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

Хотя это и не IIFE, V8 будет использовать эвристику и сделает полный анализ с самого начала:

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

На практике общей причиной ненужных предварительных анализов является то, что минификатор UglifyJS удаляет круглые скобки из IIFE для сохранения байтов:

Это не меняет поведение кода, но нарушает эвристику Chrome.

Если вы запустите optimize-js на уменьшенном коде выше, скобки будут восстановлены:

Кстати, readme optimise-js уточняет, что Chakra, движок JavaScript, используемый в Edge, способен правильно определять синтаксис !Function ()() IIFE и предотвращать предварительный анализ.

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

В документации optimize-js есть результаты несколько тестов производительности, показывающие впечатляющие ускорения — около 20%. Однако в Chrome на моем ноутбуке фактическое улучшение для образца приложения на React составляет всего 6 мс (время загрузки кода уменьшилось с 24мс до 18мс).

Ускорение будет заметнее на более медленных устройствах. Но не на iPhone: движок Safari, JavaScriptCore, не показывает улучшения для оптимизированного кода.

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

источник

Рано или поздно большинство веб-мастеров озадачивается вопросом оптимизации сайта для его быстрейшей загрузки.

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

Получив от плагина сообщение «При начальной загрузке страницы выполняется синтаксический анализ JavaScript в объеме 142.2Кб. Чтобы ускорить отображение страницы, отложите синтаксический анализ JavaScript», начинающие веб-мастера впадают в ступор: «как его отложить-то. «

На самом деле все несложно.

Можно запустить скрипт через какое-то время после загрузки документа, а не сразу:

script type=»text/javascript» >
function onLoadScript () var scri = document.createElement(‘script’);
scri.src = ‘ путь к файлу > ‘;
document.body.appendChild(scri);
>
window.onload = function () )>
/script >

в качестве примера:

script type=»text/javascript» >
function onLoadScript () var scri = document.createElement(‘script’);
scri.src = ‘chtoto.js’;
document.body.appendChild(scri);
>
window.onload = function ()
/script >

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

источник