janfabry
  • 0
Гуру

Шаги по оптимизации WordPress в отношении нагрузки на сервер и скорости сайта?

  • 0

Помимо установки W3 Total Cache или другого плагина кэширования, какие шаги я могу предпринять, чтобы убедиться, что моя тема и сайт работают как можно быстрее.

Share
  1. если вы запускаете свой сайт на vps, вам следует попробовать кеш Redis.

    • 0
  2. Вы можете установить WordPress на Nginx. Есть ряд ресурсов, которые помогут:

    Некоторая информация о производительности из этой последней ссылки (которая, похоже, немного отличается от других):

    Поэтому я решил поставить прокси перед wordpress для статического кеша, насколько это возможно. ВЕСЬ неаутентифицированный трафик обслуживается непосредственно из файлового кеша nginx, при этом скорость некоторых запросов (таких как генерация RSS-канала) составляет от 6 страниц в секунду до 7000+ страниц в секунду. Уф. Nginx также обрабатывает журналирование и gzip-архивирование, предоставляя более тяжелым серверным апачам возможность делать то, что они умеют лучше всего: обслуживать динамические страницы WordPress только тогда, когда это необходимо.

    На nginx — это настолько эффективно, что даже страшно. Я никогда не видел, чтобы он использовал более 10–15 мегабайт ОЗУ и мизерную загрузку процессора, даже при нашей самой большой нагрузке. Графики наших ганглиев не лгут: мы вдвое сократили требования к памяти, удвоили пропускную способность исходящей сети и полностью выровняли нагрузку. У нас практически не было проблем с тех пор, как мы это установили.

    • 0
  3. Установите срок действия на стороне клиента для таких вещей, как css, изображения, JavaScript и т. д., которые не нужно повторно загружать для каждого просмотра страницы. Это, безусловно, оказало наибольшее влияние на время загрузки моего сайта. Самая быстрая загрузка — это загрузка, которой никогда не было…

    # BEGIN Expire headers
    <IfModule mod_expires.c>
      ExpiresActive On
      ExpiresDefault "access plus 7200 seconds"
      ExpiresByType image/x-icon "access plus 2592000 seconds"
      ExpiresByType image/jpeg "access plus 2592000 seconds"
      ExpiresByType image/png "access plus 2592000 seconds"
      ExpiresByType image/gif "access plus 2592000 seconds"
      ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
      ExpiresByType text/css "access plus 2592000 seconds"
      ExpiresByType text/javascript "access plus 2592000 seconds"
      ExpiresByType application/x-javascript "access plus 2592000 seconds"
      ExpiresByType text/html "access plus 7200 seconds"
      ExpiresByType application/xhtml+xml "access plus 7200 seconds"
    </IfModule>
    # END Expire headers
    
    # BEGIN Cache-Control Headers
    <IfModule mod_headers.c>
      <FilesMatch "\\.(ico|jpe?g|png|gif|swf|gz)$">
        Header set Cache-Control "max-age=2592000, public"
      </FilesMatch>
      <FilesMatch "\\.(css)$">
        Header set Cache-Control "max-age=2592000, public"
      </FilesMatch>
      <FilesMatch "\\.(js)$">
        Header set Cache-Control "max-age=2592000, private"
      </FilesMatch>
    <filesMatch "\\.(html|htm)$">
    Header set Cache-Control "max-age=7200, public"
    </filesMatch>
    # Disable caching for scripts and other dynamic files
    <FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
    Header unset Cache-Control
    </FilesMatch>
    </IfModule>
    # END Cache-Control Headers
    

    Вы можете предварительно заархивировать все, что возможно (7-zip — хороший инструмент для этого), и загрузить его в то же место, что и файл, который вы только что заархивировали. Измените.htaccess, чтобы он обслуживал предварительно заархивированные файлы, как показано ниже. Предостережение здесь заключается в том, что вам нужно помнить о том, чтобы повторно заархивировать их, если / когда вы что-то обновляете. Это снижает нагрузку на процессор, за исключением синтаксического анализа.htaccess.

    RewriteEngine on
    #Check to see if browser can accept gzip files. If so and we have it - serve it!
    ReWriteCond %{HTTP:accept-encoding} gzip
    RewriteCond %{HTTP_USER_AGENT} !Safari
    #make sure there's no trailing .gz on the url
    ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
    #check to see if a .gz version of the file exists.
    RewriteCond %{REQUEST_FILENAME}.gz -f
    #All conditions met so add .gz to URL filename (invisibly)
    RewriteRule ^(.+) $1.gz [QSA,L]
    

    Это просто сырой ответ. Вариаций на эту тему очень много. Я написал об этом в блоге и добавил немало ссылок на более подробные статьи по адресу http://icanhazdot.net/2010/03/23/some-wordpress-stuff/. Прочитайте это и, что более важно, ссылки, на которые я указываю — это хорошие ресурсы.

    Имейте в виду, что если вы часто возитесь, пользователям нужно будет обновить свой кеш.

    Я также нашел очень полезным плагин wp-minify. В этом случае следует обратить внимание на то, что вы должны исключить элементы, специфичные для страницы (контактная форма, слайдер на главной странице и т. д.), чтобы вам не приходилось повторно загружать весь набор css, JS и т. д. для каждой страницы. Это хороший способ минимизировать, комбинировать и сжимать ваш базовый CSS, JS и т. д. Он значительно сокращает HTTP-запросы. Wp-minify хорошо работает с supercache, а также с заголовками истечения срока действия, которые я описал выше.

    Используйте Yslow в Firebug (Firefox) или аналогичном для мониторинга ваших http-запросов и того, что сжато, а что нет. Взгляните также на заголовки истечения срока действия. Вскоре вы увидите, что можно улучшить.

    • 0
  4. Сведите к минимуму количество подключаемых модулей, которые вы запускаете, до тех, которые вам действительно нужны. Особенно помните о плагинах, которые добавляют код javascript и CSS при каждой загрузке страницы, даже если этот код не используется на странице.

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

    Настройте W3TC для использования CDN (например, Amazon CloudFront или любого другого, поддерживаемого W3TC).

    Посмотрите, работают ли для вас параметры Minify (некоторые плагины генерируют js/css, которые не будут хорошо минимизированы, поэтому обязательно протестируйте свой сайт после активации функции минимизации).

    Если у вас есть полный контроль над вашим сервером MySQL, убедитесь, что у вас включен query_cache. Используйте сценарий настройки MySQL, чтобы найти другие способы оптимизации конфигурации вашей базы данных.

    Если использование CDN по какой-то причине проблематично, настройте mod_expires в настройках apache. Установите максимально допустимое время истечения для статических типов, таких как изображения, css, javascript, видео, аудио и т. д.

    • 0
  5. Запустите memcached и используйте кеш объектов, чтобы уменьшить количество запросов к базе данных. Это кеширует данные из базы данных, а не страницы. Не уверен, что w3-total-cache уже делает это.

    Убедитесь, что вы используете кэш кода операции, такой как APC. (Есть еще несколько доступных.)

    • 0
  6. В дополнение к использованию подключаемого модуля кэширования диска, такого как wp-cache, поместите свой блог на хост-том, на котором установлено свойство «noatime». В противном случае подключитесь к вашему хосту по SSH (если ваш веб-хост это предоставляет) и регулярно запускайте эту команду для ваших файлов каждые несколько дней:

    chattr -R +A ~/*
    

    ~/* означает «мои файлы в моем домашнем каталоге». Вы можете изменить этот путь по своему усмотрению. Вы также можете настроить это на задании cron в cpanel, если ваш веб-хост предоставляет это.

    Дополнительные сведения о свойстве atime см. в этом. Это значительно ускоряет чтение диска Linux.

    Иногда ваш сайт атакуют пауки. Вы можете использовать такой инструмент, как SpyderSpanker или Chennai Central, чтобы отфильтровать пауков, которые не помогают повысить рейтинг страницы на вашем сайте, а просто замедлить его, а затем задушить хороших пауков (таких как Google, Bing и т. д.), посылая им случайные Сообщения HTTP 304 Not Modified.

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

    Помимо всех других решений здесь, вы также можете создать веб-ферму WordPress для своего блога, разместив ее на нескольких компьютерах с веб-узлом, которые все подключаются к одной базе данных и одному единственному тому диска для файлов (например, тому, смонтированному через NFS). ). Посмотрите Ultra Monkey, чтобы узнать, как все это реализовать.

    • 0
  7. Несколько ответов, которые приходят мне в голову:

    1) Минимизируйте количество HTTP-запросов, которые браузер должен делать на вашем хосте, объединяя JavaScript и CSS, где это возможно/практично.

    2) Перенесите как можно больше ваших изображений/медиафайлов на сторонние CDN, особенно если вы используете виртуальный хостинг.

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

    3a) Попробуйте использовать тему, которая представляет несколько избранных постов целиком на главной странице, а все другие, более старые посты — в виде выдержек.

    • 0
  8. Кэширование меню WordPress также повышает производительность. Это следует учитывать, особенно если у вас много страниц или гигантская структура меню.

    Сделайте это в 2 простых шага. Сначала создайте функцию, которая получает или создает меню вместо wp_nav_menu прямого вызова.

    function get_cached_menu( $menuargs ) {
    
        if ( !isset( $menuargs['menu'] ) ) {
    
            $theme_locations = get_nav_menu_locations();
            $nav_menu_selected_id = $theme_locations[$menuargs['theme_location']];
            $termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );
            $transient = 'menu_' . $termslug->slug . '_transient';
    
        } else {
    
            $transient = 'menu_' . $menuargs['menu'] . '_transient';
    
        }
    
    
        if ( !get_transient( $transient ) ) { // check if the menu is already cached
    
            $menuargs['echo'] = '0'; // set the output to return
            $this_menu = wp_nav_menu( $menuargs ); // build the menu with the given $menuargs
            echo $this_menu; // output the menu for this run
            set_transient( $transient, $this_menu ); // set the transient, where the build HTML is saved
    
        } else {
    
            echo get_transient( $transient ); // just output the cached version
    
        }
    
    }
    

    В вашей теме замените wp_nav_menu s на get_cached_menu . Теперь каждый раз, когда вызывается меню, у вас есть один запрос к базе данных вместо всего построения меню.

    Меню меняются не часто, но вам также нужно подключиться к wp_update_nav_menu действию, чтобы удалить старые переходные процессы.

    Сделай это так:

    add_action('wp_update_nav_menu', 'my_delete_menu_transients');
    
    function my_delete_menu_transients($nav_menu_selected_id) {
    
        $termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );
    
        $transient = 'menu_' . $termslug->slug . '_transient';
    
        delete_transient( $transient ); 
    
    }
    

    Меню будет сгенерировано при следующем вызове страницы и будет использовать кешированную версию до тех пор, пока кто-нибудь снова не обновит меню.

    Обновленная версия

    Спасибо @helgatheviking за указание на ошибку между слагами и идентификаторами. Обновил функции, так что работает и с theme_position и menu (для прямого вызова меню).

    Меню всегда сохраняются с именем меню, а не с позицией в теме.

    • 0
  9. Используйте класс базы данных, урезанный для оптимизации. Мы получили хороший опыт работы с собственным кодом, чтобы уменьшить использование памяти и скорость доступа к базе данных. Кроме того, вы можете оптимизировать саму структуру базы данных, внеся небольшие изменения, которые также имеют большое значение.

    Часть кода класса базы данных можно найти в трассировке wordpress, она не вошла в ядро ​​( тикет № 11799 и связанные с ним ).

    • 0
  10. Для сайта с высокой посещаемостью вам следует настроить все буферы MySQL для содержимого, которое есть сейчас. Независимо от версии WordPress, уровень MySQL может вычислять свою конфигурацию.

    На самом деле, если у вас есть данные InnoDB без включения innodb_file_per_table, вам необходимо очистить InnoDB, сегментировав каждую таблицу в отдельное физическое табличное пространство. Можно выполнить приличную настройку MySQL , даже если у вас ограниченное аппаратное обеспечение. Есть много сценариев для выполнения таких оптимизаций InnoDB.

    ИМХО, вы не можете спланировать хорошие настройки для my.cnf, не зная объема данных для настройки. Вам придется периодически загружать текущий набор данных из рабочей среды в промежуточную среду, выполнять оптимизацию и получать числа для настройки в файле my.cnf производственного сервера.

    • 0
  11. вы можете включить глобальное сжатие вывода. это будет сжимать все, что происходит автоматически, если браузер поддерживает это. Это значительно уменьшает размер передаваемых файлов, но увеличивает нагрузку на процессор.

    • 0
  12. Недавно я говорил на эту тему на WordCamp Houston. Все вышеперечисленные рекомендации великолепны, и важно убедиться, что весь внешний интерфейс полностью оптимизирован, после чего вы можете начать работать над проблемами кэширования и производительности сервера.

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

    Кроме того, если вы используете много кнопок социальных сетей, вы можете настроить скрипты так, чтобы они загружались в iframe после полной загрузки страницы. Я написал руководство о том, как сделать это с помощью кнопки повторного твита TweetMeMe (сейчас она устарела, поскольку Twitter выпустил собственную кнопку ретвита), но ее все еще можно применить к другим кнопкам «Поделиться».

    Для производительности сервера обратите внимание на Nginx в качестве внешнего прокси-сервера для статического контента, а Apache обрабатывает тяжелый PHP и MySQL.

    • 0
  13. Поскольку никто еще не упомянул об этом, одним из наиболее важных шагов для повышения производительности сервера в сочетании с любой настройкой LAMP будет переключение на рабочий поток apache и mod_fcgid.

    Это освободило 500 МБ памяти на моем виртуальном частном сервере.

    • 0
  14. Руководство по проверке замедления работы плагина

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

    <?php
    function ur_pageload_footer() {
        printf(__('Page in %s seconds', 'pageload'), timer_stop());
    }
    add_action('wp_footer', 'ur_pageload_footer')
    

    Потом:

    1. Создать электронную таблицу
    2. Перечислите все ваши активные плагины и поместите их туда
    3. Обновите страницу три раза, отмечая время загрузки страницы каждый раз
    4. Пройдитесь по своим плагинам один за другим, деактивируя их
    5. Повторите шаг 3
    6. Обратите внимание на порядок деактивации плагинов.

    Ваша таблица должна выглядеть примерно так

    +-------+-------+-------+-------+--------+
    | Run 1 | Run 2 | Run 3 | Order | Plugin |
    

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

    Я нашел два плагина, которые вызывали «значительное» замедление mqtranslate и (довольно старый, но хороший) плагин многоуровневой навигации.

    • 0
  15. Используйте плагин W3 Total Cache для кэширования в WordPress. Включите кэширование страниц и кэширование базы данных на странице настроек плагина. Убедитесь, что вы выбрали «Альтернативный кэш PHP (APC / APCu)» в качестве механизма кэширования. НЕ включайте минимизацию в W3 Total Cache, так как у вас есть много шансов нарушить внешний вид и / или функциональность вашего сайта. Мы оставим это Cloudflare.

    Когда вы закончите настройку остальных функций плагина, настройте Cloudflare для своего веб-сайта. Убедитесь, что вы включили Cloudflare в настройках W3 Total Cache в разделе «Расширения».

    Cloudflare — это сеть доставки контента, которая кэширует все статическое содержимое (файлы изображений, CSS, JS, документы и т. д.) с вашего сайта и предоставляет его вашим посетителям с их глобальных серверов. Это поможет ускорить загрузку страниц и снизить нагрузку на сервер. Список типов файлов, кэшируемых Cloudlfare, см. в этом списке. Более того, у Cloudflare есть бесплатный план.

    В Cloudflare установите стандартный уровень кэширования и установите срок действия кэша браузера как минимум более 20 часов. Включите Always Online™, так что даже если ваш сервер выйдет из строя, Cloudflare будет обслуживать статические страницы вашего сайта из своего кеша. Также включите их функцию автоматической минимизации (помните, почему я просил вас не включать минимизацию для W3 Total Cache? Потому что Cloudflare делает это лучше!) Затем установите для Rocket Loader™ автоматический режим.

    Вот выдержка из того, что делает Rocket Loader:

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

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

    • Кэширование скриптов локально (с помощью LocalStorage, доступного в большинстве
      браузеров и смартфонов), чтобы они не загружались повторно без
      необходимости.

    Дополнительную информацию можно найти здесь.

    Если возможно, переключитесь на фреймворк Genesis для WordPress, потому что они чисты и не раздуты. Genesis был создан с учетом скорости и SEO. Я сам протестировал его, и мои оценки PageSpeed ​​были хорошими. Также, если вы используете Genesis, не забудьте включить кеширование фрагментов в настройках W3 Total Cache.

    Поскольку теперь вы используете Cloudlfare в качестве CDN, вы можете использовать плагин, такой как « Imagify » или « Сжатие изображений JPEG и PNG » от TingPNG, для сжатия ваших изображений. Оба являются бесплатными плагинами, доступными в репозитории плагинов WordPress.org. Кроме того, Imagify поддерживает мощный алгоритм сжатия с потерями.

    Наконец, установите плагин « Удалить строки запроса из статических ресурсов » из репозитория WordPress, чтобы он удалял строки запроса из статических ресурсов, таких как файлы CSS и JS. Это связано с тем, что ресурсы с «?» или «&» в URL-адресе не кэшируются некоторыми прокси-кэширующими серверами (помните, что Cloudflare также является прокси-кэширующим сервером).

    Затем установите плагин « Использовать библиотеки Google ». Этот плагин позволяет вашему сайту WordPress использовать CDN Google AJAX Library API, а не напрямую обслуживать эти файлы из вашей установки WordPress.

    Некоторые из преимуществ:

    • Увеличивает вероятность того, что пользователь уже кэшировал эти файлы.
    • Снимает дополнительную нагрузку с вашего сервера.
    • Использует сжатые версии библиотек (если они доступны).
    • Серверы Google настроены на согласование сжатия HTTP с запрашивающим браузером.

    И последнее, но не менее важное: используйте плагин WP-Optimize от Рухани Рабина для очистки и оптимизации вашей базы данных.

    Надеюсь, это ответит на ваш вопрос об оптимизации WordPress для снижения нагрузки на сервер.

    • 0
  16. Что касается всего «стека» сервера и не только, я бы отослал вас к этому вопросу (и моему ответу там), в котором обсуждаются несколько элементов, включая DNS, SSL, центры обработки данных, ОС и стеки LEMP. Суть моего ответа заключалась в использовании облачных серверов KVM с кэшированием объектов Nginx, PHP-FPM и Redis.

    Но природа этой темы больше сосредоточена на самом WordPress, а также на соответствующих передовых методах, поэтому я упомяну несколько вещей в более узком смысле:

    Во- первых, слишком много внимания уделяется кэширующим «плагинам» в сообществе WordPress. Причина этого в том, что общий хостинг Apache по-прежнему доминирует на рынке, и по целому ряду причин удобства использования большинство недорогих веб-хостов по умолчанию избегают активации кэширования на уровне сервера (если вообще).

    За годы, прошедшие после этого вопроса, стали популярными несколько «премиальных» веб-хостов, некоторые из которых имеют встроенное кэширование на уровне сервера (эти кэши обычно построены на Nginx, Redis или Varnish, хотя некоторые cPanel- хосты теперь используют кеш Litespeed). Кэш Nginx FastCGI, возможно, является наиболее надежным вариантом, когда речь идет о кэшировании на уровне сервера, а также наименее подверженным конфликтам. Некоторые плагины кеша для WordPress интегрируются с Nginx, но это довольно глупо и только увеличивает раздувание.

    Во- вторых, в наши дни CDN почти ожидаемы. Многие «премиальные» хосты по умолчанию предлагают CDN для обслуживания ваших статических ресурсов с пограничных узлов по всему миру, или вместо этого вы можете использовать стороннюю службу. Самый популярный вариант — CloudFlare, потому что это бесплатный CDN (и SSL-прокси). Имейте в виду, что CDN не обслуживают HTML-контент, поэтому важно кэширование на уровне сервера.

    В-третьих, и наиболее распространенная причина низкой производительности по моему опыту (помимо хостинга) — это проблема сторонних скриптов и ресурсов — другими словами, элементы, которые ваш сайт загружает с других серверов, такие как скрипты отслеживания и рекламы, виджеты и формы, видео и мультимедиа и многое другое. Даже если эти вещи загружаются асинхронно/отложенно (в фоновом режиме), это все равно может вызвать серьезные проблемы из-за огромного размера и количества ресурсов, которые часто загружаются. Иногда это также вызывается плагином или темой: например, я видел темы WP, загружающие более 20 вариантов шрифтов Google!

    В-четвертых, это проблема нагромождения общей темы и плагинов. Мало того, что некоторые из них встраивают сторонние ресурсы с удаленных серверов, но некоторые из них также ужасно закодированы и вызывают перегрузку базы данных и т. д. Даже если качество кода приличное, слишком много веб-мастеров думают, что они могут использовать очень раздутую тему вместе с с плагином компоновщика страниц и надстройками для компоновщика страниц и кучей других плагинов, а затем просто установите плагин кеша/скорости, чтобы минимизировать или отложить загрузку всего… НЕТ, это не так. Наличие сотен элементов DOM и десятков файлов CSS/JS всегда будет вызывать проблемы с производительностью, несмотря ни на что. Самый быстрый вариант загрузки всегда будет темой WordPress с пользовательским кодом.с жестко закодированным HTML, одним файлом style.css (загруженным встроенным) и минимальным количеством легковесных и хорошо закодированных плагинов… и точка.

    Наконец, (и да, распространенный) просто избегать «глупых» ошибок. Я не могу сосчитать, сколько раз я видел, как клиентский веб-сайт загружался более 30 секунд только для того, чтобы обнаружить, что их тема пытается загрузить несколько отсутствующих файлов, которые вызывают ошибки 404 не найдены, или их фоновая «анимация» домашней страницы составляет 50 МБ в размер!

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

    • 0

Оставить ответ

You must login to add an answer.