Оптимизация WordPress — 3. Простые движения.

И таки снова здравствуйте дражайший читатель.

Речь пойдёт всё о том же, о чем уже неоднократно писано в статьях по оптимизацию с W3 Total Cache и о результатах данной оптимизации. Как можно было заметить, прирост производительности с W3 Total Cache был отрицательным — блог стал работать медленнее. Да, либо плагин слишком сырой, либо просто слишком много возможностей, и, как результат, слишком долгое исполнение кода. Но нам, как пользователям, в общем-то плевать, верно? Нам хочется простой рецепт, который можно один раз сделать, и забыть о неприятностях.

Так вот, с некоторой натяжкой я такой рецепт таки нашёл. Это старый добрый WP Super Cache, в связке с WP Minify. Оба плагина позволяют установить их из панели, и затем использовать совместно, не заботясь о каком-либо обслуживании. Скажем, среднее время загрузки сайта по тестам составило 3 секунды, что уже более-менее приемлемо (а бывало доходило и до 7-8). Что делают эти плагины? WP Minify позволяет во-первых, объединить CSS и JS файлы в один большой и слегка «пожатый» удалением пробельных символов СSS и JS файл (по сути у вас становится всего два файла, один css, другой js). Браузеру всё равно, а размер становится иной раз меньше в разы. И количество запросов тоже уменьшается — к примеру до у меня было 14 (кажется) запросов на javascript & css ресурсы, а теперь только три, при этом два внешних — системы статистики, и один внутренний — на «родные» файлы. Затем, этот плагин также сжимает и HTML контент, что также уменьшает время загрузки. Опять же удалением пробельных символов.

Читать далее Оптимизация WordPress — 3. Простые движения.

О кэшировании в Web

День добрый, дражайший читатель.

Вообще, я не имею уж очень большого опыта в работе с высоконагруженными системами. Обычно проекты, которые мне доводилось делать, были рассчитаны на посещаемость в 20000 человек в сутки. Ну или около того. Однако, однако… Программисты народ странный. Мы иногда делаем нечто «на будущее». Ну вдруг потребуется. Но вначале немного теории. Как строится высоконагруженная система? Основной её компонент — это балансировщик нагрузки. Фактически он просто обеспечивает обработку запроса пользователя одним из нескольких back-end’ов. Например один балансирощик (и лично мне доводилось слышать, что в его роли может выступать например nginx), раскидывает запросы по нескольким PHP-сборщикам (или бросается смотреть в кэш — нет ли уже того, что требуется). Те, соответственно формируют контент, и отдают его обратно. Это очень упрощённо, прямо скажем. Потому что я всё-таки не администратор веб-серверов, и всех тонкостей не знаю.

Так вот, это я к тому, что кэширование — один из действенных способов снижения нагрузки. Зачем выполнять кучу кода для формирования HTML-контента, если такая работа уже была сделана ранее, и с тех пор ничего не поменялось? Правильно, незачем. Так не логичнее ли сохранить страницу в кэш, и отдавать её каждый раз быстро и без мучений? Логичнее, все так и делают. И вот тут есть выбор — где размещать кэш. Существует много вариантов, но если свести к основным, это либо жёсткий диск, либо оперативная память. Чувствуете разницу? Скорость обращения к жёсткому диску в разы ниже, чем к оперативке, но при этом кэширование на жёстком диске подходит практически для любого хостинга, в том числе и виртуального. Однако важно понимать, что высоконагруженные проекты никогда не размещаются на виртуальном хосте. Его мощностей и возможностей просто не хватит для обработки такого потока данных. Потому для просто посещаемых проектов это минимум VPS. А для проектов с высокой нагрузкой необходимо строить распределённую систему с балансировкой, отдельным сервером для БД, для кэшировщика, для контент-сборщиков и так далее. Это дорого, но как правило ресурс окупает подобные затраты.

Читать далее О кэшировании в Web

Оптимизация WordPress – продолжение

Таки снова здравствуйте, дорогие мои читатели!

Не так давно писал, на тему оптимизации WordPress с помощью плагина W3C Total Cache. И вот, пишу тут продолжение :) С ентим плагином мы прожили более месяца, однако — никакого прироста производительности это блогу не дало (если верить графику на Google Webmaster) — среднее время загрузки оставалось в районе 4 секунд, и падать не желало… И вот, наконец, порядком подзаебавшись оптимизировать сайт и ожидать загрузки страниц  долгими осенними вечерами — я решил прогнать движок через клоподав и профилёр. Сказано — сделано, сайт полностью выкачан по ФТП на локальный комп, сделан дамп базы, всё установлено, и включено. В NuSphere PHP Editor был создан проект, и запущен на профилирование index.php — итак, первая загрузка — 3.6 секунд на построение страницы сервером.

Читать далее Оптимизация WordPress – продолжение

Оптимизация WordPress, W3 Total Cache и иже с ней

Здравствуй-здравствуй, дорогой читатель.

Тема оптимизации WordPress неоднократно и здорово муссировалась на разных блогах, форумах, порталах, и прочих, прочих. Да, WP работает медленно, в базовой комплектации, и сделать с этим что-либо довольно сложно. Дело осложняется хостером. Дело в том, что блоги как правило находятся на бюджетных хостингах, стоящих в районе 150 р/мес, и этот блог не исключение. Зачастую же, разные пособия говорят о том, как можно улучшить железо и хостинг, путём установки дополнительной памяти, установкой расширений для PHP, и прочего, прочего. Я решил описать более-менее доступные варианты, но не обойду и варианты более дорогие. Блог на wordpress, если им более или менее заниматься, начинает набирать популярность, посетителей становится всё больше и больше, и вы начинаете подумывать о том, что хостинг — ну например на такой каке как джино (где находится мой нынешний сайт) — может и не возрадоваться возросшей нагрузке, да и увеличить время отдачи страницы секунд так до 10-15. Это не есть хорошо, ага, особенно если учесть что нормальный пользователь шлёт сайт в пеший сексуальный поход после 4-5 секунд загрузки. Если обобщить, то есть несколько вариантов как улучшить ситуацию:

Читать далее Оптимизация WordPress, W3 Total Cache и иже с ней