Кроки з оптимізації WordPress щодо завантаження сервера?

Окрім установки W3 Total Cache або іншого кешування плагіну, які дії я можу зробити, щоб переконатися, що моя тема та веб-сайт працюють якомога швидше.

Ви можете встановити WordPress на Nginx. Існує ряд ресурсів, які допоможуть:

• Плагін сумісності nginx

• ЯК: Встановити WordPress на Nginx -

• Обговорення

• Як пришвидшити WordPress за допомогою кешу Nginx та WP Super

• WordPress на nginx + lighttpd + FastCGI + php

• Nginx як кеш-проксі кеш для WordPress

Деякі відомості про ефективність цього останнього посилання (яке, схоже, трохи інше, ніж інші):

Тому я вирішив поставити проксі перед wordpress для статичного кешу якомога більше. ВСІ неавторизований трафік подається безпосередньо з кешу файлів nginx, приймаючи деякі запити (наприклад, генерація каналу RSS) від 6 сторінок / секунду до 7000+ сторінок / секунду. Вихід. Nginx також обробляє журнал та gzipping, залишаючи більш важкі сервісні апарати для того, щоб робити те, що їм найкраще: обслуговувати динамічні сторінки WordPress лише за потреби.

...

На nginx - це так ефективно, що це страшно. Я ніколи не бачив, щоб він використовував більше 10 - 15 мега оперативної пам’яті та частину центрального процесора, навіть під нашим найсильнішим навантаженням. Наші графіки ганглій не брешуть: ми вдвічі зменшили вимоги до пам’яті, подвоїли пропускну здатність мережі та повністю вирівняли наше навантаження. У нас із цим не було проблем.

Встановіть термін дії на стороні клієнта для таких речей, як 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

Ви можете попередньо gzip все, що ви розумно можете (7-zip - це гарний інструмент для цього) і завантажити його там же, що і файл, який ви тільки що gzipped. Змініть .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 чудово поєднується з суперкешем, а також із заголовками закінчення терміну дії, які я детально описав вище.

Використовуйте Yslow у Firebug (Firefox) або подібне, щоб відстежувати ваші запити http, а що таке, а не стискається. Подивіться також на заголовки з закінченням терміну дії. Ви незабаром побачите, що можна вдосконалити.

Мінімізуйте кількість запущених плагінів до того, що вам дійсно потрібно. Особливо пам'ятайте про плагіни, які додають код JavaScript та CSS при кожному завантаженні сторінки, навіть коли цей код не використовується на сторінці.

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

Налаштуйте W3TC для використання CDN (наприклад, Amazon CloudFront або будь-якого іншого, що підтримується W3TC).

Подивіться, чи працюють для вас опції Minify (деякі плагіни генерують js / css, які не зробляться красиво, тому обов'язково протестуйте свій сайт після активації функції minify).

Якщо ви повністю контролюєте свій сервер MySQL, переконайтеся, що ввімкнено кеш запитів. Використовуйте сценарій настройки MySQL, щоб знайти інші способи оптимізації конфігурації вашої бази даних.

Якщо використання CDN чомусь проблематично, налаштуйте mod_expires у вашій установці apache. Встановіть термін придатності, наскільки це розумно для статичних типів, таких як зображення, css, javascript, відео, аудіо тощо.

Запустіть складений і використовуйте кеш об'єктів, щоб зменшити кількість запитів до бази даних. Це кешує дані з бази даних, а не сторінки. Не впевнений, чи це вже кеш w3-total-cache.

Переконайтеся, що ви кешуєте кеш-код опкоду, як APC . (Є ще кілька доступних.)

На додаток до використання плагіну кешування диска, наприклад wp-кеша, розмістіть свій блог на хості, на якому встановлено властивість "noatime". В іншому випадку, SSH у ваш хост (якщо ваш веб-хостинг це надає) і регулярно виконувати цю команду у своїх файлах кожні кілька днів:

chattr -R +A ~/*

~ / * Означає "мої файли під домашнім каталогом". Ви можете змінити цей шлях, як вважаєте за потрібне. Ви також можете встановити це на cron завдання в cpanel, якщо ваш веб-хост це забезпечує.

Для отримання додаткової інформації про atime властивості дивіться це . Це значно прискорює продуктивність читання з диска Linux.

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

Інше, що я бачу - це лише погано написані плагіни. Якщо ви навчитеся робити плагіни, ви починаєте бачити, як деякі плагіни неефективно закодовані, або навіть знаходите часові бомби, наприклад таблицю бази даних, яка заповнює та заповнює і ніколи не очищається, зберігаючи такі речі, як дані, що надходять.

Крім усіх інших тут рішень, ви також можете створити веб-ферму WordPress свого блогу, розмістивши його на декількох комп'ютерах із веб-вузлами, які всі підключаються до однієї бази даних та одного єдиного дискового файлу для файлів (наприклад, об'єм, встановлений на NFS ). Ознайомтеся з Ultra Monkey, як досягти цього.

Кілька відповідей у ​​верхній частині голови:

1) Мінімізуйте кількість запитів HTTP, які браузер повинен зробити своєму хосту, об'єднавши JavaScript та CSS, де це можливо / практично.

2) Завантажте якомога більше своїх зображень / медіа, що обслуговуються сторонніми CDN, особливо якщо ви використовуєте спільний хостинг.

3) Спробуйте зменшити кількість публікацій, які ви показуєте на головній сторінці, щоб зменшити загальний час візуалізації.

3а) Спробуйте скористатись темою, яка представляє кілька викладених публікацій повністю на головній сторінці та всі інші, старіші публікації, як уривки.

Кешування меню 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_menus на get_cached_menu. Тепер, кожного разу, коли меню викликається, у вас є один Databasequery замість усієї Menubuilding.

Меню не змінюється часто - але вам також доведеться вступити в 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для прямого виклику меню).

Меню завжди зберігається з назвою Меню, а не з позицією в Темі.

Використовуйте клас бази даних, який оброблений для оптимізації. Ми створили хороший досвід роботи з власним кодом, щоб зменшити використання пам'яті та швидкість доступу до бази даних. Поруч із цим ви можете оптимізувати саму структуру бази даних за допомогою невеликих змін, які також роблять багато.

Частину коду класу бази даних можна знайти в текстовій програмі wordpress, вона не ввійшла в основу ( Ticket № 11799 та пов'язані з цим ).

Для веб-сайтів, що торгуються людьми, вам слід налаштувати всі буфери MySQL на вміст, який зараз є. Незалежно від версії WordPress, на шарі MySQL може бути обчислена його конфігурація .

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

IMHO, ви не можете планувати хороші налаштування для my.cnf, не знаючи, скільки даних потрібно налаштувати. Вам доведеться періодично завантажувати поточний набір даних від виробництва в інсценувальне середовище, проводити оптимізацію та переходити з номерами для налаштування в my.cnf виробничого сервера.

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

Нещодавно я говорив про цю тему в WordCamp Houston . Усі вищезазначені рекомендації є чудовими, і найважливіше - переконатися, що всі деталі передньої частини повністю оптимізовані, щоб ви могли почати працювати над питаннями кешування та продуктивності сервера.

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

Крім того, якщо ви використовуєте багато кнопок соціальних медіа, ви можете налаштувати сценарії, щоб вони завантажувались у рамку iframe після повного завантаження сторінки. Я написав підручник про те, як це зробити за допомогою кнопки tweetMeMe re tweet (тепер застаріла, оскільки Twitter випустив власну кнопку ретвіту), але все ще можна застосувати до інших кнопок спільного доступу.

Для продуктивності сервера розгляньте Nginx як проксі-сервер для статичного вмісту з Apache, що обробляє важкі PHP та MySQL ліфтинг.

Оскільки про це ще ніхто не згадував, одним з найважливіших кроків для підвищення продуктивності сервера у поєднанні з будь-якою установкою LAMP було б перехід на робочу нитку apache та mod_fcgid.

Це звільнило 500 Мб пам'яті на моєму віртуальному приватному сервері.

Посібник з перевірки сповільнення плагіна

Існує прекрасний простий плагін під назвою « Час завантаження сторінки» , який додає таймер до нижнього колонтитулу сторінки. Це фактично лише чотири рядки коду:

<?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 та (досить старий, але хороший) багаторівневий плагін навігації .

Дотримуйтесь плагін W3 Total Cache для кешування функцій у WordPress. Увімкніть кешування сторінок і кешування даних на сторінці налаштувань плагіна. Переконайтеся, що ви вибрали "Альтернативний кеш PHP (APC / APCu)" як механізм кешування. НЕ вмикайте будь-які зміни в кеш-пам'яті W3, оскільки є багато шансів порушити зовнішній вигляд та / або функціональність вашого сайту. Ми залишимо це Cloudflare.

Після завершення налаштування решти функцій плагіна налаштуйте Cloudflare для свого веб-сайту. Переконайтеся, що ви включили Cloudflare у налаштуваннях загального кешу W3 також у розділі "Розширення".

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.

Оскільки зараз ви використовуєте Cloudlfare як CDN, ви можете використовувати плагін типу " Imagify " або " Стиснути зображення JPEG і PNG " від TingPNG для стискання зображень. Обидва є безкоштовними плагінами, доступними у сховищі плагінів WordPress.org. Також Imagify підтримує потужний алгоритм стиснення втрат.

Нарешті, встановіть плагін " Видалити рядки запитів із статичних ресурсів " із сховища WordPress, щоб він видаляв рядки запитів із статичних ресурсів, таких як файли CSS та JS. Це відбувається тому, що ресурси з URL-адресою "?" Або "&" не кешуються деякими серверами кешування проксі-сервера (пам'ятайте, Cloudflare також є сервером кешування проксі).

Потім встановіть плагін " Використовувати бібліотеки Google ". Цей плагін дозволяє вашому веб-сайту WordPress використовувати CDN API бібліотеки AJAX, а не обслуговувати ці файли безпосередньо з установки WordPress.

Деякі з переваг:

• Збільшує ймовірність того, що користувач уже має кешовані файли.
• Знімає додаткове навантаження з вашого сервера.
• Використовує стислі версії бібліотек (коли вони доступні).
• Сервери Google створені для узгодження стиснення HTTP із браузером, що запитує.

Не в останню чергу, використовуйте плагін " WP-Optimize " від Ruhani Rabin для очищення та оптимізації вашої бази даних.

Сподіваємось, це відповість на ваше запитання щодо оптимізації WordPress для зменшення навантаження сервера.