Товарищи разработчики!
Пожалуйста помещайте все любые куски кода javascript и css в отдельные файлы. Вместо использования <style> и <script>
И для вывода прописывайте ссылки для скриптов и css:
<link href="/wa-apps/shop/plugins/
MYPLUGIN/css/
FILENAME.css?
{$wa->version()}" rel="stylesheet">
<script src="/wa-apps/shop/plugins/MYPLUGIN/js/FILENAME.js?{$wa->version()}"></script>
Таким образом браузеру не придется перечитывать кучу одинакового кода при каждом запросе, а он закеширует файлы при первом запросе, что значительно ускорит загрузку сайта!
Так же желательно было бы чтобы модераторы компании вебасист давали рекомендации по оптимизации кода, при виде совсем запущенных случаев работающего, но абсолютно не оптимизированного кода.
23 комментария
Это сильно категорично. Иногда удобнее и правильнее все же использовать inline вставку, чем делать лишние запросы.
Тем более это влечёт с собой дополнительные ограничение в виде того, что во внешних файлах не используются smarty.
Да с любыми кусками я погорячился)
И это опять не 100%. При использовании HTTP/2 выгоднее разбить на много мелких файлов %)
Дитя google pagespeed
я не дитя гугл спид. Просто столкнулся с проблемой на одном сайте, там во первых сама тема генерит css цвета через смарти , а еще там стоит четверть всех плагинов. Код head превращается в индусский код! Хотя половина кода могла бы находится в файлах. Да действительно бывают случаи когда надо передать переменную смарти в javascript, я для этого использую json обьект. Что же касается сss, то можно компилировать файлы, сохранять и отдавать как файл
50% виденных мной плагинов представляют собой лапшу из серии "х..як, х..як и в продакшн")) да и если говорить о частной разработке, то всем подавай подешевле, вот в итоге и получается подобный говнокод (хотя им и сама WA постоянно грешит - т.ч. понятно откуда сторонние разработчики черпают "вдохновение"). Также согласен с замечанием Евгения.
Да! поддерживаю!!!!
Проблема в общем-то не особо из-за javascript, а из-за дополнительных запросов в бд плагинами по каждому пуку! многие плагины делают свои выводы через методы хелперов да еще и без хранения дополнительной информации в статических переменных(например массив данных самой категории) и при каждом запросе метода хелпера для получения информации о товаре, которых для показа 50, заново запрашивается инфа текущей категории ( это как пример), а особенно это сказывается на производительности при показе товаров категории!
Также создание объектов моделей можно также заносить в пул!
Вот простой код хранения моделей плагина:
Проще тогда уж singleton использовать.
Мне не проще) Проще пул одиночек! Мне не надо знать является ли объект одиночкой или нет, мне без разницы, я получу все равно копию нужного мне объекта не зависимо от его реализации) Можно еще проверять является ли класс одиночкой и его тогда загружать через метод
Это и есть синглтон. Если присмотреться %)
Ну, фабричный метод с кэшем и синглтонами :D
Отличие синглтона от статики для использования в WA в том что в смарти нельзя инициализировать классы через new, поэтому синглтон это как защита от использования класса в шаблоне.
запрет на инстанцирование объектов классов вполне оправдан
знаю)))
Хочу апнуть тему.
Это код в head только от 3-х! плагинов.
Создаете вы шаблон для массового использования далекими людьми. Хотите дать из возможность менять основные цвета на те, что они хотят. Давайте, сударь, расскажите как сделать это без выноса стилей в сам шаблон. С JS аналогично.
А вообще странный подход. Винить продажные темы/плагины широкого потребления в том, что они в вашем персональном случае имеют лишний код. Не подходит - пишите своё.
он уже написал как - генерировать js\css файлы
Ггенерация средствами шаблона. Отличная идея! Скажу своему единорогу заняться этим.
Мой уже рог сточил.... Евгений, от куда сплагиатили единорога?
Что же касается js/сss генерируемых, то можно компилировать файлы, сохранять и отдавать как файл! Это конечно не подходит для тем, но для плагинов самое оптимальное решение!
И в этом способе я тоже могу найти ряд проблем. Но начнем с другого. А хочется ли разработчикам плагинов, которые стоят копейки, так заморачиваться?
Автору стоит понять, что товары широкого потребления предназначены для других целей. А еще вам, Гена, стоит получше изучить тему оптимизации. Расскажите чем плох JS в шаблоне? Только лишь тем, что зрительно картина не соответствует тому, чему учат в школе. Только клиенты туда не смотрят. А вот лишний файлик = лишний http-запрос. Об этом не написано в "оптимизация для чайников". Но во многих случаях вынос js в саму страницу является более профитным, чем подключение десятка файлов.
Так! Вот явный пример: Плагин Обратный звонок
Вот строки которые подключают файл js :
Вот код самого файла js/callb.frontend.js
Это идет в head страницы и каждый раз компилируется через смарти!!!!!
Посмотрев переменные которые передаются и используются для компиляции данного js, понятно что туда передаются только массив настроек $callb_settings.
Так почему бы не сделать объект
А в шаблон передавать только массив json
Что вы скажете про данный случай?
1. В моей реализации передается только Json массив
2. код скрипта будет зfпрошен один раз (далее будет из кеша браться)
3. никакой лишней компиляции через PHP
4. вполне удобно читаемый код Js
Про этот конкретный случай скажу, что автор погорячился.
И что ему вправду стоит попробовать почитать документацию по написанию jQ-плагинов
Потом подумать и переписать это без jQ совсем. %)
Кстати именно из-за этого плагина я и создал тему((((
Когда один такой плагин вроде бы ничего страшного, а когда таких будет установлено 30?!!!
Давайте посчитаем
компиляция занимает 0.012 сек
компилированный код таких 30 скриптов весит 164kb
+ это все надо отдать браузеру вывод