— График
— Почему так?
— Как быть?
— Состав скорости «открывания» страниц сайта
— Время загрузки страницы в броузер
— Время генерации страницы
— Статическое кэширование в UMI CMS
На графике — реальный пример использования этого метода для ускорения магазина с 2500 товаров, с большими и разными между собой наборами характеристик (~50). Скачок вверх оранжевой линии — переход с тарифа 201 nic.ru на тариф 301, с бОльшим объемом доступной памяти. Снижение синей линии нагрузки после 22 апреля — это перевод каталога на узкоспециальный код на основе нового официального API, с индивидуально разработанным кэшированием. Чистота эксперимента соблюдена: установка nginx не проводилась, изменений настроек сервера не было.
Простой путь ускорить работу каталога из многих тысяч сложных товаров — заменить большой универсальный модуль общего назначения коротким и быстрым кодом, специально сделанным для этой конкретной задачи.
В довершение — собирать сложные элементы страниц и целые страницы один раз, и выдавать потом из кэша многократно. Простой рецепт, который делает сайт «моментальным». Даже на дешевом хостинге.
Новорожденный интернет-магазин обычно работает быстро. Товаров (и, соответственно, страниц) очень мало, посещаемости нет, и обрасти довесками типа аукциона, «похожих товаров» или «случайных спецпредложений» он обычно ещё не успел. Нагрузка на хостинг маленькая, и все летает и так. Однако со временем страницы открываются все тяжелее, и вот уже некоторые посетители не дожидаются, когда откроется найденная поисковиком страница, и закрывают окно броузера.
Почему так?
Первоначальная причина простая, экономическая: большой сложный каталог товаров обычно требует особого подхода, индивидуального программирования. А при старте интернет-магазина на малых бюджетах студии делают каталог на стандартном универсальном модуле, без учета трудоемких индивидуальных особенностей. Это позволяет достичь рентабельности. На первых порах это нормально.
Потом товаров становится много, появляются классификаторы и сортировки, дополнительные свойства у каждого товара, и тому подобные усложения. В результате для выдачи страницы каталога движку (CMS сайта) приходится собирать и сортировать очень много информации. Не просто показать все товары в подгруппе, а, например, выдать товары из нескольких категорий, имеющие такие-то характеристики, и при этом показать, какие ещё есть характеристики и какие им соответствуют подгруппы. И какие спецпредложения по аналогичным товарам есть. И желательно в порядке популярности товаров у покупателей на основе данных за последние две недели. Если товаров тысячи, то построение такой страницы каталога — это уже задача не на одну секунду даже для быстрого хостинга. Теперь умножим это на число страниц каталога — их сотни, да ещё на число обращений к этим страницам — с учетом поисковиков это десятки тысяч, и вот у нас уже сервер завален работой. Недорогой шаред давно не справляется. Переезжают на собственный сервер помощнее, но и он уже еле успевает.
Как быть?
Кто-то пробует аренду отдельного сервера под базу данных, переезд на PostgreSQL, или отказ от PHP в пользу местами более быстрой, но весьма дорогой в разработке платформы ASP.NET. Многим это помогает отсрочить решение проблемы, но очень дорогой ценой.
А из чего вообще состоит скорость «открывания» страниц сайта?
1. Время загрузки страницы в броузер посетителя и отображение в нем.
2. Время генерации страницы. Это за сколько секунд движок сайта (cms) подготавливает страницу, собрав все товары и их данные, которые надо отобразить, и сделав из них html-документ, который Вы видите, нажав Ctrl+U в броузере. Обычно только после того, как страница полностью сформирована, она начинает отдаваться в броузер, и идет загрузка. То есть время генерации — это та пауза, которая идет перед началом загрузки страницы.
Есть и другие компоненты, но их влияние незначительно.
Время загрузки страницы в броузер
По второму пункту резервы ускорения небольшие. Самый быстрый (и дорогой) сервер + быстрая в отображении верстка + оптимизированные картинки, — в итоге всего в два раза лучше по этому показателю, чем средний сайт на среднем хостинге. Если страница огромная, на ней множество картинок товаров и прочей информации, то она будет все равно загружаться не сразу, особенно у тех, кто на мобильном интернете. А делать поменьше товаров на странице владельцы магазинов обычно не хотят.
Если у веб-сервера apache подгружаются неиспользуемые модули, небольшое ускорение работы интернет-магазина возможно за счет их отключения.
Разумеется, есть смысл ставить nginx — это даст 20-30% ускорения загрузки. А то и больше, если причиной тормозов была, прежде всего, нехватка памяти на хостинге. У многих хостеров и так он установлен, в варианте фронтэнда к apache.
Из популярных CMS практически все имеют возможность работать c конфигурацией nginx frontend + apache backend без дополнительной доработки движка. То есть это дешевый путь. Типовая работа, выполняемая любым системным администратором за сумму около 3 тысяч рублей. Исключение — сайтовый и форумный движок VBulletin Publishing suite версии 4 и выше, он требует модификации, из коробки с nginx работать не хочет. В этом случае есть работа не только для сисадмина, но и существенная работа для программиста.
Ещё более быстрая и экономная по использованию памяти конфигурация — это nginx + php-cgi. Тут для любого сайта с чпу нужна модификация cms или воссоздание ЧПУ в nginx, это часто трудоемкая задача — требует опытного программиста, и при этом иногда возможны перебои в работе сайта. Правда, для некоторых распространенных движков есть готовые конфигурации — шанс переехать на nginx почти даром.
Разумеется, надо упомянуть такие методы ускорения серверов, как хранение базы данных в памяти и хранение картинок и файлов на ssd.
Современные сервера могут хранить в оперативной памяти даже базу из миллиона товаров, что сводит на нет необходимость в выделенном сервере баз данных.
Увеличить время «открывания» страниц во много раз по этому пути не получится, максимум в полтора-два раза.
Время генерации страницы
Вот здесь действительно есть смысл поработать, ведь скорость генерации можно увеличить иногда в сотни раз!
Прежде всего, есть смысл создать тестовую страницу, с типичным для этого сайта «медленным» содержимым. И экспериментировать с ней, удаляя разные блоки и замеряя среднее время создания страницы. Таким образом можно выяснить, на что тратится время.
Если все сделано по стандартной схеме, то сервер тратит много времени, выполняя одну и ту же работу. Например, для отображения большого ветвистого меню собирает все категории и подкатегории каталога и потом выдает их. Логично, что он мог бы собирать их один раз и сохранять в файле или в памяти (tmp fs, memcached). Главное в этом случае сделать надежный механизм обновления этого кэша, чтобы он удалялся, или в идеале — пересоздавался при редактировании тех или иных страниц, которые влияют на пункты меню (например, корневые страницы разделов сайта).
Одновременно стоит попробовать заменить код найденных «тяжелых» элементов на более простой и быстрый. Дело в том, что код стандартных модулей у современных движков реализует разнообразные функции, которые у вас могут не использоваться, а только тратить время. Оставьте только реально используемые сайтом функции. В некоторых случаях есть готовые решения на этот случай — например, у UMI CMS есть альтернативный партнерский модуль каталога, который подходит как раз в случае интернет-магазина с десятками тысяч товаров.
Ещё один фокус для ускорения интернет-магазина: вынести не критичный для SEO тяжелый контент в ajax. Очень быстро загружается основная страница, а на ней бегунок, и через пару секунд подгружаются результаты поиска по сайту или иное содержимое, которое в данном конкретном движке категорически невозможно ускорить. Поскольку результаты поиска все равно, как правило, закрыты от индексации, это приемлемо для продвижения. Пользователи не любят белый экран, они считают, что сайт завис. А вот смотреть на бегунок они могут даже десяток секунд, лишь бы он был красивый, в идеале показывал прогресс в процентах, если находится на экране больше трех секунд.
Отличная вещь — сортировка товаров прямо на странице, без её перезагрузки. Если на какой-то странице отображаются все товары нужной категории, то их сортировка по цене, типу и другим характеристикам может проводиться моментально прямо в броузере посетителя, вообще без обновления страницы или каких-либо ajax-бегунков загрузки. Минус только в том, что некоторые люди не понимают, что сортировка произошла. Кликают «сортировать по размеру», и ждут привычного перехода на другую страницу. В таких случаях есть смысл на секунду вывешивать бутафорский бегунок. В плане продвижения такая сортировка тоже приемлема, так как изначально подгруженные на страницу товары сделаны в обычном html и замечательно индексируются. Такой путь даже лучше, поскольку нет множества ненавидимых сеошниками дублей — каталожных страниц с одинаковыми товарами, отличающихся только порядком сортировки.
Правильно используемый ajax и сортировка товаров на странице — это всегда индивидуально разрабатываемый функционал, потому что пока ни у одного из популярных сайтовых движков нет таких функций. Но оно того стоит. Когда сайт моментально реагирует на действия посетителя — это улучшает впечатление, людям нравится.
Вообще проблема скорости и требовательности к хостинговым ресурсам у современных движков отлично известна производителям cms, и они работают над этим. У обоих крупнейших игроков российского рынка — Битрикс и UMI — имеются достойные кэширующие механизмы. Главное, их правильно задействовать. Часто бывает так: включают кэш, замечают проблемы. Не обновляются те или иные страницы, неправильно работают формы обратной связи или корзина. И выключают кэш. А всего-то надо было прописать исключения из кэширования, чтобы страницы определенного типа не затрагивались. И это ускорило бы сайт в разы, и сэкономило бы большие деньги, и добавило бы довольных посетителей.
Конечно, только на кэш полагаться тоже не метод. Особенно потому, что обычно создание кэша возложено на посетителей. То есть схема такая: обнулили вы кэш, и пока страницу кто-то не посетил, заготовки этой страницы нет. У первого посетителя страница строится и открывается долго, а потом уже сохраняется в кэше и отдается моментально. Но вот этот первый-то посетитель тоже важен. Вот почему мы в «Крафтворке» используем в таких случаях обновление кэша специальным роботом. Более трудоемкий, но качественный путь. Есть и другие детали, из-за которых иногда целесообразоно заменить общие кэширующие механизмы узкоспециальными, разработанными для конкретного интернет-магазина.
Тут следует в очередной раз сказать доброе слово о созданном уже более года назад механизме статического кэширования в UMI CMS (не обычный статический кэш, а тот, что под nginx). За счет того что он создает не заготовки, а готовые html страницы, время генерации просто вообще равно 0. Без преувеличений: страницы не создаются, они все уже есть. Подобные методы используют поисковики и другие гиганты. Вдобавок раздача таких страниц средствами nginx ускоряет интернет-магазин до удивительных высот, так что у некоторых с собственного жесткого диска файлы не так быстро открываются, как такой сайт. Даже небольшой DDOS может остаться незамеченным благодаря такой скорости.
Гугл, с которого весь интернет берет пример, давно озаботился скоростью сайтов. Измеряет её, показывает в счетчике Гугл-Аналитикс и открыто заявляет, что скорость влияет на ранжирование. То есть чем быстрее сайт открывается, тем больше посетителей получает от Гугла. И тем больше посетителей становятся покупателями, потому что им нравится быстрый сайт.
