Ускоряем wordpress

    Привет.
    Думаю, среди читателей хабра найдется немало тех, кто имеет stand-alone blog на движке wordpress.

    Так вот, для вас, дорогие мои, у меня есть две новости, как водится, плохая и хорошая.
    Плохая состоит в том, что wordpress — довольно-таки тормознутая штука.
    Виноваты в этом в основном криворукие производители тем и, особенно, криворукие производители плагинов. Особенно кривой плагин, на мой вкус, wp-ajax-edit-comments, который является образцом быдлокодинга.

    Хорошая — в том, что это можно поправить.


    Теория



    Сначала немного теории. Уже довольно давно умные люди из компании Yahoo провели исследования на тему «как же нам ускорить наши сайты». И выяснили, что на скорость сайта с точки зрения пользователя в основном влияет оптимизация front-end'a, а не server-side. Подробнее об этом можно почитать на сайте webo.in на русском и на сайте yahoo на английском, я же просто опишу несколько простых шагов, которые позволят существенно ускорить скорость работы своего блога.

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

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

    Практика



    Оптимизируем тему



    Да, открытость платформы Wordpress — это очевидное благо. Я серьезно.
    Множество прекрасных дизайнеров, верстальщиков, программистов с горящими от энтузиазма глазами вдохновенно, вдумчиво создают темы и плагины для всех, для всего человечества, не требуя ничего взамен. Это действительно прекрасно.

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

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

    Таким образом, нам надо исправить недостатки, которые (возможно) присущи вашей любимой теме от рождения и поправить ее код.

    Итак, для того, чтобы тема стала работать быстрее, надо сделать следующее:
    1. Если тема сверстана на таблицах, переверстать ее на дивы. Я не буду касаться давнего спора «как вестать — дивами и таблицами», замечу только, что точки зрения поставленной перед нами цели (быстро работающий с точки зрения пользователя блог) таблицы проигрывают дивам — потому что таблица отрисовывается браузером только после того, как будет полностью загружена, тогда как дивы отрисовываются сразу, как только браузер получит их с сервера. А значит, если страница сверстана в дивах, пользователь быстрее увидит контент сайта, что нам и нужно, не так ли?Кроме того, как указывает в комментариях len:
      верстка div-ами вместе с разбиением странички на файлы типа left-sidebar, right-sidebar, header, footer etc. позволит быстрее и проще поменять какой-нибудь небольшой кусочек кода прямо из панели управления движком (Дизайн -> Редактор тем), чем попытки из этой же панели управления поменять кусочек своей табличной верстки, в которой можно потеряться за забором из tr и td.
    2. Вы будет смеяться, но нужно убрать все стилевые правила во внешние файлы. И JavaScript — тоже. Это настолько очевидно, что я даже не буду пояснять, зачем это нужно.
    3. Внешний стилевой файл прописываем в блоке head, а JavaScript файл подключаем как можно ближе к закрывающему тэгу «body». И все скрипты аналитиков тоже располагаем пониже.
    4. Сжимаем js и css. Для этого мы будем использовать yui-comressor. Делается это примерно так: качаем последний стабильный релиз YUICompressor'a с официального сайта, устанавливаем, если еще не установлено JRE и выполняем на css/js файл команду следующего вида:

      java -jar /path/to/yuicompressor-*.*.*.jar -o "output_filename" src_file

      * This source code was highlighted with Source Code Highlighter.




    можно использовать флаг -type, который указывает, какой тип файла (css или js). Если флаг не указан, то тип файла определяется по расширению.

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

    Уменьшаем количество файлов



    Так как мы можем серьезно ускорить скорость загрузки файлов, уменьшив число этих файлов (удивительно, правда? :), то разумнее всего будет слить все css-файлы и js-файлы в один. Если эти файлы размером больше ~70 килобайт, то лучше разбить их на два куска.

    Если нужно уменьшить количество картинок, используя технику css спрайтов и технику image map.

    Тут надо отдельно заметить, что у многих (практически у всех) плагинов есть совершенно идиотская особенность — прописывать свои js и css файлы. Идиотизм заключается в том, что очень часто разные плагины используют одну и ту же библиотеку, и подключают ее по нескольку раз. И пользователь, просматривающий ваш блог, вынужден по два-три раза грузить, к примеру, prototype или jquery. Лишние ~30-160+ KB. Неслабо, прадва?

    Тех. заметка: при этом совершенно непонятно, что мешало создателям wordpress сделать контроль надо всеми ресурсами, что прописывают плагины, как сделано, к примеру, в RichFaces. К примеру, если один плагин, которому нужен jQuery, прописывает тэг script с jQuery и рапортует — «Вот мол, подгрузил, все, кому надо, могут использовать», а другой, которому тоже нужен jQuery уже знает об этом и не подгружает свой вариант.

    Лечится это так — все скрипты, что подгружают плагины слейте с теми, что написали сами и воткните в футер, а плагинам запретите их подгружать. Тоже самое сделайте с css, только воткните в header.

    Оптимизируем графику



    Картинки в png и jpg форматах довольно часто неоптимизированы и хранят много лишней информации. Было бы неплохо избавиться от этой лишней информации и таким образом сжать файлы. Делается это с помощью специальных утилит. Это позволит нам уменьшить их размер в отдельных случаях на 50 процентов. Неслабо, правда?

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

    Информацию об этих утилитах и команду я позаимствовал у Дмитрия Ищенко. Надеюсь, он не в обиде :)

    Итак, для оптимизации всего png картинок мы будем использовать pngcrush. Я затрудняюсь ответить, как ее инсталлировать на windows или linux, но я на своем mac'e без проблем установил эту утилиту из портов.

    Чтобы сжать png-файлы без потери качества, используйте следующую команду:
    pngcrush -rem alla -reduce -brute image.png result.png

    * This source code was highlighted with Source Code Highlighter.


    Для сжатия jp(e)g-файлов используйте jpegtran, которая входит в пакет libjpg, который я также установил из портов. Команда для сжатия jp(e)g-файлов без потери качества:

    jpegtran -copy none -optimize -perfect src.jpg dest.jpg

    * This source code was highlighted with Source Code Highlighter.


    Я тут набросал shell-скрипт, который рекурсивно пройдет по директории и оптимизирует все png/jp(e)g картинки в ней:

    for file in `find . -iname "*.jpg" -or -iname "*.png" -or -iname "*.jpeg"`;do
      ext=${file##*.}
      if [ -n "$ext" ]; then
        if [ "$ext" = "jpg" ]; then
          echo "optimizing ${file} as jpeg file with jpegtran"
          jpegtran -copy none -optimize -perfect -outfile temp_abracadabra_filename.jpg $file
          mv -f temp_abracadabra_filename.jpg $file;
        fi
        if [ "$ext" = "jpeg" ]; then
          echo "optimizing ${file} as jpeg file with jpegtran"
          jpegtran -copy none -optimize -perfect -outfile temp_abracadabra_filename.jpeg $file
          mv -f temp_abracadabra_filename.jpeg $file;
        fi
        if [ "$ext" = "png" ]; then
          echo "optimizing ${file} as png file with pngcrush"
          pngcrush -rem alla -reduce -brute "$file" temp_abracadabra_filename.png;
          mv -f temp_abracadabra_filename.png $file;
        fi
      fi
    done;


    * This source code was highlighted with Source Code Highlighter.


    Просто выполните его в директории uploads что в папке wp-content и все будет хорошо. Можно даже повесить его на cron-job и больше не париться на этот счет — все вновь прибывшие файлы будут оптимизироваться.

    Разумеется, надо оптимизировать графику, используемую в теме, так что вот еще один shell-скрипт, который рекурсивно пройдет по директории, сожмет css, js файлы и оптимизирует jp(e)g/png файлы. На всякий случай перед его использованием не забудьте забэкапиться:

    for file in `find . -iname "*.jpg" -or -iname "*.jpeg" -or -iname "*.png" -or -iname "*.js" -or -iname "*.css" `;do
      ext=${file##*.}
      if [ -n "$ext" ]; then
        if [ "$ext" = "css" ]; then
          echo "compressing ${file} as css file with yui compressor"
          java -jar /opt/yuicompressor/yuicompressor-2.3.5.jar --type css -o "temp_abracadabra_filename.css" $file
          mv -f temp_abracadabra_filename.css $file;
        fi
        if [ "$ext" = "js" ]; then
          echo "compressing ${file} as js file with yui compressor"
          java -jar /opt/yuicompressor/yuicompressor-2.3.5.jar --type js -o "temp_abracadabra_filename.js" $file
          mv -f temp_abracadabra_filename.js $file;
        fi
        if [ "$ext" = "jpg" ]; then
          echo "optimizing ${file} as jpeg file with jpegtran"
          jpegtran -copy none -optimize -perfect -outfile temp_abracadabra_filename.jpg $file
          mv -f temp_abracadabra_filename.jpg $file;
        fi
        if [ "$ext" = "jpeg" ]; then
          echo "optimizing ${file} as jpeg file with jpegtran"
          jpegtran -copy none -optimize -perfect -outfile temp_abracadabra_filename.jpeg $file
          mv -f temp_abracadabra_filename.jpeg $file;
        fi
        if [ "$ext" = "png" ]; then
          echo "optimizing ${file} as png file with pngcrush"
          pngcrush -rem alla -reduce -brute "$file" temp_abracadabra_filename.png;
          mv -f temp_abracadabra_filename.png $file;
        fi
      fi
    done;


    * This source code was highlighted with Source Code Highlighter.


    Используйте меньше dns-lookups. Не выкладывайте картинки, src которых указывает на другой ресурс, лучше загрузите их к себе и пропишите ссылку на автора. Работать будет быстрее.

    Сжатие



    Все современные браузеры поддерживают сжатие, так что можно существенно уменьшить размер отдаваемых файлов (а значит, и время их загрузки) при помощи mod_deflate (для Apache 2.2 для Apache 1.3 надо использовать mod_gzip). Так что включите mod_deflate. Если же вы используете Apache 1.3, ниже приведенный код вам не не нужен, вам поможет статья «mod_gzip — сжатие html страниц 'на лету'» на сайте webo.in.

    Найдите файл .htaccess в корневой директории установки wordpress и добавьте в конец следующее:

    <IfModule mod_deflate.c>
      AddOutputFilterByType DEFLATE text/html text/plain text/xml
      SetOutputFilter DEFLATE
      BrowserMatch ^Mozilla/4 gzip-only-text/html
      BrowserMatch ^Mozilla/4\.0[678] no-gzip
      BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
      SetEnvIfNoCase Request_URI \.(?:gif|png)$ no-gzip dont-vary
      Header append Vary User-Agent env=!dont-vary
    </IfModule>


    * This source code was highlighted with Source Code Highlighter.


    Таким способом можно добиться уменьшения js/css/html файлов на 70-80%, и примерно 10% уменьшения jpeg-файлов, что значительно ускоряет загрузку сайта. Следует, правда, помнить, что использования mod_deflate увеличивает нагрузку на сервер, так как ему нужно сжать файлы перед тем, как отдать их, так что стоит проконтролировать, что использование mod_deflate не создает чрезмерной нагрузки на сервер.

    Кеширование



    Ну и последнее — для того, чтобы ускорить серфинг по вашему сайта нужно врубить кеширование. Это не ускорит загрузку сайта у пользователя, который первый раз пришел на ваш сайт, но положит все внешние js, css файлы, картинки к нему в кеш, и в следующий раз, когда он будет бродить по вашему сайту, ресурсы будут грузиться не с сервера, а из кеша, что значительно ускорит скорость работы вашего сайта с _точки зрения пользователя_, а также значительно снизит нагрузку на ваш сервер. Помните, что закешированные у пользователя файлы берутся из кеша браузера, поэтому, если вы внесете изменения в файл, скажем, стилей, пользователь, закешировавший style.css, не увидит их. Так что лучше включать кеширование после того, как вы доработали тему.

    Опять же, добавьте следующие строчки в конец файла .htaccess и не забудьте включить mod_headers и mod_expires (или хотя бы один из них):

    # используем mod_expires
    <IfModule mod_expires.c>
      ExpiresActive On
      ExpiresDefault A86400    
      ExpiresByType image/x-icon A2592000
      ExpiresByType application/x-javascript A2592000
      ExpiresByType text/css A2592000
      ExpiresByType image/gif A604800
      ExpiresByType image/png A604800
      ExpiresByType image/jpeg A604800
      ExpiresByType text/plain A604800
      ExpiresByType application/x-shockwave-flash A604800
      ExpiresByType video/x-flv A604800
      ExpiresByType application/pdf A604800
      ExpiresByType text/html A900
    </IfModule>

    # используем mod_header
    <IfModule mod_header.c>
      # 3 Month
      <FilesMatch "\.(flv|gif|jpg|jpeg|png|ico|swf)$">
        Header set Cache-Control "max-age=7257600"
      </FilesMatch>
      # 1 Week
      <FilesMatch "\.(js|css|pdf|txt)$">
        Header set Cache-Control "max-age=604800"
      </FilesMatch>
      # 10 Minutes
      <FilesMatch "\.(html|htm)$">
        Header set Cache-Control "max-age=600"
      </FilesMatch>
      # NONE
      <FilesMatch "\.(pl|php|cgi|spl)$">
        Header unset Cache-Control
        Header unset Expires
        Header unset Last-Modified
        FileETag None
        Header unset Pragma
      </FilesMatch>
    </IfModule>


    * This source code was highlighted with Source Code Highlighter.


    Кеширование на стороне сервера



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

    Есть несколько плагинов к wordpress'у, которые позволяют кешировать файлы на стороне сервера. Работают они по такому принципу: как только какая-то из ваших страниц запрашвается на сервере, она динамически строится и создается html-файл со всеми данными, который ложится в кеш. Как только приходит запрос на эту страницы, пользователю отдается html файл вместо того, чтобы динамически строить страничку, что значительно снижает нагрузку на сервер (теперь ведь не прогоняются php-скрипты и не нагружается база данных).
    К сожалению, все эти плагины работают как-то очень странно, во всяком случае, у меня не работали должным образом ни wp-cache, ни работающий на его основе wp-super-cache.
    Зато работает 1 Blog Cacher, правда, у него достаточно сложная настройка. Надеюсь, вы разберетесь. Я использую его.

    Итого



    После того, как я провел над своим блогом ряд этих нехитрых действий, блог стал загружаться на 80% быстрее.
    Теперь perfomance meter моего сайта с точки зрения плагина к firebug'у YSlow равен B(85), был F(33). Думаю, неплохой результат.
    Кросс-пост в моем блоге.
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 35
    • +4
      wp-cache и wp-super-cache рулят, остальное — в топку.
      как потом обновлять такой блог?
      • 0
        Насколько я в курсе, wp-cache и wp-super-cache совместимы с wordpress только до версии 2.5.2. Во всяком случае, у меня (2.6.2) они не работали, и, как я слышал, у многих также не работали.

        Впрочем, 1 Blog Cacher тоже далеко не идеально работает — к примеру, если вносятся правки в пост, то кеш не удаляется, приходится руками его удалять.

        Пожалуй, стоит приписать, что использовать эти плагины надо с осторожностью.
        • +1
          в 2.6.2 у меня все отлично работает.
          • 0
            возможно, wp-cache использует какие-то платформенно-зависимые возможности php.

            у меня сервер, на котором вертится блог, на винде, так что, возможно, в этом дело.
            • +4
              ну да, там симлинк на файл надо делать, php под виндой — это просто мегажесть ::)
              • 0
                Посмотрю, поверчу, попробую.
                Может, получится что-то сделать.
      • +1
        Спасибо, как раз борюсь со скоростью загрузки wp, тема нагруженная очень js и картинками) сделаю все по вашему рецепту)
      • 0
        По поводу сжатия картинок и скриптов — глупо, по-моему…
        Насчет кэширования и т. д. — настройка отдачи статики через легкий сервер типа nginx (раз уж у вас есть возможность ковырять такие странные модули апача, значит у вас что-то типа сервера или vds?), кстати, он же и созмет все на лету…
        • +1
          насчет оптимизации картинок и скриптов/стилевых файлов — как сказать, как сказать. уменьшение размера на 20-80% это не фигня. вот, к примеру, у вас картинки+js+css размером в 200 KB. Уменьшили вы их на 20 процентов (самый плохой случай), итого размер стал 180 KB, или экономия 20 KB. Теперь прикинем, что у блога посещаемость 500 уников в день. 500*20 = 10000 KB, или почти 9.8 мегабайт. Теперь умножим на 31, и получим, что экономия достигает 300 мегабайт. И это не учитывая сжатых картинок, которые не относятся к файлам темы.
          Думаю, экономия значительная, особенно, если у вас сервер на коллокейшене, у которого исходящий трафик лимитирован и платный сверх определенного предела, а блог — только довесок к основным сайтам, вертящимся на нем.

          Отчего же? Да, у меня сервер, но редактирование .htaccess доступно даже на самых дешевых хостинговых планах (а на них, думаю, большинство блогов на таких и вертится), так что ничего странного в этих модулях апача нет.

          Ну а nginx тоже надо настраивать, чтобы он выставлял заголовки кеширования и жал файлы. Во всяком случае, я настраивал на своих серверах.
          • 0
            у меня js и css жмется gzip-ом, картинки изначально обрабатываются в фотошопе и им делается save for web — зачем весь этот изврат?
            • +1
              Уменьшение (minify) css и js перед сжатием (таким образом, мы сначала уменьшаем файл, а потом жмем его) позволяет (хотя и очень на немного, 0.5-1%) уменьшить размер итогового файла.
              Цифра невелика, но, опять же, если перемножать на все заходы, и учесть пусть ничтожное, но уменьшение времени ожидание пользователя, я считаю использование minify оправданным, благо, YUICompressor (или другая утилита, которую вы используете), есть не просит и на карман не давит.

              Что касается «save for web» в фотошопе, то pngcrush может и после этого уменьшить размер файлов еще на 2-7 процентов. Имхо, эту утилиту стоит использовать.
        • 0
          а как сделать чтобы динамические части сайта не кешировались
          • 0
            Приведите пример, пожалуйста.
            Так, в общем случае, сложно ответить.
            • 0
              ну например есть виджет с последними комментариями который обновляется каждый раз когда кто-то оставит комментарий, если поставить плагин кеширования то это виджет не обновляется. Как сделать так чтобы он не кешировался?
          • –2
            Автор начитался webo.in и решил пост (точнее кросс пост)?
            Для пиара своего блога чтоль?
            • +2
              Эта статья скорее сборник готовых решений именно для движка wordpress.
              Если ты не заметил, здесь довольно много материала, которого нет на webo.in. Одновременно, здесь много отсылок к webo.in, так как это лучший ресурс по оптимизации загрузки сайта в рунете.

              Я не думаю, что каким-то образом отбираю славу у webo.in — скорее, показываю на частном случае (блог на движке wordpress), как применить то, о чем пишет sunnybear
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                Хотелось бы увидеть ссылку на указанные тесты, и если это действительно так (т. е. какая именно верстка, не влияет на скорость загрузки), то я изменю этот пункт. В любом случае, в пользу верстки дивами немало аргументов, так что я пункт оставлю, изменю только содержание.
              • 0
                Ускорить Wordpress? Отличная идея.

                Наверное, мало кого сейчас надо убеждать в выигрышности div'овой верстки по сравнению с табличной, но если уж у Вас поднята тема «таблицы vs дивы»… ИМХО, полезно добавить, что верстка div-ами вместе с разбиением странички на файлы типа left-sidebar, right-sidebar, header, footer etc. позволит быстрее и проще поменять какой-нибудь небольшой кусочек кода прямо из панели управления движком (Дизайн -> Редактор тем), чем попытки из этой же панели управления поменять кусочек своей табличной верстки, в которой можно потеряться за забором из tr и td.
                • 0
                  Разумно, стоит добавить.
                • 0
                  Думаю, эта статья подойдет для многих сайтов, не только wordpress.
                  • +1
                    несколько сумбурно получилось. Я бы закончил статью выкладкой всех полезных конфигов/скриптов и цифрами: время загрузки было таким-то, стало таким-то. Иначе разговор немного в пустоту получается. Прямо как у Пелевина :)
                    • 0
                      Да, думаю, скрипты/htaccess и цифры стоит выложить.
                      Думаю, еще добавлю, что именно править в этих долбанных плагинах, чтобы предметно получалось и совсем неплохо выйдет.
                    • +2
                      По поводу переноса javascript в конец файла — а что будет, если js еще не загрузился, а пользователь кликнул на кнопку с onclick=«doSomathing()»? Будет ошибка яваскрипта, а это плохо (первое пришедшее в голову решение: ненавязчиво перейти к «ненавязчивому»яваскрипту )
                      • 0
                        В таком случае лучшим выходом, имхо, в данном случае будет применение unobtrusive javascript.
                        Если же javascript занимает в работе приложения такое большое место, то и оптимизировать его надо по-другому.

                        К примеру, yahoo на странице своей почты при первом посещении грузит сразу одним файлом все — и html, и css, и js, а затем в фоновом режиме подгружает js/css файлы с тем же содержимым, что уже загружено и выставляет куки «ресурсы загржены», и в следующий раз, когда вы идете на эту страницу, сервер смотрит, есть ли у вас куки «ресурсы загружены», и если да, то отдает уже другой файл, который содержит только html данные, а js/css берется из кеша.

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

                        Также интересна техника <a href=«ajaxpatterns.org/On-Demand_Javascript'>on-demand javascript.
                      • 0
                        ну уж таблицы отрисоввывались после полной загрузки только в Netscape 4 и более старых. Все современные броузеры рендерят таблицы по мере загрузки
                      • 0
                        Пару полезны ссылок: «Я хочу WordPress плагин» altblog.ru/wordpress-plugins-i-want/
                        И альтернативный способ кэширования — превратить всё в статику: kmb-tips.blogspot.com/2008/03/php.html
                        • 0
                          Увы, слитие всех JS и CSS в WP — не идеальный вариант. Многие плагины, как автор справедливо заметил, имеют гадскую привычку подключать свои файлы в хидер, и их можно собрать в один. Но. Делать это придётся КАЖДЫЙ раз, когда какой-нибудь плагин надумает обновиться (а происходит это не реже, чем раз в неделю при небольшом числе плагинов). То есть придётся каждую неделю проводить ряд мероприятий, а с автообновлением придётся попрощаться.
                          Я от такого решения из-за природной лени отказался, ограничившись WP-Cache и отдачей статики Nginx.
                          • 0
                            Вот-вот! Есть у моего дневника плагин wp-page-navi, который подключает свой CSS в хеадер.
                            Так вот, в этом CSS всего несколько строк, и конечно же я изменил стили для своей темы.
                            Плагин чувствую придется вручную обновлять (ведь я внес в него изменения получается), и в хеадере наравне с моим основным CSS подключаются отдельным файлом еще эти несколько строк((

                            Таким образом, чтобы HTML-разметка была красивой (CSS и яваскрипта по минимуму, а не этот бардак), надо вручную править под себя плагины, и потом вручную же их обновлять. Брррр!!!
                            • +1
                              просто отключите header.php и лишь выберите из него нужные инклюды и добавьте их вручную, таким образом даже в плагины лезть не придётся. странно что автор не упомянул об этом.
                        • 0
                          Было бы интересно прочитать про ускорение непосредственно PHP в WordPress, т.е. серверную, а не клиентскую оптимизацию.
                          • 0
                            Монстры типа mashable и Дж.Чау используют для кеширования плагин W3 Total Cache. Вот только… насколько хорошо он работает? Кто-нибудь пробовал?

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