Шпаргалка по оптимизации производительности сайта

  1. Провести замеры текущих показателей, чтобы сравнить исходные данные с результатами после внесения изменений
  2. Получить информацию о том, что занимает время при генерации страницы. Для этого следует использовать либо встроенные в CMS возможности , сторонние/внешние инструменты, либо придется написать их самостоятельно для для этой задачи.
  3. В целях экономии времени, следует попробовать найти те боттлнеки(bottleneck, бутылочное горлышко, узкие места производительности), устранение которых даст максимальный результат при как можно меньших трудозатратах. Например, если есть блок меню каталога, который генерится долго, но редко меняется, его можно обернуть в кеш, тем самым оперативно и значительно сократив нагрузку на сайт.
  4. На основе данные анализа нагрузки найти неиспользуемые возможности, которые создают нагрузку. Это могут быть модули или фичи CMS, которые включены по-умолчанию, но ни кем не используются. Такой фичей может оказаться модуль внутренней статистики CMS, которым никто никогда не пользовался, а нагрузка, которую он создает хорошо заметна под нагрузкой и место в БД отъедает порядочно, что увеличивает ресурсные аппетиты БД и размер слепка БД при бекапах.
  5. Проверить запросы отправляемые браузером серверу на основных типах страниц сайта. Часто из-за ошибки в JavaScript-коде, браузер отправляет лишние Ajax-запросы серверу, создавая дополнительную нагрузку.
  6. Проверить запросы, отправляемые браузером к серверу на предмет 404-ых ошибок. Например, если шаблон или контент страницы указывает на несуществующую картинку, CMS в ответ будет отдавать полноценную страницу сайта, тратя время на генерацию всех блоков, только для того, чтобы сказать, что страница не найдена.
  7. Найти пачки однотипных запросов к БД, отправляемых за одно открытие страницы. Это может быть признаком формирования SQL-запросов в цикле. Характерно для страниц с листингом товаров. Следует переписать генерацию списка товаров, чтобы использовать 1 запрос, который включит в себя все необходимые данные или прибегнуть к кешированию. Стоит учесть, что в ключ кеша может потребоваться внести какие-то данные, например, группа покупателей или размер скидки. Если этого не сделать, то в кеш лягут товары с ценой для одной группы покупателей, а видеть их будут все.

Bonus level: инструменты для анализа нагрузки

  • New Relic: на мой взгляд, самый мощный инструмент для анализа нагрузки. Показывает наиболее нагружающие транзакции (URL), разбивку нагрузки на странице, с количеством запросов к таблицам, внешним источникам и так далее. Есть пробный период, в рамках которого пользователям показывается крайне детальная информация, с помощью которой можно очень быстро вылечить тормозной сайт.
  • Opbeat.com это аналогичный предыдущему инструмент, хотя он на много проще NR. Есть бесплатный тариф на 500 000 событий(просмотров страниц) в месяц. Подойдет тем у кого не большой трафик. Информации меньше чем в NR, но инструмент не раз помогал находить и устранять боттлнеки.

Let the performance be with you!

Как не надо проводить оптимизацию производительности сайта

За последние дни на просторах интернета удалось наткнуться на гору статей от «гуру» по оптимизации производительности сайтов.

Многое из того что было мной поочитано больше похоже на вредные советы оптимизатора.

Кое что так очень сильно меня возмутило и я решил перечислить эти ошибки здесь:

  1. Нельзя делить CSS/JS скрипты на отдельные файлы под каждый тип страницы. Сделайте один файл для JS и один для CSS, в котором есть всё что пригодится на всех страницах сайта. Такой подход даст возможность избежать повторных загрузок этих ресурсов на каждой странице – всё сразу одним куском будет загружено при первом открытии сайта.
  2. Старайтесь загружать с общедоступных сетей доставки контента (CDN) библиотеки и шрифты. Библиотеки вроде jQuery и шрифты с Google Fonts встречаются на разных сайтах и велика вероятность того, что при просмотре другого сайта, браузер посетителя уже скачал этот шрифт или эту библиотеку. Это значит, что на вашем сайте он уже не будет тратить время на загрузку этих файлов, так как они уже в кеше браузера. Если вы будете складывать эти ресурсы на своем сайте и заставлять браузеры посетителей качать их с вашего сервера, то это лишь увеличит время загрузки сайта.

Часть 3. Как маркетологи убивают производительность сайтов

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

Читать далее «Часть 3. Как маркетологи убивают производительность сайтов»

Часть 2. Какие бывают проблемы с производительностью универсальных коробочных CMS

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

Эти решения отлично работают на старте, пока магазин маленький.

Тут вам и красивые интерфейсы и удобные настройки, а всякие маркетинговые задачи на базовом уровне решаются установкой дополнения из магазина модулей выбранной CMS.

Однако, у всех этих красивостей и удобств есть цена, которую приходится платить, когда магазин развивается и растёт.

Читать далее «Часть 2. Какие бывают проблемы с производительностью универсальных коробочных CMS»

Часть 1. О производительности сайтов.

Проблемы с производительностью сайта рано или поздно начинают волновать почти всех.

За последние несколько лет, я постоянно занят на многих проектах, где вопрос производительности вообще никогда не снимается и постоянно контролируется.

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

Не существует одного подхода к решению задачи такого типа, который подошел бы всем сайтам, потому что причины разные.

Читать далее «Часть 1. О производительности сайтов.»

Набор программ для Web разработки на Android

Хочу рассказать о необычной задаче, которая встала передо мной, когда я уехал из дома на день и не взял с собой ноутбук.

Мне потребовалось быстро отреагировать на письмо от Sentry, сообщавшее об критической ошибке в продакшене.

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

Читать далее «Набор программ для Web разработки на Android»

Проверка на наличие ip адреса в SPF с помощью Python

Мне потребовалось быстрое решение, чтобы проверять может ли определенный IP адрес, отправлять письма с заданным email-адресом.

Быстрым решением оказалось проверка TXT записи у домена, и проверка наличия IP адреса в SPF.

Для работы функции, потребуется dnspython

Вот сама функция:

Пример вызова даной функции:

Ограничения

Это очень топорный способ. Он учитывает только прямое вхождения ip-адреса в SPF. Таким образом, этот способ не сработает в случае, если в SPF указана подсеть, а не конкретный IP адрес. Наверняка, есть еще масса интересных моментов, которые зарыты в стандартах SPF, которые мне для быстрого решения задачи изучать не требовалось. Тем кому нужен 100% надежный способ проверки SPF записей, придется искать более надежный способ.