Аудит js кода, или как избавиться от лишнего?

Последние пару месяцев я занимался созданием шаблона для перевода сайта с ВП на Альто. За основу был взят шаблон Experience Simple. Об этом я пожалел, когда было сделано уже половина работы. Я стал активно избавляться от всего лишнего, было переписано очень много css и html кода, поправлен js. В итоге вес шаблона с 3,21Mb сократился до 1Mb без ущерба функциональности. К чему я все это пишу. Сейчас очень остро встал вопрос по оптимизации js из ядра движка, я хочу узнать, может быть, у кого есть «списочек» того, что используется в шаблонах, а от чего можно отказаться? Загружать при первом посещении по 1,5Mb скриптов, глядя на белую страницу по 10-15 секунд, это просто... ну нет слов. Перенести скрипты в футер или ужать gzip'ом тоже нельзя, часть или все функции отваливаются. Понятно, что это вопрос больше индивидуальный и все зависит от предъявляемых требований. Если не «список», то хотя бы посоветуйте инструменты для аудита js.

Вот на примере bootbox.js — насколько я могу понять, он используется для вызова модального окна при правке участников в личных сообщений, весит 30Kb, ужатый 9Kb, где он еще используется? Или, например, jquery-ui — слон в 350+180Kb, наверняка некоторые компоненты не используются, библиотеку можно пересобрать на официальном сайте. Кажется, что вес скриптов маленький, но вот из таких кирпичиков получается целая гора, как в случае с шаблоном Experience Simple, в котором правила в css могут дублироваться по несколько раз и образую целые каскады наследования. Разбираться в тонкостях нет желания, легче все переписать. Вопрос об аудите js кода, я думаю, назревает со времен ЛС. Что посоветуете, господа?

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

38 комментариев

+1
Меня тоже смущает такая ситуация, у меня сайт на LS с базой в 330 mb плагинов порядка 30 штук full time 0.7 и альто база В 10 раз меньше, плагинов В 2 раза меньше, full time 2,4 правда шаблон не simple а просто experience, на одном vps. Может В этом причина…
Отредактирован:
+1
Если речь про значение «full time», которое выводится в футере, то у Альто там два числа: первое считается, как у ЛС, а второе — «по чесноку». Но это, в любом случае, не связано с js, т.к. считается время обработки на сервере, а the-boss ведет речь о файлах, которые грузятся на странице в браузере у юзера
0
Я не понял существо вопроса… прошу прощения… но просто почему выводятся столь большие цифры full time: 2.751 / 2.797? Это другая тема конечно… Хотелось бы уменьшить это значение тоже раза в три:)))
+1
Вот на примере bootbox.js — насколько я могу понять, он используется для вызова модального окна при правке участников в личных сообщений, весит 30Kb, ужатый 9Kb, где он еще используется?
Как ты правильно заметил все очень индивидуально, к примеру bootbox можно попробовать вынести в футер а вот jquery — нет
+1
Вообще я склоняюсь к тому, чтобы выделить основу из скриптов + css и вынести их загрузку на экшены. Тогда при первой загрузке сайта будет использоваться только самое необходимое: основные стили + jquery + bootstrap js. А все остальное будет подгружаться постепенно. Это хоть как-то поможет разбить монолит.

Если я правильно понял, shtrih в одном из тикетов на гитхабе предлагал Вадиму какую-то php библиотеку для постепенной подгрузки нужных файлов, но чем все закончилось я уже не помню. Пока буду играться с консолью в Хроме ))
+1
Ну этот вариант не настолько хорош, как кажется. Если на каждой странице будут уникальный набор скриптов/стилей, то в случае, если они минимизируются и склеиваются, браузеру придётся заново их скачивать, ибо конечный файл будет всегда разным. Это увеличит кол-во трафика и плохо повлияет на скорость загрузки страницы. Сейчас, поскольку всегда используется один и тот же набор скриптов/стилей, склеенный файл не нужно постоянно перегенерировать, он скачивается и кешируется браузером. Таким образом, скорость загрузки страниц увеличивается за счет использования кеша.
+1
Я понимаю все плюсы и минусы, но пока решение вот такое, и оно не окончательное, буду тестировать.
0
Думаю, можно таким способом оптимизировать: общий набор скриптов так и оставить единым для всех страниц, но разбить его на две части — первую (базовую) загружать в хедере, а вторую в футере. И хоть файлов из одного станет два, но на всех страницах они будут одни и те же
0
Тоже вариант
+1
А сколько всё это весит в сжатом минимизированном склеенном виде?
+1
js ужимается до 450-500Kb под гзипом, только толку от этого нет, сайт из динамического превращается в статический )). А так было бы в самый раз.
+1
только толку от этого нет, сайт из динамического превращается в статический ))
в смысле что-то не работает? В стандартных вроде всё нормально. Если конкретно в вашей теме что-то ломается после минификации — надо разобраться и решить проблему.
+1
После сжатия гзипом весь js отваливается. Но тестирую пока на денвере на локалке. Посмотрим, как будет в сети.
+1
А это сейчас так, или давно пробовал включать? Там были такие проблемы, но они должны быть уже пофикшены.
+1
Да буквально полчаса назад пробовал включать на версии 1.1.8, увидел что все отвалилось и вернул назад, глубого не копал. Пока с шаблоном вожусь.
+1
Вот ошибки из консоли hkar.ru/DVda. Возможно, я как-то не так включаю сжатие gzip через конфиги и в админке, но результат налицо ))
Отредактирован:
+1
А, вот ты про какое сжатие! Я что-то подумал, что речь про сжатие средствами сервера. Это надо будет проверить
+1
Судя по всему, файлы сжимаются, но браузер не может их разжать. Может быть, используется какой-то плагин для потокового сжатия данных, которое ни в коем случае не должно применяться к сжатым жс-файлам. А может проблема связана с windows или с тем, что денвер устарел и не нужен. У меня (Apache/2.4.7 (Ubuntu), PHP 5.5.9) проблемы нет.
0
Ладно, пока остановимся, как сайт в сеть выкачу, будем смотреть. А то не поймешь, кто виновник.
0
… тестирую пока на денвере...
Кстати, очень рекомендую вместо денвера вот это: open-server.ru/

А денверу — увы! — пора на свалку истории.
0
Спасибо. Надо будет попробовать. Денвер использую больше по привычке. Инталлятор на винте был, я его и установил.
+1
Насчет gzip'а что-то не понял. На демо-сайте (который собирается с гитхаба при каждом коммите) gzip работает без проблем:
+1
Вадим, я тестирую пока на локалке. Выкачу в инет, там посмотрим. На локалке я делаю следующее: в админке включаю сжатие js (два верхних чекбокса), потом еще и в конфигах опцию $config['compress']['js']['gzip'] = true; Потом очищаю кеш и js отваливается. Потому как ссылается на файлы /_run/assets/aafd5c7955ebaf44e1e50ed3178c2c21.min.js.gz.js
0
Подтверждаю у меня проблема повторилась. на Ubuntu 14.02 и apache 2.4 но думаю что проблема в приписке в админке
Отдача CSS в виде gzip средствами Alto CMS возможна только если в качестве веб-сервера используется apache и для него установлен модуль mod_headers.
the-boss глянь есть ли у тебя и правильно настроено или нет
Отредактирован:
0
В конфигах апача (httpd.conf) включил mod_headers и файлы, сжатые gzipом, заработали. Надо в описание опции в админке добавить предупреждение об этом. Правда, при включении «Отдавать CSS в виде gzip» страницы показываются без стилей. Нужно ковырять правила в .htaccess.
0
Так же подтверждаю что если включить mod_headers в апаче то проблема пропадает
+1
До aVadim раз уж конфиг настолько серверо зависимый то предлагаю предусмотреть там и работу с nginx и его настройкой gzip_static при включении которой оно будет искать файл .js.gz и отдавать его вместо .js с пометкой о сжатии, это разгрузит апач которому итак есть чем заняться (скорее всего хватит подправить файл PackageJs (PackageCss) строчка 100 или 126 (и аналогичная в CSS ках))
Отредактирован:
0
Поддерживаю. Сервер на nginx…
0
С настройкой $config['compress']['js']['gzip'] = true; я тупанул, она включается и через админку, конфиги можно не трогать.
0
Очень интересная тема.
Поддерживаю. Хотелось бы вырезать из Альто все, что не нужно и по надобности подключать.
Чем быстрей загружается и меньше весит тема, тем лучше для ПС.
+1
Вообще, в плане оптимизации скриптов — поле непаханное.

Например, кроме разбивки на два блока скриптов, как писал выше в комментах (т.е. что-то грузим в хедере, что-то в футере), можно (нужно) еще поэкспериментировать с атрибутами defer и async, объединяя скрипты в группы с одинаковыми атрибутами. Например, если используется какой-то скрипт без зависимостей — можно смело ему ставить async — пусть браузер сам решает, когда его грузить и выполнять. А jquery-плагины можно объединять в группу с defer, подключая их после jquery.
0
Было бы неплохо добавить такую возможность в админку в новом обновлении.
+1
Нет, такие настройки в админку выносить смысла нет. Это надо в конфигах/ассетах скинов явно прописывать.
0
Можно вопрос.

Да, и в качестве дружеского совета хотел бы предупредить, если у вас нет знаний в веб разработке, то лучше не используется на своих сайтах шаблон Experience Simple.
А с чем это связано? На какие трудности можно напороться?
0
Все недостатки сразу и не вспомню. Вот лишь малая часть: во-первых, он очень тяжелый, во-вторых, избыточен, некоторые правила повторяются сначала в style.experience.min.css (68Kb), потом theme.default.css (91Kb) и в конце еще и в style.bootstrap.min.css (205Kb), в-третьих, перегружен сомнительным функционалом, например, для выпадающего меню сделан эффект анимации и затухания, за красивости расплачиваемся 124Kb кодом в hover.css, за такое руки отрубать надо, изменен календарь для выбора даты, который ничем не лучше стандартного из jquery-ui, при этом старый функционал не выпелен полностью, зато поверх добавлен новый (+21Kb), со всеми вытекающими последствиями, в-четвертых, частично переписан стандартный js темы, который работал со времен LS, а теперь не работает, например, сворачивание и разворачивание комментариев. Кто неопытен или кому нравятся свистоперделки, тому шаблон самый раз. Но все это чаще всего не нужная мишура.
0
Спасибо! Задумался. Хотел именно этот шаблон переделывать под свой…
0
Забираем с CDN, если не «тянется» даем свой. Пример
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.11.2.min.js"><\/script>')</script>
0
Решение хорошее, но только когда вручную верстаешь сайт целиком и руками прописываешь скрипты. А тут ведь скрипты собираются подключаются самим движком. Конечно, можно подумать о том, чтоб в описании ассетов как-то задавать условия и альтернативный вариант подключения, но как-то уж очень навороченно получается
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.