День добрый,
Почему нужно грузить js после контента можно почитать, например тут. Если кратко — это нужно для того, чтобы ускорить загрузку страниц. В блогах и на форуме готового решения не нашел, если пропустил — кидайте в комментах.
На гите инициатива делить теги на те, что нужно грузить в head и те, что в перед </body> потерпела неудачу (возможно, моей аргументации не хватило), поэтому напишу что можно сделать на текущий момент для реализации этой идеи.
На InstantCMS2 есть для этого механизм — почти без танцев, почти без бубна. Но некоторые нюансы есть, поэтому появилось желание оформить это постом.
В чем сложность:
Нам надо оставить часть скриптов сверху, а часть снизу — а функция для вывода js только одна $this->printJavascriptTags. Сверху должна быть статистика и те скрипты, без которых код на странице выдаст ошибки при загрузке.
Решение этой задачи сводится к внесению изменений в один файл шаблона main.tpl.php. Минус в том, что мы больше не сможем использовать методы addMainJS, addControllerJS, addJSFromContext для скриптов, которые нужно загрузить в секцию head, но если на кону скорость загрузки страницы… Еще минус в том, что мы грузим jquery напрямую и возможны ситуации, когда этот скрипт повторно загрузится снизу… Обычно такого не должно быть, но ситуация возможна.
В шаблоне вместо
вставляем строку
2. Грузим сверху все css и другие теги (сюда могут попасть и js, которые добавлены через функцию addHead)
Заменяем строку
на
3. Добавляем перед </body> строку
После этих замен сверху будут грузиться все стили, jquery и другие теги, которые добавлены через метод addHead.
Остается вопрос — что делать со скриптами, которые обязательно должны грузиться сверху? — их нужно подключать не через addMainJS или addControllerJS. Подключать их теперь нужно только через addHead и тогда они попадут в блок <head></head>.
Почему нужно грузить js после контента можно почитать, например тут. Если кратко — это нужно для того, чтобы ускорить загрузку страниц. В блогах и на форуме готового решения не нашел, если пропустил — кидайте в комментах.
На гите инициатива делить теги на те, что нужно грузить в head и те, что в перед </body> потерпела неудачу (возможно, моей аргументации не хватило), поэтому напишу что можно сделать на текущий момент для реализации этой идеи.
На InstantCMS2 есть для этого механизм — почти без танцев, почти без бубна. Но некоторые нюансы есть, поэтому появилось желание оформить это постом.
В чем сложность:
Нам надо оставить часть скриптов сверху, а часть снизу — а функция для вывода js только одна $this->printJavascriptTags. Сверху должна быть статистика и те скрипты, без которых код на странице выдаст ошибки при загрузке.
Решение этой задачи сводится к внесению изменений в один файл шаблона main.tpl.php. Минус в том, что мы больше не сможем использовать методы addMainJS, addControllerJS, addJSFromContext для скриптов, которые нужно загрузить в секцию head, но если на кону скорость загрузки страницы… Еще минус в том, что мы грузим jquery напрямую и возможны ситуации, когда этот скрипт повторно загрузится снизу… Обычно такого не должно быть, но ситуация возможна.
Решение
1. Подключаем jquery в блоке head напрямую.В шаблоне вместо
<?php $this->addMainJS("templates/{$this->name}/js/jquery.js"); ?>
<script type="text/javascript" src="/templates/default/js/jquery.js"></script>
Заменяем строку
<?php $this->head(); ?>
<?php $this->head(true, false, true); ?>
<?php $this->printJavascriptTags(); ?>
Остается вопрос — что делать со скриптами, которые обязательно должны грузиться сверху? — их нужно подключать не через addMainJS или addControllerJS. Подключать их теперь нужно только через addHead и тогда они попадут в блок <head></head>.
Будем разбираться.
Спасибо!
Спасибо!
Уже не помню какие проблемы возникли, но core.js, rating.js и еще несколько, должны быть на верху, так как перед footer-ом есть такой код https://prnt.sc/ginla2
По этому, без таких методов как $this->addFooterJS() и для вывода $this->footer() на мой взгляд не получиться грамотно реализовать
Предполагаю, что данный вопрос пока труднореализуемый или действительно не стоит всех усилий.
Нельзя массово переносить скрипты вниз. этим нужно управлять. Не все скрипты приводят к "подмигиванию", какие-то можно безболезненно убрать вниз.
Простой пример. У меня есть компонент, который грузит 200кб скриптов - я их подключаю у себя снизу (добавил хук "print_footer"), потому что незачем тратить время на загрузку пользователем 200кб скрипта. Но я не могу дать пользователям такую возможность без правок шаблона, а добавлять такое требование к компоненту не хочу - это усложняет использование компонента.. В итоге получается все пользователи вынуждены замедлять загрузку страницы из-за одного компонента, который этого даже не требует - ему все-равно где и что подгружать.
Решение для себя вижу в добавлении доп настроек - если пользователь руками хочет добавить хук, то скрипт будет подключаться внизу. Если не хочет, то сверху со всеми вместе.
Т.к. это CMS т.е. система для сайтостроителей без глубоких знаний программирования, то при переносе скриптов к футеру резко повышается вероятность всевозможных ошибок инлайн скриптов которые сделаны так чтобы сразу выполняться (и это не оф. разработчики так делают, а сторонние горе программисты или сами админы сайтов находят на просторах интернета). И посыпятся куча претензий от таких сайтостроителей что ничего не работает и во всем этом виноват движок, а не их кривые руки.
И последнее, если не ошибаюсь в современных стандартах и современных браузерах (IE 10+) подгружать скрипты можно в неблокирующем асинхронном режиме ( ссылка). По сути тот же эффект что и перемещение к закрывающему тегу body. Можно в функции типа addJS(), addMainJS() и др. добавить флаг is_async или is_defer кому надо чтобы пользовался)) без костылестроения.
Я нашел решение, как буду делать для своих компонентов.. Это будет просьба для пользователей добавить хук в перед </body>, в противном случае загрузка в head c атрибутом async - это не самый плохой вариант.
С другой стороны, блокировки контента не будет, эффект пользователя достигнет, а то что какой либо скрипт подгрузится позже (не в порядке следования) на работоспособность страницы не повлияет (если конечно с умом подходить к вопросу).
Предложите решение в виде от которого разработчики не смогут отказаться и я ваш стописяттысячный должник!
Костылями я и сам могу что угодно провернуть, но дело в том, что пользователи моего компонента "костылять" не будут, я их и просить об этом не стану..
Я вас прекрасно понимаю, про is_async и is_defer, но сейчас это костыли.
Я предложил вариант по примеру функций html компонентов (html_input, html_textarea и др.). В них есть возможность добавлять свои атрибуты для тега ( $attributes=array() ). Но просто так добавить атрибуты в JS (и CSS) нельзя. Конечно нужно допиливать весь механизм сбора js-тегов их мерж и вывод. В текущей версии движка из коробки этого нет. Если сделать получим возможность сбора всех JS в одном месте и не блокированную загрузку тех из них которые разработчик дополнения посчитал возможным и необходимым это сделать. Т.е. более логично все скрипты видеть в одном месте чем разбросанными по странице.
Откровенно говоря лишь единицы захотят разбираться с асинхронностью и допиливать свои дополнения чтобы страница прогрузилась на 70 мсек быстрее)). Поэтому "овчинка не стоит выделки".
Я лишь указал что такое возможно. Но я не говорил что это делается в 2 клика.
Если делать, то делать все в одном месте или внизу или вверху. Внизу для универсальной CMS опасно. Поэтому логично сделано вверху. Если хочется получить возможность оптимизации загрузки - то логичнее дорабатывать атрибуты, а не разбрасывать скрипты по странице.
Я бы добавил - лишь единицы могут разрабатывать компоненты, поэтому можно не париться)) Позиция не супер для универсальной CMS.. Нужно добавлять и атрибуты (атрибуты может быть важнее и приоритетнее - да и проще) и вывод внизу - я все-таки думаю, что должна быть универсальность.
Какой -то забавный спор выходит. Первая позиция - "надо сделать универсальней". Вторая - "да ладно, и так пойдет". Если пойдет, то конечно можно не продолжать) Как-нибудь и так будет работать, работало же раньше, можно и не пытаться сделать лучше и быстрее - не пойдем на поводу у гугломерок.
Для нормальных посещаемых сайтов и 70 мсек имеют значение если это задержка только от одного компонента. которых могут быть десятки.
Точнее их можно использовать только в функции addHead - там все что хочешь.. И атрибуты, и теги и тд.. И все выведется сверху.