Разгоняем Drupal

1 сентября 2009 в 4:38
Аватар пользователя Гость 0 26

Разгоняем Drupal

Примечание: ниже расположен перевод заметки "Improving Drupal's page loading performance", в которой рассматриваются прикладные методы увеличения клиентской производительности для сайтов, построенных на этой CMS. Весьма интересен ход рассуждений при построении высокопроизводительного сайта. Мои комментарии далее курсивом.

Введение

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

Поскольку вы читаете эту статью, то, скорее всего, являетесь разработчиком под Drupal. И по всей видимости, некоторые из посетителей вашего сайта, сделанного на Drupal, недовольны скорость загрузки страниц. И это не зависит от того, расположен сайт на виртуальном хостинге, VPS или выделенном сервере. А если ваши посетители физически расположены вдали от самого сервера, то проблемы эти для них приобретают еще больший масштаб.

В этой статье рассказывается, как с этим бороться

продолжение...

Комментарии

Прошелся по всем ссылкам и увидел много полезнейшего материала.
Автору огромное спасибо!
Скачал YSlow. Сейчас опробую эту штуковину.

1 сентября 2009 в 11:40

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

1 сентября 2009 в 20:03
Аватар пользователя cpu cpu 0

Что заметил.
Многие сайты на Drupal обьеденяет загрузка страницы.
Сначала загружается HTML(белый экран и текст на нем), и только потом CSS(появляется оформление этого всего).
Иногда, если сайт не догрузился, CSS вообще не подгружается.
Кто как с этим борется?
Drupal.ru кстати тоже так грузится.

1 сентября 2009 в 21:17

cpu wrote:
Что заметил.
Многие сайты на Drupal обьеденяет загрузка страницы.
Сначала загружается HTML(белый экран и текст на нем), и только потом CSS(появляется оформление этого всего).
Иногда, если сайт не догрузился, CSS вообще не подгружается.
Кто как с этим борется?

В книжке ("Разгони свой сайт") подробно описан этот "феномен". Называется "куча скриптов в head-страницы" (причем это может быть даже всего один файл, просто очень большой, это же к стилям относится -- но с последними много не пошаманишь). Нужно выносить вниз, либо по событию DOMloaded вставлять.

По поводу книги "Реактивные веб-сайты" -- через две недели планируется выложить первую версию. То, что сейчас выложено, - лишь предварительные наброски материала, уже сейчас рукопись в полтора раза больше. Следите за обновлениями
speedupyourwebsite.ru/books/reactive-websites/

По поводу оптимизация скорости загрузки и прочего. Авторами книг разработано инновационное приложение для применения всех возможных действий по клиентской оптимизации (анонс здесь уже мелькал) - Web Optimizer. Пока как модуль для Drupal его нет, оно ставится поверх любого PHP-сайта. Мы будем рады услышать отзывы от пользователей Drupal. Загрузить приложение можно здесь: code.google.com/p/web-optimizator/downloads/list

2 сентября 2009 в 11:01

"cpu" wrote:
YSlow штука хорошая, но из-за нее у многих катастрофически тормозит Файрфокс,

Особых тормозов я не заметил, но обратил внимание на утверждение этой хрени, что скорость загрузки drupal.ru, например, можно увеличить в несколько раз. Хотя он и так довольно шустро загружается.
"cpu" wrote:
Иногда, если сайт не догрузился, CSS вообще не подгружается.

Рекомендуют, например, вставлять CSS в шапку возможно выше, а JS -- в подвал, оптимизировать стилевые таблицы, использовать спрайты, ну, и сжимать всё это хозяйство.

P.S. Кстати, по ссылкам скачал 2 очень приличные книги:
http://speedupyourwebsite.ru/books/speed-up-your-website/SpeedUpYourWebs...
http://speedupyourwebsite.ru/books/reactive-websites/ReactiveWebsites.v0...

1 сентября 2009 в 22:41

2mdinc В опросе нехватает "Нет, но собираюсь", или "Нет , но очень хочу" В связи с чем спасибо за статью Smile

А неподскажете как быть с оптимизацией css и js файлов , если включён приватный метод загрузки. Есть ли какие другие способы?

1 сентября 2009 в 23:57

mdinc wrote:
Это не аптимизатор а всего навсего упаковщик который прикручивается через ob_start
короч берет весь вывод drupal и прогоняет через себя тратя при этом процессорное время
этот способ прикручивания вы можете организовать и сами без таких левых и громоздких скриптов
и кстати тож самое кеширование и JS и CSS в Drupal реализовано
Но правда слишком топорно

И тем более никак он не уменьшит число запросов к БД

1. Именно так и работает, занимает 3-5 мс (если не врубать кэш). Обычно страница на сервере генерится 100-300мс. Вам жалко 2% серверного времени? А собрать оптимизированную сборку Drupal, чтобы сэкономить время вебмастерам и не объяснять, почему нужно включать объединение CSS (которые, нужно заметить, в Drupal реализовано неэффективно) не хотите ли? Вот, и я тоже не хочу, зато предлагаю решение, котрое облегчит жизнь миллионам людей.

Если стоит задача собрать сайт на Drupal "за час", то человек не будет лазить по форумам, ручками клеить спрайты в теме и тюнить систему. Возьмет и поставит Web Optimizer, и сэкономит кучу времени

2. По поводу "тож самого кеширования и JS и CSS" я написал выше. Если люди делают что-то на коленке, то и качество получается средненькое. Хотите полусборный сайт -- пользуйтесь встроенными методами. Хотя авторы модулей и ядра Drupal всерьез позаботились о производительности, но там, действительно, нужно много еще чего сделать.

3. Оптимизировать число запросов к БД нужно, но Web Optimizer этим не занимается. Это вообще нетривиальная задача: уменьшить число запросов в автоматическом режиме. Разогнать сайт за счет клиентской составляющей -- да, автоматизируется. А БД -- только за счет многоуровневого кэширования (и только так в общем случае).

4. Уважаемый, и почему там хочется вылить ушат грязи на чужой, незнакомый проект, о котором, мало что не слышали ни разу, так еще и, наверное, сами не пробовали и не пытались разобраться, что же предлагают авторы. Откуда такое неуважение к окружающим?

7 сентября 2009 в 22:01

что я всегда делаю:
- собираю все CSS в один и оптимизирую его TidyCSS и создаю gzip-нутую копию
- JS Aggregator
- jpg в оформлении как правило отлично переводится в png/gif

2 сентября 2009 в 13:05
Аватар пользователя cpu cpu 0

Вот как у меня на странице page.tpl.php

<head>
  <title><?php print $head_title; ?></title>
  <?php print $head; ?>
  <?php print $styles; ?>
  <?php print $scripts; ?>
</head>

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

Стили грузятся так, сначала все стили элементов модулей.
Например: /sites/all/modules/jimage/jimage.css
потом стили темы: /sites/all/themes/nametheme/nametheme.css

Может дело в этом?

2 сентября 2009 в 13:46

Может. Объединение css пробовали включить?

Если браузер Опера, то это вообще не проблема, т.к. этот браузер начинает рендеринг (прорисовку) еще до полной загрузки страницы и скриптов. Осел обычно ждет полной загрузки необходимых элементов.

2 сентября 2009 в 14:17
Аватар пользователя Dan Dan 0

Насколько я знаю, ни одна существующая CMS/CMF не позволяет создавать CSS sprites «не лету». И ни в одной системе нет даже модуля или расширения, которое бы позволяло это делать. Это может стать ключевой возможностью в Drupal, если появится ее поддержка. И любая CMS значительно выиграет от этого. На данный момент автоматизировать процесс только создания data:URI из исходных CSS-файлов.

Было две попытки: [module=css_sprites], [module=sprite] и один модуль: [module=sprites]. Судя по статистики использования, одним - не нужно, другие - делают ручками.

2 сентября 2009 в 14:52

"Dan" wrote:
Насколько я знаю, ни одна существующая CMS/CMF не позволяет создавать CSS sprites «не лету».

А зачем «на лету»?
Ведь не каждый же день их нужно создавать?
Неужели буржуинам и ручками уже лень пошевелить?

2 сентября 2009 в 21:35

Quote:
Пока кто-нибудь не укажет мне на необходимость расположения JS-файлов в начале странице, я не изменю своего мнения по поводу упомянутого правила.

Ифрейм Google CSE криво выводится, если js в футере.

3 сентября 2009 в 23:27

Далеко не каждый скрипт можно вынести вниз страницы. Особенно когда используется тонна разных скриптов от кучи людей... Вот что мне реально не нравится, так то, что BUEditor и Lightbox срут в код страницы своими настройками. Как и многие другие модули, впрочем...

4 сентября 2009 в 19:30

<a href="mailto:Mr.Alinaki@drupal.org">Mr.Alinaki@drupal.org</a> wrote:
Далеко не каждый скрипт можно вынести вниз страницы. Особенно когда используется тонна разных скриптов от кучи людей... Вот что мне реально не нравится, так то, что BUEditor и Lightbox срут в код страницы своими настройками. Как и многие другие модули, впрочем...

В общем случае, задача все же решается. Просто довольно много моментов нужно учитывать для алгоритма "переноса вниз". Но можно.

7 сентября 2009 в 22:02

перенес скрипты вниз
блин, стало летать Smile в смысле страница открываетс быстро, а потом, где то там, видно что скрипты подгружаются

5 сентября 2009 в 21:02
Аватар пользователя Dan Dan 0

"<a href="mailto:Mr.Alinaki@drupal.org">Mr.Alinaki@drupal.org</a>" wrote:
Далеко не каждый скрипт можно вынести вниз страницы.

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

8 сентября 2009 в 14:38

Не особо сложно. Есть опция scope в ядре. Но меня просто затрахало патчить кучу модулей и выбирать, что и куда. Пока это не будет массово - можно только руками.

Например, развернуть scope в полную силу было бы круто в модуле jsalter, если для шестерки. Но пока там этого нет, а у меня просто нет времени на патч.

8 сентября 2009 в 17:29