Разгони свой сайт – автоматическая СКЛЕЙКА + GZIP

    Разгонись

    Есть куча советов как убыстрить отдачу сайта – это и статика через nginx и кластеризация и куча еще всяческих хитрых технологий. Однако во всех книжках, советующих как можно повысить загрузку сайтов можно найти две постоянно повторяющиеся темы – «склеивание CSS/JS» и «включение сжатия».

    Склейка
    Все просто – если например у Вас на страничке 3 CSS файла и 5 JS, браузеру при загрузке придется создавать 8 соединений и выкачивать по ним данные, а как известно, лучше несколько больших файлов чем множество мелких. Связано это с тем, что на каждую установку соединения браузер тратит время и зачастую немаленькое – до 40% времени загрузки.

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

    Как говорят «никогда не переписывайте то, что можно просто вырезать и наклеить» ;)

    Сжатие
    Чем меньше объем «прокачиваемых» файлов, тем соответственно меньше время тратится на загрузку. Даже если эти файлы сжаты и мы тратим некторое время на распаковку – при современных вычислительных мощностях на клиенте эта временная затрата практически не существенна.
    Большинство современных браузеров поддерживают метод сжатия deflate, иногда называемый gzip по имени стандартной *nix утилиты, осуществляющей это дело.

    Что можно и нужно сжимать в веб? Любые текстовые запросы, как то: JS / CSS / JSON / HTML.

    Есть замечательный модуль для Апача mod-deflate, которым можно прямо из .htaccess указать чего сжимать и чего не сжимать, очень прост в использовании, но увы и ах! – обычно запрещенный на стандартных хостингах по причине того, что они (хостеры) опасаются за свое процессорное время.
    Доля разумного в этом конечно есть – этот модуль жмет все «на лету» и если не принять некоторых хитростей, каждый раз грузя страничку для нового пользователя он будет
    заново пережимать все CSS / JS и т.д.

    Если же у вас VDS и Вы – сам себе хозяин – используйте mod-deflate, ибо он хорошо отлажен и примеров применения в сети масса.

    А мы вернемся к обычным хостигам – есть ли выход? Даже если Вас съели, у вас всегда есть два выхода — есть выход и здесь. Причем эта задача очень хорошо ложиться на предыдущую – сейчас объясню почему.

    Большинство JS / CSS и других текстов – это статика, т.е. они не меняются в процессе функционирования сайта — есть смысл их объеденить, чтобы удовлетворить пункту о «склейке» + сразу же сжать.

    Полученные файлы мы положим в некий кэш, откуда наш Апач будет их брать и отдавать. Причем процесс мы автоматизируем через mod-rewrite.

    Алгоритм получится примерно такой:
    1. запрашивается некий файл со специального URL
    2. если клиент поддерживает сжатие и сжатый файл такого типа есть в нашем кэше – отдаем и завершаем обработку
    3. если же сжатие не поддерживается и есть просто файл такого типа – отдаем его и заканчиваем обработку
    4. иначе запускаем наш обработчик

    Условимся, что срабатывать наша модель при обращении к URLу вида «/glue/….»,
    А файлы будут лежать в «/static/glue/…».


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

    В принципе можно сделать так, чтобы папка совпадала с URL-ом, тогда чуть упростится конфиг mod-rewrite но будет не так интересно, вобщем упростить всегда можно :)

    Надеюсь, что в корне Вашего сайта уже живет файл .htaccess с содержанием типа такого:

    RewriteEngine On
    RewriteBase /
    RewriteRule ^.*$ index.php [QSA,L]
     


    Ну либо похожий. Основное условие, что если mod-rewrite не нашел чего сделать с пришедшим URL, он в конце концов вызовет какой-то скриптовый файл.
    В данном случае – index.php

    Для добавления нашего алгоритма пропишем в .htaccess следующее:

    Добавляем поддержку сжатых файлов .gz, а также .jz.gz и .css.gz

    AddEncoding gzip .gz

    <FilesMatch "\.js.gz$">
            #для проксей
            Header set Cache-control: private
            Header append Vary User-Agent

            ForceType "text/javascript"
            Header set Content-Encoding: gzip
            AddCharset windows-1251 .js.gz
    </FilesMatch>
    <FilesMatch "\.css.gz$">
            #для проксей
            Header set Cache-control: private
            Header append Vary User-Agent

            ForceType "text/css"
            Header set Content-Encoding: gzip
    </FilesMatch>
     


    Добавляем правило отдачи наших файлов (разыменовывание URL в физическую папку)

    RewriteCond %{ENV:REDIRECT_GZ} =1
    RewriteCond %{REQUEST_URI} ^/glue/(.+)$
    RewriteCond %{DOCUMENT_ROOT}/static/glue/%1 -f
    RewriteRule  . - [L]
     


    Добавляем проверку на поддержку клиентом сжатия

    RewriteCond %{REQUEST_URI} ^/glue/(.+)$
    RewriteCond %{DOCUMENT_ROOT}/static/glue/%1.gz -f
    RewriteCond %{HTTP:Accept-Encoding} ^.*?gzip.*$ [NC]
    RewriteCond %{HTTP_USER_AGENT} !^konqueror [NC]
    RewriteRule  ^siteglue/(.*)$ /static/glue/$1.gz [L,E=GZ:1]
     


    Если сжатие не поддерживается

    RewriteCond %{REQUEST_URI} ^/glue/(.+)$
    RewriteCond %{DOCUMENT_ROOT}/static/glue/%1 -f
    RewriteRule  . static/glue/%1 [L,E=GZ:1]
     


    Теперь возьмемся за нашу самую главную магию – автоматическое формирование этих самых файлов.

    Здесь еще одна есть хитрость, в данном случае скорее — еще одна условность – в файлах html мы будем писать запросы к css или js в следующтим виде:
    «/glue/1.css—2.css—3-4-5.css», где «-» — это замена «/», а «--» – это разделитель файлов.

    Кроме того в именах могут быть только английские буквы, цифры и символ «_», по мне — этого более, чем достаточно.

    Конечно же, это условности и Вы можете выбрать себе другие правила и другие разделители. Например можно использовать «,» или что-либо еще.
    Однако я выбрал «-» из-за того что это вполне нормальный и часто встречающийся символ URL и с ним врядли могут быть всякие дурацкие проблемы типа вырезания его кривыми скриптами на проксях по пути от Вас до клиента.

    В файле в index.php (или что там у вас запускается согласно .htaccess?) добавляем обработчик, который проверяет URL на соответствие нашему «/glue/.*» и в случе совпадения делает echo( Glue::generate( $str ) ), где $str — то, что у нас идет в URL после последнего слэша, т.е. для «/glue/a.js» это будет «a.js»

    Сам класс Glue вот такой


    class Glue {
            static $allowedExt = array(
                    "js"    => array( "check" => "/^js/.*?.js$/", "delimeter" => ";n", "mime" => “text/javascript”),
                    "css"   => array( "check" => "/^css/.*.css$/", "delimeter" => "n", "mime" => “text/css” ),
            );

            static function generate( $str ) {
                    if ( !$str ) return null; //не нашли URL

                    $files = array();
                    preg_replace( "/((?:[a-z0-9_.]+-)+[a-z0-9_.]+.([a-z0-9]+))(?:--|$)/ie", "$files[]=str_replace( '-', '/', "1")", $str );
                    if ( count( $files ) == 0 ) return null; //не нашли ни одного файла в URL

                    $srcF =/static; //наша папка, откуда берется статика
                    $dstF =/glue”; //папка, нашего кэша

                    $content = "";

                    $cext = substr( strrchr( $files[0], '.' ), 1 );
                    if ( $cext === false ) return null; //не смогли определить расширение

                    $fd = null;
                    foreach( self::$allowedExt as $k => $v ) {
                            if ( $k == $cext ) {
                                    $fd = $v;
                                    break;
                            }
                    }
                    if ( !$fd ) return null; //не нашли среди доступных расширений

                    $usedNames = array();
                    $fdC = &$fd["check"];
                    $fdD = &$fd["delimeter"];
                    foreach( $files as $name ) {
                            $ext = substr( strrchr( $name, '.' ), 1 );
                            if (
                                    $ext === false ||
                                    in_array( $name, $usedNames ) ||
                                    $ext != $cext ||
                                    !preg_match( $fdC, $name )
                            )  return null; //не смогли найти расширения, файл ч таким именем уже есть или расширение отличается от первоначального либо имя не удовлетваряет проверке

                            $usedNames[] = $name;
                            $filec = file_get_contents( "{$srcF}/{$name}" );
                            if ( !$filec ) return null; //не смогли найти или прочитать файл
                            $content .= $content != "" ? $fdD . $filec : $filec;
                    }


                    //сохранили файл
                    file_put_contents( "{$dstF}/{$str}", $content );

                    //сохранили сжатый файл
                    $gzip = gzencode( $content, 9 );; //gzdeflate( $content, 9 );
                    if ( $gzip ) file_put_contents( "/{$dstF}/{$str}.gz",$gzip );

                    //мы должны отдать по данному запросу содержимое и mime-тип
                    header( "Content-type: " .  $fd["mime"], true );
                    return $content;
            }
    }
     


    Опять же, здесь лишь иллюстрируется один из способов КАК это сделать — не нравится статический класс — Вы можете выбрать любой другой способ — с блэкджеком и дамами не тяжелого поведения ;)

    Вот в принципе все, осталось пробежаться по файлам проекта – все таки остался кусочек «ручной» работы :( — и прописать вместо кучи скриптов один, но по правилам, описанным чуть Выше.

    Все – при первом запросе автоматически все соберется и начнет отдаваться.

    Еще одно маленькое дополнение – а что делать с контентом, отдаваемым PHP?
    Его тоже надо сжать!

    Для этого в то месте где Вы отдаете файлы текстового вида, там где отдается сформированный контент – например так echo( $content );

    Сделать следующее:

    if ( isClientSupportGzip() ) {
        ob_start("ob_gzhandler");
        echo( $content );
        ob_end_flush();
    } else echo( $content  );
     


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

    function isClientSupportGzip() {
        if ( headers_sent() || connection_aborted() ) return false;
        if ( stripos( getenv( "HTTP_ACCEPT_ENCODING" ), "gzip" ) === false ) return false;
        if ( stripos( getenv( "HTTP_USER_AGENT" ), "konqueror" ) !== false ) return false;
        return true;
    }
     


    Для девелоппинга рекомендую завести некую константу режима разработки и в случае установки ее в 1 просто не записывать файлы в кэш и не сжимать динамику – не придется при каждом изменении в каком-либо js файле лазить и очищать нашу директорию с кэшем.

    Вот и все – мы чуть-чуть разогнали свой сайт ) По моим наблюдениям прирост в скорости отдачи может составлять 30-40%.


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

    Быстрых Вам сайтов, максимального сжатия и радостных клиентов ;)      I'm

    P.S.

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

    При склейке JS помните особенность – склеивать надо через «;», т.к. в предыдущем файле после последней строчки может не оказаться «;»

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

    Если у Вас в сайт в самой непопулярной кодировке, чтобы все было шоколадно, замените
    ForceType «text/javascript» на ForceType «text/javascript; content=windows-1251»
    и добавьте: AddCharset windows-1251 .js и AddCharset windows-1251 .css

    И еще маленький совет, придерживайтесь одинаковой очередности в указании склеиваемых файлов, ибо технически «/glue/a.js—b.js» и «/glue/b.js—a.js» это одно и тоже, а на практике вы получите два файла в кэше…

    Из комментариев

    Imenem и TrueDrago подсказали, что оптимальный уровень для deflate компрессии не 9, а 6
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 85

      +26
      я всегда считал, что «чтобы все было шоколадно» всё должно быть в UTF-8
        +2
        Не всегда мы диктуем обстоятельства :)
      • НЛО прилетело и опубликовало эту надпись здесь
          –1
          Вот такой метод мне как раз не нравится… хотя бы тем, что в описанном здесь случае чтобы сделать из ветки дев ветку продакшен достаточно просто поменять одну константу :)
            0
            У меня так-же, имеется свой похожий велосипед. Но ничего менять не приходиться. :)

            Просто пишу нормальный читабельный CSS код. Скрипт обрабатывает и выдает юзеру «сжатый» и нечитабельный код в одно строку.
              +4
              Зря, я не увидел в вашем методе удаления из javascript и css комментариев, прочих символов типа перевода строки и пробелов, замены имен переменных и функций в javascript на более короткие и т.д, а ведь они тоже дают солидную экономию в весе. А еще у вас используется нерациональная степень сжатия в gzip — 9, а ведь широко известно, что больше 5 ставить нет смысла. Можете посмотреть в комментариях к функциям: gzencode, gzcompress (тут кроме степени сжатия еще и время).

              Я подключаю к файлу index.html один файл frontend.js и один style.css, внутри эти файлы, в зависимости от типа сборки, содержат или подключение остальных файлов или полностью сжатый с помощью google closure compiler и yui compressor код. А уже сервер занимается сжатием в gzip. Сжатие — это единственное, что стоит производить на уровне php, если нет доступа к сжатию с помощью самого сервера.

              По поводу изменения версии с dev на product — с помощью билд-скрипта это делается намного удобнее, особенно если назначить целям для сборки каждой версии горячие клавиши.
                0
                Ро роводу GZIP не знал — прочел в мане что максимум 9 ) Спасибо за поправку.

                А по поводу подключения к index.html — окей, а к другим страницам сайта? Или у Вас все скрипты всегда подключаются ко всем страницам?
                  +1
                  Сейчас у меня в приложениях в принципе всего одна точка входа, index.html, ибо занимаюсь в основном RIA. Но такой подход актуален и для CMS, в которых используется шаблонизация, подключение скриптов выносится в шаблон header, и не меняется для всех страниц. Конечно, рецепт не универсальный, но с точки зрения производительности проще собрать все скрипты и css в два файла, не резделяя их на группы для разных страниц, так будет меньше запросов к серверу и у пользователя в кэше сразу будет весь необходимый код. Разделять скрипты на группы я бы стал после разницы в объеме между группами в 100 Кб, например. Отдельный случай — админка CMS, ее нужно рассматривать как вторую точку входа с аналогичным подходом.
                    0
                    ага, понял. Спасибо за подробности. Еще +1 вариант работы со статикой.
                      0
                      Я пришел примерно к такому же подходу.
                        0
                        Полностью поддерживаю. От себя бы добавил насчет скрипта билда. Если используется nginx, то для статики можно и нужно использовать gzip_static модуль. Если в директории ищется style.css файл и при этом есть style.css.gz, то отдан будет последний как сжатый контент, но реально сжатия происходить не будет, nginx его отдаст как есть. Соответственно в dev окружении билд скрипт подобные файлы не генерирует, поэтому проблем с кэшированием контента не имеем.
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    Очень понравилось параллелить загрузку js через headjs.com. Ощутимо ускоряет загрузку, если много скриптов, как это бывает при использовании плагинов jQuery
                      0
                      Достаточно у себя же (в основном домене) сделать домен третьего уровня и оттуда грузить статику.
                        –1
                        У подавляющего большинства этот домен уже есть — «www», т.е. с habrahabr.ru отдавать сайт, с «www.habrahabr.ru» — статику.
                          0
                          С одной стороны — да, с другой 'www' часто делают не отдельным вирт.хостом, а через ServerAlias. То есть фактически этот тот же хост получается.
                          Может быть браузеру это все равно, могу ошибаться.

                          Не понял за что минусуют ваш комментарий, он же по делу…
                            +1
                            Браузеру всё равно как прописан хост.

                            Комментарий минусуют чайники.
                              +1
                              Ок.

                              Откуда у чайников карма и почему они такие злые?! (вопрос риторический)
                      –3
                      спасибо за картинку, поставил на телефон ^___^
                        +1
                        В Django-проектах пользуюсь django-compressor который в нужном порядке склеит и пережмет скрипты и стили с помощью yui, closure, jsmin или что-то еще.Так-же умеет работать с less. Еще он умеет потом сразу gzip'ом все это сжимать. Причем захватывает не только линкованные скрипты и стили но и те стили и скрипты которые расположены на странице.
                        В других проектах склеиваю nginx-concat модулем.
                        В некоторых проектах с невысокой нагрузкой раздаю статику напрямую с github репозитория к которому прикреплен домен.
                        Возможно кому-то мои методы окажутся полезными.
                          0
                          забыл еще упомянуть про рамдиск который почти везде применяется.
                            0
                            Ссылочку на всякий случай вдруг кто-то не в курсе github.com/perusio/nginx-http-concat
                              0
                              Кстати насчет Github Pages, там сервера nginx, статика при публикации сжимается gzip'ом можно использовать как полноценную CDN(ведь раздается все по сути с rackspace). такие проекты как cachedcommons.org/ используют Github Pages для раздачи =)
                              +1
                              В функции isClientSupportGzip нет смысла, читаем
                              php.net/manual/ru/function.ob-gzhandler.php
                                –1
                                ob_gzhandler к сожелению ориентируется только на основании заголовка Accept-Encoding, об этом тоже в хелпе есть. Увы и ах — этого не всегда достаточно, например для конкуер (а также IE5/IE6).
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    +1
                                    акутально или неактуально — решать владельцу сайта, наша задча — реализовать все как можно более коррктней, чтобы собрать как можно большую аудиторию
                                +20
                                — Apache? Нет, давно уже не слышал…
                                  +1
                                  Аналогично))
                                    0
                                    Аналогично.
                                    Скриптами склеил js/css и минимизировал через yuicompressor, загрузил на продакшен, а там «gzip on» в конфиге.
                                      –4
                                      Что посоветуете кроме php-fpm?
                                        +14
                                        А зачем вам что-то, кроме php-fpm?
                                          –3
                                          lighttpd
                                        +5
                                        Не, ну прикольно, конечно. Но всё таки я рад, что пишу на рельсах, что у меня есть Asset Pipeline, и что ничего этого мне делать не надо. :-)
                                          +3
                                          Статику всё же лучше отдавать nginx•ом, а не апачем. Я за склейку и сжатие, включая yuicompressor, перед выкладываем проекта.
                                            0
                                            Разве yuicompressor еще актуален после появления closure compiler и uglifyjs?
                                              +1
                                              yuicompressor ведь ещё и CSS умеет сжимать, кроме js?
                                            +3
                                            Отвечу одним БОООЛЬШИМ комментом ;)

                                            Про nginx — господа, если на фронтэнде у Вас торчит nginx — это круто, действительно круто, но во-первых вся эта методика подходит и для него, во вторых обычно бэкэнд у него — Апач.
                                            По этому не очень уместно спорить здесь в ключе «Камаз конечно хорошо, но вот бэха! Бэха гораааздо круче» :)
                                            Обычно nginx есть у VDS а не у простых хостингов, а VDS — совсем другая песня — я про это упоминалу уже )

                                            Про YUI & Google Closure — естественно JS как и CSS надо оптимизировать через них (я например использую YUI)
                                            Но здесь я рассказывал немного не об этом, не так ли? Можно было конечно и упомянуть минимизацию, но я считаю чтобы не было сумятицы — котлеты отдельно, мухи отельно.
                                            Минимайзеры — это вообще тема для отедльной статьи.

                                            Так, и вот самое интересное — для меня очень интересное, как господа у которых сборка проекта осуществляется через запуск спец скриптов (например через шелл).
                                            Как применить тотже YUI или другие утилиты — это вполне понятно, непонятно одно — как Вы определяете КАКИЕ файлы для КАКОЙ странички склеивать?
                                            Т.е. во-первых как у Вас подключаются склеиваемые скрипты на страничках, во вторых, как вы узнаете для каокй страницы какие скрипты склеивать?
                                            У меня сделать это както хорошо, чтобы не мозолило глаза — увы — не получилось. Поделитесь опытом? Буду очень признателен.
                                              +4
                                              Если для каждой страницы делать свою склейку, то весь бонус от склейки может сойти на нет. Браузер же кеширует статику. А если она будет меняться от страницы к странице, то при переходах всегда заново грузиться будет. Поэтому надо склеивать по частоте встречаемости. То есть, пусть немного лишнее включается, но зато одно и то же на разных страницах. Чтобы браузер в кеш клал
                                                0
                                                он в любом случае скэширует — с моей точки зрения не гоже таскать кучу ненужных библиотек если они не используются на странице. Ну ИМХО конечно.
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    0
                                                    В теории да, на практике нет. Если css файл загрузился при заходе на главную (на самом деле на любую) и содержит все правила необходимы для всего сайта, то при переходе на любую внутреннюю страницу он тут же подхватывается из кэша. Т.е. при таком подходе css гарантированно грузится один раз при первом входе на любую из страниц. А при своем css для каждой страницы все тут же ухудшается, ведь зачастую пользователь идет по дереву сайта и может на пройденные страницы и не вернуться.
                                                  +1
                                                  Ну так nginx статику отдает сам, а к апачу переадресует запросы только на динамику — вроде такая сейчас распространенная практика. Так что думаю все же для VDS, где есть возможность его поставить, сжатие статики лучше настроить на nginx, иначе эффекта не будет никакого, это надо учитывать.
                                                    0
                                                    Согласен. Там действительно проще это сделать.
                                                    Однако насчет «не будет эффекта» — не соглашусь — если Апач у Вас ОДИН раз подготовит статику в определнном месте, а потом из этого места ее отдает nginx — ничего в плане быстродействия Вы не потеряете.
                                                      0
                                                      А конфиг с таким подходом не усложнится?
                                                      Получается апачу надо будет сначала тыкаться туда где лежат зазипованные архивы, затем либо отдавать, если уже оно там есть, либо стучаться к апачу чтобы тот налету заархивировал.

                                                      У меня сейчас классически настроено — nginx сам отдает всю статику, которая лежит в определенных папках (js, css, img), для всех других запросов он стучится в апач. Конфиг в таком случае весьма прозрачен — каждый делает своё дело.

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

                                                        0
                                                        Усложнится совсем на чуть чуть но это даст возможность работаь с сайтом и без nginx — более высока я переносимость, хотя если в этом нет необходимости — то и смысла делать нет.
                                                        Я полностью согласен с Вашим методом.
                                                          +1
                                                          Да, для определенных условий ваш подход несомненно лучше в силу большей универсальности.
                                                  +1
                                                  Перед выводом контента в PHP неплохо бы формировать заголовок Content-Length, что легко сделать с помощью функции ob_get_length().
                                                    0
                                                    Есть же minify. Зачем изобретать велосипед?
                                                      0
                                                      minify каждый раз отдет статику через себя, т.е. его надо к кэшу пркручивать, но как Вариант — вполне.

                                                      Мне не очень понравился потому как у меня в движке еще масса всего делается при формировании кэша статики да и процесс хотелось бы контролировать. Кроме того по поводу минификации YUI или же Closure Compiller жмет гораздо лучше.
                                                        0
                                                        Достаточно сделать небольшой обвес вокруг minify, и в итоге организовать запросы напрямую к кэшу minify и контролировать процесс.
                                                      +2
                                                      Кстати всем настоятельно советую прочесть книгу "Разгони свой сайт — Методы клиентской оптимизации веб-страниц", которую написал Николай Мациевский. Человек реально разбирается в данной тематике, и в книге все советы подкрепляет тестированием.

                                                      Например вот графики с замерами эффективности для gzip из его статьи (в книге тоже есть):


                                                      Рисунок 1. Издержки на gzip от степени сжатия


                                                      Рисунок 2. Эффективность различных степеней gzip-сжатия
                                                        0
                                                        Николай не рассматривает отдачу предварительно сжатой статики.
                                                          0
                                                          Это справедливо лишь для контента сжимаемого на лету. В случае предварительно сжатого контента (в nginx модуль gzip_static) это уже не актуально.
                                                          0
                                                          Если хотите «разгонать сайт» — первым делом откажитесь от Apache :) А уже потом всё остальное.
                                                            +3
                                                            Нужно просто с умом к его использованию подходить)
                                                              0
                                                              Ну что за глупости? Что значит «с умом подходить»? Куда вы с ним собрались подходить? В равных условиях (железо и нагрузка) апач всегда работает медленнее nginx и lighttpd. Это факт, бенчмарков в интернетах пруд пруди, и от этого никуда не деться.
                                                                +1
                                                                Вообще есть правило хорошее «Ко всему подхродить с умом» :-D
                                                                А по поводу lighthttpd & nginx можно ведь почитать ПОЧЕМУ они так быстро работают :)
                                                                Я даже отвечу на вопрос — они ЗАТОЧЕНЫ под конкретное действо, а Апач — универсален.

                                                                Поэтому пытаться их сравнивать — не совсем корректно а говрить что nginx круче чем Апач тем более.

                                                                Самолет круче машины? ;)
                                                                  0
                                                                  Где Вы нашли слово «круче»? Я говорил, что апач работает медленнее, что по-моему вполне себе уместно в топике под названием «Разгони свой сайт».
                                                                    0
                                                                    машина тоже медленее самолета, не находите? :)

                                                                    я понял что Вы имели ввиду :) Просто не люблю когда рубят с плеча.

                                                                    И если для проекта можно обойтись lighthttpd & nginx + у вас есть хостинг позвоялющий это — то да — есть на это резон, но вот говорить так агульно «надо отказаться от апач», это, извините, смешно.
                                                                      –2
                                                                      что это за хостинг такой, что не позволяет? VPS от восьми евро в месяц. А владельцам шаредов вряд ли что-то надо разгонять.
                                                                        0
                                                                        Т.е. при шаред хостинге эти методы не дадут возпростания скорости загрузки? :-D
                                                                        Я ниже отписался HnH по этому поводу.
                                                                          0
                                                                          Да, а может ссылку дадите? А то я видел эти VPS. 300 MHz, 64 мб оперативки, (и то не гарантированно) и все настраивать руками. Я держу один проект на шаред хостинге, плачу 3 евро в месяц, и не имею геморроя (этот же хостинг нормально держал наплывы тысяч людей с хабра на личный сайт). Запарили такие диванные специалисты, у которых бюджет на нормальный VPS и люди, но которые считают своим долгом бросаться такими заявлениями и обсирать шаред хостинг.
                                                                            0
                                                                            Диванные в данном случае — по использованию шаред хостинга.
                                                                              0
                                                                              www.hetzner.de/en/hosting/produkte_vserver/vq7

                                                                              RAM 512 MB
                                                                              Hard discs 20 GB HDD
                                                                              NIC 100 MBit
                                                                              Traffic 1 TB*

                                                                              Мало?
                                                                                0
                                                                                О модели процессора вообще ни слова. Под какой виртуальной машиной крутится — тоже не вижу (ресурсы гарантированы или на бумаге?). Мутновато.
                                                                                  0
                                                                                  Откуда столько агрессии то? Я рад за вас и ваш хостинг, но тем не менее дешевый европейский впс по ценам российских шаредов существует.

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

                                                                                  Даже ели брать хостинг на не самом дешевом linode по 20 баксов (600руб) (4 ядра, 512 оперативы, 20Гб, XEN, все гарантированно) это оказывается выгоднее мастерхоста (200руб за 3 гб места и неизвестно сколько оперативы и ядер)
                                                                                    0
                                                                                    Извините, но агрессия в данном случае у вас. В России давно уже не хостился, всякими вебманями платить мне неудобно.
                                                                                    Сомневаться я могу в мощности процессора, которая не указана. Я сейчас у небольшого хостера с мощными машинами, и я не уверен что переезд на VPS мне будет выгоден. Супернагрузки на сервер не ожидается, но большое кол-во посещений — вполне, если выгорит.
                                                                                    И я не претендую на звание специалиста, просто не считаю VPS серебряной пулей.
                                                                            0
                                                                            Хостинг «может не позволять» установить nginx в одном единственном случае — когда вы используете виртуальный хостинг. Вы держите highload сайты на виртуальном хостинге? Любые аналогии хромают, но Ваша с самолётом и машиной, как мне кажется, хромает вдвойне: и apache и nginx фриварные софтины, nginx не требует никаких дополнительных вложений в компьютер, который тянет apache, или танцев с бубном вокруг ОС: это чисто вопрос выбора софта. Про разницу в цене и содержании самолёта и машины, я так понимаю, говорить не стоит. И я не рублю с плеча, с чего вы взяли? Оптимизация, подобная той которую Вы описывали в статье, нужна только при довольно высоких нагрузках. Использовать Apache при таких нагрузках — очевидно не самый лучший выбор, это всё что я хотел сказать, и ничего более.
                                                                              –1
                                                                              Оптимизация, та, которую я сказал нужна вне зависимости от сервера — ибо она при любом фронтенеде ускоряет загрузку. И вопрос не в сервере, вопрос именно в методах. Тут не причем ни Апач ни лайт.

                                                                              Или вы считаете что если сайт не хайлоад, то пусть и волочит якорь и оптимизировать его не надо? Однако пользоввателю есть разница — загрузится страница за 3 секунды или за одну, даже если таких пользователей на Вашем сайте всего 50 ;)
                                                                        0
                                                                        тем не менее, апаче согласно minecraft за январь месяц — это 59% всего веба.
                                                                        Так что, подозреваю не все так просто правда?
                                                                          +1
                                                                          Послушайте, Internet Explorer тоже занимает около 50% рынка браузеров, и что это говорит о скорости работы? Как правильно заметил ionicman apache универсален. Его удобно ставить на виртуальные хостинги с небольшой нагрузкой, ему можно скармливать .htaccess, легко подключать разные модули. Поэтому он и заслужил свою популярность. Ещё раз: я не говорю, что он плохой или хороший, я говорю что он работает медленнее, чем его конкуренты. Ситуация когда появляются более-менее высокие нагрузки на сервер и начинаешь задумываться как ускорить загрузку сайта, в т.ч. и склейкой js и css, но при это остаёшься на apache мне кажется нелепой.
                                                                            –1
                                                                            То есть вы людей, которые способны настроить апач, приравниваете к людям которые неспособны изменить браузер по умолчанию?

                                                                            > Ситуация когда появляются более-менее высокие нагрузки на сервер и начинаешь задумываться как ускорить загрузку сайта, в т.ч. и склейкой js и css, но при это остаёшься на apache мне кажется нелепой.

                                                                            Склейка js css приносит ровно такой же выигрыш в производительности как для Апача на северной стороне так и для нгинкса. Потому что минимизирует издержки клиента, на установку соединения.

                                                                            А теперь к теме
                                                                            Тем не менее почему то очень крупные хостинги использую только апач.
                                                                            Обращаю Ваше внимание что я тоже Вам не говорил что Апач быстрее.

                                                                            Я пытался обратить Ваше внимание что все НЕ ТАК ПРОСТО в выборе.

                                                                            И стандартная базовая схема сейчас это апач бэкэндом и нгинкс / лайт фронтэндом.

                                                                    +1
                                                                    Я бы также посоветовал разделять js файлы: на файлы в footer и head. Это конечно увеличит запросов, но пользователю визуально будет казаться, что страница отобразилась быстрее, это связано с тем, что то тех пор пока браузер не подтянет все файлы из head, он не отображает страницу.
                                                                      0
                                                                      Зачем добавлять js-файлы в head?
                                                                        0
                                                                        Думаю автор каммента имел ввиду синхронную и асинхронную загрузку js файлов, точнее их комбинацию.
                                                                          0
                                                                          Да именно это я имел ввиду.
                                                                      0
                                                                      Все же думаю, что пользователю приятно видеть процесс загрузки визуально, а не ждать загрузки одного большого файла. Хотя пост очень полезный, спасибо автору!
                                                                        0
                                                                        При описанном методе склейки можно нарваться на грабли вот какого рода:
                                                                        если в файлах CSS используются относительные пути, например

                                                                        background: url("../img/loader-mini.gif") no-repeat scroll center center transparent;

                                                                        то в случае, когда у вас пути реального скрипта отличаются от пути скрипта который отдает «склееный» файл вы получите CSS который ссылается на неверный путь. И граф.файлы не будут найдены и отображены.
                                                                          0
                                                                          Еще для ускорение попробуйте в css-е использовать инлайновые картинки.
                                                                          url(data:MIME;base64,CONTENT)
                                                                            0
                                                                            Насчет class Glue и иже с ним — Assetic отправляет все такие велосипеды (включая и мой самопальный :)) на свалку истории. Рекомендую.
                                                                              0
                                                                              Я хочу КРАМСАТЬ!
                                                                                0
                                                                                Imenem и TrueDrago подсказали, что оптимальный уровень для deflate компрессии не 9, а 6
                                                                                Смотрю я график и ясно вижу: разница между 1 и 6 в степени сжатия всего ~4%, а разница в производительность почти в два раза. Оптимальный с точки зрения чего? Трафик экономить? Значение по-умолчанию для этой директивы 1 выбрано не случайно.

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

                                                                                Самое читаемое