Интернет-магазин: ускоряем загрузку

Разговор в этой статье пойдет не столько о настройках сайта как такового, сколько о настройках окружения, в котором сайт работает – сервера, хостинга и т. д. То есть о тех настройках, изменение которых требует относительно небольших временных и финансовых затрат. В большинстве случаев, для этого не нужно менять код веб-приложения (сайта), а значит, и привлекать разрабочиков.

И каждая из этих настроек важна для интернет-магазина, так как влияет на ранжирование, либо конверсию, либо и на то и на другое.

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

Скорость загрузки сайтов – критически важный фактор. Считается, что психологически комфортное время отклика любой системы, с которой взаимодействует человек, в том числе и сайта – 1-2 секунды. По мнению Google, оптимальная скорость – не более 1.5 секунд. По некоторым данным, при снижении скорости полной загрузки сайта с 5 до 25 секунд конверсия снижается в 2 раза. Кроме того, скорость загрузки сайта влияет на его ранжирование в поисковиках. Если точнее, на позиции в выдаче влияет время от отправки запроса веб-сервера до начала видимой пользователю загрузки сайта, время загрузки первого байта (TFFB, timeforfirstbyte).

Доступность сайта – удельное время недоступности или сбоев в работе сайта в единицу времени (в месяц, в год). Понятно, что недоступность сайта или его некорректная работа сразу сказывается на конверсии.

Время загрузки сайта состоит из двух частей:

1) времени получения ответа от сервера и выполнения кода на сервере,

2)  времени загрузки сайта на клиенте (в браузере). Обычно оно составляет от половины до 90 процентов от полного времени загрузки сайта.

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

Более детально:

Перед оптимизацией сайта мы проверили настройки ядра операционной системы, настройки веб-сервера и php-fpm, логи веб-сервера и php-fpm на предмет наличия ошибок,.

Исходная ситуация

Нестабилен php-fpm, более половины дочерних процессов завершаются с segmentationfault, опкод фактически не кэшируется (хитрейт кэша – около 20%). Высок процент медленных запросов к базе данных и запросов с плохими индексами. На веб-сервере  не настроена до конца буферизация вывода, не включено gzip сжатие для статических файлов, файлы отдаются синхронно, оптимизация отдаваемых файлов не проводилась, кэширование ответов бэкенда недостаточно эффективно.

Чтобы  сократить время загрузки, нужно:

1. Уменьшить объем загружаемого контента

Для этого достаточно включить на веб-сервере сжатие http-ответа на лету, а также сжатие на лету отдаваемых статических файлов.

Кроме того, можно оптимизировать размер используемых на сайте изображений, используя специальные утилиты (YUI Compressor, OptiPNG и другие).

Также необходимо минимизировать объем файлов стилей (css) и javascript. При большом числе подключаемых файлов рекомендуется их склеивать для уменьшения количества http-запросов, создаваемых страницей сайта, а также использовать css-спрайты. Автоматическая генерация css-спрайтов – задача трудоемкая, и без изменения верстки (а значит, привлечения верстальщика) обычно не осуществима. А вот для склейки и сжатия файлов можно воспользоваться специальными утилитами или модулями для веб-серверов.

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

Однако, если js-файлы обеспечивают работу корзины в ИМ, разумно подключать их вверху страницы, чтобы и при неполной загрузке страницы корзина оставалась работоспособной.

2. Увеличить скорость загрузки контента.

            Для этого можно:

• включить асинхронную отдачу статических файлов на веб-сервере, если такая возможность доступна;
• кэшировать наиболее часто используемые статические файлы в оперативной памяти (скорость доступа к оперативной памяти на 1-2 порядка быстрее скорости доступа к жесткому диску);
• использовать для хранения большого количества статических файлов быстрые жесткие диски (ssd);
• использовать двухуровневую архитектуру фронтенд-бэкенд (в ней в качестве фронтенда выступает легкий веб-сервер (nginx, lightty), который отдает статические файлы и проксирует запросы, требующие выполнения программного кода, на бэкенд, а в качестве бэкенда – fastCGI-враппер или другой веб-сервер, на котором выполняется программный код сайта).

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

Причин долгого выполнения серверной части сайта может быть много. Помимо собственно выполнения кода на сервере, много времени занимает определение адреса по доменному имени сайта. Это можно изменить, уменьшив время доступа к DNS-серверу (если используется свой) или сменив провайдера DNS на другого, дающего меньшее время отклика.

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

Для уменьшения времени ответа сайта без изменения его кода необходимо хорошо настроить кэширование.

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

Также можно (и, как правило, очень эффективно) включать кэширование псевдокода, генерируемого интерпретатором для виртуальной машины, при использовании интерпретируемых языков программирования (для PHP – AlternativePHPCache, ZendOpcachePlus).

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

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

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

Как мы оптимизировали тестовый сайт

После проверки была обновлена минорная версия php для применения ряда исправлений, связанных с работой php-fpm.

Увеличен объем кэша опкода и минимальный размер кэшируемых файлов (что привело к повышению hit-rate до 90%). На веб-сервере было включено сжатие статических файлов (модуль nginx gzip_static), оптимизация на лету изображений (модуль image_filter), асинхронная отдача файлов (aio on;). Включено и настроено кэширование оптимизированных изображений (чтобы избежать заметного повышения нагрузки на процессор от постоянной оптимизации изображений на лету).

Отстроено кэширование ответов php-бэкенда, включена и настроена буферизация вывода. Кроме того, после анализа лога медленных запросов к базе данных для уменьшения их числа были изменены настройки кэша запросов (query cache) базы данных, изменен порог попадания файлов в него, увеличен кэш для выполнения join запросов. В php-fpm было также настроено ограничение максимального времени выполнения запросов к бэкенду, автоматический перезапуск дочерних процессов после выполнения около 1000 запросов, автоматический перезапуск бэкенда при отказе более половины дочерних процессов (чтобы избежать проблем в работе сайтов при возникновении в них segmentation fault).

Кроме того с помощью лога медленных запросов к FastCGI и бэкенду с автоматической трассировкой выполнения таких скриптов были выявлены "узкие места", создававшие проблемы в работе сайта. Данные о них мы передали разработчикам. Также мы настроили сервис Monit. Это система мониторинга, имеющая открытый исходный код. Monit устанавливается на сервер и при возникновении проблем отправляет уведомления администратору о перезапуске php-fpm и веб-сервера, а также об автоматическом перезапуске бэкенда и некоторых служб при превышении пороговых значений загрузки процессора и расхода оперативной памяти.

Итог

Полный размер загружаемой страницы и полное время загрузки документа уменьшились несущественно – из-за наличия на сайте двух больших изображений размером 0,45 Кб каждое, для которых полное время загрузки составляет 3,5 секунды.

Без учета их загрузки экономия трафика составила 38,7% по сравнению с исходной конфигурацией. Полное время загрузки страницы уменьшилось на 34% по сравнению с исходной конфигурацией. Время отклика страницы уменьшилось примерно в 3 раза и стало вписываться в психологически комфортные для пользователя 2-3 секунды.

Авторы:  Алексей Гальченко – технический директор, руководитель отдела разработки РА "МедиаНация",  Виктор Подгорский – системный администратор РА "МедиаНация".