Panels - использовать или нет?

Пожалуй, нет ни одного другого модуля под drupal, о котором мнения разработчиков будут так же диаметрально различаться, как о Panels. То, что модуль гибок и функционален, не вызывает сомнений ни у кого, но вот целесообразность его использования многие ставят под вопрос. Я долгое время избегал использования панелей, чтобы не перегружать сайт лишними (как мне казалось) модулями. Старался обходиться блоками, но со временем стал замечать всё больше и больше недостатков и ограничений блочной системы Drupal. Поэтому однажды я решил поглубже разобраться в панелях и понял, что они порой дают неоспоримые преимущества перед любыми другими решениями. Итак, поехали.

Когда нужно использовать Panels

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

Это можно сделать и без панелей, через views + блоки, но ведь вьюху ещё нужно создать и настроить, а в панелях прямо из коробки доступны панели со всеми отдельными полями контента. Более того, тут будет прирост по быстродействию, т.к. панели используют уже загруженный объект ноды из контекста, а вьюс возьмёт nid из url страницы и полезет за полем в базу.

2. Вывести один блок одновременно в два региона.

Панели позволяют любое содержимое вставлять в макет страницы сколько угодно раз. К слову, вовсе не обязательно выводить блок на страницу дважды, задача может стоять так, чтобы вывести блок на одних страницах в одном регионе, а на других в другом. Блочная система не позволяет этого сделать, а панели - запросто.

3. Сделать разный шаблон для разных словарей таксономии.

Если вам нужно выводить блок на страницах терминов одного словаря, а на страницах другого не нужно, то кроме панелей, это ничем не решить. Можно, конечно, сделать костыль - включить пхп-фильтр и задать в конкретных блоках пхп-условие видимости, но php-фильтр лучше не использовать никогда. И вообще, панели работают с таксономией значительно лучше, чем тот же Taxonomy Display. В частности, при использовании Taxonomy Display не работают Ajax Facets.

4. Работа с фасетами

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

5. При наличии в дизайне сайта большого количества разных шаблонов со сложной структурой колонок.

Во-первых, панели позволяют использовать гибкие лэйауты либо легко создавать свои. Есть также модуль Radix Layouts, который сожержит около 30 разных лэйаутов, совместимых с bootstrap. Во-вторых, как было сказано выше, вы можете выводить один блок в разных лэйаутах в разные регионы, что не позволяет делать блочная система. В третьих, при использовании CSS-фреймворков с сетками, вы можете легко задавать панелям нужные классы и id, чтобы выстроить их по сетке.

6. Если нужно выводить на страницу что-то дико кастомное.

Панели используют Ctools API, которое позволяет легко выводить что угодно и как угодно при довольно простом коде. Более того, подобные задачи - одни из самых любимых на собеседовании у многих работодателей, поэтому овладеть этим кун-фу будет в любом случае полезно :)

Когда не нужно использовать Panels

1. Когда у вас на сайте всего три одинаковые страницы и полтора блока.

2. Когда вы не поняли ничего из того, что было написано выше :)

Примечания

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

2. Всё вышесказанное относится к Drupal 7, в восьмой версии функционал панелей сильно урезан, а функционал блоков наоборот - расширен.

И традиционная спам-ссылка на оригинал статьи в моём говноблоге: http://wellsolutions.by/article/panels-ispolzovat-ili-net

Автор

Комментарии

Аватар пользователя bumble bumble 18 декабря 2016 в 18:04
gun_dose wrote:

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

Есть:

  • Views
  • Rules
  • DS (хотя он из той же епархии)
  • все объединяющий Commerce
  • UPD - еще всяческие Context, в т.ч. Contextual links (хоть я и сам их постоянно пользую)
  • ..ещевспомнюнапишу

Да, это модули делающие Друпал - Друпалом. Но нужно понимать что их задача - UI.
Часто платой за это является снижение производительности. И при кейсах с оптимизацией - часто, они первые идут в расход.

Аватар пользователя bumble bumble 18 декабря 2016 в 18:12

Те же панели, только для нод (вьюмодов).

По сути, гуя для перетаскивания в "регионы" полей, аля как на странице блоков.

Ну и множество манящих вкусностей, типа:

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

По сути - все круто, я использовал долго. Но когда есть возможность это дело программно пилить - конечно же будет производительнее.

А при необходимости, можно достичь многого используя просто Field Group.

Аватар пользователя gun_dose gun_dose 18 декабря 2016 в 18:23

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

Аватар пользователя bumble bumble 18 декабря 2016 в 18:28

Любой "шаблон" - это верстка со стилями.
Оборачивай все что нужно в группы, назначай им классы (если не хватит созданных), пиши им стили. Вот и панель, только самописная ))) Да, не из гуи, но в чем то есть и прелести такого подхода (во всяком случае, для маньяков вроде меня, пытающихся держать все максимально под контролем)) ).

Аватар пользователя postgres postgres 18 декабря 2016 в 18:17

Плюс ко всему - Panels взаимодействуют с ctools plugins: главные из которых content type и contexts. и незаменимы для адаптации контента под разные условия запросов: например, для мобильных устройсnв можно выводить контент с облегченным наполнением в одних панелях, а для десктопов - в других, задавая правила в настройках.

Аватар пользователя VasyOK VasyOK 19 декабря 2016 в 15:35
postgres wrote:

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

https://www.drupal.org/project/context_breakpoint - регулярно им свожу с ума заказчиков использую на различного рода проектах. Без помощи всяких панелей.

Аватар пользователя VasyOK VasyOK 18 декабря 2016 в 23:37

"4. Работа с фасетами"
Например вот сайтик с фасетами http://watches77.ru/casio (сайт просьба не судить он в вечной разработке).
Для чего тут могут понадобиться панели?

Аватар пользователя gun_dose gun_dose 18 декабря 2016 в 23:44

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

Аватар пользователя goodboy goodboy 19 декабря 2016 в 1:05
gun_dose wrote:

1. Если нужно выводить поле контента в другом регионе, либо вставить блок между полями.
Это можно сделать и без панелей, через views + блоки, но ведь вьюху ещё нужно создать и настроить, а в панелях прямо из коробки доступны панели со всеми отдельными полями контента. Более того, тут будет прирост по быстродействию, т.к. панели используют уже загруженный объект ноды из контекста, а вьюс возьмёт nid из url страницы и полезет за полем в базу.

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

gun_dose wrote:

2. Вывести один блок одновременно в два региона.

https://www.drupal.org/project/multiblock

gun_dose wrote:

3. Сделать разный шаблон для разных словарей таксономии.

https://www.drupal.org/project/block_visibility_vocabulary

Еще есть https://www.drupal.org/project/context

gun_dose wrote:

Панели используют Ctools API, которое позволяет легко выводить что угодно и как угодно при довольно простом коде. Более того, подобные задачи - одни из самых любимых на собеседовании у многих работодателей, поэтому овладеть этим кун-фу будет в любом случае полезно :)

Это да, буржуи любят панели.

Аватар пользователя gun_dose gun_dose 19 декабря 2016 в 7:31
goodboy wrote:

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

Речь идёт о выводе как раз одного единственного поля ноды. Читайте внимательнее.

Итого, вы предлагаете поставить несколько модулей, чтобы только не юзать панели?)))

Аватар пользователя goodboy goodboy 19 декабря 2016 в 16:02

Если одно поле, разницы особой не будет. В общем случае, видимо панели будут побыстрее. Интересно бы посмотреть в цифрах.

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

Я против панелей ничего не имею, просто написал, что задачу можно решить разными способами. Чем и хорош Друпал.

Аватар пользователя VasyOK VasyOK 19 декабря 2016 в 14:20
gun_dose wrote:

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

Понимаю аргумент. Надо будет взять заказ на магазин инструмента и попробую :)

Хотя если проблема в том, чтобы не было муки с перестановкой фасетов - их блоки можно сводить в группы. Например этим https://www.drupal.org/project/blockgroup (хотя тоже не особо удобное решение)
https://www.drupal.org/project/block_visibility_groups - может еще это под 8-ку подойдет.

gun_dose wrote:

Итого, вы предлагаете поставить несколько модулей, чтобы только не юзать панели?)))

таки да. У панелях реально как-то монстроузный и неинтуитивный интерфейс. Мне реально легче прописать div-ы в tpl.php шаблонах темы (хотя я добровольно так никогда не делаю), чем юзать панели. Ну или я не умею их готовить.

Аватар пользователя fairrandir fairrandir 19 декабря 2016 в 14:42

Ну и минусы панелей
1. Отсутствие сквозных блоков. Если задан кастомный заголовок например, то придётся пройтись по всем панелям и поменять вывод.
2. У блоков - не подхватываются классы из модуля block class, например. Да и вообще настройки блока в принципе.
3. Гибкие панели - только для прототипов. Каждая гибкая панель - это отдельный, генерируемый css файл. Ну и конская вложенность. (где-то в глубине 20-ти дивов спряталось маленькое содержимое поля.
Главный для меня плюс панелей - страницы таксономии и кастомные страницы. И юзаю как правило тупой лэйаут без обёрток, с одним регионом.
Второй плюс: мини-панели. Я ими блоки разные в три колонки вывожу, например.

На вкус и цвет фломастеры разные.

Аватар пользователя gun_dose gun_dose 19 декабря 2016 в 14:50
VasyOK wrote:

таки да. У панелях реально как-то монстроузный и неинтуитивный интерфейс. Мне реально легче прописать div-ы в tpl.php шаблонах темы (хотя я добровольно так никогда не делаю), чем юзать панели. Ну или я не умею их готовить.

Юзать панели для того, чтобы раскинуть контент по регионам - это действительно всё равно, что палить из пушки по воробьям. У панелей фишка в другом - надо тебе затащить дескрипшн термина вниз - взял и затащил мышью. Хочешь картинку из ноды в шапке выводить - взял и вывел. И не надо никаких вьюсов и кодинга - сокращается время на разработку. Если ничего такого не нужно, то и панели не нужны.

fairrandir wrote:

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

Согласен - это минус

fairrandir wrote:

2. У блоков - не подхватываются классы из модуля block class, например. Да и вообще настройки блока в принципе.

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

fairrandir wrote:

3. Гибкие панели - только для прототипов. Каждая гибкая панель - это отдельный, генерируемый css файл. Ну и конская вложенность. (где-то в глубине 20-ти дивов спряталось маленькое содержимое поля.

Гибкие панели не юзал. Лишние обёртки при необходимости убираю в шаблонах.

Аватар пользователя fairrandir fairrandir 19 декабря 2016 в 16:39

>> В панелях можно задавать классы любым фрагментам, т.е. при использовании панелей block class вообще не нужен.
Конечно можно. Каждому фрагменту. Какой хочешь. Но это скорее следствие пункта 1 - невозможность сквозных блоков. У меня есть сайт на поддержке, около 40-ка панелей, на 30-ти есть блок, которому надо было класс прописать. Я огорчился.

Аватар пользователя VasyOK VasyOK 19 декабря 2016 в 16:13
gun_dose wrote:

надо тебе затащить дескрипшн термина вниз - взял и затащил мышью. Хочешь картинку из ноды в шапке выводить - взял и вывел

Ну дескрипшн термина в блок, картинка ноды в шапке - еще блок. Один блок вверх другой вниз. Стили одинаково для этих элемнтов прописывать. Что они в панелях, что нет.
"И не надо никаких вьюсов" - на вьюсах между прочим очень удобно хлебные крошки делать :)

/*Добавлено*/
Конечно - вьюсом. Им же и хлебные крошки более кастомизированней чем всеми модулями крошек.

Аватар пользователя gun_dose gun_dose 19 декабря 2016 в 16:02

Чем ты засунешь дескрипшн термина в блок, если не вьюсом?

Для крошек есть path breadcrumbs

Аватар пользователя bsyomov bsyomov 19 декабря 2016 в 19:46
1

Использование панелей в подавляющим большинстве случаев, это плата производительностью и потреблением памяти за возможность "Накликать" шаблон.

В статье перечислено немало заблуждений.
1. Тут сложно что-то сказать, зависит от того что где и зачем...
2.Для этого есть context, копии блоков, программное получение блока и вывод его куда угодно.
3.Это прекрасно делается с без панелей. Если речь о шаблоне, можно делать даже простой темизацией.
5.Нужно просто уметь правильно делать тему, использовать фреймворки, и правильно переиспользовать код.
6. Это лучше делать своим модулем. =)

Я оптимизировал довольно немало сайтов. И избавление от панелей, зачастую, даёт ускорение в пару раз и уменьшает использование памяти до 10 раз! Без шуток. Так что подумайте 10-20-30 раз, стоит-ли в вашем случае скорость разработки значительного падения производительности. Например, для магазина время отклика может быть очень критичным, а именно в них я чаще всего эти проклятые панели и встречаю. =)

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

Аватар пользователя gun_dose gun_dose 19 декабря 2016 в 21:17

1. Сложно сказать, потому что панели выводят отдельные поля значительно быстрее вьюсов.
2. Контекст не менее монструозен, чем панели. Программное получение блоков хорошо для шапки и подвала, а программный вывод блоков в контентную часть ведёт к необходимости пожизненного технического сопровождения сайта.
3, 5. Простая темизация - это просто отлично, всегда при возможности обхожусь только ей, но когда шаблон имеет вид:

х9 х3
х6 х6
х5 х7
х4 х4 х4
х12

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

Что касатеся того, стоит ли скорость разработки падения производительности - однозначно стоит. Не всегда, но на небольших проектах точно.

Что касается магазинов, то там алгоритм ускорения совсем другой:
0. Перенастроить вьюсы с полей на отрендеренные сущности
1. Использовать поисковой индекс
2. Если Search API DB недостаточно - ставить solr
3. Переделать вывод меню каталога в статику. Очень интересный пункт, особенно в случае всяких мегаменю. Дело в том, что меню не кэшируется, т.к. на каждой странице нужно высчитывать актив трэйл по новой. Наверное, об этом будет мой следующий пост))

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

Аватар пользователя bsyomov bsyomov 20 декабря 2016 в 3:55

«0. Перенастроить вьюсы с полей на отрендеренные сущности»
Ну главное не на ноды... =)
Это, кстати, далеко не всегда оптимальное решение, и при его принятии стоит тестировать производительность, и убедиться перед этим, что сервер БД нормально настроен.
1,2 При чём тут поиск вообще?,
3. Интересно будет почитать об этих граблях.

Аватар пользователя gun_dose gun_dose 20 декабря 2016 в 17:24

Затем, что от индексации ускорение больше, чем якобы тормоза от панелей)))

Аватар пользователя bsyomov bsyomov 20 декабря 2016 в 23:05

Индексации чего?
У вас есть страница с панелями, есть та же без них. Один из вариантов работает эффективнее.
Каким боком тут индексация, если это не страница результатов поиска?
Или вы каталог весь предлагаете используя поиск вместо простой выборки про категории показывать, например?
Или у вас в магазине будет только форма поиска и страница с результатами? =)
Или я вообще не понимаю ход вашей мысли. Брр.

Аватар пользователя multpix multpix 20 декабря 2016 в 23:15

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

Панели тут не причем.

Аватар пользователя gun_dose gun_dose 20 декабря 2016 в 23:26

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

ЗЫ: на самом деле ресурсы жрут не панели, а php и mysql , но вы отказ от них почему-то привели в последнюю очередь)))

Аватар пользователя bsyomov bsyomov 21 декабря 2016 в 1:01

Не php и mysql, а излишние абстракции, и кривые запросы.

По поводу поискового индекса - если это внешний solr, если существует много фильтров и.т.п., да, это может быть оптимизацией. Но это не самый частый кейс.
При схеме категории-товары, без 100500 важных для фильтрации полей в товаре, реализация на таксономии и views тоже будет быстрой. Если не испортить её парой тройкой слоёв лишних абстракций, конечно...
И таких магазинов, на самом деле, куда больше. Мало того, сложные фильтры часто просто не уместны, и больше пользователей отвлекают от покупок, чем помогают что-то купить.

Кстати, join, и даже несколько сами по себе не так страшны, если есть нужные индексы.

Аватар пользователя voviko voviko 19 декабря 2016 в 20:24
bsyomov wrote:

Использование панелей в подавляющим большинстве случаев, это плата производительностью и потреблением памяти за возможность "Накликать" шаблон.

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

Аватар пользователя bsyomov bsyomov 19 декабря 2016 в 21:13
1

Панели не заменяют views, и наоборот.
Панели заменяют отчасти темизацию отчасти context. А темизация на шаблонах в разы быстрее, что и не удивительно - создать структуру по заданной программе куда накладнее, чем вставить значения в готовую структуру.
По поводу кеширования - без панелей оно тоже есть, причем масса разных уровней кеширования от views до кеша страниц, и даже boost, на любой вкус. Почему бы им не пользоваться? Тот же буст будет куда эффективнее, если вы можете позволить себе кеширование. =)
Ну и всегда надо помнить о том, что кеш надо перестраивать, о чём многие забывают, а это очень важно...
Кроме того, кеш не всегда применим в принципе.

Ещё раз советую всем тем, кто возражает по поводу быстродействия произвести эксперимент с профайлером и одинаковым функционалом с панелями и без. Это быстро поставит всё на свои места. Devel + xhprof вполне просто ставятся и неплохо работают. Даже с xdeug не придётся разбираться.

Аватар пользователя kuzmich111 kuzmich111 27 декабря 2016 в 0:19
1

На почти голом друпале стандартные 15 блоков вывел традиционным способом и через Panels. У панелей оверхед 136%, что весьма не приятно. Хотел использовать в качестве п.5, теперь сижу думаю.

Аватар пользователя bsyomov bsyomov 27 декабря 2016 в 15:58

Поздравляю. Хоть один здравомыслящий человек решил-таки проверить. =)
Это, кстати, ещё ничего - не такой и большой оверхед. Обычно всё ещё намного хуже, особенно, если начинают везде этими панелями заменять темизацию...
Там бывает и на порядок получается разница.

Аватар пользователя sergeybelya sergeybelya 27 декабря 2016 в 11:27

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

Аватар пользователя gun_dose gun_dose 27 декабря 2016 в 11:45

Специально же расписал, что к чему, а вам всё лэндинги))

Постараюсь ещё раз резюмировать в двух словах: панели - это не только таскалка квадратиков в админке, но во многих местах хорошая замена вьюсам, а также хорошее их дополнение + инструмент с мощным АПИ.

А для лэндингов лучше параграфы.

Аватар пользователя sergeybelya sergeybelya 27 декабря 2016 в 11:51

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

Аватар пользователя Studio VIZA Studio VIZA 27 декабря 2016 в 11:29

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

Аватар пользователя Studio VIZA Studio VIZA 27 декабря 2016 в 13:03
VasyOK wrote:

у панелей действительно весомое преимущество.

Человек как хочет, нажал - изменил, а в случае панелей, она часто показывает вьюху, которая показывает тип материала, в доме который построил Джек. Снос крыши обеспечен.

VasyOK wrote:

в том что они нужны многим заказчикам.

Прямо ходят и просят? я бы сказал - вспоминают с содроганием.

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

Аватар пользователя bsyomov bsyomov 27 декабря 2016 в 15:54

Что, часто,говорит о том, что заказчикам не стоит выбирать инструменты, с помощью которых будет сделан их сайт.
Ну и следующий, после такого заказа с панелями, у заказчика другой заказ - сделайте что-нибудь, чтобы сайт хотя бы на выделенном сервере не тормозил.
Вот тут то панелям и хана. =)

Аватар пользователя gun_dose gun_dose 27 декабря 2016 в 16:23

В объявлениях панели требуют знать только от тех, кого ищут на постоянку в нормальную контору. К слову, наблюдается интересная корелляция - больше всего панели не любят фрилансеры.

Аватар пользователя VasyOK VasyOK 27 декабря 2016 в 16:45

ага хотел в одну нормальную контору устроится, так меня прям порога спросили:
"Скажи мне брат, любишь ли ты панели как люблю их я, а не наплодишь ли ты регионов в теме оформления"

Аватар пользователя sergeybelya sergeybelya 27 декабря 2016 в 17:24

Не знаю, за два года в работы в одной из таких нормальных контор с панелями пришлось работать лишь однажды, причем в восьмерке и то с panelizer. Как-то больше не возникала необходимость в их использовании.

Аватар пользователя VasyOK VasyOK 27 декабря 2016 в 14:30

gun_dose, можешь в теме голосование поставить? Пункты на твое усмотрение, как вариант эти.
Panels это...
1) инструмент разработки универсальных решений (использую везде)
2) инструмент разработки кастомных решений (использую редко)
3) инструмент выбивания денег из забугорых заказчиков (использую потому что платят)
4) неудобный инструмент (не использую вообще)

Аватар пользователя bsyomov bsyomov 27 декабря 2016 в 15:49

Забыл ещё вариант:
5) Приходится вырезать на каждом втором оптимизируемом сайте. =)

Аватар пользователя gun_dose gun_dose 27 декабря 2016 в 15:59

Ты так говоришь со знанием дела и опытом. В связи с этим интересно, какого масштаба сайты приходилось оптимизировать?

Аватар пользователя bsyomov bsyomov 28 декабря 2016 в 15:47

Т.е. технические доводы кончились и начались вопросы в стиле "а ты ещё кто тут такой"?

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

2мегахита в день масштабный сайт?
Сеть сайтов раздающий видео в потоке 40Гбит масштабный проект?
Или вам интересен какой-нибудь ресурс, который у всех на слуху? Не, вот таких как-то не было, увы.