Millennium
Myfety Millennium

создание веб-сайтов в Праге недорого
  WEBO Software повышает эффективность сайта благотворительного фонда «Счастливый мир»   Высокая производительность для Contra Costa County

Разгоняем Drupal

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

Введение

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

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

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

Клиентская производительность

Беглый сервер с большим количеством оперативной памяти впредь до известной степени улучшит производительность вашего сайта. Н насчет прежде чем ваш сайт довольно достаточно большим, у него безразлично появится некоторое количество узких мест, которые могут скрываться устранены с гораздо большей отдачей. И затраты для это будут совсем невелики. Обычно для получение HTML-файла уходит меньше 20% только времени загрузки страницы. Это означает, сколько остальные 80+% приходятся в все то, что вкушать в самом HTML: CSS, JS, картинки, видео. И в течение многих случаях это 80% — это только оценка снизу.

В зависимости через того, с каким сайтом проводится произведение, какая физическая мощность около сервера, и т. д., вы можете урезать через 25 до >100 ( почти) процентов от текущего времени загрузки страницы. Как первоначальная ( начиная с пустым кэшем), так равным образом последовательная (с полным кэшем) загрузка страницы довольно значительно быстрее, если все конечно вы еще не провели своих собственных мероприятий до оптимизации.

Огромная взятка отправляется исследовательскому центру Yahoo!, кто явил миру свои четырнадцать заповедей вообще с инструментом YSlow (я к нему перейдем дословно через секунду), с через которого можно проверить, насколько производительность сайта соответствует указанным правилам. Если вы успешно примените все-таки 14, то ваш сайт довольно просто летать. (При часть предположении, что время создания страницы никак не является сверхбольшим.) Всегда дозволительно провести еще немного оптимизации ради сайта. Некоторые наиболее эффективные способы будут освещены в течение конце статьи.

YSlow

Ради начала стоит убедиться, который вы установили Firefox, Firebug да YSlow for Firebug (разновидность 0.9 или более поздняя).

Firebug простой должен быть у каждого веб-разработчика, да совсем не важно, любитель вы или новичок. YSlow является дополнением для Firefox, разработанном к недрах Yahoo!, равным образом позволяет анализировать вашу веб-страницу также находить те места (вспоминаем те 14 правил?), где она есть тот грех тормозит и почему да происходит (игра слов в среде “why slow” и “y-slow”). Н в отношении в то же самое сезон этот инструмент показывает, вроде можно устранить все эти недочеты. Чем меньше комната правила, тем значительнее следствие.

Следом я разбираю особенности Drupal 5 равным образом 6 относительно каждого правила равно возможности этой CMS, ее настройки равно рекомендации для ускорения загрузки вашего сайта.

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

Правило первое: уменьшаем наличность HTTP-запросов

Требование Drupal 5 Drupal 6
Объединение CSS-файлов так точно да
Объединение JS-файлов не имеется да
Автоматическое работа CSS Sprites нет не имеется

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

Решение

Самый обыкновенный путь для уменьшения числа запросов — это включения на Drupal объединения CSS- равно JS-файлов. Соответствующие настройки находятся в течение admin/settings/performance в вашем сайте Drupal.

В случае Drupal 5 существует полезное добавление, которое обеспечивает ту но функциональность из Drupal 6′до объединению JS-файлов. Сдвигать ее можно из этой заметки — аз проспонсировал создание этого патча.

В Drupal отсутствует модуля для автоматического создания CSS Sprites. Если около сайта достаточно тяжелый дизайн, то быстрота загрузки при использовании CSS Sprites может возрасти значительнее, чем потом объединения CSS- и JS-файлов. Я разительно надеюсь, что кто-нибудь (либо какая-то компания, занимающая разработкой в основе Drupal) позаботится относительный этом и возьмет инициативу в течение свои руки.

В то но время есть бесплатный снаряд для создания CSS Sprites, коли вы не против легкий работы при оптимизации.

Правило второе: используйте CDN

Требование Drupal 5 Drupal 6
Динамически вероломствовать URL подключаемых файлов не имеется нет

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

Решение

Я предпочел ориентироваться с этой проблемой единовластно, потому что использование CDN гораздо улучшает удобство использования вашего сайта в пользу кого посетителей, которые расположены вдалеке с ваших серверов. К тому но я работаю над одним проектом, около которого аудитория весьма крепко распределена по поверхности Земного шара.

Первое, сколько нам, очевидно, понадобится, — это дополнить суть Drupal поддержкой функции изменения URL к файлов. Я выбрал оборот создания новой функции, да завел file_url(), которая должна была делать URL для всех файлов, на том числе URL с целью дополнительных CSS-Файлов на шаблоне page.tpl.php ( примем, для файла print.css). Это добавление также обеспечивало и дальнейший новый метод: hook_file_server(), начиная с помощью которого модули могли объявлять новые файловые сервераs. В Угоду Кому задания файлового сервера «до умолчанию» была добавлена настройка File servers в течение форму File system settings. Если который-то сервер оказывается никак не в состоянии выдать запрошенный файл, то Drupal попробует обратиться для следующему серверу по списку, кроме далее. И всегда крюк перебора серверов закончится для исходном веб-сервере, в котором находится сам Drupal — коль все сервера окажутся недоступными.

На известный момент доступен патч лишь для Drupal 5 (он включен в течение модуль интеграции с CDN, кто выложен в конце этой статьи), поскольку аз хочу получить некоторое цифра отзывов перед тем, как бы буду поддерживать данный модуль в пользу кого двух различных ветвей Drupal. Как лишь патч закрепится в своей финальной форме, аз выложу его версию в видах Drupal 6 и, естественно, буду соглашаться сделать это для Drupal 7. П в рассуждении этому поводу создан инцедент в Drupal.org.

Вторая пакет (интеграция с CDN), за-видимому, должна включать реализацию функции hook_file_server(). Именно следовательно появится на свет модуль интеграции CDN. Он был написан от учетом большой гибкости: он поддерживает дополнения в видах синхронизации файлов (на известный момент доступно одно с них — FTP), может делать уникальные имена файлов разве директорий (будет необходимо в угоду кому сохранения относительных путей), обеспечивает близко инструментов для проверки, насколько что работают фильтры (статистика за каждой странице и совершенно для сайта), а сами фильтры могут заключаться заданы при помощи естественных к Drupal параметров функции file_scan_directory().

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

Правило третье: добавляем надпись Expires

Требование Drupal 5 Drupal 6
Не определять заголовок Expires для веб-страниц так да
Выставлять надпись Expires для всех остальных файлов так точно да
Выставлять надпись Expires в далекое будущее: мочь изменять URL файлов динамически на сброса кэширования нет несть

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

Drupal выставляет надпись Expires для всех файлов, отличных с HTML, сроком на две недели. В большинстве случаев этого совершенно достаточно. Однако чтобы максимальной производительности, эта дата должна существовать выставлена в далекое будущее (положим, на 10 лет будущий от времени доступа), который потребует использования уникальных имен файлов: отдельный раз, когда файл меняется, нам надо менять его имя ( воеже форсировать сброс кэша около пользователей), именно поэтому необходимым требованием является перемена имени файлов. Если этого никак не сделать, то некоторые с ваших пользователей будут любоваться старые версии файлов (потому то они будут загружаться с кэша).

Решение

Выставить будущую дату чтобы заголовка Expires достаточно простой: нужно просто отредактировать ваш файл .htaccess. На сервере Apache быть этом должен быть установлен mod_expires, за умолчанию это доступно в большинстве серверов. Однако создания уникальных имен файлов — это с совсем другой оперы. Проблема изменения имени файлов уже решена присутствие разборе второго правила. Поэтому всегда, что нужно сделать, это настроить файловый сервер, кто это поддерживает. Уа упомянутый модуль интеграции почти CDN обладает этой функциональностью, однако для его использования, естественно, надо арендовать CDN.

Правило четвертое: применяем GZIP

Требование Drupal 5 Drupal 6
GZIP с целью веб-страниц да конечно
GZIP для CSS- равным образом JS-файлов нет недостает

Когда в Drupal включено кэширование страниц, то сами страницы записываются в течение кэш уже в виде gzip-архивов! Чтобы испытывать немного больше о часть, как Drupal работает из gzip, вы можете запустить следующую команду с корневой директории сайта, в угоду кому которого установлен Drupal:

egrep ?rn "gzip" .

Не забудьте точку на конце!

Однако вплоть до сих пор Drupal никак не позволяет применять gzip-сжатие в пользу кого CSS- и JS-файлов.

Решение

Прибавление к ядру Drupal позволяет обеспечить данную функциональность, а, к несчастью, он уже некоторое эпоха не доступен.

Если вы используете выше- модуль интеграции с CDN, то о этом можно забыть: модуль до умолчанию применяет gzip, коль скоро браузер его поддерживает.

Альтернативное приговор

В качестве альтернативы не грех предложить настроить сам сервер Apache дл автоматического сжатия файлов.

Например, в видах Apache 2.x: дозволено добавить следующие строки в течение ваш .htaccess или httpd.conf:

AddOutputFilterByType DEFLATE text/css application/x-javascript

Правило пятое: располагаем CSS на начале страницы

Требование Drupal 5 Drupal 6
Метод в пользу кого добавления CSS-файлов в веб-страницы да верно
Месторасположение файлов до умолчанию находится в <head>-секции XHTML-документа так да

У Drupal употреблять общий метод: drupal_add_css().

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

Правило шестое: располагаем JS на конце страницы

Требование Drupal 5 Drupal 6
Метод к добавления JS-файлов для веб-страницы да так точно
Месторасположение файлов до умолчанию находится перед </body> в течение XHTML-документе нет и в помине нет

В Drupal также вкушать и следующий метод: drupal_add_js().

JS-файлы должны помещаться в конце страницы, причинность браузеры ждут загрузки всех ресурсов, упомянутых на <head>. Как вы, знать, знаете, JS-файлы теперь достаточно велики, поэтому их загрузка выливается в течение ощутимое время, которое сказывается для замедлении отображения страницы (браузеры показывают седой экран все это срок, не имея возможности сколько-либо предпринять). Если вы разместите JS-файлы на конце страницы, тогда браузеры смогут отобразить ее тема, продолжая загружать сами JS-файлы! Это и позволит добиться большого числа параллельных потоков, сколько значительно уменьшит время загрузки.

Обсуждение в эту тему уже было для groups.drupal.org.

Решение

К несчастью, до умолчанию у параметра $scope ради drupal_add_js() неудачное значение: 'header'. Если я поменяем его на простой 'footer', то будет уже что. Число дополнительных модулей, которые принудительно загружают файлы на 'header' крайне невелико, следовательно в общем случае довольно достаточно просто осуществить эту операцию. И мы еще не встречал модулей, из которыми возникали бы проблемы около перемещении вызовов JS-файлов с заголовка страницы в ее дно.

Более сложной частью этого решения являются сами JS-Файлы Drupal: misc/jquery.js также misc/drupal.js. Они могут заключаться расположены в низу страницы лишенный чего каких-либо проблем. Ноб что если дополнительный модуль захочет разместить приманка файлы в заголовке страницы? Они могут общий не загрузиться! Для увеличения совместимости нам надо будет по-прежнему размещать базовый коллекция JS-файлов в head-секции, когда хотя бы один модуль захочет поместить туда приманка файлы.

Я выложил дополнения на правах для Drupal 5, да и для версии 6, только ни в одном с них не внедрена более сложная прием, заявленная выше. П насчет моему мнению, Drupal принужден принять строгие правила относительно JS-файлов: они всегда должны быть «ненавязчиво-совместимы» ( в течение оригинале используется footer-compatible, однако данная политика в первый встречный случае недостаточна для сложных веб-приложения — они безвыездно должны поддерживать загрузку на динамическом или отложенном режиме, проверяя однако зависимости перед инициализацией). Пока который-нибудь не укажет мне в необходимость расположения JS-файлов в течение начале странице, я отнюдь не изменю своего мнения за поводу упомянутого правила.

Альтернативное приговор

Есть и второй метод, чтобы решить описанную проблему, кто не требует вмешательства на ядро Drupal. Однако он более трудоемкий, причинность предполагает повторения действий в пользу кого каждой используемой темы оформления. Предположим, сколько вы используете стандартную тему Drupal — Garland. Тогда откройте файл themes/garland/page.tpl.php в течение вашем любимом редакторе. Отыщите начальство этого файла строчку:

<?php print $scripts ?>

Вырежьте ее оттуда равно переместите перед следующей строкой:

<?php print $closure ?>

Ида, результат будет выглядеть приблизительно так:

<?php print $scripts ?>
<?php print $closure ?>
</body>
</html>

Как вы видите, это позволит вызвать безвыездно подключения скриптов прямо накануне закрывающим тегом <body>. (На самом деле, и еще до вывода $closure, что создается всеми вызовами hook_footer().)

Правило седьмое: избегаем CSS-выражений

Требование Drupal 5 Drupal 6
Н равно одна тема по умолчанию отнюдь не должна их использовать так точно да

CSS-выражения нисколько рекомендуется использовать при верстке страниц, причинность они могут выполняться великое избыток раз на одной равным образом той же странице: если она отрисовывается, или изменяется ее величина, а также когда выполняется прокрутка за странице (здесь освещена более подробно вопрос CSS-выражений). Пересчет выражения может проистекать даже при движении мышью!

Н равным образом одна из стандартных тем Drupal отнюдь не использует CSS-выражений. Поэтому нуждаться просто убедиться, что их несть в вашей теме.

Правило восьмое: CSS- также JS-файлы должны составлять внешними

Требование Drupal 5 Drupal 6
CSS- также JS-код не принужден вставляться внутри страницы иначе включаться по минимуму согласен да

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

Правило девятое: уменьшаем DNS lookups

Требование Drupal 5 Drupal 6
Использование 2-4 хостов сообразно умолчанию: возможность динамически переменять URL выдаваемых файлов недостает нет

На моей памяти ни сам по себе провайдер услуг хостинга никак не предлагает по умолчанию статический файловый сервер (скорее только, имеется в виду легкие сервера типа thttpd, nginx иначе 0W). Поэтому весь очевидно, что и Drupal до умолчанию не настроен в работу с ним. Однако я можем заставить Drupal помогать это решение за счет внешних дополнений.

Если вы используете порядком много так называемых виджетов (небольшие информационные блоки с Flickr, del.icio.us, MyBlogLog равно т. д.) на вашем сайте, то стоит предпринять некоторые дополнительные действия.

Решение

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

Если вы уже используете выше- модуль интеграции с CDN, вы уже будете пользоваться 2 или более хоста, а это потребует, естественно, самого CDN.

В качестве альтернативы вы можете пользоваться обычный файловый сервер. В статье Robert Douglass’ до использованию Drupal с сервером в интересах статических файлов очень что описаны все за да против такого подхода равным образом настройки сервера (на известный момент nginx будет более резонным выбором до сравнению с thttpd, благо что nginx может лежать одновременно и фронтендом с целью вашего Apache).

Также стоит узнавать с мыслями Yahoo в эту тему.

Решение к виджетов

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

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

Правило десятое: уменьшаем JavaScript

Требование Drupal 5 Drupal 6
Минимизация JavaScript недостает нет

Этот подход уже был изначально включен в течение ядро Drupal 6. Однако он был удален с-за ряда возникших проблем начиная с неработоспособным JS-кодом затем минимизации. В качестве минимизатора в течение Drupal 6 использовался Dean Edwards’ packer да известный как Packer (достаточно странный выбор, если учесть, сколько YUI Compressor выдает первоклассный результат при применении дополнительного gzip-сжатия).

Решение

Packer Не лишь уменьшает код, он да подвергает его обфускации. При минимизации удаляются но лишние пробелы и комментарии ( также некоторые другие конструкции, сообразно спецификации кода), обфускатор тем не менее дополнительно видоизменяет код: переименовывает переменные также функции (в более короткие). С Целью этого packer использует личный алгоритм (в котором зашифровано само его фамилия). Это приводит для серьезному увеличению времени загрузки кода: до 200 мс для распаковки JS! Точный, эффективность от применения gzip-сжатия существенно снижается (более подробно относительно результтах сжатия JS-файлов дозволительно прочитать в соответствующей статье).

Более разумными альтернативами данного инструмента будут JSMIN (минимизатор / преобразователь кода), Dojo Shrinksafe (минимизатор / обфускатор кода) иначе говоря YUI Compressor (минимизатор кода). Последние чета созданы на основе Rhino, движка JavaScript через Mozilla, написанного на Java. Однако однако это не подходит в угоду кому ядра Drupal. Существует Реализация JSMIN для PHP, поэтому я считаю, сколько это наилучший выбор к использования в PHP-проектах (YUI Compressor требует установленной java в сервере).

И уже создана заявка в включение его в Drupal 7.

Правило одиннадцатое: избегаем перенаправлений

Требование Drupal 5 Drupal 6
Отсутствие редиректов сообразно умолчанию да да

Drupal может перенаправлять пользователей около доступе к URL лишенный чего алиаса /node/11 для его мнемонической версии /about, а по умолчанию этого никак не происходит.

Модуль Global Redirect позволяет осуществить описанный функционал разумным способом. Более подробно описано для странице этого проекта.

Правило двенадцатое: удаляем дублирующиеся скрипты

Требование Drupal 5 Drupal 6
Метод чтобы добавления JS-файлов для страницу да да

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

Правило тринадцатое: настраиваем ETag

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

Основная задача заключается в том, сколько атрибут этот полностью зависит с самого сервера (в частности, с inodes), с которого отдается известный файл. Это означает, сколько если вы используете сколько-нибудь серверов для выдачи одного да того же файла ( скажем, CDN), то один единовременно вы можете получить файл из сервера 1, а на другой — уже начиная с сервера 2. И причинность ETag не совпадет, браузер загрузит определенный файл снова!

Решение

Если вы используете до некоторой степени серверов, просто отключите ETag. В Интересах Apache нужно просто добавить следующую строку в течение файл httpd.conf:

FileETag none

С Целью IIS решение будет более содержаться в более сложной процедуре.

Альтернативное приговор

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

От себя могу добавить, сколько вообще возможно настроить выдачу ETag на произвольном формате, но чтобы этого нужно использовать приманка обработчики для файлов. Может толкать(ся), уже есть соответствующий модуль в угоду кому nginx или Apache. Также правильная настройка выдачи заголовка Last-Modified способна решить заявленную проблему ( за сути, данный заголовок является более грубый альтернативой для ETag).

Правило четырнадцатое: делаем AJAX кэшируемым

Требование Drupal 5 Drupal 6
Подключение дополнительных форматов отображения несть нет
Возможность настройки gzip-сжатия чтобы разных форматов (как в течение правиле 4) нет не имеется

Над заявленными возможностями уже работали с целью включения их в Drupal 6, же не успели вовремя.

Возможность установки gzip-сжатия на различных файлов (см. четвертое начало) должна контролироваться каким- или дополнением или улучшением, причинность это значительно влияет в производительность при AJAX-запросах.

Другие правила (а по сути менее важные) уже автоматически работают чтобы таких запросов. Девятое да тринадцатое — потому сколько AJAX-ответы отправляются начиная с того же Drupal сервера, сколько и HTML-документы. Одиннадцатое закон — потому что перенаправления, скорее только, отсутствуют для AJAX-ответов на Drupal. А десятое обыкновенный вообще имеет мало смысла за той причине, что JSON-величина дальше минимизировать уже очень, тут поможет только gzip-сжатие..

Решение

Уа было сделано замечание до поводу отображения узлов вебсайта в Drupalcon Boston 2008 code sprint, следовательно, скорее всего, через до некоторой степени месяце оно будет реализовано.

Практическое применение

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

Живые примеры

Перед тем, как будто начать применять вышеописанные советы, вы, скорее только, захотите каким-либо образом убедиться, сколько вся эта оптимизация вместе имеет какой-либо ум. Без проблем. Вы уже ощутили ее. (имеется присутствие, конечно, загрузка страницы начиная с исходной статьей, однако это справедливо также для webo.in, добро бы он построен и отнюдь не на Drupal). Эта страница загружается меньше, чем по секунду. При этом на Drupal отключено кэширование страниц, установлен eAccelerator также включено кэширование для запросов в течение MySQL.

В качестве другого примера дозволено привести DrupalBin. Сайт расположен для виртуальном хостинге (DreamHost) лишенный чего eAccelerator и кэширования для уровне MySQL — сколько объясняет достаточно медленное изделие страниц на сервере.

Дополнительная оптимизация

В порядке эффективности применения:

  • Модуль Boost включает в течение Drupal статическое кэшированеи страниц. Это означает, сколько страницы, созданные динамически, записываются в течение файлы, и затем от помощью магии mod_rewrite отдаются наоборот сервером уже в виде файлов ( буде они существуют), при этом отнюдь не производится ни одного запроса для базе!
  • Статья в 2bits битком набита советами до оптимизации производительности Drupal.
  • Добавление для ядра расширенное кэширование еще от Robert Douglass позволяет кэшировать отдельные блоки, комментарии, структуру форума, встроенные узлы, строки пути, популярные поисковые запросы да таксономические деревья.

Заявления за поводу Drupal

Дополнительная информация

Благодарности отправляются

  • Yahoo! по их работу над YSlow.
  • Greg Knaddison (greggles) по предварительное ознакомление с этой статьей равно несколько весьма ценных предложений, которые существенно дополнили саму статью.
Вложение Размер
Прибавление для размещения JS-файлов на конце страницы для Drupal 5 1,08 Кб
Прибавление для размещения JS-файлов в течение конце страницы для Drupal 6 1,28 Кб
hook_file_server на Drupal 5 11,61 Кб

Читать дальше

This entry was posted on Thursday, February 4th, 2010 at 4:40 pm and is filed under Optimizator, WEB. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.

Comments are closed.