8 октября 2009 в 12:38
Обычно термин агрегация в рамках Drupal упоминают когда подразумевают процесс при котором все множество js css файлов собираются в один, соответствующий своему типу, файл. Тем самым добиваются уменьшения количества запросов к серверу что приводит, обычно, к снижению времени затраченное браузером на формирование страницы.
Привожу пример ситуации, о которой часто не задумываются, приводящая к тому что агрегация не только не помогает, а напротив вредит. Впрочем виновата не сама агрегация, а бездумное ее использование.
Имеем проект где активно используется jQuery и плагины к нему. Упакованный 1.2.6 сейчас занимает 30 килобайт.
Имеем две страницы
на первой используется(добавляется drupal_add_js) плагин my_plug_1 для jQuery величиной аж 1 килобайт.
На второй странице используется mu_plug_2 величиной аж 2 килобайта.
Имеем клиента с включенным в браузере кешем, делающего запрос к нашей странице номер 1.
Агрегатор включен.
произойдет следующее:
при загрузке первой страницы, агрегатор создаст файл с уникальным именем величиной JQuery + my_plug_1 = 31 килобайт.
при загрузки второй страницы создаст ЕЩЕ ОДИН УНИКАЛЬНЫЙ ФАЙЛ размером уже jQuery + my_plug_2 = 32 килобайта.
В результате из за агрегации, при запросе второй страницы вытаскивался код JQuery повторно. То есть лишних 30 килобайт.
Агрегатор выключен
при запросе первой страницы в коде двумя строками были бы указаны наши скрипты jQuery и my_plug 1. которые были бы закешированы бразуером.
При запросе второй страницы код Jquery уже бы не вытягивался - он в кеше.
Конечно я ситуацию сильно упрощаю, уже хотя бы потому, что если в условие добавить фактор как величина канала у клиента, то для него лишние 30 килобайт это ничто по сравнению с еще одним запросом к серверу.
Комментарии
вот тут на сайте, на данной странице, js-файл весит 134 кБ. Это в голове страницы. В хвосте - еще один, на 25 килограм. Вот такая вот загогулина. Плюс ко всему, 38к - ЦСС.
именно, причем это не тот же js который на главной странице. Который весит 44. 30 из которых все то же jquery
Ну достаточно сжимать css и js файлы. А вот сплитить их или нет это уже дело вкуса...
не соглашусь в вами.
при правильном использовании агрегации первая загрузка страницы (когда скрипты не закешированы) может оказаться значительно быстрее
чем та же страница с сжатыми js НО без агрегации.
Возможно, но агрегацию я не включаю. После завершения дебагинга скриптов и стилей обычно сжимаю всё, затем включаю gzip...
В случае с джаваскриптами можно сделать вывод, что лучше не использовать агрегацию, когда на разных страницах сайта мы загружаем разные плагины. Это так?
Ну, а насчет css-файлов, я думаю, что агрегация полезна, т.к. удаляются лишние определения стилей. Но это верно, если мы все css-свойства описываем только в одном style.css файле темы...
Если вы не собираетесь сами ей управлять то да
с css фалами все то же самое как и с js файлами.
бездумная агрегация вредит.
А что по вашему есть бездумная агрегация? Когда же вообще разумно ее использовать?
когда нужно скрыть, что у вас на сайте использовано 10 вагонов модулей и еще маленькая тележка
Бездумная означает собирать все в один файл что указано на текущей странице.
Такой алгоритм правильный только в одном случае - если у вас на ВСЕХ страницах одни и те же css файлы и js файлы.
Агрегация - это крайне эффективный способ оптимизации процесса загрузки страницы. И использовать его нужно обязательно. НО НЕ В ТОМ автоматическом режиме которые присутствует в друпал по умолчанию.
Разумное ее использование начинается как минимум с простого примитивного шага.
Аудит всех модулей использующих свои js файлы. И сборка ИХ всех в единый js при этом меняя логику добавления js кода на страницу. грубо говоря отключая ее совсем.
вы проигрываете в первой загрузке страницы, потому что пользователь загрузит много ненужного js кода. Но при верно выставленном кешировании более пользователь ничего грузить уже не будет.
Пример что выше крайне примитивен. И на деле же используют значительно более сложные механизмы. Но для демонстрации того как делать лучше вполне сгодится.