Меню Рубрики

Как отложить синтаксический анализ кода 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-спрайты).

источник

Профиль
Группа: Участник
Сообщений: 4
Регистрация: 20.5.2011
Где: Одесса

sashawebdirect
Дата 22.3.2012, 00:55 (ссылка) | (нет голосов) Загрузка .
Код
https://apis.google.com/_/apps-static/_/js/gapi/googleapis_client,iframes_styles_bubble_internal/rt=j/ver=q12yzL_k0Dc.ru./sv=1/am=!brN6X75-Zu- >http://factoryofsites.ru/wp-includes/js/jquery/jquery.js?ver=1.7.1 (85.1Кб)
https://plusone.google.com/_/apps-static/_/js/plusone/p1b,p1p/rt=j/ver=LR9r-WJTgqg.en_US./sv=1/am=!YYn1ndwXmbCIxnTNUQ/d=1 (51.2Кб)

неОпытный

Профиль
Группа: Модератор
Сообщений: 9820
Регистрация: 18.5.2006
Где: Днепропетровск

речь о другом — где подключать скрипты: в head или в конце body

skyboy
Дата 22.3.2012, 02:13 (ссылка) | (нет голосов) Загрузка .
Stolzen
Дата 22.3.2012, 08:53 (ссылка) | (нет голосов) Загрузка .

Эксперт

Профиль
Группа: Завсегдатай
Сообщений: 1041
Регистрация: 17.10.2005

Код
$(document).ready(function() var _gaq = _gaq || [];
_gaq.push([ ‘_setAccount’, ‘—‘ ]);
_gaq.push([ ‘_trackPageview’ ]);
(function() var ga = document.createElement(‘script’);
ga.type = ‘text/javascript’;
ga.async = true;
ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘.google-analytics.com/ga.js’;
var s = document.getElementsByTagName(‘script’)[0];
s.parentNode.insertBefore(ga, s);
>)();
>);

Профиль
Группа: Участник
Сообщений: 4
Регистрация: 20.5.2011
Где: Одесса

sashawebdirect
Дата 22.3.2012, 20:41 (ссылка) | (нет голосов) Загрузка .
Цитата(Stolzen @ 22.3.2012, 08:53)
Вот так еще можно
Код
$(document).ready(function() var _gaq = _gaq || [];
_gaq.push([ ‘_setAccount’, ‘—‘ ]);
_gaq.push([ ‘_trackPageview’ ]);
(function() var ga = document.createElement(‘script’);
ga.type = ‘text/javascript’;
ga.async = true;
ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘.google-analytics.com/ga.js’;
var s = document.getElementsByTagName(‘script’)[0];
s.parentNode.insertBefore(ga, s);
>)();
>);

это нужно прописывать для каждого скрипта?

Stolzen
Дата 23.3.2012, 09:32 (ссылка) | (нет голосов) Загрузка .

Эксперт

Профиль
Группа: Завсегдатай
Сообщений: 1041
Регистрация: 17.10.2005

Вы можете сделать функцию addScript, и для каждого скрипта ее вызвать в $(document).ready

Код
var addScript = function(path) var script = document.createElement(‘script’);
script.type = ‘text/javascript’;
script.async = true;
script.src = path;
var s = document.getElementsByTagName(‘script’)[0];
s.parentNode.insertBefore(script, s);
>;

$(document).ready(function() addScript(‘path-to-script1.js’);
addScript(‘path-to-script2.js’);
addScript(‘path-to-script3.js’);
>);

Профиль
Группа: Участник
Сообщений: 4
Регистрация: 20.5.2011
Где: Одесса

Я специально показал все, что б было видно сколько их. И это еще не все, внизу страницы еще есть.
Вы не могли бы мне показать на одном наглядно как и куда это прописывать?

Это сообщение отредактировал(а) sashawebdirect — 23.3.2012, 19:58

sashawebdirect
Дата 23.3.2012, 19:55 (ссылка) | (нет голосов) Загрузка .

Профиль
Группа: Участник
Сообщений: 4
Регистрация: 20.5.2011
Где: Одесса

sashawebdirect
Дата 24.3.2012, 20:56 (ссылка) | (нет голосов) Загрузка .
Форум для вопросов, которые имеются в справочниках, но их поиск вызвал затруднения, или для разработчика требуется совет или просьба отыскать ошибку. Напоминаем: 1) чётко формулируйте вопрос, 2) приведите пример того, что уже сделано, 3) укажите явно, нужен работающий пример или подсказка о том, где найти информацию.

0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | JavaScript: Общие вопросы | Следующая тема »

[ Время генерации скрипта: 0.0884 ] [ Использовано запросов: 21 ] [ GZIP включён ]

источник

При анализе производительности веб-приложения JSF 2.1 + PrimeFaces 4.0 с помощью Google PageSpeed рекомендуется, в частности, отложить синтаксический анализ файлов JavaScript. На тестовой странице с

которая выглядит следующим образом .

… в нем перечислены следующие файлы JavaScript, которые могут быть отложены:

  • primefaces.js (219.5 KiB)
  • jquery-plugins.js (191.8 KiB)
  • jquery.js (95.3 KiB)
  • layout.js (76.4 KiB)
  • fileupload.js (23.8 KiB)
  • watermark.js (4.7 KiB)

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

Хорошо, это выполнимо, если у вас есть контроль над этими сценариями, но все перечисленные сценарии принудительно автоматически включаются JSF. Кроме того, PrimeFaces отображает кучу встроенных скриптов для вывода HTML, которые непосредственно вызывают $(xxx) из jquery.js и PrimeFaces.xxx() из primefaces.js . Это означало бы, что было бы нелегко перенести их на onload событие, так как вы только закончите с ошибками, такими как $ is undefined and PrimeFaces is undefined .

Но это должно быть технически возможно. Учитывая, что только jQuery не нужно откладывать, так как многие пользовательские сценарии сайта также полагаются на него, как я мог бы заблокировать JSF от принудительного автоматического включения сценариев PrimeFaces, чтобы я мог отложить их, и как я мог бы справиться с этими встроенными PrimeFaces.xxx() вызовами?

Да, это возможно с компонентом, который является новым с OmniFaces 1.8.1. Для технически заинтересованных, вот вовлеченный исходный код:

В основном, компонент будет во время postAddToView события (таким образом, во время просмотра времени сборки) через UIViewRoot#addComponentResource() добавить себя в качестве нового ресурса скрипта в конце и через Hacks#setScriptResourceRendered() уведомить JSF, что ресурс скрипта уже визуализирован (используя Hacks класс, поскольку нет стандартного подхода API JSF для этого (еще?)), так что JSF больше не будет принудительно автоматически включать/отображать ресурс скрипта. В случае Mojarra и PrimeFaces name+library true для отключения автоматического включения ресурса должен быть установлен контекстный атрибут с ключом и значением.

Вы должны пропустить jquery.js файл и создать в точно таком же порядке для остальных скриптов. Имя ресурса является частью после /javax.faces.resource/ исключения сопоставления JSF ( .xhtml в моем случае). Имя библиотеки представлено ln параметром request.

Таким образом, это должно сделать:

Теперь все эти скрипты с общим размером около 516KiB откладываются на onload событие. Обратите внимание, что DeferredPrimeFaces.begin() должен быть вызван onbegin из и что DeferredPrimeFaces.apply() должен быть вызван onsuccess из последнего .

В случае, если вы используете PrimeFaces 6.0 или новее, где primefaces.js был заменен core.js and components.js , используйте вместо этого ниже:

Что касается повышения производительности, важным моментом измерения является DOMContentLoaded время, как вы можете найти в нижней части сетевой вкладки инструментов разработчика Chrome. С помощью тестовой страницы, как показано в вопросе, обслуживаемом Tomcat на 3-летнем ноутбуке, он уменьшился с

270 МС. Это относительно огромная (почти половина!) и имеет наибольшее значение на мобильных телефонах / планшетах, поскольку они отображают HTML относительно медленно, а события touch полностью блокируются до загрузки содержимого DOM.

Следует отметить, что вы находитесь в случае (пользовательских) библиотек компонентов зависит от того, подчиняются ли они правилам/рекомендациям по управлению ресурсами JSF или нет. RichFaces, например, не сделал и homebrewed другой пользовательский слой над ним, что делает его невозможным использовать на нем. См. также, что такое библиотека ресурсов и как ее следует использовать?

Предупреждение: если вы добавляете новые компоненты PrimeFaces на том же представлении впоследствии и сталкиваетесь undefined с ошибками JavaScript, то велика вероятность того, что новый компонент также поставляется со своим собственным файлом JS, который также должен быть отложен, потому что это зависит от primefaces.js . Быстрый способ определить правильный сценарий состоял бы в том, чтобы проверить сгенерированный HTML для нового сценария, а затем добавить другой для него на основе вышеуказанных инструкций.

Если вы используете OmniFaces CombinedResourceHandler , хорошо знать, что он прозрачно распознает и объединяет все отложенные сценарии с одним и тем же group атрибутом в один отложенный ресурс. Например. это .

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

В качестве живого примера проверьте нижнюю часть сайта ZEEF. Все основные сценарии, связанные с примерами, и некоторые сценарии, относящиеся к сайту, объединяются в первом отложенном сценарии, а все несущественные сценарии, связанные с социальными сетями, объединяются во втором отложенном сценарии. Что касается повышения производительности ZEEF, то на тестовом сервере JBoss EAP на современном оборудовании время DOMContentLoaded шло от

В любом случае, если вы уже используете OmniFaces, то вы всегда можете использовать CDNResourceHandler для делегирования ресурса PrimeFaces jQuery истинному CDN с помощью следующего контекста param в web.xml :

Обратите внимание, что jQuery 1.11 имеет некоторые значительные улучшения производительности по сравнению с 1.10, как внутренне используется PrimeFaces 4.0 и что он полностью обратно совместим. Это сэкономило пару сотен миллисекунд при инициализации drag’n’Drop на ZEEF.

Первоначально опубликовано в качестве ответа на отложенные приметы.загрузка js

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

Вам нужно будет настроить приметы HeadRenderer , чтобы достичь рекомендованного порядка страниц. Хотя это то, что может быть реализовано с помощью PrimeFaces, я не вижу этого в v5.2.RC2. Это строки, encodeBegin которые нужно изменить:

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

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

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

источник

Как получить быстрый сайт — оптимизация (сжатие) изображений и скриптов, а так же уменьшение числа Http запросов

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

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

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

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

Насчет картинок сразу стоит оговориться — прежде, чем приступить к их оптимизации, вам, пожалуй, следует решить, а нужны ли они у вас на сайте?! Дело в том, что в шаблоне вашего ресурса могут быть описаны в CSS файле фоновые изображения для отображения различных элементов дизайна, но при этом их вы по тем или иным причинам не используете.

Вообще, изображения на сайте могут выводиться двумя способами: с помощью Html тега IMG (тут и тут читайте подробнее), а так же с помощью CSS свойств «background» или «background-image», которое может выглядеть, например, так:

При загрузке страниц происходит и подгрузка картинок, заданных как через IMG, так и фоновых изображений, описанных свойствами «background» в CSS файле. Посмотреть все подгружаемые в браузер пользователя графические файлы можно в нашем средстве для получения быстрого сайта — Page Speed на вкладке «Resources»:

В колонке «Type» для графики, вставленной через IMG, будет прописано «image», а для фоновых картинок, вставленных через CSS — «cssimage». Поэтому при помощи Page Speed вам будет достаточно просто их различить, к тому же, подведя курсор мыши к строчке с интересующим вас изображением, вы увидите его превьюшку:

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

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

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

При первоначальной настройке темы под свои нужды, я не очень корректно убрал эти изображения из оформления, забыв удалить соответствующие им CSS свойства («background») из файла стилевого оформления темы (style.css), который обычно расположен по следующему пути:

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

К слову сказать, таким образом мне удалось сэкономить до 20 http запросов при загрузке любой страницы моего блога, удалив, соответственно, из style.css около 20 записей о подгрузке фоновых изображений (ненужных или малозначительных). Для проведения подобной операции вам нужно будет подключиться к своему ресурсу через FTP клиент и открыть на редактирование файл стилей из указанной выше папки.

Далее вы производите поиск по нему с помощью средств того редактора, в котором вы его открыли. Искать следует по названию того графического файла, который вы желаете удалить. Находите строчку со свойством «background», из-за которой подгружается это фоновое изображение и удаляете ее. Проверяете через Page Speed корректность проведенных вами действий.

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

Самый простой вариант сжать все изображения на своем сайте — подключить сервис OptiPic.io.

  1. Подключается к сайту буквально за 2 минуты.
  2. Полный автопилот — OptiPic найдет и оптимизирует все изображения на сайте в автоматическом режиме.
  3. Сервис периодически будет мониторить добавление на сайт новых изображений. Они автоматом будут добавляться в очередь на сжатие.
  4. Это безопасно — перед сжатием изображений автоматически создаются копии каждого .
  5. Есть возможность автоматически уменьшить ширины или высоту изображений (resize).
  6. Поддержка любых php-сайтов (любые CMS, фреймворки или даже самописные движки).

Плюс у OptiPic есть партнерская программа, по которой можно получать до 40% от привлеченных клиентов.

А вообще, можно сделать две вещи — оптимизировать размер каждого отдельного изображения через Page Speed, а так же объединить некоторые фоновые картинки из файла стилевого оформления в так называемые CSS спрайты.

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

Мне очень нравится онлайн сервис PunyPNG, который просто великолепно сжимает графику формата PNG (я уже писал тут, когда лучше использовать формат PNG, когда JPG, а когда и GIF):

Очень неплох был и Яховский Smush.it:

Но для работы с графикой шаблона проще будет воспользоваться возможностями самого Page Speed (ну, или на худой конец FastStone Image Viewer, описанного здесь), тем более, что он сжимает графику очень эффективно и без потери качества (иногда даже в пару раз уменьшает размер и, соответственно, и убыстряет сайт).

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

Догадайтесь, кому он может принадлежать (подсказываю — поисковой системе Google.ru, о которой речь шла тут). В принципе, создавать CSS спрайт с нуля в каком-либо графическом редакторе очень сложно, ибо потом нужно будет в style.css очень четко описать позиции того или иного рисунка на большом изображении.

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

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

Да, в принципе, точно так же, как и чуть ранее сжимали CSS средствами Page Speed. Только проделать все тоже самое нужно будет для другой строчки под названием «Optimize images». Щелкаете по плюсику рядом с этой строкой и просматриваете список тех картинок на открытой в браузере странице, которые по мнению этого плагина можно оптимизировать:

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

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

Кроме изображений с помощью Page Speed вы можете так же сжать скрипты (JavaScript, jQuery), которые подгружаются в браузеры пользователей с вашего web сервера. Сделать это можно в строке под названием «Minify JavaScript»:

Очень здорово было бы предварительно объединить все внешние скрипты в один файл (это нам советует сделать сам плагин в строке «Combine external JavaScript»), по аналогии с тем, как мы это сделали чуть ранее для CSS.

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

Правда, в файл functions.php, о котором мы говорили тут (живет он в папке /wp-content/themes/название темы WordPress/), нужно будет прописать несколько другой код с указанием регистров плагинов:

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

Поэтому после нескольких попыток я признал свое поражение и полную некомпетентность в этом вопросе. Если кто знает нюансы, которые важно учесть при объединении внешних JavaScript и jQuery скриптов, то буду очень признателен за подсказку.

Еще оной проблемой, которая была помечена в Page Speed красным цветом, как очень важная для скорости загрузки моего сайта, являлась подгрузка всех объектов с одного хоста (ktonanovenkogo.ru) — «Parallelize downloads across hostnames». По мнению этого инструмента лучше было бы распараллелить загрузку объектов с разных хостов, увеличив тем самым общую скорость.

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

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

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

Вещь достаточно удобная с точки зрения теории, но на практике, когда я перенес часть изображений из определенной папки в это хранилище для статических объектов и прописал в файле .htaccess (подробности о .htaccess можно посмотреть здесь) редирект со старой папки картинок (на основном web сервере) на новую (для статических объектов) такого вида:

Здесь /image «» — каталог с картинками на основном хосте (где и прописывается код 301 редиректа в .htaccess), а http://images.ktonanovenkogo.ru «» новое месторасположение на альтернативном хосте. Но оказалось, что, во-первых, скорость работы специализированного хоста достаточно низкая, а во-вторых, при этом перестало работать кэширования статических объектов в браузерах пользователей.

Page Speed сразу же выделил красным строку «Leverage browser caching». Причем прописывание в файл .htaccess на новом хосте нужных директив результата не дало. Скорее всего тот сервер просто-напросто эти директивы не был способен выполнить.

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

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

источник

Популярные записи