Интернет-магазин: ускоряем загрузку - Oborot.ru
Подписка
Вестник электронной коммерции
Е-коммерция для занятых и ленивых
Интернет магазин. Пособие для директора
Дизайн и usability интернет-магазинов 
Поиск
На сайте (с учетом раздела)
В форуме
 
Гостям
Экспонентам
Регистрация
 

Тематический рубрикатор
Открытие бизнеса
 Бизнес-планированиеБизнес-планирование - форум
 Привлечение инвестицийПривлечение инвестиций - форум
 Название и регистрацияНазвание и регистрация - форум
 Создание сайтаСоздание сайта - форум
 ХостингХостинг - форум
 Первые шагиПервые шаги в электронной коммерции - форум

Привлечение клиентов
 Поисковики и сбытовая рекламаПоисковое продвижение и сбытовая реклама - форум
 Имиджевая рекламаИмиджевая реклама - форум
 Public RelationsPublic Relations - форум
 Нестандартные методы раскруткиНестандартные методы раскрутки - форум
 Эффективность рекламыЭффективность рекламы - форум

Удержание клиентов
 Дизайн и usabilityДизайн и usability - форум
 КонтентКонтент - форум
 CRM и взаимоотношения с клиентамиCRM и взаимоотношения с клиентами - форум

Ведение бизнеса
 АвтоматизацияАвтоматизация - форум
 Бухгалтерия и налогообложениеБухгалтерия и налогообложение электронной коммерции - форум
 БезопасностьБезопасность - форум
 Доставка и логистикаДоставка и логистика - форум
 Обучение и управление персоналомОбучение и управление персоналом - форум
 Общий менеджментОбщий менеджмент - форум
 Платежные системыПлатежные системы - форум
 Управление ассортиментомУправление ассортиментом - форум
 Юридические вопросыЮридические вопросы - форум

Тенденции развития
 Российские тенденцииРоссийские тенденции - форум


Главная  >> Удержание клиентов >> 
Читайте также | Ваш комментарий
25.11.14 

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

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

Алексей Гальченко, Виктор Подгорский, РА МедиаНация

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

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

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

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

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

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

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

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

 

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

 

Платформа

1С Битрикс "Бизнес"

OC

FreeBSD 9

веб-сервер

nginx 1.4

fastCGI-бэкенд

php-fpm, php 5

кэшер опкода

pecl-APC

база данных

MySql 5.6 (Percona Server 5.6)

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

 

Полное время загрузки документа

 

8.2 с

Полный размер загружаемой страницы сайта (при первой загрузке в браузере)

 

1,956 Кб

Визуальное время загрузки (от начала загрузки до завершения domContentLoaded)

4,286 c

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

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

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

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

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

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

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

Также необходимо минимизировать объем файлов стилей (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 и веб-сервера, а также об автоматическом перезапуске бэкенда и некоторых служб при превышении пороговых значений загрузки процессора и расхода оперативной памяти.

 

Полное время загрузки документа

6,6 с

быстрее на 19,5%

Полный размер загружаемой страницы сайта

1,547 Кб

меньше на 20,9%

Визуальное время загрузки

1,443 с

быстрее на 66,3%

 

Итог

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

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

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

Интересно? Поделись:


Читайте также
10 убийц конверсии: что раздражает покупателей в интернет-магазинах
"Мобильный" сайт как ключ к высокой конверсии
Чек-лист: 9 неочевидных причин снижения конверсии интернет-магазина
Что раздражает вашего покупателя? Часть 2. Выбор способа оплаты и доставки
Юзабилити-экспертиза: выпуск №10

Комментарии читателей
25.11.14 20:21
Иван

У битрикса в администрировании есть прекрасная панелька производительности. И раздел БД. Про нее, часто суппорт битрикса не в курсе.


27.11.14 18:10
Kaavain
http://www.trafaret.net

Все это хорошо, но статья из раздела "вредные советы". Так как они в 90% случаев приведут к неработоспособности сайта в одном или нескольких браузерах или их версиях. Если делать такое ускорение самостоятельно, то обязательно еще и следующее:

1. Установить у себя все возможные версии браузеров.

2. Приобрести как минимум айфон и простенький андроидный телефон.

3. Установить у себя виртуальную машину с Виндой ХР

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

Если читающий эти строки и желающий "ускорить" себе сайт на все перечисленные пункты не готов, то лучше не трогать рабочий сайт.

Конечно, если страница грузится 10 секунд то тут уже ни чем не навредишь. Но если в пределах 1 или даже 3 секунд - опасно трогать.

Устриц ел.


29.11.14 00:19
VIVO
http://ru.zakvaski.com/

Спасибо за статью, но мне кажется для большинства проектов достаточно рекомендаций page speed


30.11.14 18:17
Антон

Ну да, фигня какая) Любой справится)


30.11.14 21:20
Kaavain
http://www.trafaret.net

"достаточно рекомендаций page speed" ага, чтобы убить сайт - в самый раз. У мен недавно так тоже да, сделал я скрипты асинхронными по рекомендации гугла...


01.12.14 15:34
Алексей
http://medianation.ru

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


02.12.14 12:54
Kaavain
http://www.trafaret.net

"все настройки и рекомендации должны выполняться специалистом" на специалистов может не хватить денег. Или у специалистов - времени. При должной аккуратности можно и нужно самому разобраться как живет сайт и вносить улучшения самостоятельно. Я пока не открыл ИМ вообще не знал ,что такое интернет... Но быстро понял ,что желающих меня постричь налысо, потом выпотрошить и вывесить сушиться гораздо больше, чем снится в кошмарном сне... Вот теперь я знаю что такое HTML, CSS, PHP, хотя по жизни так и остался в этом дубом.


03.12.14 16:56
Алексей
http://medianation.ru

<<на специалистов может не хватить денег. Или у специалистов - времени.>>

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

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

Но, повторюсь, рекомендации целесообразнее внедрять на тестовой машине, окружение которой содержит те же настройки, что и "боевая" машина


09.11.16 13:39
Гипермаркет туров
http://www.sletat.kz

Кстати, да наш сайт какой-то сеошник не мог вывести даже в топ50, а когда ускорили сайт у разработчика сайт стал подыматься и уже вверх на 10-15 позиций вышел, надеемся и дальше пойдет. Так что скорость гуглу точно нравится на сайтах.


24.01.17 12:26
© Oborot.ru 2001 - 2015

Сейчас 2017 на дворе


23.02.17 10:11
zaq_199

если деньги есть. то лучше не заморачиваться самим, а заказать у какого-нибудь аутсорсера, их и гонять потом можно и ответственность на них. Главное договор правильно создать, мой друг свой интернет-магазин реализовывал с помощью этой компании- http://itprof.ru/, Посмотрите, может подойдет


Ваш комментарий
Имя:*
E-mail:
Сайт:
Комментарий:*
→ введите буквы и цифры с изображения*. Все буквы - латинские (английские)
Поля, отмеченные *, обязательны для заполнения.
Наверх
Сделать стартовой Добавить в избранное
Новости электронной коммерции и торговли
13.02  Чем отличаются интернет-магазины в топе Google
29.11  АКИТ меняет команду "Черной пятницы" и "Киберпонедельника" (upd. Команда собирается оставить себе площадки realblackfriday.ru и cmonday.ru)
25.10  "Электронная торговля-2016" взяла новые планки качества и количества (2)
25.10  KupiVIP доработал дизайн
20.09  Подстроиться под любой экран
15.09  Что есть в программе "ЭТ-2016": краткий гид
01.09  "Умная кнопка" проникла в Европу



Форум
02:10 24.02 Артур Шевцов  Посмотрите, пожалуйста, сайт! Выскажите мнение. (9)
11:42 18.01 MasterOM  Оцените дизайн сайта оконной тематики (5)
11:04 16.01 serzh  Большой процент отказов (5)
22:26 01.01 roiplus  Оцените интернет-магазин светильников (4)
18:18 29.11 Майк Лермонтов  Оцените интернет магазин (4)
08:10 26.11 serzh  Оцените интернет магазин мебели (4)
14:39 21.11 e_v_medvedev  Повышение конверсии, критика сайта и советы (17)
21:42 16.11 kaavain  Ребят, посмотрите пожалуйста интернет магазин (3)
23:11 25.10 Василий Мигович  Оцените, пожалуйста, юзабилити сайта (2)
05:21 24.10 2metrics  Оцените новый интернет-магазин Кроссовок (11)


Статьи и аналитика
16.02  Топ-6 профессиональных ecommerce-мероприятий года
01.12  Как россияне ищут и покупают стройматериалы в онлайне (2)
29.08  10 убийц конверсии: что раздражает покупателей в интернет-магазинах (2)
17.08  Как "убить" платежную конверсию на своем сайте (3)
16.08  7 проверенных способов завоевать доверие покупателя
11.08  На что обратить внимание при создании или доработке сайта (3)
19.07  7 правил успешной распродажи: как подготовить сайт
24.05  "Уличная магия" для интернет-магазина: что мы сами пойдем смотреть на ECOM Expo`16
04.05  "Мобильный" сайт как ключ к высокой конверсии (2)
14.03  Чек-лист: 9 неочевидных причин снижения конверсии интернет-магазина (4)




Зарегистрированным пользователям |  Реклама на сайте |  ECOM Expo |  О проекте
Главная |  Все новости |  Все статьи | Форум
Rambler's Top100 Рейтинг@Mail.ru rax.ru: показано число хитов за 24 часа, посетителей за 24 часа и за сегодня
© Oborot.ru 2001 - 2015. Корреспонденцию присылайте на info@oborot.ru. Адрес для новостей и пресс-релизов: news@oborot.ru.