Ви, звичайно ж, в курсі, що цей блог працює на WordPress. Деякий час назад я почав серйозно турбуватися щодо швидкодії цього движка. По-перше, мене хвилювало кількість використовуваної їм пам'яті. Наприклад, коли по блогу починають ходити пошукові боти. WordPress запросто може з'їсти 1 Гб оперативки. По-друге, я був стурбований часом, за яке у користувача завантажуються сторінки. У разі потрапляння в кеш проблем не виникає, але інакше сторінка запросто може генеруватися 1-2 секунди.
Для оптимізації блогу мною були зроблені наступні кроки.
В першу чергу відключаємо всі зайві плагіни. Якщо плагін можна замінити шматком коду в шаблоні або рядком у файлі .htaccess, замінюємо. У моєму випадку залишилися тільки наступні дев'ять полігонів - це AddQuicktag, CodeColorer, Disqus, Google XML Sitemaps, Limit Login Attempts, RusToLat, WP-Optimize, WP-PageNavi, WP Super Cache. Строго кажучи, від більшості з них також можна позбутися, але, як ми скоро побачимо, в цьому немає необхідності.
Далі. Перевіряємо, чи не використовується в шаблоні десяток CSS або JS файлів. важких картинок і тп. CSS файли по можливості об'єднуємо і пакуємо, JS проганяє через Google Closure Compiler (є додаток і онлайн-версія). Дивимося, чи не можна зменшити розмір HTML-коду. Наприклад, я помітив, що в заголовках постів у мене використовується наступний код:
Я замінив його на:
... заощадивши тим самим відвідувачам кілька десятків байт трафіку. Також розмір сторінок вдалося трохи зменшити за допомогою наступного коду в functions.php:
Крім того, цей код зменшує кількість посилань, за якими намагаються ходити пошукові боти. Потім я взявся за HTTP-заголовки. З явного сміття (який видно при промохе повз кеша) в них було виявлено:
X-Pingback випилюється так:
function remove_pingback_header # 40; $ headers # 41; # 123;
unset # 40; $ headers # 91; 'X-Pingback' # 93; # 41; ;
return $ headers;
# 125;
add_filter # 40; 'Wp_headers'. 'Remove_pingback_header' # 41; ;
А ось код для випилювання Link:
function empty_shortlink # 40; $ Shortlink. $ Id. $ Context. $ allow_slugs # 41; # 123;
return NULL;
# 125;
add_filter # 40; 'Get_shortlink'. 'Empty_shortlink'. 10. 4 # 41; ;
Також, щоб не палити версію PHP (заголовок X-Powered-By), прописуємо в файлі php.ini:
Здається, після цього зміни потрібно перезапустити Apache. Заодно я перевірив список використовуваних розширень PHP і модулів Apache. У підсумку відключив штук 5 непотрібних мені модулів / розширень.
Здавалося б, тепер ми просто віддаємо користувачам статику в обхід PHP, проте кількість використовуваної пам'яті щось не поспішало знижуватися. Мабуть, PHP все-таки щось робить. Тоді я вирішив додати в index.php наступний код:
$ Fid = fopen # 40; "/path/to/index-php.txt". "A" # 41; ;
fwrite # 40; $ Fid.
date # 40; "Y-m-d H: i: s" # 41 ;. "\ T".
$ _SERVER # 91; 'REQUEST_URI' # 93 ;. "\ T".
$ _SERVER # 91; 'REMOTE_ADDR' # 93 ;. "\ T".
$ _SERVER # 91; 'HTTP_USER_AGENT' # 93 ;. "\ N" # 41; ;
fclose # 40; $ fid # 41; ;
Виявилося, що по блогу ходить безліч ботів, які шукають діряві форуми, запитують сторінки / article-name замість / article-name /, а також неіснуючі файли з іменами на кшталт apple-touch-icon.png і тд. Всі ці запити йшли повз кеша прямо в WordPress. Для боротьби з цією проблемою я додав в .htaccess наступне:
Оскільки деякі відвідувачі приходять в блог з усяким сміттям в query string типу utm_source =. я також налаштував редіректи з URL, що містять якісь аргументи на запиті, на ті ж URL, тільки без аргументів:
RewriteCond%! = ""
RewriteCond%! Codecolorer
RewriteCond%! ^ (P | page_id | preview) =
RewriteCond%! ^ / Wp- (admin | login | cron | includes)
RewriteRule ^ (. *) $ / $ 1? [R = 301, L]
Спеціально для пошукових роботів Google в robots.txt я дописав:
Disallow: * / feed
Disallow: * / trackback
Disallow: * / comment
Нарешті, щоб відвідувачі, запитали неіснуючу сторінку, бачили нормальне сполучення про помилку місце «404 Not Found», я завів спеціальну сторінку і прописав в .htaccess:
На даному етапі було абсолютно очевидно, що в WordPress не спадає ніяких зайвих запитів, в більшості випадків сторінки взагалі беруться з кеша в обхід PHP. За винятком хіба що RSS-фідів, бо WP Super Cache з якихось причин не вміє їх кешувати. Слід зазначити, що кількість використовуваної пам'яті на сервері до цього моменту вже істотно знизилося (вона коливалася в районі 100-200 Мб, з рідкісними піками до 300-400 Мб), але я все рано не був задоволений результатом.
Довелося почекати якийсь час, але результат того вартий:
Зменшення кількості використовуваної пам'яті відбувається з тієї причини, що «важкий» Apache не займається передачею даних клієнта, замість нього це робить «легкий» Nginx, піднятий локально. Apache швидко відпрацьовує, віддає дані Nginx і завершує роботу. Таким чином, одночасно працює менше процесів Apache і вільної пам'яті залишається більше.
А ось з якою швидкістю відбувається завантаження сторінок:
Скажімо так, це не повільніше, ніж завантажується головна сторінка Яндекса. І все це на самому звичайному шаред хостингу від RU-CENTER. Підозрюю, що переїздом на виділений сервер мені доведеться займатися дуже не скоро.
Крім описаних вище оптимізацій я також експериментував з наступними.
Пробував перенести картинки і всякі там архіви на Dropbox, але особливої економії пам'яті чи іншого виграшу від цього не побачив і повернув, як було. Пробував зберігати в кеш gzip'ованние сторінки і віддавати їх в такому вигляді відвідувачам (до речі, це працює навіть без mod_gzip). Теж не побачив профіту, до того ж, стиснені сторінки все одно доводиться класти в кеш на випадок, якщо прийде клієнт без підтримки gzip. Вирішив не мудрувати і відключити цю справу. Пробував відключати wp-cron в WordPress і прописувати його в crontab. Все зламав і профіту не побачив, повернув все взад. Також спробував плагін WP-Minify, що оптимізує HTML-код сторінок. Прикольна штука, але на час завантаження сторінок мало впливає, а от швидкість генерації збільшує приблизно на 100 мс. Вимкнув і видалив.
Ще знайшов прикольний плагін Really Static, що дозволяє генерувати статичні сайти на WordPress. І потім хоч на narod.ru, хоч на GitHub їх заливай. Або, щоб було зручніше, можна сам WordPress підняти на піддомені з обмеженням доступу по паролю, а на основному домені розміщувати тільки статику. Стану десятітисясніком, обов'язково гляну на нього ще раз, а поки від нього буде більше незручностей, ніж користі.
Отже, ви все ще вважаєте, що WordPress - гальмівний двигун? Або все-таки ви не вмієте ним користуватися?